4 ms·

Many of the gotchas wouldn't ever show up if only people committed to writing JS as sensibly as they write their programs in other languages when they're being

Many of the gotchas wouldn't ever show up if only people committed to writing JS as sensibly as they write their programs in other languages when they're being forced to do things a certain way. But when it comes to JS and even other dynamic languages, people for some reason absolutely lose their minds, like a teenager whose parents are going out of town and are leaving them home by themselves overnight for the first time. I've seen horrendous JS from Java programmers, for example, that has made me think "Just... why? Why didn't you write the program you would have written (or already did write!) were you writing it in Java?" Like, "Yes, there are working JS programmers who do these kinds of zany things and make a real mess like this, but you don't have to, you know?" It's as if people are dead set on proving that they need the gutter bumpers and need to be sentenced to only playing rail shooters instead of the open world game, because they can't be trusted to behave responsibly otherwise. https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf

leptons 6y ago
Honestly this is really spot-on. I think part of the problem is people have heard that javascript is bad and just expect it to be bad, so they never really try to learn it and just copy and paste something that works and maybe expand on the bad examples when they should just be learning how to use javascript. Javascript requires some self-discipline, where other languages discipline you if you try to fuck things up yourself. It's kind of like a drunken sailor on leave going on a bender on-shore - the minute they leave the ship all bets are off. Some people just can't wrap their head around using weak/dynamic typing, because it loosens the rules. But that doesn't mean there aren't any rules. I code in a dozen other languages and Javascript is still my favorite because it's so easy to use, no boilerplate, and it doesn't give me any "gotchas" because javascript actually does follow some very basic easy to understand rules. The people that don't bother to learn those rules invariably shit on javascript. It's not fair, it's not real criticism. And practically all of the "examples" of bad javascript is almost always code that nobody should ever write, in any language, because it's just stupid to write code in those ways. But people think "aHa, aNoThEr 'gOtChA'" and the myth of javascript being somehow inferior continues. And to anyone who actually knows how easy javascript is to use, it just looks silly, pathetic, and obnoxious.
sergeykish 6y ago
That is simply not true, io language is prototype based yet it is simple to reason about, fix for JavaScript: Object = Object.prototype Function = Function.prototype That's how most dynamic languages work, no need for explanations, obvious assertions: Object.__proto__ === null Function.__proto__ === Object object = new Object.constructor object.__proto__ === Object object.constructor === Object.constructor object.toString === Object.toString object.private = function () { return 'hello' } Object.shared = function () { return 'world' } Object.constructor.static = function () { return '!' } It shows hidden complexity — what does instanceof mean? // Object instanceof Function Object.constructor.__proto__.constructor === Function.constructor // Object instanceof Object Object.constructor.__proto__.__proto__.constructor === Object.constructor // Function instanceof Function Function.constructor.__proto__.constructor === Function.constructor // Function instanceof Object Function.constructor.__proto__.__proto__.constructor === Object.constructor Why would anyone want this? Lets get rid of .constructor on both sides: Object.constructor.__proto__ === Function Object.constructor.__proto__.__proto__ === Object Function.constructor.__proto__ === Function Function.constructor.__proto__.__proto__ === Object Now it is obvious — constructor is a Function, Functions __proto__ is Object. JavaScript programmers jump through ".prototype" hoops which should not be exposed.
- pwdisswordfish4 6y ago
  ... what? This comment is incomprehensible. What does it have to do with the parent comment (besides exemplifying the "teenager left at home for the first time" and creating-a-mess stuff)? None of this crazy reflective, meta-level programming belongs in the LOB application logic of any program. Save it for your programmer workspace/REPL environment--which is something that 90+% of JS programmers aren't using anyway. They're all editing "dead" files in Visual Studio Code and SublimeText. > Object.constructor.__proto__.constructor === Function.constructor // Object instanceof Object ... and that's not even what instanceof means.
  - sergeykish 6y ago
    Do you ever type "prototype"? Do you ever type "prototype" in any language but JavaScript? How it differs from other languages accessing [[Prototype]] / class directly, not through constructor? I've thought that's caused by prototype inheritance, but no io language [1] prototype based yet easy to understand. The only difference — it does not hide [[Prototype]]. I've redefined Object and Function to show how it works. You would get same result in "dead" files. REPL to make it easy to reproduce. Imagine it is another language object.private = function () { return 'hello' } Object.shared = function () { return 'world' } Object.constructor.static = function () { return '!' } vs object.private = function() { return 'hello' } Object.prototype.shared = function () { return 'world' } Object.static = function () { return '!' } Can you see the difference? Or straight from io tutorial Contact = (class { constructor(name, address, city) { this.name = name this.address = address this.city = city } }).prototype holmes = new Contact.constructor("Holmes", "221B Baker St", "London") Contact.fullAddress = function() { return [this.name, this.address, this.city].join('\n') } holmes.fullAddress() No "prototype" (except from class but it can be redefined). > ... and that's not even what instanceof means. Thank you, it should check [[Prototype]] not constructor // Object instanceof Object Object.constructor.__proto__ === Function // Object instanceof Object Object.constructor.__proto__.__proto__ === Object // Function instanceof Function Function.constructor.__proto__ === Function // Function instanceof Object Function.constructor.__proto__.__proto__ === Object [1] https://iolanguage.org/ https://iolanguage.org/

