Live data from Hacker News

Ada: a C Developer's Perspective

methodsandtools.com

41–50 of 157 posts

Re: Ada: a C Developer's Perspective

#41
post #6

It's not only a language that is key to success. Libraries. I searched for LDAP support for ADA (old protocol used by many companies). I found library ( http://savannah.nongnu.org/projects/adaldap/ ) with latest news from 2002 and CVS repo :) Then I search for SNMP (another dinosaur still in wildly use) - similar result. Second - many solutions/libraries are purely commercial. You need basic open protocols support by…

Ada is so stable and backwards compatible that old libraries will work just fine, unless they have external dependencies or depend on things that change fast in the outside world. For me personally Rust is not a good Ada replacement, because 1) it has the usual obscure syntax - maybe to attract C++ programmers, who seem to like obscurity -, 2.) many semantic tricks and borrower idiosyncrasies that makes it harder to…

I think a lot of people would disagree with #1. There was a discussion on /r/technology yesterday where people were discussing how it was exactly the other way round – Ada has weird syntax (so many English words!) which slows adoption, and Rust is C-like enough that the target market of C/C++ users can pick it up, syntactically at least. I'm saying this having done a distributed systems course in Ada. It felt like writing a novel, about some very awkward people announcing every action as they did it. Rust, on the other hand, feels like pair programming with a wizard (the compiler) who knows how to write really great C++ and has many tips to share.

Rust's syntax is, like many new languages as they are invented, essentially a pick of the crop of the best syntax ideas from other languages. 'Best' is probably debatable but familiarity is certainly not. Type annotations are basically Scala syntax. Class::method(), ditching `return` in favour of last-line expressions and the || {} closure syntax are all pretty close to Ruby. Structs/enums are also basically Scala. `instance.method()`, and pretty much the rest of the language, is universal.

It's true, Scala syntax for types is the weirdest part, but once you know what it means it's not hard to decipher. Much easier than trying to figure out function pointers in C, if you ask me.

#2 is probably true, but that's the cost of staying close to the metal. Rust makes all your memory access very explicit, rather than bundling it up in the standard/GC or leaving it to you. But it's a model you can get used to, and it has value as a mental model aside from its application in Rust.

#3 – well. Ada was young once. Rust is incredibly stable for a project designed by a distributed community of Mozilla and a ton of volunteers.

Re: Ada: a C Developer's Perspective

#42
post #25

Earlier quoted context omitted.

Ada is the F14. Expensive, works well, but ya really just don't need it most of the time.

So what's the F/A-18?

Maybe Java? It's everywhere, can fulfill just about any role you throw at it, but isn't really the world's absolute best tool for most of those roles.

Re: Ada: a C Developer's Perspective

#43
Does someone have experience with Ada 2012s Design By Contract support (including tooling, preferably for GNAT)?

Eiffel is yet another Pascal-ish language whose passing I lament, and lately I've been seriously considering giving Ada another try, given that Modula-3 and Oberon won't exactly come back to life miraculously, and I'm still a bit dubious about all the new kids on the block.

Re: Ada: a C Developer's Perspective

#44
post #37

Earlier quoted context omitted.

Ada is so stable and backwards compatible that old libraries will work just fine, unless they have external dependencies or depend on things that change fast in the outside world. For me personally Rust is not a good Ada replacement, because 1) it has the usual obscure syntax - maybe to attract C++ programmers, who seem to like obscurity -, 2.) many semantic tricks and borrower idiosyncrasies that makes it harder to…

If you start a project today that depends on a library that was last updated in 2002, then may God help you.

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

Re: Ada: a C Developer's Perspective

#45
post #40

Earlier quoted context omitted.

This idea that Rust and Ada are somehow alternatives continually pops up, and I still don't understand it. They each have their own ideas on what "safety" is, and how to address it. I'll admit I'm biased towards Ada, but I think it is pretty safe to say that "Rust safety" is a subset of "Ada safety" - but Rust does it's section and run further with it than Ada. Rust is obsessed with memory safety. That's it's thing.…

What kind of semantics cannot be well expressed with Rust type systems, compared to Ada? The type system is algebraic, and pretty powerful.

One example is integer ranges; they'd be a runtime check in Rust right now. We'll get there. That said, in general, Rust's type safety stuff is fairly powerful, and IIRC has some things that Ada does not.

