Hacker News Reader

Comment by jonathanstrange | Hacker News Reader

As an occasional Ada programmer, I've taken a look several times at Rust and have decided to skip it every time. Ada might be a pain in the ass sometimes (alias rules...), but it's way easier than Rust. In my opinion Rust is a classical case of technology that gets into humans' way rather than serving humans. For me it's just not worth the hassle, especially since most of my programs do not require any soft realtime performance guarantees and therefore work well with way more convenient garbage collected languages like Go, CommonLisp, and Racket.

That being said, Rust is already so obscure that it can easily replace C++ and I predict it a great future. Programmers love obscure programming languages with steep, long learning curves that allow them to show off.

View on HN

Second the Ada note. That language is so well constructed and thought out on many levels.

...except the outer, most superficial level. I'm genuinely afraid that it will never "catch on" because it just looks weird. (But not weird enough to attract that kind of people.)

It's a shame because

- Ada generic packages are exactly what C++ templates should have been

- Derived types and record extension is inheritance that makes sense

- Access types are obvious in hindsight

- Correct terminology for procedures and functions does help a lot in communication

- RAII in the shape of controlled types feels a bit bolted on but it works very well

- Named blocks and explicit closing is easy but very useful

- Class-wide types are deemphasized the way polymorphism should be

- The -gnatyy flag is almost as good as gofmt.

- Tasks and protected types form a very intuitive and safe concurrency mechanism

- Having contract-based programming as an option built into the language is way superior to relying on asserts in the procedure

- While not always budgeted for, when there is time to spend, SPARK is uh-mazing. Strong guarantees at relatively low cost, and reasonably easy to learn as well.

The thing that kept me from trying Ada (back a couple of years ago when I was writing firmware and so was kind of on its home turf) was a lack of good resources for learning it. I got a copy of the book "Programming in Ada" by Barnes, and did not find it very helpful. Often the advice seems to be to go read the Reference Manual, which I agree is highly readable for a language standard, but it's not aimed at users of the language. If anyone here has any other resources to recommend, I'd be happy to hear about them.

> it's not aimed at users of the language.

Is it not? It doesnt contain recipes, no, but it fully documents the fundanental units of the language youll express your solution in.

Thanks for the rundown. Sounds like Ada has a lot of good ideas to steal!

Definitely! My C coding improved vastly after spending some time with Ada. Though it's worth keeping in mind that it's not only about each individual thing being good – it's also that they work really well together.

And the STL first implementation was actually done in Ada. :)

Yes and no.

Yes, Stepanov's first attempt at writing something like the STL was done in Ada. But no, it wasn't "the STL" - it was neither Standard nor Template.

And Stepanov abandoned Ada for C++, because Ada wasn't expressive enough for what Stepanov was trying to write.

Meaning if Stepanov had not played with Ada for its first implementation, followed by Bjarne advocating him to use C++ instead, the STL would never happened in its form.

And yes, it wasn't quite the STL, we had quite a few variations of it, the most well known coming from SGI, until things kind of settled at ANSI.

I disagree. Stepanov wanted to write that kind of software. He would have done it in any vehicle he found suitable. If he hadn't started with Ada, he still would have wound up writing it in some language.

And C++ was among the better candidates for the language to use. It was more suitable than Ada.

And, do you have any basis for the statement that Stroustrup advocated C++ to Stepanov?

From the source itself,

"And, of course, Andy and Bjarne Stroustrup are responsible for putting STL into the standard."

"The support of Bjarne Stroustrup was crucial. Bjarne really wanted STL in the standard and if Bjarne wants something, he gets it. He is as stubborn as a mule. He even forced me to make changes in STL that I would never make for anybody else - I am also stubborn, but he is the most single minded person I know. He gets things done. It took him a while to understand what STL was all about, but when he did, he was prepared to push it through. He also contributed to STL by standing up for the view that more than one way of programming was valid - against no end of flak and hype for more than a decade, and pursuing a combination of flexibility, efficiency, overloading, and type-safety in templates that made STL possible. I would like to state quite clearly that Bjarne is the preeminent language designer of my generation."

http://www.stlport.org/resources/StepanovUSA.html

That says that, once Stepanov had written the STL in C++, Stroutrup advocated the STL becoming part of the C++ standard.

But you said,

> Bjarne advocating him to use C++ instead [of Ada]

which your quote here doesn't substantiate at all.

I got the names mixed up, it was Andrew Koenig not Bjarne.

"My attempts to implement algorithms that work on any sequential structure (both lists and arrays) failed because of the state of Ada compilers at the time."

"In 1987 at Bell Labs Andy Koenig taught me the semantics of C. The abstract machine behind C was a revelation. I also read lots of UNIX and Plan 9 code: Ken Thompson’s and Rob Pike’s programming style certainly influenced STL. In any case, in 1987 C++ was not ready for STL and I had to move on. "

