7 ms·

Classes Are Making Me Sad

53 points by acconrad 10y ago

Willson50 10y ago
Javascript is making you sad.
bekimdisha 10y ago
Javascript is making you sad.
gadtfly 10y ago
Whoever at Netscape vetoed Scheme as the browser language should be on trial in The Hague.
- msvan 10y ago
  https://news.ycombinator.com/item?id=2784453 https://news.ycombinator.com/item?id=2784453
- kazinator 10y ago
  The short story has it that it was some Java-pushing dickheads from Sun Microsystems.
  - kazinator 10y ago
    You may dislike my tone, but it is basically factual. https://news.ycombinator.com/item?id=9098367 https://news.ycombinator.com/item?id=9098367 Eich> I joined Netscape on April 4, 1995, to "do Scheme in the browser". Immediately I was out of luck on several fronts: Eich> [...] Eich> If there was to be a "scripting language", it had to look like Java. https://news.ycombinator.com/item?id=2786720 https://news.ycombinator.com/item?id=2786720 Eich> Remember, I was recruited to "do Scheme", which felt like bait and switch in light of the Java deal brewing by the time I joined Netscape.
    - LyndsySimon 10y ago
      Cool. This explains why the better I understood Clojure, the more my Javascript started to look lispy.
- nine_k 10y ago
  They were in an uncomfortable position. They had to add scripting capabilities, and be first at it (else MS would be the first). They had to make the language instantly understandable by an average programmer — that is, someone who has a Basic / Pascal / C / Java / Perl background, and an hour of time to get acquainted and like the language. So they created a scripting language with a familiar C-like syntax, very few restraints, and a bunch of "convenient" magic that helped a person to create a simple animation in the browser on their very first day, by mashing things together. This was a terrible strategy to create a nice language for safe and comfortable development of large applications, especially full desktop applications 20 years from the inception date. It was a very well-working strategy to get mass adoption in no time, and own the market the same year in the face of mighty competition. This is what business cared about, and this allowed Netscape to stay successful for a few more years. Alas. Now we have WebAssembly (which resembles a stripped-down JVM from 25 years ago), and soon will be able to efficiently compile our favorite "real" language to run in the browser not through JavaScript.
throwawaysed 10y ago
Having used JS along with somewhere north of 10 other languages over the years... JS is the most painful, even moreso than Perl which was close. Classes and objects are 100x better than the crap they've come up with to fix JS so far so stop complaining. Oh no it's not functional???!!! Javascript never was. It was always supposed to be an OO language the implementation is just shit. For the love of God everyone just shut up and let them fix it. Trying to change JS from what it was meant to be into something else entirely is just going to make things even worse
d--b 10y ago
Dude classes are making you sad? Man, you should shield up, _a lot_ of things beyond classes are going to make you sad. Classes and javascript are a history between 2 different clans fighting together and no one winning, but it's still javascript. Not a huge deal if it's shittier than it already is. I like the language don't get me wrong, but there is so much in there that's unpleasant, that another construct shouldn't affect you much.
ng12 10y ago
As someone who works mostly in React I've never found a use for classes. It's a contentious, messy feature that solves problems I don't have. I used Coffeescript classes in the old jQuery/Backbone days and they were useful only because the rest of the ecosystem was so terrible.
- Lazare 10y ago
  > As someone who works mostly in React I've never found a use for classes. You can't NOT use classes if you use React. [Edit: For components with state] your syntax choices are: Foo = React.createClass({}) Or: class Foo extends React.Component {} But both are examples of JS classes; it's just a question of whether you use the class keyword or not. Every React component [Edit: with state] is a class. Edit: Fixed silly error; obviously you can use stateless functional components and I do all the time, but you can't avoid classes with React.
  - ng12 10y ago
    Sure, I do define classes but that's because React expects it -- I don't actually use them as classes. My React classes would function the same as plain old objects. I never use constructors, or inheritence, or new, or any of the features mentioned in this post.
  - shepmaster 10y ago
    I tend to heavily favor functional components[1]: function Welcome(props) { return <h1>Hello, {props.name}</h1>; } or a little nicer: const Welcome = ({ name }) => ( <h1>Hello, {name}</h1> ) [1]: https://facebook.github.io/react/docs/components-and-props.html#functional-and-class-components https://facebook.github.io/react/docs/components-and-props.h...
    - Lazare 10y ago
      Sorry, typed too fast. Edited my answer to clarify.
  - armandososa 10y ago
