Live data from Hacker News

Giving Ada a Chance

ajxs.me

31–40 of 261 posts

Re: Giving Ada a Chance

#32

His discussion of Ada (not all upper case -- can the HN title be changed?) is interesting, but his criticism of Fortran, although colorful ("eldritch"?) , is vague and likely uninformed. I program in Fortran 95 a lot and can easily understand my code years later. "Admittedly, I had pictured Ada’s syntax resembling the uncompromising verbosity and rigid construction of COBOL, or perhaps the Lovecraftian hieroglyphics…

I enjoyed Fortran/FORTRAN. Is a nice succinct language. "Lovecraftian hieroglyphics of Fortran" <-- the author never programmed in Perl, I presume.

APL puts the love in Lovecraftian.

Re: Giving Ada a Chance

#33

Earlier quoted context omitted.

"Lovecraftian hieroglyphics of Fortran" The author might want to stay away from MUMPS for sanity's sake.

I very briefly encountered MUMPS in grad school and its eldritch horror has remained seared in my brain.

In true Cthulhu fashion, after encountering it at a medical facility where the lead programmer bragged about how amazing it was, I bought a book on the language. I like collecting language books (Icon was fun), but that was rather painful to read through and I have done IBM JCL and found it not unpleasant.

Re: Giving Ada a Chance

#34
In answer to what appears to be a misunderstanding about Rust:

> Its foreign function interface seems particularly poorly implemented. The official Rust documentation suggests the use of the external third-party libc library (called a 'crate' in Rust parlance) to provide the type definitions necessary to interface with C programs. As of the time of writing, this crate has had 95 releases. Contrast this with Ada’s Interfaces.C package, which was added the language in Ada 95 and hasn’t needed to change in any fundamental way since.

Rust's libc crate isn't third-party, it's first-party, developed by the Rust project itself: https://github.com/rust-lang/libc/ . It's also not just for type definitions necessary to interface with C programs; here's the first heading and first paragraph of its README:

"libc - Raw FFI bindings to platforms' system libraries"

"libc provides all of the definitions necessary to easily interoperate with C code (or "C-like" code) on each of the platforms that Rust supports. This includes type definitions (e.g. c_int), constants (e.g. EINVAL) as well as function headers (e.g. malloc)."

The fact that this library contains low-level type definitions for every platform that Rust supports explains why it's had more than one release: new platforms get added, platforms add new interfaces, and platforms change the definitions of existing interfaces (possibly incompatibly, which explains why this isn't in the standard library).

> It lacks basic features necessary for the task, like bitfields, and data structure packing.

The latter is achieved via the built-in `repr(packed)` attribute (https://doc.rust-lang.org/nomicon/other-reprs.html#reprpacke...) and the former is provided by the bitflags crate: https://crates.io/crates/bitflags (while unlike libc this does not live under the rust-lang org on Github, it does live under its own org which appears to be populated exclusively by Rust project team members).

Re: Giving Ada a Chance

#36

His discussion of Ada (not all upper case -- can the HN title be changed?) is interesting, but his criticism of Fortran, although colorful ("eldritch"?) , is vague and likely uninformed. I program in Fortran 95 a lot and can easily understand my code years later. "Admittedly, I had pictured Ada’s syntax resembling the uncompromising verbosity and rigid construction of COBOL, or perhaps the Lovecraftian hieroglyphics…

I enjoyed Fortran/FORTRAN. Is a nice succinct language. "Lovecraftian hieroglyphics of Fortran" <-- the author never programmed in Perl, I presume.

> "Lovecraftian hieroglyphics of Fortran" Or in Fortran, it's a relatively verbose language from what I remember of it (that said, I learned Fortran 90/95, so maybe the older variants were worse)

Re: Giving Ada a Chance

#37
post #27
post #22

A nitpick, but why is Ada in all caps in the title? It isn't in the article, nor is the name an acronym.

There's no real reason for it to annoy me so much, but I was just thinking about how I can't stand when people seemingly randomly capitalize words relating to technology without the intention of drawing emphasis to them: GIT, NODE, JIRA, JAVA... why??

I think people sometimes JUST do it for NO good reason other than to DRAW emphasis

Re: Giving Ada a Chance

#39
> I can’t help but think that complicated programming paradigms would seem more intuitive to beginners if taught through Ada instead of C and its derivative languages, as is common in computer science and engineering faculties worldwide.

At my university, the first courses you took in CS used Ada. I think it was a really good choice but I was in the minority I guess because after my year they switched to either using Java or Python depending on who taught which of the courses in that first series.

People found it frustrating how much work it'd take to get their programs to even compile but that's a good thing in my view. If it wasn't compiling, that was normally because the compiler found an error that would still be there at runtime in another language.

Re: Giving Ada a Chance

#40

I love Ada, unfortunately it’s real world use seems to be relegated to old legacy code. I’d like to use it a little more on the side, but I also need to keep my priorities focused on realism, which sadly means ignoring Ada and learning something like C++ which seems unapproachable from any angle. Ada also seems to have a weirdly negative rep in many circles it seems. I recall looking around for an Ada compiler for a…

Lack of a free compiler with permit to use commercially (gnu linker exception), was a problem during a significant phase of the language.
Post reply on HN