I do think your parent isn't fully right about the relationship though, as first they call Rust a "subset" of Ada's guarantees, but then say that Ada doesn't go so far as Rust in some places. In general, when discussing language semantics, I see them as more of a large overlap with some differences on each side, rather than one being a subset of the other.

Re: Ada: a C Developer's Perspective

#46
post #3

I am going to be that guy and say: Poorly compressed JPEG images for text examples?

Every time I see that shit I think, "Man, I'm glad we learned how stupid that is." but then immediately after I realize that people are still doing it all the time, because I think that same thought all the time. People are so STUPID! "Oh my god breeze, you are so rude, just because people programming critical infrastructure systems literally can't copy and paste things doesn't mean they're stupid!" -- Stupid people'…

Or much smarter than you, but wanted to show the examples with syntax highlighting but couldn't be bothered to get some editor that exports as HTML or some plugin (both of which might not even be allowed/quick to install on the CMS they use).

As for the extra compression, they could just not care as the text is still visible enough, it's not supposed to be a textbook, and it's small and loads fast.

Re: Ada: a C Developer's Perspective

#47
post #27

Earlier quoted context omitted.

Every time I see that shit I think, "Man, I'm glad we learned how stupid that is." but then immediately after I realize that people are still doing it all the time, because I think that same thought all the time. People are so STUPID! "Oh my god breeze, you are so rude, just because people programming critical infrastructure systems literally can't copy and paste things doesn't mean they're stupid!" -- Stupid people'…

I get emails all the time where people use word or powerpoint documents with just one single image pasted inside, instead of attaching it to the email or sending it in HTML format.

If a brain surgeon sends such an email to a programmer, does it mean that the surgeon is "SO STUPID" as the parent says?

Re: Ada: a C Developer's Perspective

#48
post #39
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…

> I think we all agree if we could program with simple functions that each do one thing and one thing well then combine those functions makes for a much simpler language and easier to think about. Well, I don't agree. You could end up with tons of small functions, and complex interactions between them (whether they are pure or not) than make for spaghetti logic. I also don't see how Ada's pre/post conditions make it…

> You could end up with tons of small functions, and complex interactions between them (whether they are pure or not) than make for spaghetti logic.

I think 'one thing well' is pretty much the opposite of this idea. It implies encapsulation and composition, not smushing together. If some functions are pure, there is no such thing as 'complex interactions between them', only simple ones.

On the other hand, it would definitely be weird if Ada were used as a functional programming language.

Re: Ada: a C Developer's Perspective

#49
post #40

Earlier quoted context omitted.

This idea that Rust and Ada are somehow alternatives continually pops up, and I still don't understand it. They each have their own ideas on what "safety" is, and how to address it. I'll admit I'm biased towards Ada, but I think it is pretty safe to say that "Rust safety" is a subset of "Ada safety" - but Rust does it's section and run further with it than Ada. Rust is obsessed with memory safety. That's it's thing.…

What kind of semantics cannot be well expressed with Rust type systems, compared to Ada? The type system is algebraic, and pretty powerful.

first thing that comes to mind are bounds on integer subtypes. classic example is to declare an array to be indexed with such a type, then all out-of-bounds errors can be checked at compile time.

Re: Ada: a C Developer's Perspective

#50
post #29

I had a strange internship topics involving Ada. I tried to run a huge program (a simple stdio wrapper around a huge library actually) on an Android machine (Android 2.3, ARM). At that time, the only ADA compiler for ARM was available on BSD so I had used a Windows machine for development and a OpenBSD laptop for compiling the wrapper. The subtyping feature I love the most. You see the benefit when you need to call a…

> The subtyping feature I love the most. I only have very little experience with Ada, but being able to define a type whose values are integers in the range, say, 1 .. 7, to represent days of a week was an eye opener.

Range types are probably the main thing I miss from the Rust type system.

But even without range constraints, wrapper types (called newtypes in Haskell and Rust) are great. Let's say you have a function that accepts a temperature. A temperature is a float, but you want to prevent the user from mixing up celsius and fahrenheit.

This is what newtype looks like in Rust:

  struct Celsius(pub f64);
  struct Fahrenheit(pub f64);
  fn print_celsius(temperature: Celsius) {
    println!("Temperature is {}", temperature.0);
  }
It will fail to compile if you accidentally pass a Fahrenheit value to `print_celsius`, but at compile time all values are optimized down to plain floats, without any runtime cost.

More programming languages should adopt this concept :)

Post reply on HN