"In 1993, after 5 years working on unrelated projects, I returned to generic programming. Andy Koenig suggested that I write a proposal for including my library into the C++ standard, Bjarne Stroustrup enthusiastically endorsed the proposal and in less than a year STL was accepted into the standard. STL is the result of 20 years of thinking but of less than 2 years of funding."

http://stepanovpapers.com/history%20of%20STL.pdf

> I got the names mixed up

Fair enough. I forgot he was encouraged to go to C++ by anybody.

I have done pascal before and I wish to have ADA more easily available.

> I have done pascal before and I wish to have ADA more easily available

Then you might be interested in https://nim-lang.org/ as a Pascal-like Rust alternative.

There is a free and open Ada implementation these days: GNAT, the GNU Ada Translator, is a full and complete implementation of Ada.

> That being said, Rust is already so obscure that it can easily replace C++

An obtuse syntax is a big downside of C++. Implying that a steep learning curve and the ability to 'show off' helps keep the language where it is grossly misrepresents the vast majority of C++ programmers. Those traits were born out of necessity. In C++98 you simply had to be 'clever' to keep up with modern languages because the language was stagnant for a decade. If the committee can't add things, you do something clever and do it yourself.

C++ was stagnant for the dot-com era, Web 2.0, and the rise of mobile apps, and today it thrives. There's more to that than being entrenched in legacy code bases.

Rust emulating C++s difficulty as a way to cultivate an elitist community, if that's what you're implying, will not work now when C++ is moving in the opposite direction.

We are certainly not trying to do that. Our stated goals for this past year, and possibly some of our goals this year, are the direct opposite.

I've taken a brief look at Ada several times, but gave up on it because it seemed difficult to get a cohesive set of documentation and examples (and ideally a good book) that were all in sync. Since Ada has been around for so long, there's an awful lot of outdated material. Do you have any suggestions on materials one should use while learning Ada for hobbyist purposes? I'd like to give it another go.

Four versions of Ada, named after the year it was released: 83, 95, 2005, and 2012. Each new version adds features on top of the previous.

Ada 83 has

- arrays,

- records (structs),

- derived types (subtypes carrying the same data as parent type),

- subtypes,

- access types (thick pointers),

- procedures (subprograms executed for their side effects) and functions (subprograms that return values),

- Named parameters

- reference arguments (greatly reducing the amount of pointers you have to deal with)

- Default values for arguments

- overloading by type

- in/out parameters

- private package parts (encapsulation)

- generic packages (kinda like C++ templates)

- exceptions

- tasks (concurrent processes that communicate with message passing)

-----

Ada 95 adds a lot of things that make it easier to do Java-style OOP:

- Record extension (inheritance; subtypes carrying additional data their parent type does not)

- Dynamic dispatch of subtypes

- Abstract types

- Subprogram access types (function pointers)

- Sophisticated package hierarchy (though potentially somewhat unintuitive: child packages extend their parents, parent packages are not umbrellas for children the way they are in Python)

- Protected types (protected objects)

- Modular types (unsigned ints with defined overflow characteristics)

- Unbounded_String (the std::string of Ada, compared to the char[] situation in Ada 83)

-----

In Ada 2005, the greatest addition is probably the Collections packages, which added several common data structures to the standard library:

- Instance.Method(Param) syntax sugar for Object.Method(Instance, Param)

- Interfaces

- Controlled types (RAII)

- Removed silly restrictions on access types

- Keyword "limited" to import only declarations

- Keyword "raise" takes exception message directly

- Pragma Assert

...and this is where I need to get off the train. Anyway, bookmark the Ada 2012 Reference Manual. It has everything in it.

Edit: ...but look what I found! https://www.adacore.com/about-ada/comparison-chart

This PDF introduces Ada for C++ and Java developers. After a quick perusal, it appears that it would be valuable. http://www.adacore.com/uploads_gems/Ada_for_the_C++_or_Java_...

Ada is another non-C with odd semantics, so the problem is that it goes too far and not far enough: It's not enough like C to be familiar, but it's not far enough from C to be able to go head-to-head with Haskell. If I want something that's very safe and don't care about it being similar to C, I'm going all the way to Haskell and not bothering with half-measures.

But it's a big deal to say, "Whenever safety matters, you alwys have room for a runtime with a garbage collector." I feel like you hven't substatiated that claim.

I feel exactly the same. It's so strange seeing everyone screaming about safety, yet they never gave Ada a try.

I didn't program ADA, but reading the ADA intro has left me with a good impression of the language.

It's focused on safety even more than Rust and yet it has kept an understandable syntax.

Reply on news.ycombinator.com