Advent^2 of Code continued |
|
Navigation» About » GitHub Mottek Blog» Mottek » Archive 2023 2022 2020 2019 2018 2016 2015 2014 2013 2012 2011 2010 2009 2008 2007 2006 2005 2004 2003 Search |
Advent^2 of Code continuedIn the earlier post about a spiced up Advent of Code challenge, I wrote about interfacing with the Apple Newton MessagePads as a nice all around task for learning and test driving programming languages. Back in the days, Apple provided the Desktop Integration Libraries for Classic MacOS and Windows to synchronize data between desktop and MessagePad computers. After the Newton’s cancellation, Paul Guyot, Michael Vacík and Nicolas Zinovieff set out to implement a full replacement, and adding more functionality, as well as covering also POSIX platforms in the form of the DCL. RubyThe DCL unfortunately does not support Windows natively, so I set out to see how something similar can be created using Ruby, resulting in the RDCL. Ruby turned out to be quite pleasant to work with, but one challenge back then was how to install a Ruby-based application, I never found the time to improve the user experience to a simple “step 1: download the app, step 2: sync with the Newton, … there is no step 3”. I revisited the RDCL recently to check out how Ruby has progressed, and was very impressed with the
GoOne programming language which early on got the distribution problem right is Go. Applications are single files, and can be very easily cross compiled. I implemented the most interesting parts of interfacing with a Newton in the GDCL: Encoding and decoding of NSOF data, and the Dante protocol with package installation. Go is a very pragmatic language, not overly clever or elegant, almost boring, but it does get the job done. The module system is a bit confusing, and generics are something I would still like to explore. Overall, Go looks like a solid choice for implementing at least a command line utility to interface with the Newton. ZigI came across the Zig programming language looking for an improved C
with cross compilation capabilities, and it fully delivered on that. Having worked for a while on
more high level languages like TypeScript, Scala or OCaml, it took a bit to get back to a more
low level approach (e.g. manual memory management or no asynchronous support, at least yet), but
it feels just right in many ways. For me, the most compelling feature is I got quite far with a tool to interface with the Newton, aptly called zdcl.
The development experience was very nice, and I think Zig has a bright future ahead. The 1.0 release
for Zig is still a while out, and there frequent changes to the language, the standard library and the
build system, thus I put Another change which will definitely have an impact is the switch away from LLVM. This is not so
much a problem for ClojureIn the area of cross-platform programming languages, the JVM and Node are two very interesting foundations, as both are designed from the beginning to support multiple platforms. With Clojure, it is possible to target both (either as Clojure or ClojureScript), and I started the lower level Dante protocol implementation in both Clojure and ClojureScript. REPL based development in Clojure is a really interesting experience, where code and test are iteratively implemented, and development switches back and forth between bottom up and top down. And the focus on getting your data right and letting functions transform it fits the problem space very well. JVM and Node based implementations still have the same issue as Ruby has, the runtime environment needs to be installed, or packaged with the application. The single executable approach of Go or Zig remains simpler for distribution and installation. Other CandidatesI experimented with OCaml, which I really like as a general purpose functional programming language. It seems to fit the problem well, but unfortunately, targetting Windows is not yet completely straightforward. I also started to look into C++ again, which has gone through some very fundamental changes since the original DCL was implemented. It does not direcly solve the cross platform issue, but has gotten otherwise much better in incorporating more modern programming styles. It is probably nowadays one of the more straightforward candidates for a DCL upgrade or replacement, and might be worth a second look, same as Go. 2023-08-14
|