Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Ada Is the Language You Want to Be Programming Your Systems With

hackaday.com

Post reply on HN
Print view View original

291–300 of 330 posts

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#291

Post by zozbot234 »

fluffything wrote: post #286
devnulloverflow wrote: post #148

Earlier 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).

> That sounds complicated to me, in 2019 with 25 years of C++ experience. std::cout is not a generic, but on the project I just tested, if I substitute X with a type that does not implement an appropriate operator I personally find having to do overload resolution first on a 1000 function overload set containing generic and not generic functions, and then often having to actually instantiate a generic (doing template…

Indeed, type classes as found in languages like Haskell and Rust were first designed as a way to make overloading (aka "ad-hoc polymorphism") work more sensibly, and in a way that plays nice with generics/templates.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#292

Post by steveklabnik »

johnisgood wrote: post #288
Fabien_C wrote: post #275

Earlier quoted context omitted.

I don't see the point with "zero-cost abstractions", overflow check is not an abstraction. And of course the run-time checks can also be disabled for Ada of course, and usually are for release build.

And this is worth noting: > These runtime checks[1] are costly, both in terms of program size and execution time. It may be appropriate to remove them if we can statically ensure they aren't needed at runtime, in other words if we can prove that the condition tested for can never occur. > This is where the analysis done by GNATprove comes in. It can be used to demonstrate statically that none of these errors can ever…

The rust compiler also removes bounds checks and such if it can statically prove that they won't occur. You don't have as much tooling to communicate it to the compiler as you do in SPARK just yet.

When I learned Ada (blog post somewhere in this thread) I was pretty shocked by how many more runtime checks it had than Rust does, overall. Rust usually checks things at compile time.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#293

Post by jhomedall »

antocv wrote: post #243
jeffdavis wrote: post #40

There is some overlap in the use cases between Ada-in-the-mainstream (which seems to be what the article is suggesting) and Rust. The existence of Rust will make it even harder for Ada to break out of its existing domains. Both seem to have good ecosystems, but quite different. Ada has more high-assurance tooling and practices. Rust has more in terms of packaging and general-purpose high level libraries. With Ada, it…

I still cannot forgive Rust for not learning anything from Ada. "Code is read more often than it is written". Reading Ada is so unambigous, and clear. If you mean if then, you have the keyword then, when you want to say procedure you say procedure and you can read that. Rust? fn, because is it fun, or functor, so fuck you.

You learn what 'fn' means once, and then you know it forever. It's a non-issue.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#294

Post by fluffything »

im_down_w_otp wrote: post #51
jeffdavis wrote: post #40

There is some overlap in the use cases between Ada-in-the-mainstream (which seems to be what the article is suggesting) and Rust. The existence of Rust will make it even harder for Ada to break out of its existing domains. Both seem to have good ecosystems, but quite different. Ada has more high-assurance tooling and practices. Rust has more in terms of packaging and general-purpose high level libraries. With Ada, it…

I understand what you're getting at here I tbink, but one of the ecosystem challenges we run into is that while Rust is abstractly a fantastic choice for the domain of systems development that would often be served by Ada (in fact we think it's a lot better in some respects because we can do more statically ahead of time, that Ada does dynamically at runtime, by abusing the Rust type system and borrow-checker), the R…

> There's significantly more attention provided to things like Wasm than there is to things like embedded use cases for example.

Rust is a language developed by its users. The reason less things happen in Rust embedded domain, is because less companies pay people to work on embedded Rust than they do on WASM rust.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#295

Post by fluffything »

dev_dull wrote: post #123
steveklabnik wrote: post #97

Earlier quoted context omitted.

You can get Rust binaries just as small; the smallest known one was 145 bytes. Some defaults were recently adjusted to make them smaller by default too. https://github.com/tormol/tiny-rust-executable

Nobody wants to play with their compiler to get a small binary. Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries.

> Languages are typically judged by their defaults. If rust can produce small binaries, then it must produce small binaries.

Code size isn't the only axes that can be used to measure the quality of a binary, there are many others: like run-time performance, portability, debuggability, etc.

No C compiler I know optimizes for size by default, in fact, I don't know of any C compiler that, by default, optimizes anything at all. Clang, GCC, MSVC, and all other mainstream compilers require users to enable optimizations (O1, O2, O3, Ofast, etc.) and none of these are code-size optimizations. Only relatively recently have compilers grown the ability to optimize for size, and you have to go way out of your way to do it (enable Oz, disable debug information -g0, enable LTO -flto, ...).

