I once flipped through Ada spec (purely voluntarily) and in my opinion it was a really well designed language. I generally come to believe that a language should offer fewer fancy programming constructs, but advance in specifications and definitions, and Ada looked like a solid step in that direction (as compared to C, for example). As it was recently pointed out by some other discussion here at HN the idea of software development is to document knowledge, and Ada is pretty good at that. The modern trend is very different, unfortunately.
Why Ada Is the Language You Want to Be Programming Your Systems With
261–270 of 330 posts
Re: Why Ada Is the Language You Want to Be Programming Your Systems With
#262Earlier quoted context omitted.
There is something to be said for not just halting on an error in production systems. Its the same reason assertions are usually turned off on production builds. Yes ideally the programmers should have handled the exception, but once your in production and the system is running, should you really just halt the whole program due to an exception the prograera didn't foresee?
No, the process manager should log the stack trace, restart the subsystem and try running a few more times, then try an auxiliary system or just fly without the subsystem. It should not halt the whole software.
On a rocket launch?
Re: Why Ada Is the Language You Want to Be Programming Your Systems With
#263Earlier quoted context omitted.
I'm sure that's all true. There is something to be said for a language that was written to a spec from the beginning, however. That is a luxury that few languages today can claim; most language specs were written after the first version(s) of the language were implemented, and were written to match the implementation, not the other way around. Writing the specification first makes for a much cleaner language, though…
Languages are tools to codify behaviors. The fact that we spend so much time debating which tool is better instead of “building bridges”, is why I left this industry. Just look at the web front end. Absolute cluster fuck.
Well, languages are indeed different and some are better for the task than others. And bridges do fall sometimes, so it's worth to reflect on why and how to prevent it.
Re: Why Ada Is the Language You Want to Be Programming Your Systems With
#264This article promotes a popular misconception of the programming situation for defense projects in the 1970s. There may have been "hundreds of specialized programming languages" in existence that could be used, but just a handful actually predominated. Most aeronautical projects were done in JOVIAL. I've talked about this history with engineers from the 1960s-70s. They did not regard the introduction of Ada as a good…
As I've probably posted before, I was at a Dijkstra lecture in the early 80s where he put up one of his famous hand-drawn slides that said "Ada: The latest government boondoggle that will take 5 years and 5 million dollars to kill." [5 million dollars was a lot of money back then.] So yeah, even the academics didn't much care for Ada.
Ah, those famous people and their catchy phrases. They do a lot of damage sometimes.
Re: Why Ada Is the Language You Want to Be Programming Your Systems With
#265Earlier quoted context omitted.
Ideally your type system should be aware of all the exceptions a particular function is able to throw so the compiler forces you to handle all of them before it compiles.
This is hardly possible. The whole idea of exceptions is that each function only deals with a subset. If no one does this, there's always a top-level handler that handles all. The default handler normally terminates the program, but it's totally possible to write a custom top-level handler that does something else. E.g. normally "out of memory" is an exception that causes a program to terminate, but in old Adobe Phot…
> This is hardly possible. The whole idea of exceptions is that each function only deals with a subset.
Why? It's totally possible to infer the most general type for all the functions in the program, hence to infer the type of the needed handler.
Any language with subtyping and powerful type inference can do this, here is the toy ocaml example with typed algebraic effects (you can think of them as of exceptions):
val read_file : path -[ Not_found ]-> string
val process_content : string -[ OOM | Intern_err of int ]-> float
let computation path =
let content = read_file path in
let result = process_content content in
if result val computation : path -[ Not_found | OOM | Intern_err of int | Bad_result ]-> float
Even if you want to keep some exceptions unhandled, you can easily choose which ones, and track them carefully.
Re: Why Ada Is the Language You Want to Be Programming Your Systems With
#266Earlier quoted context omitted.
> Just the mojo required to print an integer (having to instantiate a generic) was considered complicated That sounds complicated to me, in 2019 with 25 years of C++ experience. (And of course C++ error message sprouting mysterious stdlib templates also seems complicated to me).
It isn't more complicated than printf, which is also close to being a generic. PutLine("The number is " & num); printf("The number is %zu\n", num);
printf is not c++
Re: Why Ada Is the Language You Want to Be Programming Your Systems With
#267As a side note for people like me who have no option other than C for their safety critical projects, remember there's a MISRA-C standard. If that feels too much, [1] is a good starting point. [1] http://pixelscommander.com/wp-content/uploads/2014/12/P10.pd...
Thank you for the link! I think that’s really helpful and those are good explanations for each rule. Does anyone know of a guide for writing C code where you allocate a specific block of memory at the start and then use that for all data from then on? Avoiding malloc is one of the suggestions there and seems like a smart strategy.
I've never seen a guide, but I worked on some console games around 15 years ago where the rule was "malloc is evil". That mindset was enlightening and felt "correct" compared to some of the sloppy memory management I'd seen (and, sadly, implemented) on some PC game titles I'd worked on before.
Basically we treated the heap like a stack of large context oriented memory blocks. Each of these blocks contains fixed data loaded from disk (static game resources like bitmaps, UI layouts, etc) and fixed size pools of fixed size game objects. The big blocks would get allocated in a stacked manner at distinct times like game title load and level load.
So if your game has bullets, you have a memory pool of say, 100 bullets to maintain the state of each instance. If you try to shoot a 101st bullet, you either don't or you have an ejection strategy. You never malloc or free during gameplay : you only allocate from one of the pools.
When it's time to unload the level... boom, you free the whole block at once, popping this stack. This is extremely efficient compared to freeing many individual malloc allocations.
Re: Why Ada Is the Language You Want to Be Programming Your Systems With
#268Earlier quoted context omitted.
The software in the case of the 737 max performed exactly according to the spec. The problem is that the spec was buggy. The language can't fix a buggy spec. Note that the bug which caused the Ariane V disaster was written in Ada. And that was caused by the language. If the Ariane V code was written in C and the value simply overflowed, nothing negative would have happened. (The value would be hilariously wrong, but…
> value simply overflowed, nothing negative would have happened. Except overflow would most likely have caused a significantly more severe outcome than the uncaught exception. And there is a restriction in GNAT (No_Exception_Propagation) which forces you to deal with any exception immediately, and should be used in any critical software imho. https://docs.adacore.com/gnathie_ug-docs/html/gnathie_ug/gna...
Significantly more severe than the rocket blowing up?
Re: Why Ada Is the Language You Want to Be Programming Your Systems With
#269Re: Why Ada Is the Language You Want to Be Programming Your Systems With
#270Earlier quoted context omitted.
No, the process manager should log the stack trace, restart the subsystem and try running a few more times, then try an auxiliary system or just fly without the subsystem. It should not halt the whole software.
On a rocket launch?
On projects which require redundancy and resilience.