5 ms·

If you're main problem with a new language is that it's not written like the language you are used to, you're not going to be happy with the new language.

lolive 5y ago
Newer is not always better. So I prefer to stay behind a little, if I can. [I stayed away from JavaScript until ES6 and Typescript. And I think I avoided myself a lot of headaches being that cautious]
- lolive 5y ago
  Oh. And and at one moment in my career, I had to jump into serious web dev ;( But it was just after the death of IE ;) [Call me lucky] My 2 cents: widespread adoption is not synonym with long term perenity.
Aeolun 5y ago
Hence I’m not happy with anything that doesn’t look like Java. Go seems amazing otherwise, but I cannot get over the fact that it forces me to capitalize or not capitalize my variables, and has types in the wrong order.
- rob74 5y ago
  Well then I guess it's Java for you until retirement. Go can feel a bit alien if you only know "C-style" languages, because its creators took inspiration from a wide array of languages, including Pascal. Actually Pascal-style declarations are easier to read, but you have to keep an open mind and not just go "doesn't look like what I'm used to, so it must be bad"...
  - runarberg 5y ago
    C/Java style of annotating the return type of a function first, and then annotating the argument types before the name feels really old school at this point. Python, TypeScript, Go, Rust, etc. all opted for annotating after the name. Since this is so prevalent in newer languages, despite a pretty strong tradition in the other direction, I wonder if there is a pretty good reason for this which language design experts are keenly aware of when they design new languages.
    - saghm 5y ago
      I think it's much easier to parse unambiguously, especially when you have operators on values that also appear in types (e.g. `*` and &`).
    - lelanthran 5y ago
      > C/Java style of annotating the return type of a function first, and then annotating the argument types before the name feels really old school at this point. Python, TypeScript, Go, Rust, etc. all opted for annotating after the name. > > Since this is so prevalent in newer languages, despite a pretty strong tradition in the other direction, I wonder if there is a pretty good reason for this which language design experts are keenly aware of when they design new languages. My $0.02: Maybe consistency between named functions and anonymous functions? If you put the return type of a function before the name then it reads ambiguously when the name is left out (as in anonymous functions): // Named function int funcName (params) { ... } // No-name function int (params) { ... } Which leads to the language needing alternative syntax or extra keywords when declaring anonymous functions: // Something like this maybe? int lambda (params) { ... } If you put the return type after the function information but before the body then it's always consistent: // Named function funcName (params) : int { ... } // No-name function (params) : int { ... } And, of course, to retain consistency you then make sure that all variables are declared the same way (type following variable name): // Var declaration myvar : int; The disambiguation comes into its own when creating functions inline: // Prefixed return-type looks odd callFooWithFunc (int (argslist) { ... }); // Prefixed return-type requires extra keywords to not look odd callFooWithFunc (int lambda (argslist) { ... }); // Suffixed return-type looks normal callFooWithFunc ((argslist) : int { ... });
- zerocount 5y ago
  I can't stand the capitalization thing. I see this in C# methods and boolean values in Python every day and it sucks. I think Java got it right on that one.
- skybrian 5y ago
  You might like Dart better then.
eru 5y ago
You can like generics without requiring everything to look like Java. (In fact, generics have been a relatively late and reluctant addition to Java. They had been at home in ML-family languages and others for ages before.)

lolive 5y ago

Newer is not always better. So I prefer to stay behind a little, if I can. [I stayed away from JavaScript until ES6 and Typescript. And I think I avoided myself a lot of headaches being that cautious]

lolive 5y ago
Oh. And and at one moment in my career, I had to jump into serious web dev ;( But it was just after the death of IE ;) [Call me lucky] My 2 cents: widespread adoption is not synonym with long term perenity.

Aeolun 5y ago

Hence I’m not happy with anything that doesn’t look like Java. Go seems amazing otherwise, but I cannot get over the fact that it forces me to capitalize or not capitalize my variables, and has types in the wrong order.

rob74 5y ago
Well then I guess it's Java for you until retirement. Go can feel a bit alien if you only know "C-style" languages, because its creators took inspiration from a wide array of languages, including Pascal. Actually Pascal-style declarations are easier to read, but you have to keep an open mind and not just go "doesn't look like what I'm used to, so it must be bad"...
- runarberg 5y ago
  C/Java style of annotating the return type of a function first, and then annotating the argument types before the name feels really old school at this point. Python, TypeScript, Go, Rust, etc. all opted for annotating after the name. Since this is so prevalent in newer languages, despite a pretty strong tradition in the other direction, I wonder if there is a pretty good reason for this which language design experts are keenly aware of when they design new languages.
  - saghm 5y ago
    I think it's much easier to parse unambiguously, especially when you have operators on values that also appear in types (e.g. `*` and &`).
  - lelanthran 5y ago
    > C/Java style of annotating the return type of a function first, and then annotating the argument types before the name feels really old school at this point. Python, TypeScript, Go, Rust, etc. all opted for annotating after the name. > > Since this is so prevalent in newer languages, despite a pretty strong tradition in the other direction, I wonder if there is a pretty good reason for this which language design experts are keenly aware of when they design new languages. My $0.02: Maybe consistency between named functions and anonymous functions? If you put the return type of a function before the name then it reads ambiguously when the name is left out (as in anonymous functions): // Named function int funcName (params) { ... } // No-name function int (params) { ... } Which leads to the language needing alternative syntax or extra keywords when declaring anonymous functions: // Something like this maybe? int lambda (params) { ... } If you put the return type after the function information but before the body then it's always consistent: // Named function funcName (params) : int { ... } // No-name function (params) : int { ... } And, of course, to retain consistency you then make sure that all variables are declared the same way (type following variable name): // Var declaration myvar : int; The disambiguation comes into its own when creating functions inline: // Prefixed return-type looks odd callFooWithFunc (int (argslist) { ... }); // Prefixed return-type requires extra keywords to not look odd callFooWithFunc (int lambda (argslist) { ... }); // Suffixed return-type looks normal callFooWithFunc ((argslist) : int { ... });
zerocount 5y ago
I can't stand the capitalization thing. I see this in C# methods and boolean values in Python every day and it sucks. I think Java got it right on that one.
skybrian 5y ago
You might like Dart better then.

eru 5y ago

You can like generics without requiring everything to look like Java. (In fact, generics have been a relatively late and reluctant addition to Java. They had been at home in ML-family languages and others for ages before.)