7 ms·

What ways does do the wrong things by default? I can't think of a single one. You might say, well, == is broken and you have to use ===, but that's not "the wro

by sbjs 3y ago

What ways does do the wrong things by default? I can't think of a single one. You might say, well, == is broken and you have to use ===, but that's not "the wrong thing by default" unless you assume that == is what ought to be the default operator and === ought to be secondary. But that assumption has to come from somewhere, and probably comes from the fact that other languages do it that way. But there's nothing inherently incorrect about === being the default operator and == being the rare secondary one. I think the same principle applies to any example you might be able to give me: if you assume that another language is objectively right, only then can you say that JavaScript is objectively wrong in comparison to that language which apparently descended from the heavens.

david422 3y ago
Well === was added to make up for deficiencies in == so seems reasonable that saying == is the default that does things incorrectly.
wtetzner 3y ago
I would argue that implicit conversions in a dynamically typed language is a mistake in general. It's the "wrong thing by default" in the sense that it's too easy to write broken code by accident. And I think that's what is usually meant by "wrong thing by default". I think if you really want implicit conversions, then you want to do what Perl does (never thought I'd say that): different operators for different types.
mjburgess 3y ago
You're assuming a certain sort of perspectivalism: the only reasons X could be better than Y is that, from someone's pov, some language has X. This is kinda insane. People can give reasons X is better than Y on grounds of various theoretical virtues of X -- that has nothing to do with a preference for any language. Here's an example virute: Behaviour should be consistent unless specialised. When specialised it should be obvious which specialisation is chosen. (Violation: basically all of js' operators).
airstrike 3y ago
Exhibit A: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
claytongulick 3y ago
It's pretty easy to footgun when you're mixing event/callback based flow with promises/async. It's really easy to forget a closure in an event driven function and to produce difficult to debug, error prone code. A classic example I just screwed up: export function getSFTPConnection(options) { let key = readFileSync(options.keyfile_path, 'utf8'); let ssh = new ssh2.Client(); return new Promise( (resolve, reject) => { ssh.on('error', reject); ssh.on('ready', () => { ssh.sftp((err, sftp) => { resolve(sftp); }); }); ssh.on('close', (err) => { reject(new Error('SSH connection closed: ' + err)); }) ssh.connect( { host: options.host, username: options.username, privateKey: key, } ); } ) } The bug here isn't obvious, at least to me - but it caused me much heartache and pain because I was moving too fast and not thinking - but a good example of unexpected behavior by default. The bug is that there's not a closure around the ssh instance, so if you call this function multiple times it'll actually return the same connection instance. The extra fun part of this bug is that the code worked - but because I was using the same instance, when I'd download multiple files in parallel, it would interleave the data, corrupting the files. And the thing is, I know better. I've been doing js for decades. I love js, but stuff like this is pretty frustrating, and can be a nightmare for new devs.
- minitech 3y ago
  > The bug is that there's not a closure around the ssh instance, so if you call this function multiple times it'll actually return the same connection instance. I’m not entirely sure what you mean by this, but it doesn’t sound like a correct diagnosis. Each call to `getSFTPConnection` creates a new `ssh2.Client` instance (unless `ssh2.Client`’s constructor does something really weird), and the promise can only resolve with the value `ssh.sftp` passes. (The error handling does look broken, though – I would expect the 'error' event to be able to fire at any time, and the `ssh.sftp` callback is missing a check.)
  - claytongulick 3y ago
bee_rider 3y ago
== was already a silly operator, === is just ridiculous.
Dylan16807 3y ago
It's a huge stretch to claim that === isn't secondary to ==.

by sbjs 3y ago

david422 3y ago

Well === was added to make up for deficiencies in == so seems reasonable that saying == is the default that does things incorrectly.

wtetzner 3y ago

I would argue that implicit conversions in a dynamically typed language is a mistake in general. It's the "wrong thing by default" in the sense that it's too easy to write broken code by accident. And I think that's what is usually meant by "wrong thing by default". I think if you really want implicit conversions, then you want to do what Perl does (never thought I'd say that): different operators for different types.

mjburgess 3y ago

You're assuming a certain sort of perspectivalism: the only reasons X could be better than Y is that, from someone's pov, some language has X. This is kinda insane. People can give reasons X is better than Y on grounds of various theoretical virtues of X -- that has nothing to do with a preference for any language. Here's an example virute: Behaviour should be consistent unless specialised. When specialised it should be obvious which specialisation is chosen. (Violation: basically all of js' operators).

airstrike 3y ago

Exhibit A: https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat

claytongulick 3y ago

It's pretty easy to footgun when you're mixing event/callback based flow with promises/async. It's really easy to forget a closure in an event driven function and to produce difficult to debug, error prone code. A classic example I just screwed up: export function getSFTPConnection(options) { let key = readFileSync(options.keyfile_path, 'utf8'); let ssh = new ssh2.Client(); return new Promise( (resolve, reject) => { ssh.on('error', reject); ssh.on('ready', () => { ssh.sftp((err, sftp) => { resolve(sftp); }); }); ssh.on('close', (err) => { reject(new Error('SSH connection closed: ' + err)); }) ssh.connect( { host: options.host, username: options.username, privateKey: key, } ); } ) } The bug here isn't obvious, at least to me - but it caused me much heartache and pain because I was moving too fast and not thinking - but a good example of unexpected behavior by default. The bug is that there's not a closure around the ssh instance, so if you call this function multiple times it'll actually return the same connection instance. The extra fun part of this bug is that the code worked - but because I was using the same instance, when I'd download multiple files in parallel, it would interleave the data, corrupting the files. And the thing is, I know better. I've been doing js for decades. I love js, but stuff like this is pretty frustrating, and can be a nightmare for new devs.

minitech 3y ago
> The bug is that there's not a closure around the ssh instance, so if you call this function multiple times it'll actually return the same connection instance. I’m not entirely sure what you mean by this, but it doesn’t sound like a correct diagnosis. Each call to `getSFTPConnection` creates a new `ssh2.Client` instance (unless `ssh2.Client`’s constructor does something really weird), and the promise can only resolve with the value `ssh.sftp` passes. (The error handling does look broken, though – I would expect the 'error' event to be able to fire at any time, and the `ssh.sftp` callback is missing a check.)
- claytongulick 3y ago

bee_rider 3y ago

== was already a silly operator, === is just ridiculous.

Dylan16807 3y ago

It's a huge stretch to claim that === isn't secondary to ==.