Objects Have Not Failed (2002) | Hacker News Reader

Objects Have Not Failed (2002)

dreamsongs.com

37 pointsmpweiher13 comments

Context:

I saw the other post (Objects have failed, https://news.ycombinator.com/item?id=34995359) and just so happen to know that these two are connected, they were the two starting positions of a panel discussion.

Presenting one without the other seemed...incomplete.

https://news.ycombinator.com/item?id=34996888

> As for C++–well, it reminds me of the Soviet-era labor joke: "They pretend to pay us, and we pretend to work." C++ pretends to provide an object-oriented data model, C++ programmers pretend to respect it, and everyone pretends that the code will work.

> and nearly 2/3 are using JavaScript (which at least tries to be object-oriented)

While Javascript is usually maligned fairly, in this case I think it's unfair. The JS design learned from Self that one of Smalltalk's accidental sources of complexity was having classes as an object-like piece of syntax when they can be built out of objects themselves. JS has a more object-oriented design than some of the other examples of "object-oriented languages" presented without comment in the article.

[As an aside: I don't think programming languages can be functional, object-oriented, or otherwise paradigmatic. I think program designs can have those properties, and programming languages can support or hinder expressing those properties clearly.]

This was from 2002, when most JavaScript was authored and consumed as "JavaScripts" - little opaque snippets you could download from places like dynamicdrive.com and paste into a script tag to add some kind of "dynamic" effect to a page (hide/show content on click, for example).

It was almost universally thought of as a toy language that wasn't even as good as VBScript.

It took David Flanagan's JavaScript: The Definitive Guide and Douglas Crockford's JavaScript: The Good Parts for people to begin taking it seriously. Prior to that, any serious client-side code was authored as a Java applet or in Flash.

> It took David Flanagan's JavaScript: The Definitive Guide and Douglas Crockford's JavaScript: The Good Parts for people to begin taking it seriously.

You're giving developer.mozilla.org (and the existence proof that is/was Firefox and other Mozilla toolkit applications) short shrift.

The wider world began taking JS even more seriously when the iPhone launched with the imprimatur that Safari was its SDK (even if that detail was eventually reversed and largely forgotten).

Also: thought of as a toy language, sure, but being considered one that "wasn't even as good as VBScript" is highly exaggerated.

Indeed; and I was talking about the Javascript "object model" as it existed at the time, not the ES5 thing that adds classes back in after we failed to teach JS developers what "this" is. Those little dynamic effects were, after all, working almost exclusively with the Document Object Model.

The object model hasn't changed -- ES5 classes are syntactic sugar on top of standard prototype-based JS classes :-)

It's true that the implementation model didn't change, but the conceptual model did: the new "class" thing lets people express designs containing what they call "classes" with "methods" even though what they're building is constructor functions that return objects where some of the properties are occupied by functions.

That kind of chicanery isn't unique to JS, by the way, which I mention because of the unfair malignment of JS in the original article. Smalltalk-80 syntactically has blocks, but the code in a block is just compiled into the surrounding method and the block invocation is a fancy GOTO statement.

The fact that you both refer to "ES5 classes", when in fact ES5 has no classes, is very relevant to the meta/epistemological aspects of this discussion and an indicator of whether or not some of the other remarks should be taken as authoritative truths.

My bad, I forgot when the class syntax was introduced. And yes, don't take my points as authoritative. Here's a more authoritative resource: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

sorry, on my keyboard 5 is right next to 6.

> and programming languages can support or hinder expressing those properties clearly.

Surely you would agree that if a language hinders one of such properties to extreme extent, then it would make sense to call such language "definitely non-[paradigm-name]"? For example, take Pascal without procedural/functional parameters: you can write functional programs, by manually applying defunctionalization and lambda-lifting... but it's so cumbersome that I'd argue such a dialect of Pascal is definitely not a functional language.

qualityposting B)

Reply on news.ycombinator.com