logoalt Hacker News

hackrmn • yesterday at 4:23 PM • 3 replies • view on HN

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.

Replies

init1 • yesterday at 9:19 PM

> 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.
➕ show 2 replies
layer8 • yesterday at 7:31 PM

The reflection part is true. Private members are accessible to reflection in Java. You can call setAccessible(true) and then modify the contents of a String, for example.

twoodfin • yesterday at 5:17 PM

LLMs are weaponized Gell-Mann amnesia when it comes to writing for humans.

➕ show 1 reply