4 ms·

I used to think there was an idiomatic way to write code in a given language, that following conventions and community guidelines was a good thing, that languag

I used to think there was an idiomatic way to write code in a given language, that following conventions and community guidelines was a good thing, that languages had a natural flow to them and writing against the flow was a bad thing. These days I focus on solving problems. Idioms, conventions, languages, etc. are all bullshit. Everything is subservient to solving a problem. Ember or Angular? Don't care. Ruby or Python? Don't care. C# or Java? Don't care. Haskell or F#? Don't care. Statically typed or dynamically typed? Don't care. What is the problem we're solving? Now we're getting somewhere.

mgkimsal 12y ago
"Everything is subservient to solving a problem". Correct. And writing good, clean, idiomatic code usually helps you avoid introducing code-level problems when trying to solve your "real world" problem. You're not wrong so much as perhaps just more experienced to the point where caring about the idioms isn't much of an issue any more, not because idioms don't matter, but because you're writing code that's good enough. i've found the 'standards' and 'idiomatic code' to be useful not so much as a benchmark for "you're 100% wrong if you don't do this" but "you're creating another set of problems for yourself if you're not careful". "Ember or Angular? Don't care. Ruby or Python? Don't care. C# or Java? Don't care" Well... you may need to care, because one of the problems you may have to consider is long-term maintenance as well. Using Ruby for "project X" in a team of 15 .net developers with extensive C# experience, simply because "Ruby is best for this problem" is probably just trading one problem for another.
- vinceguidry 12y ago
  > Well... you may need to care, because one of the problems you may have to consider is long-term maintenance as well. Using Ruby for "project X" in a team of 15 .net developers with extensive C# experience, simply because "Ruby is best for this problem" is probably just trading one problem for another. I'd like to reiterate this point. At some point, somewhere down the road, a different programmer than you is going to have to read your code and try to figure out what it does. If you don't learn your languages well enough to be idiomatic, then you'll be contributing to technical debt load instead of helping to pay it off. Unless you're doing big enterprise consulting. That's an entirely different sport.
- dkarapetyan 12y ago
  Right, I mean at the end of the day the social problems like the one you mention instead of the technical merits of one platform over another is what will dominate in the long term. So whatever stack is chosen is not going to matter as much as people think. If the problem is ill-defined and there is lack of agreement on what exactly is being solved then adding technology into the mix is not going to make a difference.
dmux 12y ago
I think this is what Andrew Hunt and David Thomas meant when they said "program _into_ a language" as opposed to "program in a language" in their book The Pragmatic Programmer.
jghn 12y ago
Disagree, you should always strive to write code in the common idioms found in that language's community with local "house rules" deciding the fuzzier points. I've gotten into this argument frequently with coworkers over the years, usually surrounding situations where we have some side code in a language where the common idioms, style guides, etc are vastly different than our main language. They end up writing X as if it were Y with different syntax, to which I object. Their take is always that it makes the code more readable, but that's not really true - it's only more readable to a Y programmer, not the space of X programmers.

mgkimsal 12y ago

"Everything is subservient to solving a problem". Correct. And writing good, clean, idiomatic code usually helps you avoid introducing code-level problems when trying to solve your "real world" problem. You're not wrong so much as perhaps just more experienced to the point where caring about the idioms isn't much of an issue any more, not because idioms don't matter, but because you're writing code that's good enough. i've found the 'standards' and 'idiomatic code' to be useful not so much as a benchmark for "you're 100% wrong if you don't do this" but "you're creating another set of problems for yourself if you're not careful". "Ember or Angular? Don't care. Ruby or Python? Don't care. C# or Java? Don't care" Well... you may need to care, because one of the problems you may have to consider is long-term maintenance as well. Using Ruby for "project X" in a team of 15 .net developers with extensive C# experience, simply because "Ruby is best for this problem" is probably just trading one problem for another.

vinceguidry 12y ago
> Well... you may need to care, because one of the problems you may have to consider is long-term maintenance as well. Using Ruby for "project X" in a team of 15 .net developers with extensive C# experience, simply because "Ruby is best for this problem" is probably just trading one problem for another. I'd like to reiterate this point. At some point, somewhere down the road, a different programmer than you is going to have to read your code and try to figure out what it does. If you don't learn your languages well enough to be idiomatic, then you'll be contributing to technical debt load instead of helping to pay it off. Unless you're doing big enterprise consulting. That's an entirely different sport.
dkarapetyan 12y ago
Right, I mean at the end of the day the social problems like the one you mention instead of the technical merits of one platform over another is what will dominate in the long term. So whatever stack is chosen is not going to matter as much as people think. If the problem is ill-defined and there is lack of agreement on what exactly is being solved then adding technology into the mix is not going to make a difference.

dmux 12y ago

I think this is what Andrew Hunt and David Thomas meant when they said "program _into_ a language" as opposed to "program in a language" in their book The Pragmatic Programmer.

jghn 12y ago

Disagree, you should always strive to write code in the common idioms found in that language's community with local "house rules" deciding the fuzzier points. I've gotten into this argument frequently with coworkers over the years, usually surrounding situations where we have some side code in a language where the common idioms, style guides, etc are vastly different than our main language. They end up writing X as if it were Y with different syntax, to which I object. Their take is always that it makes the code more readable, but that's not really true - it's only more readable to a Y programmer, not the space of X programmers.