11–20 of 144 posts
Earlier quoted context omitted.
The headline is sort of misleading. It is (appropriately) primarily about inappropriate abstractions. As you say, some abstractions are unavoidable. Even assembly language is an abstraction.
That's why real programmers write binary object code directly.
This sounds like an application risk-aversion/-seeking that Kahneman highlights in "Thinking, Fast and Slow" Specifically... each of these individual decisions (wrt to abstraction, in this context) was made to locally optimize (speed, simplicity, etc) some issue or other But when taken in gestalt, they're overall not only not optimal, but downright bad Most of those decisions are made by people far to close to a tiny…
Systems that don’t use the same jargon as the user base end up having substantial bugs, especially ones the authors insist are features. The abstractions are a bad fit for the problem domain and they break things.
I’m in a project that did that massively, at the hands of both architectural astronauts and another common blunder: people who seemed to think the concerns of the user base are beneath them tend to create a fantasy world for themselves where they can pretend they work on something more esoteric than the petty concerns of the people who pay their salaries.
Because of the bullshit (and more importantly, the top-heavy sources of that bullshit) we’ve lost a lot of the better people who could have fixed that situation. Meanwhile we are also trying to expand into a new industry, and I can’t help but wonder if we would have been in trouble even if our abstractions had matched our core competency. I would have needed all of those missing people to make the refactors necessary to do that work, so the agents of chaos and delusion are a little vindicated.
I have a couple of things I want to button up but they are all fast approaching. I don’t expect to be here in six months. I’ve started fantasizing about my exit interview. In which I will probably suggest that my team is too powerful and isolated from the end user and so needs to be disbanded, its members dispersed into groups one and two steps closer to the users. So as to concretize some of the code and confront them with the day to day struggles of internal customers, dealing with the batshit parts of the code.
Lack of abstraction is also expensive: try writing something large in assembly. I'd say that lack of a language / system of notions adequate to the subject area is expensive. The desire to describe things in a way that's efficient for a particular class of problems leads to invention of various frameworks. Say, Rails makes you hugely productive at solving a particular type of problems (see [Shopify]), though it's les…
Go's compiler intrinsics immediately come to mind here. They allow you to easily write Go functions in native assembly, without CGo, for hot code paths. We get the benefits of a high-level language with a fat runtime, but can easily drop down to assembly when we need to.
Every problem in computer science can be solved with abstraction other than too much abstraction.
Earlier quoted context omitted.
The headline is sort of misleading. It is (appropriately) primarily about inappropriate abstractions. As you say, some abstractions are unavoidable. Even assembly language is an abstraction.
That's why real programmers write binary object code directly.
Here is the brief version of that essay:
* Programming is about building theories/models of the problem. Source code largely has no value by itself [1]
* It is very difficult, if not impossible, to transfer these models/theories between humans (see the essay I linked below for details)
* Because of this difficulty, programming is essentially teaching (when writing program code, we're teaching other people of the problem domain, and models that fit that problem domain)
* Another way to phrase this: All programming is building user interfaces. When you're writing, say, a function, you're writing a more abstract UI for the next programmer or yourself
* The tools we have for writing these UIs are terrible - taken the above example of writing a function, what are the tools you have to communicate this idea to the next person? A single string of characters (the function name). In a typed language you get a bit of extra info because of the type information (I believe this to be the main advantage of type systems).
* The big question is: What would a better UI for communicating abstractions look like?
* I don't know the answer to that question but I have a hunch that it has to be bi-directional. If you've ever worked with a GUI library that has a visual editor, you know how awful they are, unless there is also a representation of the same GUI in code. This bi-directional mapping of code and GUI makes it very easy to understand the two different ways of looking at the problem. I think something like this is needed down to the very lowest levels of abstractions.
* Another way to phrase this: Imagine two different scientific models for the same problem. For example, for the model of an atom, its protons and neutrons, there is the more simple Bohr Model, which is completely wrong, given our current knowledge, but still very useful in many modern calculations. But in certain situations, a more accurate model is needed, which takes quantum mechanical effects into account. I see an analogy for programming here: In most cases, a simplified model suffices, but as more performance is needed, a more complex model is required. The question is, how can we easily teach someone the more difficult model, once they've understood the simple one? And the other way around (which is often also not easy, since simple is not the same as easy).
If you have any thoughts on what I've written, any at all, I'd love to hear from you (I'll watch this thread, or find my email in my bio).
The problem is that application performance doesn't only depend on the thing you want to do, but also depends on the low level implementation details and workload, which the programmer may not fully understand or in control of. Some operation may be optimal when executed alone but exists better alternative for batch processing. Some programs may be optimized for throughput but is really bad for low latency applicatio…
I think this way, but in terms of the "performance" of writing the application. What makes it hard to write this program? For example, in high-performance computing, you may need to control memory alignment (for SIMD and cache reasons). That makes it harder to write a program that just implements an algorithm.
So I think you should identify what it is that makes the program hard to write, and pick abstractions that help with that, that give you easier ways of controlling or managing that hard part.
Lack of abstraction is also expensive: try writing something large in assembly. I'd say that lack of a language / system of notions adequate to the subject area is expensive. The desire to describe things in a way that's efficient for a particular class of problems leads to invention of various frameworks. Say, Rails makes you hugely productive at solving a particular type of problems (see [Shopify]), though it's les…
The headline is sort of misleading. It is (appropriately) primarily about inappropriate abstractions. As you say, some abstractions are unavoidable. Even assembly language is an abstraction.