3 ms·

This guy shits all over his credibility by turning it into a language war. He clearly is out of his depth on the Haskell issue, and I know credible people who t

This guy shits all over his credibility by turning it into a language war. He clearly is out of his depth on the Haskell issue, and I know credible people who think highly of q and kdb (which are rare outside of finance, but ubiquitous in finance). That said, he's got a point, but the only solution he gives is "Include some comments!" I've seen so many shitty comments that I really think this is no advice at all. Four levels of software maturity. (There are others. This is a simplified model.) Level 1: Your work doesn't exist until it's in version control. It might be amazing to 2012-era programmers that this could be controversial, because even the laggards have reached L1 maturity, but at one time, it was. (See: the Joel test.) Level 2: Your work doesn't exist until it has tests at multiple levels (e.g. unit and integration). Otherwise, it has no enforced semantics. Level 3: Your work doesn't exist until it has well-documented semantics in addition to the tests, which cannot cover all cases. Otherwise, how does one even decide what a "bug" is? Level 4: Your work doesn't exist until you've provided the resources (e.g. a code walk or an interactive module) to teach people how to use it. If you're at Level 1, you won't lose source code. If you're at Level 2, your breakage rate will be reduced, and you can run CI. At Level 3, your system integrity will remain decent because you don't end up with those software-as-spec modules that, over time, corrupt the whole system. Guess what? It takes Level 4 to get good code. Unless there is a culture of teaching (incremental code reviews are not enough) within the company, you will not have good code for very long. Since engineers are intolerant of context switches and in-person teaching doesn't scale, the teaching should be automatic. Interactive modules or, at the least, code walks should come with the technical asset being demonstrated. If people don't know what they are looking at, then how can they be expected to review or maintain code. With the worst code, it's not even clear why it's bad. It's just incomprehensible.

mikegioia 14y ago
Come on! He makes one reference to Haskell, links to the SO post on it, admits he has never used it, and all of a sudden he "shits all over his credibility by turning it into a language war"? It's an example of how ugly code can get for goodness sake.
- spacemanaki 14y ago
  The Haskell code snippet is from a parody of Wikipedia, and is purposefully obfuscated code. Imagine someone holding up a piece of code written in C from an IOCCC entry, as an example of how C is a language to be avoided. Additionally, bringing it up is a total non sequitur, because Haskell doesn't have much to do with the problems the article discusses, and neither does APL. I think it does ruin the author's credibility. They didn't do the most basic research before including that code snippet, and are just holding it up as a distracting side show. The rest of the screed might have some value, but I'm pretty skeptical of that after reading the last paragraphs.
- michaelochurch 14y ago
  And one language I’ve been warned about, though I’ve never had the opportunity to use it, is Haskell, an offshoot of ML. According to a friend in academia who’s studied it, it’s “the Taliban version of ML,” in which it’s all but impossible to write readable code. He follows this with a line of intentionally hard-to-read code. Everyone who is familiar with Haskell knows that it's possible to write code like this, but it's not common. You have to actually work at it to make truly awful code in Haskell or ML.
