[lelanthran]

> The fact that you need to use entire words to denote syntax makes it much harder for your brain to parse things : Instead of immediately seeing "this is code structure" and "this is actual code", you need to actually read the words to make that distinction. It is very counter-productive and a bad design solution, imo.

While I agree that it gets slightly tedious to read daily, I have to say that there is no language other than pascal that lets me come back to the language after 3 years and instantly be able to read it with no problems.

I don't know if any other language where this is possible.

[rlawson]

Agree! I also find Pascal very soothing to write. Yes it's a little more verbose than C but it makes you think ahead and stay organized.

[zozbot234]

Many people have the same experience writing Rust. And they have plenty of time to relax while the program compiles.

[LorenzoGood]

Relevant Xkcd: https://xkcd.com/303/

[tux3]

While I'm not the world's #1 Golang fan, this is something that they have. They took a lot of complexity out of the language, so any code you look at will seem very simple & readable. There's not a lot of magic syntactic sugar, you just write things down the simple verbose way.

The flip side of that coin is you have to reimplement a lot of things yourself, so any essential complexity that the language doesn't handle for you is pushed on you to re-implement in your codebase.

Python's decent at this too. At least the simple Python people use in small scripts. It's almost pseudocode, as long as no one tries and overengineers it.

[archargelod]

> Python's decent at this too. It's almost pseudocode. Nim has Python-like syntax. But, I find it even easier to read/parse at a glance than Python.

Also, I hate that in languages with dynamic typing you have to read whole function to understand what type of arguments it takes and what is the return type. Nim is statically-typed, so all the types are properly declared.

[wizzwizz4]

In my experience, Python, C and JavaScript* all have this property; whereas I have to relearn Pascal, Haskell, sh and (to an extent) Rust every time I go away from them for a bit. I think this is more a property of you or I than of particular languages.

*: excluding `for (… of …)` and `for (… in …)` – I can never remember which is which. `for (… of …)` is the one you can use with Arrays and other iterables.

[lelanthran]

> *: excluding `for (… of …)` and `for (… in …)`

There's more that will trip you up in JS if you leave it for too long. Off the top of my head:

1. Which function definition (`function` or `=>`) do I need to use in order to make the `this` keyword point at the correct object in an event handler/anonymous function/foreach parameter?

2. I see code with both `!==` and `!=` - what is the significance of using both?

3. Long chains of `filter` and `map`.

[jameshart]

Long chains of filter and map are common in any language - they may have better chaining syntaxes, but since mapreduce can basically implement any collection operation you can imagine, filter and map chains are going to crop up.

With its tuple, object, and destructuring syntaxes JS actually ends up with some of the most readable mapreduce code of mainstream C-derived languages (it’s soooo much worse in Java).

[wizzwizz4]

1. `function` gives you a new `this`, whereas `=>` closes over the `this` from the parent scope. Which to use depends on what you want. (Full disclosure: I would've had to think for a bit whether the syntax was `->` or `=>` – though I'd probably guess `=>` because `->` means something in C.)

2. `!==` is strict comparison, and `!=` tries to do incomprehensible magick to munge incomparable types together. I still know some of the rules (array to string sticks in my mind), but I doubt many people know all of them. There's almost never a good reason to use `!=`, outside `elem.value != my_integer`. (Though `NaN !== NaN`, so you need to watch out for that: since equality is defined recursively on objects I'm pretty sure this is infectious.)

3. The length of the chain is easy (though, iirc there are performance implications since it's not lazy). The hard part is the fact that map callbacks can take one, two or three arguments, so stuff like `["123", "456", "10", "1234"].map(parseInt)` will behave unexpectedly. (Something like `[123, undefined, 2, 5]`, though I might be thinking of PHP.) Not sure whether `Array.prototype.filter` has similar gotchas.

That's off the top of my head. I haven't seriously used JavaScript since the ES5 times, but JavaScript's a very… memorable… language. (I can't even remember hello world in Pascal.)

[Jean-Papoulos]

I just tried make a ".any" generic function for arrays, and by god :

Most languages : myArray.any((e) => true);

Delphi : AClass.any<Type>(myArray, function (e) : Boolean begin Exit(True); end);

The readability is through the roof, lol.

[fzzzy]

Just always use !==. != will automatically cast and !== won't, therefore "1" != 1 is false and "1" !== 1 is true.

[hellcow]

Unless you’re testing if something is null or undefined, in which case a single “x != null” handles it.

[fzzzy]

Sure. I usually just use !x for that.

[SamBam]

That doesn't test if it's null or undefined, that just tests if it's not falsy.

x = 0; !x → true

y = ""; !y → true

z = null; !z → true