Comment by sprachspiel | Hacker News Reader

Comment by sprachspiel | Hacker News Reader

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.

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

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.

Somebody once said:

  the trouble is abstraction can solve all problems except too much abstraction.

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

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.

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.

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.

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.

I don't there are any abstractions that universally improve the understandability of code. It always depends on context.

Everything always depends on context.

Functions cover a lot of contexts (in languages that support them properly and where they are not a syntactic burden).

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

Reply on news.ycombinator.com