6 ms·

Whenever I read articles like this and the ensuing discussion that follows, I'm reminded of this quote from Dijkstra: Don't blame me for the fact that competen

Whenever I read articles like this and the ensuing discussion that follows, I'm reminded of this quote from Dijkstra: Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner. Dijkstra (1975) Comments at a Symposium Whenever I read code written in the "so boring it cannot fail" camp I get exhausted. This code is inherently procedural and rolls itself into a giant ball of mud -- composition is difficult to achieve so as requirements change the code accrues more loops and conditionals until it is nearly incomprehensible. It might start out neat and clean but rarely will it stay that way. Good, non-leaky abstractions are key. This can even be achieved with procedural code but I think functional programming techniques like pure functions, immutable values, and a sound type system help a great deal... even at the expense of the initial "cognitive load," it takes to learn how to employ these tools.

DanielBMarkham 10y ago
Meh. I think you're overshooting the runway a bit here. I'm a functional coder and I like the idea of reducing cognitive load. The procedural guys use it in a different fashion but if you're writing code you can't understand after walking away for a few months and coming back? You're doing something wrong. I don't think that relates to the abstraction or composability of your solution style. I find good naming, decomposition, and re-composition allows me to take things that don't matter and put them in a utility library somewhere. Then I'm left with a small number of new symbols and configurations that's easy enough to grok coming in cold. There are plenty of FP guys that don't do this. Hell if I'd want to maintain their code.
- braveo 10y ago
  yeah, I'm always amazed at the people who claim they looked at code they wrote 6 months ago and think it's horrible. I've looked at code I wrote 2-3 years ago, and upon examination thought to myself "that's fairly reasonable code, I got most of it right". I see people claim that means you're not growing as a developer, but my growth is about being able to build larger and more complex systems rather than perfecting small snippets of code. In other words, I've stopped caring about the specifics of code (within reason), and I get better at building systems.
