Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

iqiipi.com

Post reply on HN
Print view View original

171–180 of 242 posts

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

#171

Post by hackrmn »

masfuerte wrote: post #166
hackrmn wrote: post #153

Earlier quoted context omitted.

Can't argue with that. But in defence of JavaScript -- since it enjoys routine bashing, not always undeserved -- it now has true runtime-enforced private members (the syntax is prefixing the name with `#`, strictly as part of an ES6 class declaration), but yeah -- this doesn't invalidate the statement "kind of got there 32 years after Ada, stumbling over itself".

JavaScript has supported real data hiding since the beginning using closures. You define your object in a function. The function's local variables act as the private members of the object. They are accessible to all the methods but completely inaccessible to consumers of the object.

I completely forgot about closures. Frankly, they're still my go-to method for encapsulation, in part because the Java-isation of JavaScript done with the private class members and the onslaught of the "Alan Kay's ideas meet Simula" OOP flavour, is relatively new and I am still unsure whether it's a critical thing to have in JavaScript.

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

#172

Post by adrian_b »

GhosT078 wrote: post #132
adrian_b wrote: post #115

Earlier quoted context omitted.

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.

Indeed, the fact that is not clear what scope is being ended by the closing bracket is very serious.

This is why much more bracket pairs are needed in a programming language than the 3 pairs provided by ASCII.

Ada uses many pairs of brackets, but most of them are implemented with keywords, for instance if => end if, loop => end loop, and so on.

These long keyword-based brackets can be replaced with various Unicode bracket pairs that are graphically distinct.

Such brackets, for instance angle brackets instead of "if"/"end if", take much less space and they are also much more salient than keywords, which for me improves a lot the readability of the text.

Even if you do not know before that how the brackets are assigned, by reading the text you can discover very quickly the correspondence, because you can recognize what kind of structure is started by a certain kind of bracket, and then you know that when you will see a closing bracket of the same shape that is the end of the structure.

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

#173

Post by blueybingo »

but why does "the industry ignored it" hold as the central framing when the actual story seems to be "the DoD mandated it, contractors used it, and it worked fine for exactly what it was built for"? the implicit assumption is that widespread adoption is the metric for a language succeeding, but ada wasnt trying to win over web developers, it was trying to stop missiles from being maintained in 450 incompatible dialects, which... it actaully did?

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

#174

Post by wrs »

hackrmn wrote: post #142
wrs wrote: post #137

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.

I think you're confusing values with types. JS modules can certainly keep a value private, but there's no way for them to expose an opaque type, because that concept simply doesn't exist in JS. The language only has a few types, and you don't get to make more of them. TypeScript adds a lot of type mechanism on top, but because it's restricted to being strippable from the actual JS code, it doesn't fundamentally change that.

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

#175

Post by init1 »

cestith wrote: post #156

I like Ada. I can’t believe this whole discussion about how types are handled missed the entire ML family of languages. ML, Standard ML, Concurrent ML, Caml, OCaml, and more have structural types, supported and enforced by the compiler. Ada has one of the same primary issues as PL/I, PHP, and Perl. As much as one might like it, it’s a huge language with loads of syntax and semantics baked into the core language. The…

As far as I can tell you cannot create your own bounded Integer/Floating point types in any of the ML languages. That's one example of one of the core Ada type features. Most people have never experienced a type system like Ada and you will be surprised by how it helps you write higher quality software that is also more reliable.

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

#176

Post by Jtsummers »

blueybingo wrote: post #173

but why does "the industry ignored it" hold as the central framing when the actual story seems to be "the DoD mandated it, contractors used it, and it worked fine for exactly what it was built for"? the implicit assumption is that widespread adoption is the metric for a language succeeding, but ada wasnt trying to win over web developers, it was trying to stop missiles from being maintained in 450 incompatible dialec…

> it was trying to stop missiles from being maintained in 450 incompatible dialects, which... it actaully did?

No, it didn't. The objective of consolidating DOD systems on Ada failed, the mandate was short-lived and exceptions were broadly available. Why make things up like this?

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

#177

Post by Raphael_Amiard »

leoc wrote: post #51
Raphael_Amiard wrote: post #34

Earlier quoted context omitted.

> Today, the criticism about complexity seems naive, because many later languages have become much more complex than Ada I don’t think you really understand what you’re saying here. I have worked on an ada compiler for the best part of a decade. It’s one of the most complex languages there is, up there with C++ and C#, and probably rust

