Hacker News Reader

Comment by dccoolgai | Hacker News Reader

|JS is widely considered a pain.

I find that is widely enjoyed by the "silent majority" and decried as a pain by a very vocal subset of developers. It's a little surprising that 1 + '1' is '11', until you spend a little time and learn the rules instead of fighting them - then you start doing your work in a way that uses that to save time. It's not great for everyone, but I like it - and I know a lot of other good devs who prefer the answer '11' (when you understand the fairly simple rules) to 'OMFGNOIQUIT'. I find "Number beats bool, string beats number" for implicit coercions covers 95% of cases where it would actually matter. For the other 5%, just type it in the console.

Because I like it that way, doesn't mean you have to as well - but it also doesn't mean that because you don't like (or even most of the commenters on HN) it it is "widely considered a pain".

View on HN

> It's a little surprising that 1 + '1' is '11', until you spend a little time and learn the rules instead of fighting them - then you start doing your work in a way that uses that to save time.

You are omcpletely underestimating the complexity of JS's implicit coercions. If you haven't already seen it, watch the Wat talk [1].

Finally, the fact that you need the console to even understand the meaning of a code fragment is a perfect example of language failure.

[1] https://www.destroyallsoftware.com/talks/wat

> Finally, the fact that you need the console to even understand the meaning of a code fragment is a perfect example of language failure.

Isn't that the case for every language with polymorphism? Even C, once you add function pointers to the mix.

I've certainly heard polymorphism and OOP criticized on these grounds, but unless you're a hardcore kernel or embedded developer, that ship sailed about 25 years ago. Everybody uses debuggers and log statements these days. Expecting to be able to look at a code sample in isolation and know what it does is unrealistic for any large-scale system.

No? Also, there's more than one kind of polymorphism.

> Expecting to be able to look at a code sample in isolation and know what it does is unrealistic for any large-scale system.

My number one favorite thing about Go: you can look at a code sample in isolation in a large-scale system and know what it does.

Why? Every identifier is either lexically scoped or lives in a module. There are about 6 control structures and they all do what they look like they do. Operators are all defined over a small set of well-defined primitives, they can't be overridden. Closures, callbacks, and non-linear control flow are rare and obvious. There is no way for code to be skipped by exceptional control flow apart from the single escape hatch called panic().

It's really like no other language I've ever coded in. You can work in large codebases that are as clear as your average Go code, if you have strong guidance about what kinds of code complexity are acceptable and you are ever-vigilant about avoiding language pitfalls, but nothing is quite as freeing as knowing for a fact you will be able to parse someone else's code because there wasn't any way for them to write something you can't understand.

You still have interfaces. When you invoke a method on an interface, you don't know exactly which code will be called. It could do anything from crash to format your hard drive. In theory, the semantics of the interface should be well-specified and any implementation that doesn't conform to them is a bug, and Go culture holds pretty strictly to this, but there's nothing in the compiler that imposes solid restrictions on what the implementation of an interface can do.

If you're disciplined, you can write solid, easy-to-understand code in any language, Javascript included. I've worked on million+ line Javascript codebases and been productive (as a developer new to the codebase) within 3 days. But this imposes trade-offs in verbosity and flexibility that are often not worth it for most (non-Google-scale) JS codebases.

> Expecting to be able to look at a code sample in isolation and know what it does is unrealistic for any large-scale system.

I don't know why you'd think that. In a typed language, you simply look at the types and you know exactly the intended meaning of a code fragment ie. what inputs are needed, what outputs are produced, etc. That's not remotely the case for JavaScript due to its implicit conversions.

Reply on news.ycombinator.com