3 ms·
One person's readable code is another person's unreadable mess. It depends on what kind of program you're writing. The fact that functional programming emphasi
by cle 5y ago
One person's readable code is another person's unreadable mess. It depends on what kind of program you're writing.
The fact that functional programming emphasizes "abstraction" so much means that, by definition, you're further away from what's actually happening. So looking at some declarative code it's not immediately obvious what the computer will actually do. The kinds of programs I write require me to care about that deeply. So when I see declarative code all I see is a giant question mark as I wonder what in the world the computer will actually be doing when it executes that code.
Anyway, my point isn't that one is better than the other, it's that it depends on what you're doing. For some of us, the higher levels of abstraction are actually less readable.
- ebingdom 5y agoI think this is a reasonable point, and of course you could take it further and say that assembly language is better than functional programming when you're doing work that requires you to reason about what the CPU is doing exactly. But I would argue that the majority of Go programs should not require the programmer to follow the intimate details of a program's execution when trying to understand the business logic. The fact that the language has a garbage collector would suggest that it was designed for programs where some details can be hidden away. So I agree with your general point, but I am somewhat skeptical about its application to Go.
- nexuist 5y agoIf the lack of abstraction is a requirement, why use a language like Go at all? Shouldn't you be using C for these sort of projects?
- cultofmetatron 5y agozig is also a really good contender in this space as well. it also maps fairly cleanly to assembly while providing a bit more safety.
- kaba0 5y agoThe only thing that makes programming any useful program even remotely possible is abstractions. The human brain simply breaks down even at the fraction of the complexity of any non-trivial app. There is wrong abstraction, and over-abstraction that can obscure a codebase, but it is orthogonal. And no, you can’t write simpler code, there is essential complexity, that can’t be reduced. Also, it’s kind of laughable to think that writing code in a high level language with a runtime, GC, etc, you have any idea what will happen at execution.
- cle 5y agoI'm not saying to never use abstractions. There's a balance.