Live data from Hacker News

Ada, its design, and the language that built the languages

iqiipi.com

131–140 of 242 posts

Re: Ada, its design, and the language that built the languages

#131

Earlier quoted context omitted.

And the cpu that was designed to implement ADA also failed miserably: the iAPX 432. https://en.wikipedia.org/wiki/Intel_iAPX_432

The claim that it was designed for Ada was just marketing hype, like the attempt of today of selling processors "designed for AI". The concept of iAPX 432 had been finalized before Ada won the Department of Defense competition. iAPX 432 was designed based on the idea that such an architecture would be more suitable for high level languages, without having at that time Ada or any other specific language in mind. The i…

The other CPU that was designed for Ada succeeded spectaculary:

https://datamuseum.dk/wiki/Rational/R1000s400

Re: Ada, its design, and the language that built the languages

#132

Earlier quoted context omitted.

I agree. I've never understood or accepted the claim that Ada is verbose. It's simply clear and expressive. If there were some alternative concise syntax for "Ada" then I would not want to use it (because it would not be Ada). This was proposed, as a joke, some years ago: https://www.adacore.com/blog/a-modern-syntax-for-ada This is an old but good article on the topic: https://www.embedded.com/expressive-vs-permissiv…

Because that is a joke, it proposes replacements only for a small set of Ada tokens and it is not clear how the proposal can be cleanly extended to the full set of Ada tokens. Nevertheless in is possible to define a complete 1 to 1 mapping of all Ada syntactic tokens to a different set of tokens. The resulting language will have exactly the same abstract syntax as Ada, so it is definitely exactly the same language, o…

I think there is a significant difference between choosing to use words (from some language) versus using brackets like {}, () and []. With nested brackets there are often debates over placement and it is usually less clear what scope is being ended by the closing bracket.

Re: Ada, its design, and the language that built the languages

#133
The article states, quoting:

"JavaScript's module system — introduced in 2015, thirty-two years after Ada's — provides import and export but no mechanism for a type to have a specification whose representation is hidden from importers."

Then:

"in Ada, the implementation of a private type is not merely inaccessible, it is syntactically absent from the client's view of the world."

Am I missing something -- a JavaScript module is perfectly able to declare a private element by simply not exporting it, accomplishing what the author prescribes to Ada as "is not merely inaccessible, it is syntactically absent from the client's view of the world"? Same would go for some of the other language author somewhat carelessly lumps together with JavaScript.

I loved the article, and I have always had curiosity about Ada -- beyond some of the more modern languages in fact -- but I just don't see where Ada separates interface from implementation in a manner that's distinctly better or different from e.g. JavaScript modules.

Re: Ada, its design, and the language that built the languages

#134

> The verbosity was deliberate — Ichbiah wanted programs to be readable by people other than their authors, and readability over time favours explicitness — but it was experienced as bureaucratic and un-hacker-like, and the programming culture that formed in the 1980s and 1990s was organised around the proposition that conciseness was sophistication. Ada was the language of procurement officers. C was the language of…

Not really. That was written by someone who doesn't really know the language and is writing from a position of hearsay. Ada is "verbose" in that it has fairly rigorous type specification. It was verbose in comparison to languages that had weak or primitive typing. A lot of the "bureaucracy" in the language is being very specific about types to catch bugs. Ada 83 did have a problem in that it lacked [interfaces]. This…

https://ada-lang.io/docs/learn/lang/being-more-terse

Re: Ada, its design, and the language that built the languages

#135

Earlier quoted context omitted.

I always found it funny when Rust came about, I can't help but feel like, and maybe I'm misremembering when I deep dove Ada the first time, Ada was our first "Rust" like language, maybe Delphi / Pascal is the only other really close one that became mainstream enough before Rust did?

Rust emerged from the language enthusiast community not a formal industry committee and in some ways that was its superpower. I and many others have looked at Ada with some appreciation for decades. But the actual "community" around the language was foreign to me; government, defense contractors, etc places that frankly wouldn't even hire me. It's got appealing constructs, and I grew up with the Wirth languages so I…

I agree, as someone who is fascinated by it. I worked for a defense contracting company, and no even they used it. It's such a strange gem of a language, so much potential lost.

Re: Ada, its design, and the language that built the languages

#136
I find multiple "strange" flaws with the article, even for my appreciation of Ada _and_ the article as an essay:

* The article claims only Ada has true separation of implementation vs specification (the interface), but as far as I am able to reason, also e.g. JavaScript is perfectly able to define "private" elements (not exported by an ES6 module) while being usable in the module that declares them -- if this isn't "syntactical" (and semantical) separation like what is prescribed to Ada, what is the difference(s) the article tries to point out?

* Similarly, Java is mentioned where `private` apparently (according to the article) makes the declaration "visible to inheritance, to reflection, and to the compiler itself when it checks subclass compatibility" -- all of which is false if I remember my Java correctly -- a private declaration is _not_ visible to inheritance and consequently the compiler can ignore it / fast-track in a subclass since it works much the same as it has, in the superclass, making the "compatibility" a guarantee by much the same consequence