NoahSussman 14y ago
> Unless there is a culture of teaching (incremental code reviews are not enough) within the company, you will not have good code for very long. Very insightful observation. Bad code is a problem that is both technical and social. Purely technical solutions won't cut it.
- michaelochurch 14y ago
  The problem is the low social status of software engineers. We're well paid because of our rarity, but we've done an absolutely terrible job of getting respect for ourselves, so most of our work is treated as a commodity. Consequently, business people don't trust us to do anything that resembles leadership. It's not just that they won't rely on us. They won't even let us take the time (which is why it's better to just do and ask for forgiveness, not permission) to do anything that involves future orientation or leadership. The reality is that programming is a leadership role. When you write code and design systems, you will affect how other people work, unless your work is of such low quality that no one can use it. The result of this is that we have a Greenspun's Tenth Law situation where the failure to address a capability results in it being met in an ad-hoc, ineffective way. Programmers aren't supposed to be multipliers, but such responsibilities emerge naturally and, when they do, the people picked to handle them (usually for political reasons, since business people are hopeless at evaluating software ability) are usually incapable of doing it. Blog plug on this: http://michaelochurch.wordpress.com/2012/12/14/the-unbearable-b-ness-of-software/ http://michaelochurch.wordpress.com/2012/12/14/the-unbearabl...
stephencanon 14y ago
How can you possibly have tests without well-documented semantics? You may have code that you call "tests" and it may print some reassuring messages, but you can't actually test anything without a specification of what the correct behavior is.
jakejake 14y ago
I think if you talk to a lot of developers they would like to be at a "level 4" as you call it but the pressures and deadlines on them don't allow for that as often as they'd like. Of course it's in the best long-term interest, but management are not doing this type of long term thinking. I think it's easy to judge from academia where you do an assignment, then move on to the next. But it only takes a couple of years in a real-world environment for code to get incredibly f'd up even if the developers were trying to be diligent. People come and go, platforms go out of style, programming fads come and go and, of course, one or two mediocre people on the team add their code to the mix.
carterschonwald 14y ago
Well said points Michael! Reasoning about your semantics and having the learning of the code be reified are certainly important. So then the question becomes how to incentivize helping that learnng
algorias 14y ago
Allow me to be a bit provocative: Level 5: your work doesn't exist until it has been formally proven to be correct. It's obvious that the amount of effort involved in this is so huge that it should only be considered in a select few problem domains. The same is true for the other levels. They're just a scale of increasing formalization/rigor, but you've said nothing to justify why they should be applied universally. I think it's important to keep in mind that these levels (or something analogous) exist, but different domains have different sweet spots and a deliberate choice needs to be made for each project.
- Retric 14y ago
  I would go so far as to say going past 2 is generally a waste of time until the code can do something useful. However, when bugs are measured in lives lost and billions of dollars things change.

mikegioia 14y ago

Come on! He makes one reference to Haskell, links to the SO post on it, admits he has never used it, and all of a sudden he "shits all over his credibility by turning it into a language war"? It's an example of how ugly code can get for goodness sake.

spacemanaki 14y ago
The Haskell code snippet is from a parody of Wikipedia, and is purposefully obfuscated code. Imagine someone holding up a piece of code written in C from an IOCCC entry, as an example of how C is a language to be avoided. Additionally, bringing it up is a total non sequitur, because Haskell doesn't have much to do with the problems the article discusses, and neither does APL. I think it does ruin the author's credibility. They didn't do the most basic research before including that code snippet, and are just holding it up as a distracting side show. The rest of the screed might have some value, but I'm pretty skeptical of that after reading the last paragraphs.
michaelochurch 14y ago
And one language I’ve been warned about, though I’ve never had the opportunity to use it, is Haskell, an offshoot of ML. According to a friend in academia who’s studied it, it’s “the Taliban version of ML,” in which it’s all but impossible to write readable code. He follows this with a line of intentionally hard-to-read code. Everyone who is familiar with Haskell knows that it's possible to write code like this, but it's not common. You have to actually work at it to make truly awful code in Haskell or ML.

NoahSussman 14y ago

> Unless there is a culture of teaching (incremental code reviews are not enough) within the company, you will not have good code for very long. Very insightful observation. Bad code is a problem that is both technical and social. Purely technical solutions won't cut it.

michaelochurch 14y ago
The problem is the low social status of software engineers. We're well paid because of our rarity, but we've done an absolutely terrible job of getting respect for ourselves, so most of our work is treated as a commodity. Consequently, business people don't trust us to do anything that resembles leadership. It's not just that they won't rely on us. They won't even let us take the time (which is why it's better to just do and ask for forgiveness, not permission) to do anything that involves future orientation or leadership. The reality is that programming is a leadership role. When you write code and design systems, you will affect how other people work, unless your work is of such low quality that no one can use it. The result of this is that we have a Greenspun's Tenth Law situation where the failure to address a capability results in it being met in an ad-hoc, ineffective way. Programmers aren't supposed to be multipliers, but such responsibilities emerge naturally and, when they do, the people picked to handle them (usually for political reasons, since business people are hopeless at evaluating software ability) are usually incapable of doing it. Blog plug on this: http://michaelochurch.wordpress.com/2012/12/14/the-unbearable-b-ness-of-software/ http://michaelochurch.wordpress.com/2012/12/14/the-unbearabl...

stephencanon 14y ago

How can you possibly have tests without well-documented semantics? You may have code that you call "tests" and it may print some reassuring messages, but you can't actually test anything without a specification of what the correct behavior is.

jakejake 14y ago

I think if you talk to a lot of developers they would like to be at a "level 4" as you call it but the pressures and deadlines on them don't allow for that as often as they'd like. Of course it's in the best long-term interest, but management are not doing this type of long term thinking. I think it's easy to judge from academia where you do an assignment, then move on to the next. But it only takes a couple of years in a real-world environment for code to get incredibly f'd up even if the developers were trying to be diligent. People come and go, platforms go out of style, programming fads come and go and, of course, one or two mediocre people on the team add their code to the mix.

carterschonwald 14y ago

Well said points Michael! Reasoning about your semantics and having the learning of the code be reified are certainly important. So then the question becomes how to incentivize helping that learnng

algorias 14y ago

Allow me to be a bit provocative: Level 5: your work doesn't exist until it has been formally proven to be correct. It's obvious that the amount of effort involved in this is so huge that it should only be considered in a select few problem domains. The same is true for the other levels. They're just a scale of increasing formalization/rigor, but you've said nothing to justify why they should be applied universally. I think it's important to keep in mind that these levels (or something analogous) exist, but different domains have different sweet spots and a deliberate choice needs to be made for each project.

Retric 14y ago
I would go so far as to say going past 2 is generally a waste of time until the code can do something useful. However, when bugs are measured in lives lost and billions of dollars things change.