Live data from Hacker News

Ada: a C Developer's Perspective

methodsandtools.com

61–70 of 157 posts

Re: Ada: a C Developer's Perspective

#61
post #47
post #27

Earlier quoted context omitted.

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?

A brain surgeon might be excused, but not the guys from customer's IT department or other fellow developers in offshored teams, they should know better.

Re: Ada: a C Developer's Perspective

#62
post #50
post #29

Earlier quoted context omitted.

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

Huh. That's clever. This approach should also work in other languages, say, C/C++/C#. I don't remember if C uses structural identity for struct types, but it might work.

Re: Ada: a C Developer's Perspective

#63
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.

Why? Ada libraries from 2002 without outside dependencies work perfectly fine. I'm using that old libraries all the time. Ada has been designed specifically for that, it's been used in the aviation industry that runs the same code for 20+ years minimum.

That you think otherwise only shows that you've never seriously used Ada in a larger project.

Re: Ada: a C Developer's Perspective

#64
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.

Re: Ada: a C Developer's Perspective

#65
post #50
post #29

Earlier quoted context omitted.

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

One of my favorite features of Scala that Java is missing is Scala's newtype-like functionality. It lets you define types which get erased to another one the JVM level (so there's no unnecessary boxing) but are checked in Scala and can hide their interior type and provide different methods.

Re: Ada: a C Developer's Perspective

#66

Is Ada losing ground to dependently typed languages, or are these still too "academic" for production use?

Ada as an ecosystem has it's own alternative, SPARK. It's not a dependently typed language, but you can go just as far with it using pre and post conditions, and ghost code, insofar as what you can prove.

You can see here for more information:

http://www.spark-2014.org/ http://docs.adacore.com/spark2014-docs/html/ug/en/tutorial.h...

Re: Ada: a C Developer's Perspective

#67
post #4

So how does Ada go speed wise (real world not micro benchmarks)? Were/are there legitimate reasons to opt for c over Ada?

In theory, it's just as fast as C/C++, when you compare GNAT against GCC/G++.

In practice, some language constructs are not as optimized as their C++ counterpart.

The end result is that you can expect the Ada 83 subset to be extremely fast, but more recent constructs like OO and controlled types (equivalent to C++ virtual destructors) to be slower.

All in all it has a pretty good performance story !

Re: Ada: a C Developer's Perspective

#68
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 feel like I have to rule out some misconceptions and defend Ada a bit, even though I don't use it very often any longer.

Ada is not a magic bullet

1) Nothing is a magic bullet. (And certainly no actual user of Ada has ever claimed that it is a magic bullet.)

Ada is not easy to write, it's around the level of C I grant you.

2) Ada is way harder to write than C, unless you're very proficient with it, of course. It's a much bigger language, and the syntax is not easy. Ada is designed for easy readability and maintainability, not for easy writing. It also requires a lot of repetition if you write good style. (You can write Ada code like C and Pascal, but then you loose most of the language's main advantages.)

Overhead, each of these features like assert adds a lot of overhead into the system, this is just not viable in a lot of systems.

3.) Ada is blazingly fast even without any optimization, and after optimization basically around the performance of C (or C++, if you use tagged types with dynamic dispatch). That's not very surprising, since GNAT uses gcc's backend optimizations. As for overhead, every runtime-check in Ada can be switched off. You can even discard the whole runtime system and use your own minimal runtime system, if you feel ambitious.

There is reason to believe that future versions of Rust (or even the current compiler) are faster than idiomatic, well-styled Ada. The goal of Ada was never to produce the fastest executables, and the fact that GNAT creates so fast ones is merely due to the authors of GCC and Ada's strong focus on compile-time operations and checks that it shares with Rust.)

Toolchain and library support, most of us can't afford expensive toolchains and libraries

4) Absolutely true, library support is not comparable to C and not even remotely comparable to C++. However, see my other remark here, an Ada library that appears to be abandoned will compile and work 100% fine and you can understand it by reading the source code (no documentation needed). But yeah, there are way less libraries, of course.

As for Java or Python, these are bad comparisons. They are both much slower than Ada and way less maintainable.

Re: Ada: a C Developer's Perspective

#69

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…

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

> Structs/enums are also basically Scala.

How so? Scala class bodies are a mix of ordered constructor statements and unordered declarations/method definitions, while Rust structs can only declare fields (without any sort of initial value). Scala enumerations (both scala.Enumeration and the more common sealed class versions) look nothing like a Rust enum; if anything Rust enums look like ML/Haskell algebraic type definitions.

> It's true, Scala syntax for types is the weirdest part, but once you know what it means it's not hard to decipher.

The part of the type syntax that is like Scala (i.e. the colons and arrows) has its origins in the ML family IIRC. Rust's bootstrapping compiler was written in OCaml, so I suspect that was in fact the inspiration.

Re: Ada: a C Developer's Perspective

#70
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.

Well, why? Why would a library be bad just because it hasn't been updated in 15 years? Does it spoil? Maybe it doesn't need to be updated.
Post reply on HN