4 ms·
> 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 unfai
by grahamlee 4y ago
> 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.]
- TimTheTinker 4y agoThis 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.
- grahamlee 4y agoIndeed; 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.
- TimTheTinker 4y agoThe object model hasn't changed -- ES5 classes are syntactic sugar on top of standard prototype-based JS classes :-)
- cxr 4y agoThe 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.
- TimTheTinker 4y agoMy 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/Reference/Classes https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- grahamlee 4y agosorry, on my keyboard 5 is right next to 6.
- grahamlee 4y agoIt'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.
- cxr 4y ago> 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.
- Joker_vD 4y ago> 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.