1. 17
  1.  

  2. 14

    How different the world would’ve been if people had endeavored to understand what prototype-based inheritance was, rather than bolt class-based inheritance on top of it, or emulate it with dozens of different frameworks. (Admittedly, JavaScript didn’t make this easy with its bolting-on of Java-like syntax and its rather…interesting…mechanism of doing constructors.)

    (Look at Io if you want to see prototype-based inheritance done right. The guy who wrote it is a gifted programmer, though I’m pretty sure he and I sit at completely opposite ends of the political spectrum…)

    1. 5

      But prototype based inheritance in JS is just shit. It is badly implemented parody of Self, where it actually makes sense.

      1. 4

        Could you elaborate on the differences? I’ve never looked into the specifics of Self’s prototypical model, but am curious about how it compares with JS’s.

        1. 2

          I wrote a bit here about some of the differences between prototype based languages and Self.

          1. 1

            Great article, I forgot how nice Io’s syntax is. I had not heard of the “organising program without classes” before.

      2. 2

        If one programmer uses your language feature badly, maybe they’re a bad programmer. But if every programmer uses your language feature badly, it’s probably a bad language feature.

      3. 13

        Ha. Ha ha. HAHAHAHAHAHAHAHAHA.

        It’d be less funny if this shit wasn’t the bane of my career. Some folks tried to warn others about adding new cruft, but we were ignored and/or mocked.

        Anyways, a point the author doesn’t bring up that’s essential to proper vulgar-OOP (e.g., Enterpriesy heavily inheritance-based) stuff: there still is no way of properly handling visibility, for things like protected and private.

        Seriously, look at this abortion. Look. at. it.

        All that happy horseshit about modules and tree-shaking and all that, and I can’t make a for-real no-sharing private class method without resorting to acrobatics? Srsly?

        1. [Comment removed by author]

          1. 7

            Because this pig brings home the bacon.

            I agree with you, mind you, but the problem is that the quality of this tool is actively declining as they keep adding shit to the language. And to the ecosystem. And to the tooling.

            1. 2

              What better tools? If your use-case involves JS, there’s not much that can done about that.

              1. 12

                at the very least you can use typescript - it can at this point be considered not just viable but even “conservative” (in the “no one ever got fired for buying ibm” sense). it’s a strict improvement over javascript, can seamlessly consume existing javascript code, and the language itself is improving all the time (seriously, see the frequency of releases, each with an impressive changelog).

                1. 3

                  I’ll second the recommendation for TypeScript. I don’t feel as strongly about JS’s warts as angersock, but TypeScript definitely alleviates a lot of JavaScript’s worst problems.

                  1. 2

                    This encouraging to hear. I hope this becomes more commonplace over time.

                    I’m hesitantly very-much-for the static typing revolution. (But iff it increases security and programmer productivity).

                  2. 6

                    Things like this are the raw materials that fuel compile-to-js languages…

                    1. 3

                      That’s fair, although even in compile-to-js languages it is difficult to escape JS entirely.

                    2. 2

                      PureScript - only use JS via the FFI for performance or interop reasons.

                  3. 2

                    I’m not sure what kind of benefit you would get with having private/protected slots in a dynamic language. It’s mostly a compiler’s business to enforce access permissions, and there are plenty of transpilers with this kind of features to choose from.

                    I would have personally preferred JS to improve its core model and runtime so that transpilers can be implemented more efficiently, instead of adding sugar and complexity to a clunky language. Thank God, Webassembly is coming.

                    1. 3

                      Even Python can hide things from you, which is super useful if you want to alter an object’s state without exposing all the plumbing.

                      1. 1

                        Are you referring to the __ slot prefix? It’s not the same semantics as access protection, as in Python it will rewrite the slot name on assignment but it’s still going to be accessible afterwards (under the rewritten name). I’d be curious to know if you were thinking about another feature in Python that I’m not aware of.

                        1. 1

                          It’s that but accessing the rewritten name is obfuscated enough that it’s hidden for all intents and purposes, at least in my book.

                          I’d tend to agree that complete protection is a hassle/impossible without a compiler, but IMO the Python solution blows at least JS out of the water.

                    2. 1

                      Python, Perl, and Ruby don’t have private/protected either, so this is a thin argument to hang your hat on. There are much juicier targets when contemplating js flaws.

                      1. 0

                        Do i know you? You remind me of someone i know. Also, to answer your closing question: no, you can’t. Not that I’m aware of.