Hacker News Reader

Hacker News

Comment by 29athrowaway | Hacker News Reader

Full thread

29athrowaway

History of computer programming:

- Having an accumulator (abacus)

- Accumulator with operations (calculator)

- Multiple registers with more complex operations (early computers with plugboards)

- Stored program computer (abstraction over the plugboards)

- Imperative programming (simple abstraction over operations + registers)

- Procedures, Functions, Structures

- OOP, functional programming, and beyond.

Why do we keep making layers of abstraction? reusability.

We want abstractions that reduce effort by making code reusable.

But abstractions are only a tool, using the tool correctly is on the programmer.

Code is written once, read many times. Languages that focus on "easy to write" are a trap. Languages that focus on "easy to reuse" are what you want.

View on HN

Abstraction isn't just about reusability; it's also about comprehensibility. I put a lot of effort into lower layers that abstract away complexity, not so that my business logic is reusable, but so that my business logic is easy to write, easy to comprehend, and (within the constraints defined by my abstraction) easy to modify without breaking things. This does require that the lower layers, the abstracting layers, are well engineered, with well-defined interfaces and behaviour, but it pays off, even if reusability is nowhere to be seen.

I highly agree with this. It's almost a necessity these days with a major push to hire "junior" developers at a discounted rate. By doing those lower abstraction layers, you allow them to write the necessary high-volume business code while reducing their ability to do something subtly stupid for the business/data. Usually this involves abstracting away a lot of the database transaction-type stuff.

And on a side note: Never let juniors anywhere near the database design without supervision by the team/seniors. They won't learn anything that way, and they will inevitably make a mess.

In genetic algorithms, you select the best from each generation to breed the next generation.

I think this holds true in software development teams as well.

When you indoctrinate new developers, you should delegate mentorship to the best* performing teams, so new developers can assimilate good practices and develop an intuition for how thing should work.

I think this is much more valuable than giving them grunt work.

*: just like with genetic algorithms, picking the right fitness function is everything. Good performance is about steady, consistent, sustainable development... rather than trading today's problem with tomorrow's problem.

> Languages that focus on "easy to write" are a trap

Reminds me of that time when my company abused Scala Implicits, possible because one of it's libraries for mapping scala to relational database had examples of it.

---

Regarding re-usability. Does that imply well defined interfaces and private scopes? Does that eventually lead us to Pure functions? Afaik, pure func has maybe the highest ease/simplicity for reuse. Happy to be hear your thoughts.

Reply on news.ycombinator.com