3 ms·
I've flirted with Ada over the years. The clean--if somewhat verbose--syntax is appealing and the speed of compiled code is outstanding. That being said, Ada
by kingmanaz 14y ago
I've flirted with Ada over the years. The clean--if somewhat verbose--syntax is appealing and the speed of compiled code is outstanding.
That being said, Ada is not fun to program in. Ada is a perfect language for planners rather than experimenters given that the compiler checks are thorough and at times aggravating. It takes a bit of thinking before starting on any project with Ada, doubly so with SPARK.
Having said the above, while python may be fun to prototype with, I would feel much more comfortable if my airliner's avionics were written in Ada rather than Python, Ruby, or (God-forbid) Perl. Ada is a perfect fit for mission critical applications and that's why it has quietly been doing so well in the field for decades.
- JulianMorrison 14y agoI disagree it's not fun. Probably because type-led programming suits me well, I find it feels like sketching the problem into types and connecting them up with algorithm. When I say type-led, I mean the use of types to define the problem, and the use of language features that make code dependent on attributes of types. An approachable example of this in another language is Go's "range" operator, that automatically bounds loops to lists or ends them when a channel closes. Similar mechanisms are much more intricate and advanced in Ada.
- kingmanaz 14y agoThere is a case for Ada being a fun language to program in. Ada will likely appeal to those who enjoy organization. A fan of Ada will likely have a neatly-ordered garage, or if they do DBA work, they will be drawn to the elaborate and tidy typing which C.J. Date demonstrated in his Tutorial-D language. To reuse the garage analogy, simple types will likely appear to those naturally drawn to Ada as unboxed tools or unshelved parts. Personally I prefer C or Go's approach to typing, eg., use base types (int32, int64, string, etc.) as often as possible or practicable and keep the type hierarchy flat by avoiding multiple-inheritance. Using base types keeps things simple as is reflected in Go's documentation; when descending through documentation for types one can be confident that there is not far to go before hitting a base type. The object is understood. I do love Ada's use of the range operator (".."), as with it one can simply create 1-based domains and thereby avoid C's omnipresent 0-based domains.
- JulianMorrison 14y agoBase types are just CPU operand categories, it's convenient for the CPU to process numbers in 8/16/32/64/128 bit representations, but those only crudely approximate the domain of a function. It's just nicer to be able to statically say "the volume knob is a real-valued number in the closed interval [0, 11] represented as 32 bit floating point" and have the compiler complain if you even could accidentally assign it the floating point representations of -1 or 12 (which are legal in the CPU type but out of domain for all volume functions).
- draegtun 14y agoIt's probably God forbid any scripting language in this situation. However if forced I would much prefer Perl over Python or Ruby because Perl catches far more errors at compile time.