3 ms·
Ada is not widely used in OSS, but it remains widely used in industry. It is generally not chosen for new projects because of the lack of developers, but I alwa
by webreac 14y ago
Ada is not widely used in OSS, but it remains widely used in industry. It is generally not chosen for new projects because of the lack of developers, but I always ear positive feedback on Ada. The latest ones were about migration (from redhat 5.8 to redhat 6.0 and from Ada95 to Ada2005). 90% of the migration workload was in C++, almost nothing for Ada and Java. Ada is more than 50% of the application (many 10s of million lines).
When multitasking and/or reliability are required, Ada is present in most legacy systems.
- pjmlp 14y agoSince GNAT became available it seems Ada usage is being on the rise. At least in Europe there are a few universities now teaching it.
- webreac 14y agoAda was the main language at my school (I graduated in 1993), they have changed a few years latter (for Caml or OCaml AFAIK). I do not think that Gnat has increased the usage of Ada. Before Gnat, there was an army of salespeople selling very expensive compilers. After Gnat, they have switched to other expensive technologies (for example SNiFF+, Weblogic, ...) not related to Ada. It is too sad that this looks like a lost battle. Ada is so superior to C++.
- pjmlp 14y agoI may be wrong, that was my feeling due to the increase in Ada exposure at FOSDEM, Ada has become one of the standard language tracks in the last years. The opening talk in 2012 was done by Ada Core.
- kingmanaz 14y agoI'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).