Live data from Hacker News

Ada: a C Developer's Perspective

methodsandtools.com

121–130 of 157 posts

Re: Ada: a C Developer's Perspective

#121
post #5

It's such a pity these days there is no modern tool chain/workflow for Ada (or C++ for that matter). I mean, a package manager, a build tool with integrated dependencies. As far as I know, there is very little open source software for Ada. It's a shame, because I feel like the language would become more mainstream, if only better tooling was easily available.

There are a few people at AdaCore working on this, we're trying to bootstrap it and involve the community, more about that soon we hope :) The build tool, GPRBuild is already a step above makefiles, and personally I find it very convenient to work with.

Then I hope to see soon a non-trivial (setting up a few dependecies) "Getting Started" for the layman !

Re: Ada: a C Developer's Perspective

#122
post #72
post #8

Earlier quoted context omitted.

On early PCs, Pascal and C were pretty much tied in popularity. Both were free to implement, and small enough that you could make a fast compiler on a typical PC with only 256-640 kB RAM. C won because it was more flexible and was chosen by Microsoft, but Pascal definitely had a strong following (it was the original Mac's API language, and on PC it was a major contender thanks to the nice and fast Turbo Pascal IDE).…

Was anyone building things like operating systems or drivers in pascal? AFAIK that was always the realm of c. Turbo pascal was the first language I was taught, I have a soft spot for it but I think it had largely faded away by then.

I wrote some pretty low-level stuff in VAX PASCAL, which had extensions to let you do just about anything. It was a nice language.

Re: Ada: a C Developer's Perspective

#123
post #22
post #19

Earlier quoted context omitted.

The problem is that it does not manage and version dependencies for you. Say I start a new C++ project where I want - say - use ZeroMQ and also Folly to parse JSON. Where do I start? Should I install ZeroMQ and its headers globally? What if the version changes? Will it conflict with other system libraries? Well, better start using Docker. What if the version I need is not in the Ubuntu repositories yet? I need to add…

To paraphrase JWZ... "Some people, when confronted with a dependency problem, think 'I know, I'll use Docker.' Now they have two problems." Unfortunately there's no single answer. Static libraries vs. dynamic? Global install or packages from a repo? Everything depends on the degree of control you have over the deployment environment.

IMO, since the trend today seems to be building static binaries, I'd like to see an opinionated tool that made that use case stupid simple.

Re: Ada: a C Developer's Perspective

#124

Earlier quoted context omitted.

I don't really understand the "Rust is obsessed with memory safety" meme. When pitching Rust to others of course memory safety and thread safety get hyped a lot; because it's talking about something that most languages just can't do -- safety without compromise. But actually ... memory safety is a small part of the reasons why I like Rust, and there are plenty of other cool bits in the language. It stands out a bit b…

Safety without compromise doesn't exist. Rust does what it does well, but at significant cost in developer time. I'd rather use a garbage collector, it's much much simpler and fine for 99.9% of use cases.

Garbage collection does make things easier, prettier, and simpler. BUT there are many problem domains in which a GC can not be used. A browser being a prime example...

Re: Ada: a C Developer's Perspective

#126
post #107

Earlier quoted context omitted.

This is why static checking is better than runtime checking. Rust has some, but not enough. What is needed is something like Isabelle sledgehammer, quickcheck and metis logic and higher function correctness checkers. (Yes, Haskell has a bit more primitive version of Quickcheck.)

That's basically what SPARK Ada is.

A smaller less featured one, but very useful nonetheless. (Specifically, sledgehammer is superior as a checker and automated proof library check is also invaluable in simplification.)

Technically, Why3 (intermediate language and prover manager used in SPARK for verification) can interface with Isabelle too. I should try it out.

More edit: someone has done it, called HOL-SPARK. Excellent.

Re: Ada: a C Developer's Perspective

#127
post #36
post #35

Here is my list of shortcomings when it comes to Ada 1) Ada is not a magic bullet, the seminal case study of why computer bugs are bad taught in CS courses around the world is the failed 1996 Ariane 5 rocket launch where the rocket veered off course and then exploded due to a software error that caused it not to understand the data it was getting from a sensor. More recently there are plenty of demonstrations of poor…

1) and 3) are related as far as I remember - Ada WOULD have found the problem which was responsible for the Ariane 5 launch failure, but the section involved was speed critical, so the asserts were dropped to make the code run fast enough. Sad reality: The best security features in the world are useless if they are too slow for your use case.

A Denial of Service vulnerability is a security vulnerability no matter the cause. That COULD be an attacker, but it could also be that your code runs too slowly or the UI is too hard to learn.

Re: Ada: a C Developer's Perspective

#128
post #72
post #8

Earlier quoted context omitted.

On early PCs, Pascal and C were pretty much tied in popularity. Both were free to implement, and small enough that you could make a fast compiler on a typical PC with only 256-640 kB RAM. C won because it was more flexible and was chosen by Microsoft, but Pascal definitely had a strong following (it was the original Mac's API language, and on PC it was a major contender thanks to the nice and fast Turbo Pascal IDE).…

Was anyone building things like operating systems or drivers in pascal? AFAIK that was always the realm of c. Turbo pascal was the first language I was taught, I have a soft spot for it but I think it had largely faded away by then.

Yeah, when I was working at Burroughs in 1980, they were doing printer drivers and a distributed OS prototype in their version of Pascal. Problem was, everyone needed to beef up Pascal in their own way to make it industrial level.

Re: Ada: a C Developer's Perspective

#129
post #36
post #35

Here is my list of shortcomings when it comes to Ada 1) Ada is not a magic bullet, the seminal case study of why computer bugs are bad taught in CS courses around the world is the failed 1996 Ariane 5 rocket launch where the rocket veered off course and then exploded due to a software error that caused it not to understand the data it was getting from a sensor. More recently there are plenty of demonstrations of poor…

1) and 3) are related as far as I remember - Ada WOULD have found the problem which was responsible for the Ariane 5 launch failure, but the section involved was speed critical, so the asserts were dropped to make the code run fast enough. Sad reality: The best security features in the world are useless if they are too slow for your use case.

It was actually an engineering error. The software in question was designed for Ariane 4, and the condition that happened in Ariane 5 could not occur. But a shortcut was taken, and the suitability of the software was not reassessed. Then Ada's exception mechanism was pulled into play when it never should have been given the requirements of the Ariane 4.

Re: Ada: a C Developer's Perspective

#130
post #44

Earlier quoted context omitted.

Same goes for a library that was last updated 5 minutes ago though.

Good point. I'd rather pick the one that hasn't needed an update in 20 years unless they're assuming it is bitrotten.

How do you distinguish between "hasn't needed an update" and "was abandonded by the developer"?
Post reply on HN