Mind you, that suggests that the sentence is at least half-true even if "much more complex" is a big overstatement, since Rust, "modern" C++ and the later evolutions of C# are all relatively recent. (What would have compared to Ada in complexity back in the day? Common Lisp, Algol 68?) As a matter of general interest, what features or elements of Ada make it particularly hard to compile, or compile well? (And are the…

You're right in your first part. Ada 83 is less complex than modern C++ or Rust. However Ada kept evolving, and a lot of complexity was added in later revisions, such as Ada 95, which added a kind of bastardized and very complex Java style object model layer.

Ada features that are hard to compile are very common in the language. It is generally a language that is hard to compile to efficient code, because rules were conceived in an abstract notion of what safety is. But in general Ada is an extremely over specified language, which leaves very little space to interpretation. You can check the Ada reference manual if you want, which is a use 1000 pages book (http://www.ada-auth.org/arm.html)

* Array types are very powerful and very complicated * Tasking & threading are specified in the language, which seems good on paper, but the abstractions are not very efficient and of tremendous complexity to implement. * Ada's generic model is very hard to compile efficiently. It was designed in a way that tried to make it possible to compile down both to a "shared implementation" approach, as well as down to a monomorphized approach. Mistakes were done down the line wrt the specification of generics which made compiling them to shared generics almost impossible, which is why some compiler vendors didn't support some features of the language at all. * Ada scoping & module system is of immense complexity * The type system is very vast. Ada's name & type resolution algorithm is extremely complex to implement. functions can be overloaded on both parameters & return types, and there is a enclosing context that determines which overloads will be used in the end. On top of that you have preferences rules for some functions & types, subtyping, derived types, etc ...

This is just what comes to mind on a late Friday evening :) I would say that the language is so complex that writing a new compiler is one of those herculean efforts that reach similar heights as writing a new C++ compiler. That's just a fe

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

#178

Post by init1 »

hackrmn wrote: post #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 "…

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

This is false. For example in Ada you can write:

    package Foo
        type Bar is private;
        procedure Initialize (Item : in out Bar); 
    private
        type Bar is record
            Baz : Integer;
            Qux : Float;
        end record;
    end Foo;
Users of the Foo package know there is an opaque type called Bar. They can declare variables of the type, they can use the defined API to operate on it but they cannot reference the implementation defined private members (Baz, Qux) without compile errors. Yes Ada does give you the power and tools to in a very blatantly unsafe and obvious way cast it as another type or as an array of bytes or whatever but if you're doing stuff like that you have already given up.

In JavaScript there are no such protections. For example if you have a module with private class Bar and you export some functions that manipulate it:

    class Bar {
        constructor() {
            this.Baz = 420;
            this.Qux = 1337.69;
        }
    }
    export function Initialize() {
        return new Bar();
    }
In client code you have no issue inspecting and using the private values of that class:

    import { Initialize } from 'module';
    let myBar = Initialize();

    myBar.Baz = 42069; // works just fine
    Object.keys(myBar).forEach(console.log); // you can iterate parameters.
    myBar.Quux = 'Corge'; // add new parameters
    delete myBar.Baz; // I hope no functions rely on this...
Using the private parts of Bar should 100% be a compilation error and even the most broken languages would have it at least be a runtime error. Lmao JS.

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

#179

Post by Raphael_Amiard »

feelamee wrote: post #83
Raphael_Amiard wrote: post #34

Earlier quoted context omitted.

> Today, the criticism about complexity seems naive, because many later languages have become much more complex than Ada I don’t think you really understand what you’re saying here. I have worked on an ada compiler for the best part of a decade. It’s one of the most complex languages there is, up there with C++ and C#, and probably rust

what do you mean under Ada's complexity? E.g. C++ is really complex because of a lot of features which badly interoperate between themselves. Is this true for the Ada lang/compiler? Or do you mean the whole complexity of ideas included in Ada - like proof of Poincaré conjecture complex for unprepared person.

"Is this true for the Ada lang/compiler"

Yes, Ada has a lot of the same kind of fractal complexity that C++ has, which derives from unforeseen interaction of some features with some other.

On top of that, as I said in another comment, features are extremely overspecified. The standard specifies what has to be done in every edge case, often with a specification that is not very practical to implement efficiently

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

#180

Post by [deleted] »

init1 wrote: post #178
hackrmn wrote: post #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 "…

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

[deleted]
Post reply on HN