Ada? Surely you jest Mr. Pythonman
The past couple weeks I’ve been spending my BART commutes learning the Ada programming language. Prior to starting to research Ada, I sat in my office frustrated with Python for my free time hackery. Don’t get me wrong, I love the Python language, I have enjoyed the ease of use, dynamic model, rapid prototyping and expressiveness of the Python language, I just fall into slumps occasionally where some of Python’s “quirks” utterly infuriating. Quirks such as its loosey-goosey type system (which I admittedly take advantage of often), lack of good concurrency in the language, import subsystem which has driven lesser men mad and its difficulty in scaling organically for larger projects (I’ve not yet seen a large Python codebase that hasn’t been borderline “clusterfuck”.)
Before you whip out the COBOL and Fortran jokes, I’d like to let it known up front that Ada is a modern language (as I mentioned on reddit, the first Ada specification was in 1983, 11 years after C debuted, and almost 30 years after COBOL and Fortran were designed). It was most recently updated with the “Ada 2005” revision and supports a lot of the concepts one expects from modern programming languages. For me, Ada has two strong-points that I find attractive: extra-strong typing and built-in concurrency.
Incredibly strong typing
The typing in Ada is unlike anything I’ve ever worked with before, coming from
a C-inspired languages background. Whereas one might use the plus sign operator
in Python to add an
int and a
float together without an issue, in Ada
there’s literally zero auto-casting (as far as I’ve learned) between types.
To the inexperienced user (read: me) this might seem annoying at first, but
it’s fundamental to Ada’s underlying philosophy of “no assumptions.” If you’re
Integer into a procedure that expects a
Float, there will be no
casting, the statement will error at compile time.
Unlike C, Java, Objective-C and Python (languages I’ve used before), Ada has concurrency defined as part of the language, as opposed to an abstraction on top of an OS level library (pthreads). In Ada this concept is called “tasking” which allows for building easily concurrent applications. Unlike OS level bindings built on top of pthreads (for example) Ada provides built in mechanisms for communicating between “tasks” called “rendezvous” along with scheduling primitives.
Being able to define a “task” as this concurrent execution unit that uses this rendezvous feature to provide “entries” to communicate with it is something I still haven’t wrapped my head around to be honest. The idea of a language where concurrency is a core component is so new to me I’m not sure how much I can do with it.
For my first “big” project with Ada, I’ve been tinkering with a memcached client in Ada which will give me the opportunity to learn some Ada fundamentals before I step on to bigger projects. Disregarding the condescending jeers from other programmers who one could classify as “leet Django haxxorz”, I’ve been enjoying the experience of learning a new vastly different language than one that I’ve tried before.
So stop picking on me you big meanies :(