I am still reading the article, but having discovered the above points, it detracts from my taking it as seriously as I set out to -- wanting to identify value in Ada that we "may have missed" -- a view the article very much wants to front.

Re: Ada, its design, and the language that built the languages

#137

The article states, quoting: "JavaScript's module system — introduced in 2015, thirty-two years after Ada's — provides import and export but no mechanism for a type to have a specification whose representation is hidden from importers." Then: "in Ada, the implementation of a private type is not merely inaccessible, it is syntactically absent from the client's view of the world." Am I missing something -- a JavaScript…

Assuming we’re talking about TypeScript here, because JavaScript doesn’t have exportable types… Any instance in JavaScript, whether or not its type is exported, is just an object like any other, that any other module is free to enumerate and mess with once it receives it. In Ada there are no operations on an instance of a private type except the ones provided by the source module.

In other words, if module X returns a value x of unexported type T to module Y, code in module Y is free to do x.foo = 42.

Re: Ada, its design, and the language that built the languages

#138

Earlier quoted context omitted.

You could do the same in reverse as well. Many of the features listed in the first paragraph existed before in other languages, though probably not all of them in a single language. In fact, I believe the design process (sensibly) favored best practices of existing languages rather than completely new and unproven mechanisms. So there was considerable borrowing from PASCAL, CLU, MODULA(-2), CSP. It's possible that th…

Ada has borrowed nothing from Modula. There are features common to Ada and Modula, but those have been taken by both languages from Xerox Mesa. The first version of Modula was designed with the explicit goal of making a simple small language that provided a part of the features of Xerox Mesa (including modules), after Wirth had spent a sabbatical year at Xerox. Nowadays Modula and its descendants are better known tha…

Mesa was my first language that I used out of Collage for the seven years that I worked on the Xerox Star document editor. The job where I learned more in 6 months than I did in 4 years of collage or my entire working career afterwords.

It was by far the best language that I used for my entire working career where I had to endure such languages as PL/1 (and PL/S), C, C++, Java, JavaScript and PHP. While Java as a lang was not too bad it still paled in features and usability compared to MESA and it too was influenced by MESA.

But as was true at Xerox was it was the complete network that was revolutionary at the time in the early 80’s. The fact that I could source debug any machine remotely on the corporate would wide network of over 5000 machine and that the source code would be automatically done loaded to my machine (mean I could easily debug from any nearby random machine) was just something I could never “easily’ do elsewhere.

MESA was missing a few things (which CEDAR solved and used generally within only Xerox PARC partially because at the time it really only ran on Dorado class machine) such as Garbage collection and in the case of Star it would have been much better if the language supported OOP. For Star we had had a system called Traits to support objects but it had some serious issues IMHO (which would be fodder for a separate post.)

When talking about Mesa you also need to talk about Tajo, its development environment built onto- of the OS Pilot (Star also used Pilot.) But systems also supported a mouse and a large bitmapped monitor and had overlapping windows (although most of Star have automatic non overlapping windows that was a UI usability decision.)

There is also more because the network was very important. Print severs, file servers, mail servers, cloudless store for all of Star’s user files/desktop. All this in the very early 80’s was unheard of elsewhere. It’s very similarly to what Steve Jobs missed when he saw Smalltalk where he only really saw a new UI and missed much more that was demoed.

It was a magic place to work at the time, I had left in the very late 80s for Apple and it was a huge step backwards at the time (but did amazing stuff with their limited tools but made working not fun.)

Re: Ada, its design, and the language that built the languages

#139

It'd be a neat trick to have a single unified language which could bridge the gap between software and hardware description languages.

I’ve written some bit-banged serial drivers in Ada. It’s not exactly VHDL, but it rhymes.

https://github.com/JeremyGrosser/softdev/tree/master/src

Re: Ada, its design, and the language that built the languages

#140

Ada was also ignored because the typical compiler cost tens of thousands of dollars. No open source or free compiler existed during the decades where popular languages could be had for free. I think that is the biggest factor of all.

Given some of the other issues, I’m not sure it would have mattered, but it certainly didn’t even allow the experiment to be run. I would not have wanted to compile Ada in the 1980s on that hardware. Given all the checking, the compiler must have been horribly slow (imagine compiling Rust on that same 1980s hardware).

I was student between 1990 and 1993 and Ada was the main language. Compilation speed was not an issue. I remember that Eiffel was very slow to compile, but not Ada. Between 1994 and 1999, I have worked with Ada on Vax machines. The full recompilation took 2 hours because the machine was slow, not because of the language. Other languages were similarly slow (pascal, C). C was slow because of the lack of precompiled headers (many headers had to be parsed many times). With Ada (alsys ada), there were "libraries" that were black boxes directories containing object code and already parsed package specifications. Between 1999 and 2002, I have handled projects in Ada, C++ and Java. C++ was slightly slower than Ada (slow link). Java was a lots faster. Nowadays, Ada compilation is faster than C++.
Post reply on HN