Hacker News Reader

Comment by sbjs | Hacker News Reader

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.

View on HN

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.

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

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).

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.

> 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.)

Yes, you're 100% correct, I mixed some stuff up when I was posting the code for simplicity.

Bad example!

> 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.

You've either adjusted the code for posting or you misunderstood what the problem was, because no, that's not the case. The ssh variable is local to the getSFTPConnection function and is not reused between multiple calls to the function, and throwing a pointless extra closure in there wouldn't do anything.

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

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

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

Reply on news.ycombinator.com