3 ms·

"Everything is subservient to solving a problem". Correct. And writing good, clean, idiomatic code usually helps you avoid introducing code-level problems whe

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

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.