mikekchar 10y ago
We've been refactoring and decoupling code for decades in imperative coding styles. I think one of the problems we have as a community of programmers is the concept that it must end up in a ball of mud. Almost all of our extant systems are developed in imperative style. The system I work on today is many orders of magnitude larger than the systems I first learned on and yet it is dramatically easier to write useful code. That's because over time, we have extracted and polished functionality into useful and unambiguous pieces. Back when I was a young programmer it was often said, "If you don't have time to get it right the first time, how on earth will you have time to do it again?". To me, this concept is why we get into the ball of mud. It will happen to you no matter what style of programming you choose, because you can't get it "right" the first time. You don't know what "right" is. Because we resist the rework/refactoring, we build balls of mud. We even blame it on the people before us "who got it wrong" (which is easy to do because average attrition is about 2 years and they've likely left the company). I like functional style as much as the next programmer (well, probably more than most in fact), but FP isn't going to save you in this instance. The only way to maintain high levels of productivity in projects is ruthless rework in the face of changing requirements.
- hvidgaard 10y ago
  "If you don't have time to get it right the first time, how on earth will you have time to do it again?" I like that quote, but to be honeste. Some times you have to get it out of the door, and time is of the essence. And you can go back and fix it. That is okay, as long as you understand that shortcutting now, will cost time tomorrow (i.e. technical debt).
  - btschaegg 10y ago
    Yeah, the problem appears if your superiors don't understand that. It'll be a "quick fix", when you want to clean it up after the crunch the comments will be "nah, we don't have time for that right now" (non-coders never seem to understand that messy code is a liability - thus cleaning up code seems like a waste of time). And a couple of months later, it comes back biting you in the behinds. At which point, someone will tell you or some other unfortunate colleague to "just fix it quickly". In such an environment "quick and dirty" only works if it is kept locally, i.e. the author is the only one that uses the code. Hence Uncle Bob's insistence that a good developer must say "NO!" from time to time[1]. [1]: https://sites.google.com/site/unclebobconsultingllc/blogs-by-robert-martin/saying-no https://sites.google.com/site/unclebobconsultingllc/blogs-by...
mybrid 10y ago
Functional programming is inscrutable by most. Berkeley uses LISP as a flunk out class to weed out freshman. I find it odd that given in the physical world people require different shoe sizes for different feet that in the intellectual world people believe one size fits all, or that there is ultimately a single style of code that is comprehensible. Do you really believe our brains are all the same? The functional programming crowd will always play a minor roll in human programming and not because as you suggest, you are all superior. But rather it has to do with how brains differ. In fact I think the very real, emotional, visceral reaction people have to functional programming is key. People who love it, love it. Everyone else is completely demotivated by it. Lost in sets of parenthesis as the say. There is little middle ground. The very emotional reaction people have speaks volumes about how the brain views programming. Spoken language changes every day because people use words differently due to brains being different. This vexes those who are compulsive about adhering to fixed definitions and grammar rules because of some imagined ideal. The same is playing out in software. We will always be creating new languages and tweaking them and there are there will be those who believe in an imaginary ideal of what readable code is. Ultimately I think software writing needs to mature to where written language has matured: editors. Code review has some semblance as does paired programming. But editing is far more involved. Editors can reject entire writings. So why do we need editors in the first place? Because in order to have happy consistency a set of rules is not enough. I comes down to style: a word here, a name change there. It may not seem like much but in fact it is. Given a language is Turing complete, meaning it can exercise the full capability of the CPU and computer, then the choice of language and style is about the human condition, a condition which is as varied as the people in it. If one cannot write code that ones finds usable then one needs to keep searching in earnest for a better style. However, once you have a style you can appreciate your own code from years ago then it is a matter of arbitrary standards when interacting with others. You have to draw the line somewhere but lets not pretend for a second that a single writing style is ideal for everyone, or even most. Its arbitrary because without any standards you have an unmanageable chaos.
- patrec 10y ago
  Functional programming has made huge inroads into mainstream languages over the last 20 years, so I suppose this is because people's brains have suddenly changed?
btschaegg 10y ago
While I know Dijkstra's name only from a "historical perspective" (the algorithm, the goto-letter and some of his reasonings), I somehow grew very fond of a motivational-style picture of him almost frowning[1] with the title "quick and dirty". I still would like to see a version that is of a high enough resolution so one could properly print, frame and hang it on an office wall. I like the idea that - when the next unavoidable proposal of "can't we just [...]" or "all we need is a prototype"[2] comes around - I'll be able to point to it and say something along the lines of "convince EWD first!". [1]: http://www.catonmat.net/blog/difference-between-edsger-dijkstra-and-larry-wall/ http://www.catonmat.net/blog/difference-between-edsger-dijks... [2]: Sometimes I wonder: Is there a "named law" for this? If not, why? It's never just a prototype.
bryanrasmussen 10y ago
sometimes the surgeon is tired, and might like to have a problem phrased in a way that even the barber in the shop around the corner can understand.
nsb1 10y ago
This is a rather idealistic approach to something which has real-world constraints: Despite our misinformed bathtub-curve view of the abilities of the software development community, the world is absolutely teeming with "average programmers", not superstars. It is in your best interests not to shut these folks out of your project if you want to guarantee that the people you hire are able to hit the ground running and not stop by your office every 10 minutes when they get stumped by some quirk in the codebase. What you describe is the "Knotted Shoelace" antithesis to the ball of mud. Functional? Yes. Strong? Sure...but to re-lace your shoe you have to painstakingly pick it apart.
catnaroek 10y ago
Imperative code can be clean and stay clean too, it just requires more effort. Remember that functional programs are easier to understand only because they are less expressive - they can't express concurrency and nondeterminism. That being said, the principle of least power applies in full force, so if (a part of) your program can be written purely functionally, it should probably be written that way.
jxy 10y ago
I always like comparing coding with writing. Depending on your proficiency, you might want to write a pulp fiction, a news article, a PhD thesis, or Shakespeare. You might write in English, American English, Chinese, classical Chinese, Japanese, or Farsi. Maintainability or the cognitive load of the reader or writer completely depends on the proficiency of the reader or writer.

DanielBMarkham 10y ago

Meh. I think you're overshooting the runway a bit here. I'm a functional coder and I like the idea of reducing cognitive load. The procedural guys use it in a different fashion but if you're writing code you can't understand after walking away for a few months and coming back? You're doing something wrong. I don't think that relates to the abstraction or composability of your solution style. I find good naming, decomposition, and re-composition allows me to take things that don't matter and put them in a utility library somewhere. Then I'm left with a small number of new symbols and configurations that's easy enough to grok coming in cold. There are plenty of FP guys that don't do this. Hell if I'd want to maintain their code.

braveo 10y ago
yeah, I'm always amazed at the people who claim they looked at code they wrote 6 months ago and think it's horrible. I've looked at code I wrote 2-3 years ago, and upon examination thought to myself "that's fairly reasonable code, I got most of it right". I see people claim that means you're not growing as a developer, but my growth is about being able to build larger and more complex systems rather than perfecting small snippets of code. In other words, I've stopped caring about the specifics of code (within reason), and I get better at building systems.

mikekchar 10y ago

We've been refactoring and decoupling code for decades in imperative coding styles. I think one of the problems we have as a community of programmers is the concept that it must end up in a ball of mud. Almost all of our extant systems are developed in imperative style. The system I work on today is many orders of magnitude larger than the systems I first learned on and yet it is dramatically easier to write useful code. That's because over time, we have extracted and polished functionality into useful and unambiguous pieces. Back when I was a young programmer it was often said, "If you don't have time to get it right the first time, how on earth will you have time to do it again?". To me, this concept is why we get into the ball of mud. It will happen to you no matter what style of programming you choose, because you can't get it "right" the first time. You don't know what "right" is. Because we resist the rework/refactoring, we build balls of mud. We even blame it on the people before us "who got it wrong" (which is easy to do because average attrition is about 2 years and they've likely left the company). I like functional style as much as the next programmer (well, probably more than most in fact), but FP isn't going to save you in this instance. The only way to maintain high levels of productivity in projects is ruthless rework in the face of changing requirements.

hvidgaard 10y ago
"If you don't have time to get it right the first time, how on earth will you have time to do it again?" I like that quote, but to be honeste. Some times you have to get it out of the door, and time is of the essence. And you can go back and fix it. That is okay, as long as you understand that shortcutting now, will cost time tomorrow (i.e. technical debt).
- btschaegg 10y ago
  Yeah, the problem appears if your superiors don't understand that. It'll be a "quick fix", when you want to clean it up after the crunch the comments will be "nah, we don't have time for that right now" (non-coders never seem to understand that messy code is a liability - thus cleaning up code seems like a waste of time). And a couple of months later, it comes back biting you in the behinds. At which point, someone will tell you or some other unfortunate colleague to "just fix it quickly". In such an environment "quick and dirty" only works if it is kept locally, i.e. the author is the only one that uses the code. Hence Uncle Bob's insistence that a good developer must say "NO!" from time to time[1]. [1]: https://sites.google.com/site/unclebobconsultingllc/blogs-by-robert-martin/saying-no https://sites.google.com/site/unclebobconsultingllc/blogs-by...

mybrid 10y ago

Functional programming is inscrutable by most. Berkeley uses LISP as a flunk out class to weed out freshman. I find it odd that given in the physical world people require different shoe sizes for different feet that in the intellectual world people believe one size fits all, or that there is ultimately a single style of code that is comprehensible. Do you really believe our brains are all the same? The functional programming crowd will always play a minor roll in human programming and not because as you suggest, you are all superior. But rather it has to do with how brains differ. In fact I think the very real, emotional, visceral reaction people have to functional programming is key. People who love it, love it. Everyone else is completely demotivated by it. Lost in sets of parenthesis as the say. There is little middle ground. The very emotional reaction people have speaks volumes about how the brain views programming. Spoken language changes every day because people use words differently due to brains being different. This vexes those who are compulsive about adhering to fixed definitions and grammar rules because of some imagined ideal. The same is playing out in software. We will always be creating new languages and tweaking them and there are there will be those who believe in an imaginary ideal of what readable code is. Ultimately I think software writing needs to mature to where written language has matured: editors. Code review has some semblance as does paired programming. But editing is far more involved. Editors can reject entire writings. So why do we need editors in the first place? Because in order to have happy consistency a set of rules is not enough. I comes down to style: a word here, a name change there. It may not seem like much but in fact it is. Given a language is Turing complete, meaning it can exercise the full capability of the CPU and computer, then the choice of language and style is about the human condition, a condition which is as varied as the people in it. If one cannot write code that ones finds usable then one needs to keep searching in earnest for a better style. However, once you have a style you can appreciate your own code from years ago then it is a matter of arbitrary standards when interacting with others. You have to draw the line somewhere but lets not pretend for a second that a single writing style is ideal for everyone, or even most. Its arbitrary because without any standards you have an unmanageable chaos.

patrec 10y ago
Functional programming has made huge inroads into mainstream languages over the last 20 years, so I suppose this is because people's brains have suddenly changed?

btschaegg 10y ago

While I know Dijkstra's name only from a "historical perspective" (the algorithm, the goto-letter and some of his reasonings), I somehow grew very fond of a motivational-style picture of him almost frowning[1] with the title "quick and dirty". I still would like to see a version that is of a high enough resolution so one could properly print, frame and hang it on an office wall. I like the idea that - when the next unavoidable proposal of "can't we just [...]" or "all we need is a prototype"[2] comes around - I'll be able to point to it and say something along the lines of "convince EWD first!". [1]: http://www.catonmat.net/blog/difference-between-edsger-dijkstra-and-larry-wall/ http://www.catonmat.net/blog/difference-between-edsger-dijks... [2]: Sometimes I wonder: Is there a "named law" for this? If not, why? It's never just a prototype.

bryanrasmussen 10y ago

sometimes the surgeon is tired, and might like to have a problem phrased in a way that even the barber in the shop around the corner can understand.

nsb1 10y ago

This is a rather idealistic approach to something which has real-world constraints: Despite our misinformed bathtub-curve view of the abilities of the software development community, the world is absolutely teeming with "average programmers", not superstars. It is in your best interests not to shut these folks out of your project if you want to guarantee that the people you hire are able to hit the ground running and not stop by your office every 10 minutes when they get stumped by some quirk in the codebase. What you describe is the "Knotted Shoelace" antithesis to the ball of mud. Functional? Yes. Strong? Sure...but to re-lace your shoe you have to painstakingly pick it apart.

catnaroek 10y ago

Imperative code can be clean and stay clean too, it just requires more effort. Remember that functional programs are easier to understand only because they are less expressive - they can't express concurrency and nondeterminism. That being said, the principle of least power applies in full force, so if (a part of) your program can be written purely functionally, it should probably be written that way.

jxy 10y ago

I always like comparing coding with writing. Depending on your proficiency, you might want to write a pulp fiction, a news article, a PhD thesis, or Shakespeare. You might write in English, American English, Chinese, classical Chinese, Japanese, or Farsi. Maintainability or the cognitive load of the reader or writer completely depends on the proficiency of the reader or writer.