Hacker News new | past | comments | ask | show | jobs | submit login

I think bottom-up programming is great, but I have a bone to pick with that On Lisp quote.

"So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them."

Here's the problem: it's hard to build good abstractions. Every abstraction has a cost and an overhead in learning it, getting used to it, managing the cognitive overhead. The binary black-and-white phrasing of this argument utterly sidesteps any mention of the tradeoffs involved. Most abstractions we encounter in real-world code fail to take into account the cost of using an abstraction. You built it, you're used to it, you can't empathize with others who need to learn it.

Here's my stab at articulating the tradeoffs: http://news.ycombinator.com/item?id=2329613

Common Lisp is a great language, but it's littered with crappy abstractions: too many kinds of equality http://www.nhplace.com/kent/PS/EQUAL.html, an inability to override or extend coerce, redundant control abstractions like keyword args to reverse traversal order (http://dreamsongs.com/Files/PatternsOfSoftware.pdf, pages 28-30), the list goes on and on.




There's even worse than abstractions that are used by their creator only: those that are not used by their creators at all.

I see that in my code all the time: my abstractions tend to suck until I use them myself, at which point I fix them.

The problem is, we often have to build abstractions that others will use before we use them ourselves. At that point we're kinda stuck, because the necessary changes will break code, and that's scary.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: