4 ms·

> 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

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

tux3 3y ago
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 3y ago
  > 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 3y ago
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 3y ago
  > *: 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`.
  - Jean-Papoulos 3y ago
    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.
  - jameshart 3y ago
    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).
  - fzzzy 3y ago
    Just always use !==. != will automatically cast and !== won't, therefore "1" != 1 is false and "1" !== 1 is true.
    - hellcow 3y ago
      Unless you’re testing if something is null or undefined, in which case a single “x != null” handles it.
      - fzzzy 3y ago
        Sure. I usually just use !x for that.
rlawson 3y ago
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 3y ago
  Many people have the same experience writing Rust. And they have plenty of time to relax while the program compiles.
  - LorenzoGood 3y ago
    Relevant Xkcd: https://xkcd.com/303/ https://xkcd.com/303/

tux3 3y ago

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 3y ago
> 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 3y ago

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 3y ago
> *: 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`.
- Jean-Papoulos 3y ago
  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.
- jameshart 3y ago
  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).
- fzzzy 3y ago
  Just always use !==. != will automatically cast and !== won't, therefore "1" != 1 is false and "1" !== 1 is true.
  - hellcow 3y ago
    Unless you’re testing if something is null or undefined, in which case a single “x != null” handles it.
    - fzzzy 3y ago
      Sure. I usually just use !x for that.

rlawson 3y ago

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 3y ago
Many people have the same experience writing Rust. And they have plenty of time to relax while the program compiles.
- LorenzoGood 3y ago
  Relevant Xkcd: https://xkcd.com/303/ https://xkcd.com/303/