politician 10y ago
Try Elm?
- shp0ngle 10y ago
  I am missing Go, Rust and Haskell in this thread.
  - cies 10y ago
    And since you reply on a comment mentioning Elm, I think PureScript (feature-wise it's more Haskell-like, also more general purpose) deserves a mention as well. http://www.purescript.org/ http://www.purescript.org/
- mixedCase 10y ago
  Not OP, but I just finished a small trial phase with it. There's no straightforward way to make nested record updates. You have to write separate setter functions for every step of the way. If you don't list every single mutation in a single type, and have a single update function to handle them all, you're in for an exhorbitant amount of boilerplate to wire it all. Long, single file types and functions with Objective-C style namespacing are idiomatic. All is good error wise, until you have to use the escape hatch to JavaScript, in which case good luck building a separate castle of abstractions to fit both of them together and debug it. There's also the fact that the language creator has to bless a set of bindings before they're allowed to be packaged and uploaded. I do not know how this works out in practice, but it certainly made me raise my eyebrows and not in a good way. In summary: It's a promising language, but using it to build large codebases either involves techniques the community doesn't know about or it's an exercise in masochism. Maybe in a few years it'll be good.
  - politician 10y ago
    Thanks for the insight; we're also evaluating Elm, but our code base isn't large, and we committed to using flat records. Good point about the nested record handling.
bradmwalker 10y ago
How much energy will be spent thrusting this regressive pig?
- CharlesW 10y ago
  More than will be spent thrusting all other barnyard animals combined?
shp0ngle 10y ago
Every time I think I understand Javascript, I read something about its prototypes and constructors and how 'new' and 'this' works and I am lost again. The thing I like about classes is I vaguely understand what is going on and why, coming from Java and similar. So I am using them, together with Flow typechecking. I am not saying the javascript prototype logic is bad, just that I never understood it, even when I work in Javascript for years. Sometimes I understand, for a brief moment, "how", but never "why".
- Ghostium 10y ago
  Maybe this could help: https://github.com/getify/You-Dont-Know-JS/blob/master/this%20&%20object%20prototypes/README.md#you-dont-know-js-this--object-prototypes https://github.com/getify/You-Dont-Know-JS/blob/master/this%...
  - shp0ngle 10y ago
    Yeah, I always understand "how" from books like this, but not "why". Why is javascript like that? More to the point, what is the reason for prototype-based inheritance, what is its benefit, what more can you do with it than with C++/java, where does it make life easier.
- jaredsohn 10y ago
  I would encourage you to read https://github.com/getify/You-Dont-Know-JS https://github.com/getify/You-Dont-Know-JS (ideally all of it, but start by doing searches for 'class', 'prototype', etc.) Edit: Funny to see someone else post a link to the same book at the same time :)
- iamjs 10y ago
  > The thing I like about classes is I vaguely understand what is going on [...] I am not saying the javascript prototype logic is bad, just that I never understood it, even when I work in Javascript for years. But by using classes, you're still using prototypes, it just isn't as immediately apparent.
  - 10y ago
omegbule 10y ago
There isn't really a need for classes...
BuuQu9hu 10y ago
If only ES were more like E or Monte, where there are no classes and no `this`.
taurath 10y ago
I'd love if we could have a better conversation about JavaScript than "the language is bad and if you like it in any way you should feel bad" but seemingly not today. To create a bit to the discussion, I feel like the class abstraction in ES2015 is mostly a mask that doesn't do people any favors - it makes one think they know what is happening but leads experienced programmers to false reasoning and much head banging. I've highly preferred a more functional style for most of my projects and teams - I wish there were better standard tools for enforcing style, as organizationally it's harder to get everyone on the same page than with more mature OOP tooling (which OOP patterns/strong typing makes easier to build).
- LyndsySimon 10y ago
  > I feel like the class abstraction in ES2015 is mostly a mask that doesn't do people any favors I agree completely. When I first read the ES2015 draft, I was excited to see the class syntax. I assumed that it meant that JS was getting "traditional" inheritance, and it seems like a lot of others did too. That illusion was shattered shortly after beginning to use it. Now, instead of thinking "Hey, these weird objects that I barely understand how I created don't behave as I expect! Javascript is different.", I think a lot of less experienced developers end up thinking "Hey, these objects don't behave as I expect. Javascript sucks."
- jackmott 10y ago
  Seems like you kind of agree it is bad.
- rocqua 10y ago
  Really, the largest problem I see in javascript is exactly how it doesn't have a lot of features to enforce style. Sure, there is some other wonky stuff, but the ease with which one can write bad javascript is the core issue.
  - treehau5 10y ago
    This is a relatively solved problem with a proper .eslintrc and a style guide. You can pick two of the most popular -- airbnb or standardjs, npm install their eslint rules, and go on your merry way. Rolling your own and/or extending these is relatively simple.
camus2 10y ago
> Classes Are Making Me Sad And they are in the spec. It's too late to be sad about that, people are going to use them and they should.
dongslol 10y ago
JavaScript is not an object-oriented language, but a prototypical one. JS "classes" are really an attempt to use syntactic sugar to beat one concept into another. This is inherently ugly. For anyone convinced they hate JS, I encourage looking through Crockford's JavaScript: The Good Parts, in which he talks about the idea mentioned above, before swearing off JS forever.
- dragonwriter 10y ago
  > JavaScript is not an object-oriented language, but a prototypical Prototypical languages are a subset of OO languages, despite the fact the the industrial popularity of a handful of class-based OO languages (especially C++ and it's descendants) starting in the late 1980s have made it so that many people confuse OO with specifically class-based OO.
  - munificent 10y ago
    The first object-oriented languages—Simula and Smalltalk—were class-based, so when "object-oriented programming" was coined, it implicitly included classes. Every OOP language had classes. Only later when Self came out was the term broadened to include languages oriented around objects without classes. Sure, we need to be more precise today and refer to "class-based object-oriented" and "prototypal object-oriented", but that's not a fault of the class-based languages. They laid claim to the general term first. Before horseless carriages, all carriages had horses, so it seems unreasonable to expect people to have presciently called them "horseful carriages" even before automobiles were invented.
    - Diederich 10y ago
      http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." Simula has classes, but Alan Kay's "object oriented" wasn't about classes at all.
- camus2 10y ago
codecurve 10y ago
Wonder what the language would now look like if we had some dedicated syntax for Object.create instead of hiding the underlying prototype mechanism under the familiar class syntax. typeof (class {}) === "function" This is almost guaranteed to be a future WAT[1] moment for the next generation of JavaScript programmers. I can already see that a big part of the appeal for classes is that they keep your code looking neat and succinct (as opposed to throwing .prototype and Object.create all over the place. I'd much rather be writing code that looked something like the below, than having to think about super, static, own properties, constructors, private fields etc. // provided by some view library let Component = { state: null, setState(state) { Object.assign(this.state, state); this.forceUpdate(); } // ... } let Counter is Component { get state() { return { count: 0 }; }, inc() { let { count } = this.state; let { step } = this.props; this.setState({ count: count + step }); }, render() { let { count } = this.state; return <button onClick={this.inc}>{count}</button>; } } render(<Counter step={2} />); Although it introduces a new keyword, the abstraction ends up being minimal, because it's just a sugar for the existing Object.create. // let Counter is Component let Counter = Object.create(Component); This is obviously a very half baked idea, but I have programmed quite happily with Object.create for a long time without ever _needing_ to use classes. If we had better tools for working with prototypes then maybe we wouldn't have to pretend the language had classes instead. [1]: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
SFJulie 10y ago
Me I am sad about how unreliable comparison operators are. We fix equality by using === instead of ==. == is so bad that it is not transitive if a==b && b==c you are not sure c==a And everytime we use <, <=, >, >=, cmp we are back at using == implicitly, which triggers so many problems and bugs (and sort relies on them, thus sort is also broken). If a language cannot do simple math correctly, it should never be used for stuffs related to commercial transactions or security... anything serious.
golergka 10y ago
I always thought that Javascript kind of is modern Lisp, apart from all the parens. Radical freedom means everybody implements their own classes, promises, all kind of stuff that is out of the box in other languages — which makes us happy because we can play with it, but then makes everybody unhappy when we try to bring our toys together. And when somebody gets their way in deciding what is the _right_way_ to play, all the rest of us get even more unhappy.
guilhas 10y ago
Comunism for you then. Let's end the class struggle! PS: This comment does not intend to be productive in any way.

53 points by acconrad 10y ago

Willson50 10y ago

Javascript is making you sad.

bekimdisha 10y ago

Javascript is making you sad.

gadtfly 10y ago

Whoever at Netscape vetoed Scheme as the browser language should be on trial in The Hague.

msvan 10y ago
https://news.ycombinator.com/item?id=2784453 https://news.ycombinator.com/item?id=2784453
kazinator 10y ago
The short story has it that it was some Java-pushing dickheads from Sun Microsystems.
- kazinator 10y ago
  You may dislike my tone, but it is basically factual. https://news.ycombinator.com/item?id=9098367 https://news.ycombinator.com/item?id=9098367 Eich> I joined Netscape on April 4, 1995, to "do Scheme in the browser". Immediately I was out of luck on several fronts: Eich> [...] Eich> If there was to be a "scripting language", it had to look like Java. https://news.ycombinator.com/item?id=2786720 https://news.ycombinator.com/item?id=2786720 Eich> Remember, I was recruited to "do Scheme", which felt like bait and switch in light of the Java deal brewing by the time I joined Netscape.
  - LyndsySimon 10y ago
    Cool. This explains why the better I understood Clojure, the more my Javascript started to look lispy.
nine_k 10y ago
They were in an uncomfortable position. They had to add scripting capabilities, and be first at it (else MS would be the first). They had to make the language instantly understandable by an average programmer — that is, someone who has a Basic / Pascal / C / Java / Perl background, and an hour of time to get acquainted and like the language. So they created a scripting language with a familiar C-like syntax, very few restraints, and a bunch of "convenient" magic that helped a person to create a simple animation in the browser on their very first day, by mashing things together. This was a terrible strategy to create a nice language for safe and comfortable development of large applications, especially full desktop applications 20 years from the inception date. It was a very well-working strategy to get mass adoption in no time, and own the market the same year in the face of mighty competition. This is what business cared about, and this allowed Netscape to stay successful for a few more years. Alas. Now we have WebAssembly (which resembles a stripped-down JVM from 25 years ago), and soon will be able to efficiently compile our favorite "real" language to run in the browser not through JavaScript.

throwawaysed 10y ago

Having used JS along with somewhere north of 10 other languages over the years... JS is the most painful, even moreso than Perl which was close. Classes and objects are 100x better than the crap they've come up with to fix JS so far so stop complaining. Oh no it's not functional???!!! Javascript never was. It was always supposed to be an OO language the implementation is just shit. For the love of God everyone just shut up and let them fix it. Trying to change JS from what it was meant to be into something else entirely is just going to make things even worse

d--b 10y ago

Dude classes are making you sad? Man, you should shield up, _a lot_ of things beyond classes are going to make you sad. Classes and javascript are a history between 2 different clans fighting together and no one winning, but it's still javascript. Not a huge deal if it's shittier than it already is. I like the language don't get me wrong, but there is so much in there that's unpleasant, that another construct shouldn't affect you much.

ng12 10y ago

As someone who works mostly in React I've never found a use for classes. It's a contentious, messy feature that solves problems I don't have. I used Coffeescript classes in the old jQuery/Backbone days and they were useful only because the rest of the ecosystem was so terrible.

Lazare 10y ago
> As someone who works mostly in React I've never found a use for classes. You can't NOT use classes if you use React. [Edit: For components with state] your syntax choices are: Foo = React.createClass({}) Or: class Foo extends React.Component {} But both are examples of JS classes; it's just a question of whether you use the class keyword or not. Every React component [Edit: with state] is a class. Edit: Fixed silly error; obviously you can use stateless functional components and I do all the time, but you can't avoid classes with React.
- ng12 10y ago
  Sure, I do define classes but that's because React expects it -- I don't actually use them as classes. My React classes would function the same as plain old objects. I never use constructors, or inheritence, or new, or any of the features mentioned in this post.
- shepmaster 10y ago
  I tend to heavily favor functional components[1]: function Welcome(props) { return <h1>Hello, {props.name}</h1>; } or a little nicer: const Welcome = ({ name }) => ( <h1>Hello, {name}</h1> ) [1]: https://facebook.github.io/react/docs/components-and-props.html#functional-and-class-components https://facebook.github.io/react/docs/components-and-props.h...
  - Lazare 10y ago
    Sorry, typed too fast. Edited my answer to clarify.
- armandososa 10y ago

politician 10y ago

Try Elm?

shp0ngle 10y ago
I am missing Go, Rust and Haskell in this thread.
- cies 10y ago
  And since you reply on a comment mentioning Elm, I think PureScript (feature-wise it's more Haskell-like, also more general purpose) deserves a mention as well. http://www.purescript.org/ http://www.purescript.org/
mixedCase 10y ago
Not OP, but I just finished a small trial phase with it. There's no straightforward way to make nested record updates. You have to write separate setter functions for every step of the way. If you don't list every single mutation in a single type, and have a single update function to handle them all, you're in for an exhorbitant amount of boilerplate to wire it all. Long, single file types and functions with Objective-C style namespacing are idiomatic. All is good error wise, until you have to use the escape hatch to JavaScript, in which case good luck building a separate castle of abstractions to fit both of them together and debug it. There's also the fact that the language creator has to bless a set of bindings before they're allowed to be packaged and uploaded. I do not know how this works out in practice, but it certainly made me raise my eyebrows and not in a good way. In summary: It's a promising language, but using it to build large codebases either involves techniques the community doesn't know about or it's an exercise in masochism. Maybe in a few years it'll be good.
- politician 10y ago
  Thanks for the insight; we're also evaluating Elm, but our code base isn't large, and we committed to using flat records. Good point about the nested record handling.

bradmwalker 10y ago

How much energy will be spent thrusting this regressive pig?

CharlesW 10y ago
More than will be spent thrusting all other barnyard animals combined?

shp0ngle 10y ago

Every time I think I understand Javascript, I read something about its prototypes and constructors and how 'new' and 'this' works and I am lost again. The thing I like about classes is I vaguely understand what is going on and why, coming from Java and similar. So I am using them, together with Flow typechecking. I am not saying the javascript prototype logic is bad, just that I never understood it, even when I work in Javascript for years. Sometimes I understand, for a brief moment, "how", but never "why".

Ghostium 10y ago
Maybe this could help: https://github.com/getify/You-Dont-Know-JS/blob/master/this%20&%20object%20prototypes/README.md#you-dont-know-js-this--object-prototypes https://github.com/getify/You-Dont-Know-JS/blob/master/this%...
- shp0ngle 10y ago
  Yeah, I always understand "how" from books like this, but not "why". Why is javascript like that? More to the point, what is the reason for prototype-based inheritance, what is its benefit, what more can you do with it than with C++/java, where does it make life easier.
jaredsohn 10y ago
I would encourage you to read https://github.com/getify/You-Dont-Know-JS https://github.com/getify/You-Dont-Know-JS (ideally all of it, but start by doing searches for 'class', 'prototype', etc.) Edit: Funny to see someone else post a link to the same book at the same time :)
iamjs 10y ago
> The thing I like about classes is I vaguely understand what is going on [...] I am not saying the javascript prototype logic is bad, just that I never understood it, even when I work in Javascript for years. But by using classes, you're still using prototypes, it just isn't as immediately apparent.
- 10y ago

omegbule 10y ago

There isn't really a need for classes...

BuuQu9hu 10y ago

If only ES were more like E or Monte, where there are no classes and no `this`.

taurath 10y ago

I'd love if we could have a better conversation about JavaScript than "the language is bad and if you like it in any way you should feel bad" but seemingly not today. To create a bit to the discussion, I feel like the class abstraction in ES2015 is mostly a mask that doesn't do people any favors - it makes one think they know what is happening but leads experienced programmers to false reasoning and much head banging. I've highly preferred a more functional style for most of my projects and teams - I wish there were better standard tools for enforcing style, as organizationally it's harder to get everyone on the same page than with more mature OOP tooling (which OOP patterns/strong typing makes easier to build).

LyndsySimon 10y ago
> I feel like the class abstraction in ES2015 is mostly a mask that doesn't do people any favors I agree completely. When I first read the ES2015 draft, I was excited to see the class syntax. I assumed that it meant that JS was getting "traditional" inheritance, and it seems like a lot of others did too. That illusion was shattered shortly after beginning to use it. Now, instead of thinking "Hey, these weird objects that I barely understand how I created don't behave as I expect! Javascript is different.", I think a lot of less experienced developers end up thinking "Hey, these objects don't behave as I expect. Javascript sucks."
jackmott 10y ago
Seems like you kind of agree it is bad.
rocqua 10y ago
Really, the largest problem I see in javascript is exactly how it doesn't have a lot of features to enforce style. Sure, there is some other wonky stuff, but the ease with which one can write bad javascript is the core issue.
- treehau5 10y ago
  This is a relatively solved problem with a proper .eslintrc and a style guide. You can pick two of the most popular -- airbnb or standardjs, npm install their eslint rules, and go on your merry way. Rolling your own and/or extending these is relatively simple.

camus2 10y ago

> Classes Are Making Me Sad And they are in the spec. It's too late to be sad about that, people are going to use them and they should.

dongslol 10y ago

JavaScript is not an object-oriented language, but a prototypical one. JS "classes" are really an attempt to use syntactic sugar to beat one concept into another. This is inherently ugly. For anyone convinced they hate JS, I encourage looking through Crockford's JavaScript: The Good Parts, in which he talks about the idea mentioned above, before swearing off JS forever.

dragonwriter 10y ago
> JavaScript is not an object-oriented language, but a prototypical Prototypical languages are a subset of OO languages, despite the fact the the industrial popularity of a handful of class-based OO languages (especially C++ and it's descendants) starting in the late 1980s have made it so that many people confuse OO with specifically class-based OO.
- munificent 10y ago
  The first object-oriented languages—Simula and Smalltalk—were class-based, so when "object-oriented programming" was coined, it implicitly included classes. Every OOP language had classes. Only later when Self came out was the term broadened to include languages oriented around objects without classes. Sure, we need to be more precise today and refer to "class-based object-oriented" and "prototypal object-oriented", but that's not a fault of the class-based languages. They laid claim to the general term first. Before horseless carriages, all carriages had horses, so it seems unreasonable to expect people to have presciently called them "horseful carriages" even before automobiles were invented.
  - Diederich 10y ago
    http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay... "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things." Simula has classes, but Alan Kay's "object oriented" wasn't about classes at all.
camus2 10y ago

codecurve 10y ago

Wonder what the language would now look like if we had some dedicated syntax for Object.create instead of hiding the underlying prototype mechanism under the familiar class syntax. typeof (class {}) === "function" This is almost guaranteed to be a future WAT[1] moment for the next generation of JavaScript programmers. I can already see that a big part of the appeal for classes is that they keep your code looking neat and succinct (as opposed to throwing .prototype and Object.create all over the place. I'd much rather be writing code that looked something like the below, than having to think about super, static, own properties, constructors, private fields etc. // provided by some view library let Component = { state: null, setState(state) { Object.assign(this.state, state); this.forceUpdate(); } // ... } let Counter is Component { get state() { return { count: 0 }; }, inc() { let { count } = this.state; let { step } = this.props; this.setState({ count: count + step }); }, render() { let { count } = this.state; return <button onClick={this.inc}>{count}</button>; } } render(<Counter step={2} />); Although it introduces a new keyword, the abstraction ends up being minimal, because it's just a sugar for the existing Object.create. // let Counter is Component let Counter = Object.create(Component); This is obviously a very half baked idea, but I have programmed quite happily with Object.create for a long time without ever _needing_ to use classes. If we had better tools for working with prototypes then maybe we wouldn't have to pretend the language had classes instead. [1]: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat

SFJulie 10y ago

Me I am sad about how unreliable comparison operators are. We fix equality by using === instead of ==. == is so bad that it is not transitive if a==b && b==c you are not sure c==a And everytime we use <, <=, >, >=, cmp we are back at using == implicitly, which triggers so many problems and bugs (and sort relies on them, thus sort is also broken). If a language cannot do simple math correctly, it should never be used for stuffs related to commercial transactions or security... anything serious.

golergka 10y ago

I always thought that Javascript kind of is modern Lisp, apart from all the parens. Radical freedom means everybody implements their own classes, promises, all kind of stuff that is out of the box in other languages — which makes us happy because we can play with it, but then makes everybody unhappy when we try to bring our toys together. And when somebody gets their way in deciding what is the _right_way_ to play, all the rest of us get even more unhappy.

guilhas 10y ago

Comunism for you then. Let's end the class struggle! PS: This comment does not intend to be productive in any way.