leptons 6y ago

Honestly this is really spot-on. I think part of the problem is people have heard that javascript is bad and just expect it to be bad, so they never really try to learn it and just copy and paste something that works and maybe expand on the bad examples when they should just be learning how to use javascript. Javascript requires some self-discipline, where other languages discipline you if you try to fuck things up yourself. It's kind of like a drunken sailor on leave going on a bender on-shore - the minute they leave the ship all bets are off. Some people just can't wrap their head around using weak/dynamic typing, because it loosens the rules. But that doesn't mean there aren't any rules. I code in a dozen other languages and Javascript is still my favorite because it's so easy to use, no boilerplate, and it doesn't give me any "gotchas" because javascript actually does follow some very basic easy to understand rules. The people that don't bother to learn those rules invariably shit on javascript. It's not fair, it's not real criticism. And practically all of the "examples" of bad javascript is almost always code that nobody should ever write, in any language, because it's just stupid to write code in those ways. But people think "aHa, aNoThEr 'gOtChA'" and the myth of javascript being somehow inferior continues. And to anyone who actually knows how easy javascript is to use, it just looks silly, pathetic, and obnoxious.

sergeykish 6y ago

That is simply not true, io language is prototype based yet it is simple to reason about, fix for JavaScript: Object = Object.prototype Function = Function.prototype That's how most dynamic languages work, no need for explanations, obvious assertions: Object.__proto__ === null Function.__proto__ === Object object = new Object.constructor object.__proto__ === Object object.constructor === Object.constructor object.toString === Object.toString object.private = function () { return 'hello' } Object.shared = function () { return 'world' } Object.constructor.static = function () { return '!' } It shows hidden complexity — what does instanceof mean? // Object instanceof Function Object.constructor.__proto__.constructor === Function.constructor // Object instanceof Object Object.constructor.__proto__.__proto__.constructor === Object.constructor // Function instanceof Function Function.constructor.__proto__.constructor === Function.constructor // Function instanceof Object Function.constructor.__proto__.__proto__.constructor === Object.constructor Why would anyone want this? Lets get rid of .constructor on both sides: Object.constructor.__proto__ === Function Object.constructor.__proto__.__proto__ === Object Function.constructor.__proto__ === Function Function.constructor.__proto__.__proto__ === Object Now it is obvious — constructor is a Function, Functions __proto__ is Object. JavaScript programmers jump through ".prototype" hoops which should not be exposed.

pwdisswordfish4 6y ago
... what? This comment is incomprehensible. What does it have to do with the parent comment (besides exemplifying the "teenager left at home for the first time" and creating-a-mess stuff)? None of this crazy reflective, meta-level programming belongs in the LOB application logic of any program. Save it for your programmer workspace/REPL environment--which is something that 90+% of JS programmers aren't using anyway. They're all editing "dead" files in Visual Studio Code and SublimeText. > Object.constructor.__proto__.constructor === Function.constructor // Object instanceof Object ... and that's not even what instanceof means.
- sergeykish 6y ago
  Do you ever type "prototype"? Do you ever type "prototype" in any language but JavaScript? How it differs from other languages accessing [[Prototype]] / class directly, not through constructor? I've thought that's caused by prototype inheritance, but no io language [1] prototype based yet easy to understand. The only difference — it does not hide [[Prototype]]. I've redefined Object and Function to show how it works. You would get same result in "dead" files. REPL to make it easy to reproduce. Imagine it is another language object.private = function () { return 'hello' } Object.shared = function () { return 'world' } Object.constructor.static = function () { return '!' } vs object.private = function() { return 'hello' } Object.prototype.shared = function () { return 'world' } Object.static = function () { return '!' } Can you see the difference? Or straight from io tutorial Contact = (class { constructor(name, address, city) { this.name = name this.address = address this.city = city } }).prototype holmes = new Contact.constructor("Holmes", "221B Baker St", "London") Contact.fullAddress = function() { return [this.name, this.address, this.city].join('\n') } holmes.fullAddress() No "prototype" (except from class but it can be redefined). > ... and that's not even what instanceof means. Thank you, it should check [[Prototype]] not constructor // Object instanceof Object Object.constructor.__proto__ === Function // Object instanceof Object Object.constructor.__proto__.__proto__ === Object // Function instanceof Function Function.constructor.__proto__ === Function // Function instanceof Object Function.constructor.__proto__.__proto__ === Object [1] https://iolanguage.org/ https://iolanguage.org/