4 ms·

Three sad programmer stories and a happy ending: In order to handle complexity, I split my program carefully into modules with low coupling. I'm happy until a

Three sad programmer stories and a happy ending: In order to handle complexity, I split my program carefully into modules with low coupling. I'm happy until a new feature comes along which cannot be implemented without destroying the independence of the existing modules. Then there are two options: Either I redesign the system based on the new requirements or hack the new feature into the old architecture. Both alternatives make me sad. I recognize some repetitive pattern in my code. So I create some straightforward abstraction that removes the redundancy. I'm happy until the pattern appears again, but this time in some slightly different form so that the old abstraction can't handle it. Then I change the abstraction to include the new case. Eventually, I realize that the abstraction has only complicated the system, because now one has to understand both the implementation of the abstraction and the use of it. This make me sad. I'm working on some easy task. I know that I have solved problems like this many times before. Unfortunately this time my brain just refuses to solve the problem. Without solving the problem, I go home and think about pursuing a different career. On the next morning I solve the problem within 5 minutes and I'm glad to be a programmer.

j_baker 17y ago
"On the next morning I solve the problem within 5 minutes and I'm glad to be a programmer." I can't count the number of times this has happened to me. Never underestimate the effects of a good night's rest.
- RyanMcGreal 17y ago
  A good night's sleep is an essential part of my problem solving work flow. For smaller problems, I find a brisk walk can often break the mental logjam.
eru 17y ago
> Eventually, I realize that the abstraction has only complicated the system, because now one has to understand both the implementation of the abstraction and the use of it. That's a real problem. The best abstractions are so useful, that they even help understanding when you only use them once. E.g. functions come to my mind --- because they have clear entry and exit points (of control and communication), they can be easier to understand than the same code inlined. (Functors and Monads also seem to enhance my understanding.)
- igrekel 17y ago
  Functions are indeed a good tool but at one point, they accumulate more and more parameters or more complex structures as parameters. Eventually, while you still understand the purpose of a function, it is difficult to understand all that it abstracts away. I am just saying this because I totally relate to the article,it is often very hard to contain or abstract complexity. or it requires nearly equally complex mechanisms or abstractions.
  - eru 17y ago
    Yes, a function should be short and sweet. This applies very well to functions in Haskell or Scheme (or words in Forth). Those languages (Scheme slightly less so) also have low syntactic overhead for defining a function/word. It's OK for functions to grow more abstract. Just provide the simple things, too. E.g. you start out with `map' and `filter', but then realize that `foldr' can express both of them and much more. One viable path is to rewrite the definitions of `map' and `filter' in terms of `foldr'. One should not use `foldr' everytime in the code where a `map' or `filter' suffice. One can layer abstractions and then use the most specific tool possible that still has all the flexibility you need at each point.
    - igrekel 17y ago
      As features accumulate over time, I find this is harder and harder to maintain. But it heavily depends on the situation (abstractions don't always hold as well as originally hoped). I guess I just remember more the times it goes wrong than the times it went right.
      - eru 17y ago
        Oh, I often have to bang my head against the wall quite a few times, before I hit on the right abstraction. Having more powerful abstraction techniques, like they are possible in languages like Haskell or Scheme/Lisp, tends to give less leaky abstractions for me.
- joe_the_user 17y ago
BigZaphod 17y ago
This is the most accurately stated summary of the process of programming that I've ever read!
olliesaunders 17y ago
Somebody once said: the trouble is abstraction can solve all problems except too much abstraction.

j_baker 17y ago

"On the next morning I solve the problem within 5 minutes and I'm glad to be a programmer." I can't count the number of times this has happened to me. Never underestimate the effects of a good night's rest.

RyanMcGreal 17y ago
A good night's sleep is an essential part of my problem solving work flow. For smaller problems, I find a brisk walk can often break the mental logjam.

eru 17y ago

> Eventually, I realize that the abstraction has only complicated the system, because now one has to understand both the implementation of the abstraction and the use of it. That's a real problem. The best abstractions are so useful, that they even help understanding when you only use them once. E.g. functions come to my mind --- because they have clear entry and exit points (of control and communication), they can be easier to understand than the same code inlined. (Functors and Monads also seem to enhance my understanding.)

igrekel 17y ago
Functions are indeed a good tool but at one point, they accumulate more and more parameters or more complex structures as parameters. Eventually, while you still understand the purpose of a function, it is difficult to understand all that it abstracts away. I am just saying this because I totally relate to the article,it is often very hard to contain or abstract complexity. or it requires nearly equally complex mechanisms or abstractions.
- eru 17y ago
  Yes, a function should be short and sweet. This applies very well to functions in Haskell or Scheme (or words in Forth). Those languages (Scheme slightly less so) also have low syntactic overhead for defining a function/word. It's OK for functions to grow more abstract. Just provide the simple things, too. E.g. you start out with `map' and `filter', but then realize that `foldr' can express both of them and much more. One viable path is to rewrite the definitions of `map' and `filter' in terms of `foldr'. One should not use `foldr' everytime in the code where a `map' or `filter' suffice. One can layer abstractions and then use the most specific tool possible that still has all the flexibility you need at each point.
  - igrekel 17y ago
    As features accumulate over time, I find this is harder and harder to maintain. But it heavily depends on the situation (abstractions don't always hold as well as originally hoped). I guess I just remember more the times it goes wrong than the times it went right.
    - eru 17y ago
      Oh, I often have to bang my head against the wall quite a few times, before I hit on the right abstraction. Having more powerful abstraction techniques, like they are possible in languages like Haskell or Scheme/Lisp, tends to give less leaky abstractions for me.
joe_the_user 17y ago

BigZaphod 17y ago

This is the most accurately stated summary of the process of programming that I've ever read!

olliesaunders 17y ago

Somebody once said: the trouble is abstraction can solve all problems except too much abstraction.