141–150 of 242 posts
Sadly the review meetings focused on document structure instead of thoughtful software design and analysis. ADA didn't help; it was cumbersome to get working well, and ADA experience in the contracting agencies was low. The waterfall approach made the projects slow to implement.
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…
To preempt the obvious: yes, I know _everything_ (nearly) in JavaScript is an object, but a module exporting a `Function` can expect the caller to use the function, not enumerate it for methods. And the function can use a declaration in the module that wasn't exported, with the caller none the wiser about it.
You define the interface, types, pre/post conditions you want in .ads file, then let the agent loose writing the .adb body file. The language’s focus on readability means your agent has no problem reading and cross referencing specs. The compiler and proof tools verify the body implements the spec.
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…
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.
The ADA compiler for OpenVMS was over $200,000 in the 1990s.
Earlier quoted context omitted.
That's a decade too late.
Let's just be honest that even if there was a free compiler in 1985 or earlier, there's no way that e.g. someone like Linus Torvalds or an RMS etc would have written various groundbreaking pieces of software on Ada. It was just in an entirely different headspace. I was around then, and culturally there just wasn't this (legitimate) concern with safety in the more "hacker" and Unix community generally. C won headspace…
Yes, I think this is key. I wasn't around in 1985, but on every attempt to write something in Ada I've found myself fighting its standard library more than using it. Ada's stdlib is an intersection of common features found in previous century's operating systems, and anything OS-specific or any developments from the last 30 years seem to be conspicuously absent. That wouldn't be so much of a problem if you could just extend the stdlib with OS-specific features, but Ada's abstractions are closed instead of leaky.
I'm sure that this is less of a problem on embedded systems, unikernels or other close-to-hardware software projects where you have more control over the stdlib and runtime; but as much as I like Ada's type system and its tasking model I would never write system applications in Ada because the standard library abstractions just get in the way.
To illustrate what I mean, look at the Ada.Interrupts standard library package [0] for interrupt handling, and how it defines an interrupt handler:
type Parameterless_Handler is
access protected procedure
with Nonblocking => False;
Ada's stdlib file operations suffer from closed enumerations: the file operations Create and Open take a File_Mode argument, and that argument is defined as [1]:
type File_Mode is (In_File, Inout_File, Out_File); -- for Direct_IO
type File_Mode is (In_File, Out_File, Append_File); -- for Stream_IO
Another example is GNAT.Sockets (not part of Ada stdlib), which defines these address families and socket types in a closed enum:
type Family_Type is (Family_Inet, Family_Inet6, Family_Unix, Family_Unspec);
type Mode_Type is (Socket_Stream, Socket_Datagram, Socket_Raw);
[0] https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-C-...
[1] https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-A-...
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…
Where it went wrong is in two areas: 1) as far as I know the 286 does not correct restart all instruction if they reference a segment that is not present. So swapping doesn't really work as well as people would like.
The big problem however was that in the PC market, 808[68] applications had access to all (at most 640 KB) memory. Compilers (including C compilers) had "far" pointers, etc. that would allow programs to use more than 64 KB memory. There was no easy way to do this in 286 protected mode. Also because a lot of programs where essentially written for CP/M. Microsoft and IBM started working on OS/2 but progress was slow enough that soon the 386 became available.
The 386 of course had the complete 286 architecture, which was also extended to 32-bit. Even when flat memory is used through paging, segments have to be configured.
When I was a young lad, must have been 20 I came across some programming books, including programming in Ada.
I read so much of it but never wrote a line of code in it, despite trying. Couldn't get the build environment to work.
But the idea of contracts in that way seemed so logical. I didn't understand the difference this article underpins though. I learned Java and thought interfaces were the same.
Great article, great language.
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 "…
Earlier quoted context omitted.
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…
* only if `x` is _an object_ (read: has methods) To preempt the obvious: yes, I know _everything_ (nearly) in JavaScript is an object, but a module exporting a `Function` can expect the caller to use the function, not enumerate it for methods. And the function can use a declaration in the module that wasn't exported, with the caller none the wiser about it.