Comment by nickpsecurity | Hacker News Reader

Comment by nickpsecurity | Hacker News Reader

Parent Full thread

Good article. It was indeed too far ahead of its time. That's despite compelling benefits in the field it's designed for:

http://www.adacore.com/knowledge/technical-papers/safe-secur...

Interestingly, languages such as Rust are still trying to accomplish the combination of efficiency and performance Ada has been doing for decades. Meanwhile, Ada developers (esp at AdaCore) haven't stood still: Design by Contract, provable absence of certain errors in SPARK code, more programming in the large support, zero-runtime deployment options, web app support, separation kernel runtimes for highest security, and more.

So, it might be a verbose, old language. It might not support the latest 1,000 fads in IT. Yet, here is a language designed in the 80's that does what modern systems languages are attempting to do, does it well, and has great tool support. So, I'd say the case for using Ada is long-made and companies doing mission-critical software have plenty reason to try to use it. Just try a project or two to see its benefits, at the least.

I have to add that verbosity serves a purpose here. Programming in the large often means those systems are long-living and the teams programming and maintaining them are huge, heterogeneous (in skill), and changing (esp. if it's a system running for decades). The verbosity comes from making many things pretty explicit and clear.

Ada is not made for explorative hacking or intellectual workouts but for reliable implementation. And it's not that those who criticize its verbosity program in APL themselves. ;)

> Programming in the large often means those systems are long-living and the teams programming and maintaining them are huge, heterogeneous (in skill), and changing (esp. if it's a system running for decades). The verbosity comes from making many things pretty explicit and clear.

I would say that this is the rule, rather than the exception, in software, and the fact that languages designed for "explorative hacking or intellectual workouts" eventually make it into production is simply a matter of inexperienced, though bright, developers prioritizing initial development cost over maintenance cost (which makes sense in startups, but those are a tiny minority of the industry). The average production codebase lifespan is about a decade, probably more.

I also agree that verbosity (up to a reasonable point) assists in maintaining codebases over time.

It might get verbose, but that's not what strikes me when I look at:

http://goanna.cs.rmit.edu.au/~dale/ada/aln/2_sample_programs...

Which I recently came across looking for some simple Ada examples. It's verbose in the sense that there are fewer shortcuts -- you can't just read bytes, assume they convert to integers, and be done with it -- but in production you don't really want that anyway. Of course, doing what you should, rather than doing what you can get away with, will mean that when an engineer says "one week", and you multiply with two, for actual time of "two weeks" -- you'll have to multiply that again, for actual-for-reals, interface-actually-covers-the-bare-bones-we-need, of "four weeks"...

@jk4930, e12e I agree with both of you for the reasons for much of its verbosity and justification for that. One thing you two might have missed, in Safe Syntax chapter of my link, is that many verbose commands are designed so a single-letter typo causes compile failure rather than causes runtime error. Brilliant move I'd have never thought of doing.

Yet, there are readable, robust languages without a lot of verbosity. The question is what is the right balance. I show here [1] an alternative syntax to one of code examples in e12e's link that I believe is more readable while conveying the same thing. Shows room for improvement even in Ada's fundamentals. Note that I know Ada has several different I/O's on purpose but basic choices can often be inferred through types. Specifying such a core feature shouldn't be necessary except in unusual cases.

[1] http://pastebin.com/6CvpCany

Reply on news.ycombinator.com