Optimizing for size over anything else by default is one of the worst trade-offs a compiler can make. It's a bad trade-offs for most programs, and it is a bad-tradeoff for most compiler users.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#296

Post by AnIdiotOnTheNet »

bdavis__ wrote: post #91
wrp wrote: post #72

This 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…

Many of the 'programmers' of those days lacked the sophistication and education to appreciate Ada. Just the mojo required to print an integer (having to instantiate a generic) was considered complicated Ada was also very slow to compile, on the order of 10 times slower than Jovial. (my experiences) Avionics systems back then were tiny. Jovial usually ran on a 16 bit processor. Ada enabled a certain maturity and corre…

> Many of the 'programmers' of those days lacked the sophistication and education to appreciate Ada.

That certainly sounds like academic self-righteousness.

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#297

Post by oblio »

dev_dull wrote: post #124
haolez wrote: post #68

Earlier quoted context omitted.

Having a big ecosystem of libraries is not even close to a big concern when developing critical applications like what Ada seems to be used for.

Totally. For defense, I think a large third party ecosystem is pointless unless every square inch of it has been verified for compliance. Do people think part of missile software includes “npm install wordpad”?

No, but I would expect it to contain "npm install launchpad" :-p

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#298

Post by waynecochran »

realusername wrote: post #188
waynecochran wrote: post #186

Ada was the language of the undergraduate curriculum at the University of Washington when I was there (late 1980's) -- because Boeing. One of the core safety mechanisms was exception handling. * The biggest thing I miss is that every block was inherently a try-block. Just put your exception handlers at the bottom of the block. This provided a nice separation of "normal flow-control" and "exceptional flow-control". Wh…

> * The biggest thing I miss is that every block was inherently a try-block. Just put your exception handlers at the bottom of the block. This provided a nice separation of "normal flow-control" and "exceptional flow-control". Why have try-catch anyway -- I never got used to that later in life. That's still the case in Ruby, you can put a rescue at the end of the block.

"rescue" seems to imply "error," whereas "exception" means simply an unusual / non-normal condition. Does Ruby encourage exception handling as control-flow besides error conditions?

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#299

Post by mumblemumble »

Mikhail_Edoshin wrote: post #258
harry8 wrote: post #201

Earlier quoted context omitted.

Uncaught exception and die. For a banking application, yes, die, hard, as loudly as possible. Downtime is worth it. Do not continue, do nothing until it is understood and fixed. When you're flying. Hmmm. Not so much. Dying is a really bad idea. Ok you should have it tested thoroughly so it isn't going to happen but if it does and "anything could happen" well "anything" is better than killing all the passengers, crew…

The default out-of-box runtime can only handle one general scenario. The runtime designers choose to print the error message and terminate, and this seems to be the only sound option for default behavior. It's up to the developer to replace this default handler when the scenario differs that much.

> this seems to be the only sound option for default behavior

I think that is the crux of this debate. In my background, yeah, you fail hard when anything unexpected happens. It's the most straightforward way to fail safe.

But my background maps better to the financial case; I've never worked on avionics or anything like that. I can see the point, though, that, in that kind of situation, failing hard doesn't fail safe at all.

It's conceivable to me that different problem domains require different default behavior. (And perhaps, by extension, different programming languages.)

Re: Why Ada Is the Language You Want to Be Programming Your Systems With

#300

Post by kazinator »

shakna wrote: post #290
bdavis__ wrote: post #284

Earlier quoted context omitted.

pakage int_io is new integer_io (num=>integer); and then int_io.putline(num);

with Ada.Text_IO; use Ada.Text_IO; with Ada.Integer_Text_IO; use Ada.Integer_Text_IO; ... PutLine(num); As far as I can tell, Ada has had Integer_Text_IO that does that all for you, since the early days. [0] (Note that the reference is the first "public" release of Ada outside of the DOD). [0] https://www.adahome.com/LRM/83/RM/rm83html/lrm-14-03.html#14... (Ada 83 Manual)

That's an awful amount of boilerplate for a simple integer hello world.

Languages with these modules and import statements should be burned. (Starting with Python.)

For pete's sake, couldn't they at least combine this with and use into one keyword so you don't have to repeat yourself?

Or can't use be made to forgive a missing with and just get on with the show?

Do defense contracts pay by the byte or what?

Post reply on HN