Hacker News Reader

Comment by mrkeen | Hacker News Reader

I think a good first step towards improvement in this space is by separating the terms 'abstraction' and 'indirection'.

Programmers too often add indirections which don't provide abstraction:

  * The programmer wants to POST an object to a web server.
  * The programmer also wants to think about it at the level of POSTing an object to a web server.
  * And yet the programmer creates an HttpClient.java and an AbstractClientManager.java an ClientManager.java.
  * These extra classes are just pointless indirection - not only do they not prevent the programmer from needing to reason about POSTs, but they actively make it harder to do so.

In contrast, if you have a collection type (Set, History, Permissions) and want to treat it as a monoid, that's a huge leap in abstraction, with only one level of indirection.

View on HN

Yes. Anything that is destroyed during the process of compilation is not architecture. It is just a method of code organisation, and we've turned the subject into a holy war, pulling in mindshare that should be spent on more important problems (e.g. we have fibre lines and Ghz multi-core processors, but why are user interactions slower than they were in 1995?).

80% of code organisation problems require doing a couple of things right: directory design (directories, file names, file contents), function design (purpose, naming, parameters, context and return type). I've been coding for almost 25 years and I've encountered the balance "20%" extremely rarely. Even then, 100 lines of simple code is easier to read and modify than 20 lines wrapped in clever abstraction (e.g. I once had the dubious honour of refactoring a broken and unmaintainable state-machine driven code base back to a simple series of if/else/switch/case statements, and the improvement in the development and troubleshooting times seemed almost unfair for such a simple "trick").

This an amazing way to concisely explain the difference between indirection and abstraction. Works for me at least.

Anything undone by the compiler (perhaps even inlined) is just indirection. Everything beyond is actual abstraction (which cannot be broken down further by the compiler as it’s far too limited in its understanding).

I agree that is a large problem with industry.

Folks that have really strong opinions on issues of taste, but then they output apps that send a couple of thousand requests ( with several second latency ) are extremely difficult to reason with.

> we have fibre lines

We do? In my neighborhood, we can’t get fiber lines because of some combination of NIMBYism and political back-scratching allowing a cable company to continue to serve us shit slow and unreliable internet. In the middle of a city!

I’m more interested in solving _those_ problems than how long a request round trip takes.

I live in Sri Lanka. In a Colombo suburb. Fibre lines are available almost everywhere except rural districts. Surely it can't be worse where you are?

I think the reason people do that stuff is because they do provide abstraction, but they only do it in UML diagrams, not in the code.

I've found the shittest programmers to work with are the ones that think visually, because in their head they just deleted two boxes and four lines, but in reality all they did was add 40 lines of code that do nothing.

I think visually, but in terms of memory and datastructures, not in UML diagrams. I don't think the "visual" part is the problem.

I’ve found the shittiest devs still use UML.

https://news.ycombinator.com/item?id=26956298

Because almost all programmers tend to add not only abstractions, but also shortcuts. And as everybody knows, shortcut is a longer but more challenging route.

This, a manager and domain manager for everything. One of the reasons I love go is that is inherently encourages being direct. All of the verbosity that people complain about it is infinitely offset by simply doing the thing. Some examples:

- how directory structure is part of the code organization of the language, and how it's something you have no choice about (so have to spend zero brain power on), and works out of the box.

- the concept of exported/unexported fields (no need complex logic/annotations, ineffective _prefixes)

- named returns eliminating the need for explicit, so useful when exiting early

- default values (+ named returns)

Any of these *manager concepts just seem out of place in Go.

Reply on news.ycombinator.com