4 ms·

I think this is something where it works well with language support (like Rust), but it seems really unidiomatic in JavaScript, and so it ends up hurting readab

I think this is something where it works well with language support (like Rust), but it seems really unidiomatic in JavaScript, and so it ends up hurting readability more than helping it. In a team context you would have to make a code style decision to handle things this way.

ehnto 7y ago
You would then have to teach every developer who you onboard this novel way of doing things. I feel idiomatic code is really the best code, even if it's not always the most elegant way to achieve something it excels in practical ways. This is definitely one of the benefits of using a framework. Not every language has strong idioms for all uses, but you can often find them in a framework.
- nine_k 7y ago
  There's no single definition of "best"; your is implicit, but what specifically do you imply? Straightforward, idiomatic imperative code can be "best" if you have to maintain a legacy app and can hire developers with little experience and desire to learn. Code which is less like Basic can be "best" if it allows your team to move twice as fast, and have 10x as short a backlog of defects to fix. It may take a more expensive team, and some onboarding time for new members, of course.
  - acdha 7y ago
    > Code which is less like Basic can be "best" if it allows your team to move twice as fast, and have 10x as short a backlog of defects to fix. It may take a more expensive team, and some onboarding time for new members, of course. This is true in theory but it’s famously hard to measure, having both very strong religious beliefs and notorious confounds. For example, is any particular anecdote telling you that a niche language like Lisp or Haskell actually makes people more productive or just that you’re filtering for developers who would be above average in any language? Actually measuring these sorts of claims scientifically is expensive enough that it’s rarely attempted, but that rarely causes people to taper the degree of certainty people express. That doesn’t mean that new languages are bad but I think Fred Brooks was right to recommend skepticism of big claims rather than more incremental improvements.
  - ehnto 7y ago
    I wasn't really clear sorry. I am really advocating for idiomatic code at the implementation level. Of course your architecture will be novel, and it's there that you build efficient and easy to use systems. You want people to be focusing on that, not being distracted by arbitrarily different unidiomatic details.
nine_k 7y ago
The notion of "idiomatic" changes over time. I've seen quite a change in Java during 20 years I use it. I've seen quite a change in JS frontend approaches for last ~5 years, since the wide adoption of React. Expecting any improvement to come with a flat learning curve is unrealistic at any job, and especially so at programming.

ehnto 7y ago

You would then have to teach every developer who you onboard this novel way of doing things. I feel idiomatic code is really the best code, even if it's not always the most elegant way to achieve something it excels in practical ways. This is definitely one of the benefits of using a framework. Not every language has strong idioms for all uses, but you can often find them in a framework.

nine_k 7y ago
There's no single definition of "best"; your is implicit, but what specifically do you imply? Straightforward, idiomatic imperative code can be "best" if you have to maintain a legacy app and can hire developers with little experience and desire to learn. Code which is less like Basic can be "best" if it allows your team to move twice as fast, and have 10x as short a backlog of defects to fix. It may take a more expensive team, and some onboarding time for new members, of course.
- acdha 7y ago
  > Code which is less like Basic can be "best" if it allows your team to move twice as fast, and have 10x as short a backlog of defects to fix. It may take a more expensive team, and some onboarding time for new members, of course. This is true in theory but it’s famously hard to measure, having both very strong religious beliefs and notorious confounds. For example, is any particular anecdote telling you that a niche language like Lisp or Haskell actually makes people more productive or just that you’re filtering for developers who would be above average in any language? Actually measuring these sorts of claims scientifically is expensive enough that it’s rarely attempted, but that rarely causes people to taper the degree of certainty people express. That doesn’t mean that new languages are bad but I think Fred Brooks was right to recommend skepticism of big claims rather than more incremental improvements.
- ehnto 7y ago
  I wasn't really clear sorry. I am really advocating for idiomatic code at the implementation level. Of course your architecture will be novel, and it's there that you build efficient and easy to use systems. You want people to be focusing on that, not being distracted by arbitrarily different unidiomatic details.

nine_k 7y ago

The notion of "idiomatic" changes over time. I've seen quite a change in Java during 20 years I use it. I've seen quite a change in JS frontend approaches for last ~5 years, since the wide adoption of React. Expecting any improvement to come with a flat learning curve is unrealistic at any job, and especially so at programming.