6 ms·

They are not overlooked, they are better handled further up the call stack. And not having the option to forward them implicitly is a step back, not forward. Th

by codr4 8y ago

They are not overlooked, they are better handled further up the call stack. And not having the option to forward them implicitly is a step back, not forward. There's no way to make a programming language better by forcing users to do anything, in many cases the user will have more experience than the person implementing the language. A programming language is a tool, predicting and dictating how the tool is to be used is missing the point.

deleted 8y ago
[deleted]
qz_ 8y ago
I don't think forcing is the right word.. I've noticed that languages where the "right way" is the path of least resistance the code quality stays high even if a lot of people with varying levels of expertise contribute
- maxscam 8y ago
  Well in my experience golang Is a long ways from this anyway ... It's a very prescriptive language
cle 8y ago
> There's no way to make a programming language better by forcing users to do anything Sure there is, many important language features boil down to forcing users to do the right thing (not necessarily the easy thing). In highly concurrent languages like Go, there’s not always a meaningful stack to unwind, and you end up having to pass error values around anyway. So I can easily sympathize with the decision to stick with one mechanism for error handling.
- jcelerier 8y ago
  > many important language features boil down to forcing users to do the right thing this just causes the users to use another language for their projects instead
  - mixedCase 8y ago
    And fixing the output of that is where the rest of us often profit from. A language that provides a lot of freedom when it comes to expressiveness without offering much in the way of constraints (to truly convey the purpose of a given piece of code with the least amount of ambiguity possible) will almost definitely turn into utter crap in contact with junior developers, and will often be a source of pain for more experienced ones once the project is nontrivial, whether they realize it or not.
    - codr4 8y ago
      Do you see any problems with optimizing everything we do for junior developers? I mean, most of us aren't, and it would be really nice if someone gave a crap about wasting our lives as well.
      - chousuke 8y ago
        It's not necessary optimizing for junior developers. When properly implemented, language hand-holding is a tool for "better" programmers as well. I find that my brain capacity is limited, and the more I can focus it on issues that are productive rather than eg. tracking the liveness status of my data or potential system-wide effects messing with it, the more useful work I can perform. Not to mention working together with more junior people, in which case it will be you doing the hand-holding instead, because the tools don't
TheCoelacanth 8y ago
Forwarding errors upwards is one character in Rust (?). IMO that is pretty much the perfect balance between forwarding errors easily and explicitness.

by codr4 8y ago

deleted 8y ago

[deleted]

qz_ 8y ago

I don't think forcing is the right word.. I've noticed that languages where the "right way" is the path of least resistance the code quality stays high even if a lot of people with varying levels of expertise contribute

maxscam 8y ago
Well in my experience golang Is a long ways from this anyway ... It's a very prescriptive language

cle 8y ago

> There's no way to make a programming language better by forcing users to do anything Sure there is, many important language features boil down to forcing users to do the right thing (not necessarily the easy thing). In highly concurrent languages like Go, there’s not always a meaningful stack to unwind, and you end up having to pass error values around anyway. So I can easily sympathize with the decision to stick with one mechanism for error handling.

jcelerier 8y ago
> many important language features boil down to forcing users to do the right thing this just causes the users to use another language for their projects instead
- mixedCase 8y ago
  And fixing the output of that is where the rest of us often profit from. A language that provides a lot of freedom when it comes to expressiveness without offering much in the way of constraints (to truly convey the purpose of a given piece of code with the least amount of ambiguity possible) will almost definitely turn into utter crap in contact with junior developers, and will often be a source of pain for more experienced ones once the project is nontrivial, whether they realize it or not.
  - codr4 8y ago
    Do you see any problems with optimizing everything we do for junior developers? I mean, most of us aren't, and it would be really nice if someone gave a crap about wasting our lives as well.
    - chousuke 8y ago
      It's not necessary optimizing for junior developers. When properly implemented, language hand-holding is a tool for "better" programmers as well. I find that my brain capacity is limited, and the more I can focus it on issues that are productive rather than eg. tracking the liveness status of my data or potential system-wide effects messing with it, the more useful work I can perform. Not to mention working together with more junior people, in which case it will be you doing the hand-holding instead, because the tools don't

TheCoelacanth 8y ago

Forwarding errors upwards is one character in Rust (?). IMO that is pretty much the perfect balance between forwarding errors easily and explicitness.