Learning about the concept of "Leaky Abstractions" made me finally get why programming is so complex these days. Of course there is a lot more actual complexity in what needs to get built, and abstractions can help to simplify that complexity, but the abstractions can't cover up all of the underlying complexity, some of it "leaks" out. So if you're using an abstraction and encounter a leak, you still need to have a proper understanding of the hidden complexity to work around it. If you don't understand the complexity, you either have to work around it with a messy subpar solution or you're just stuck. With so many layers of abstraction between the CPU and many modern frameworks, the surface area of understanding is huge. If you want to make a good application nowadays, you have to understand all the frameworks you're using, the things they're built off of, what those things were built on, etc., plus all the smaller abstractions inside those larger abstractions e.g. strings or networking. People not having any idea of what abstractions are covering up are how you get web devs who don't know what memory management is, and write wasteful, multi-level nested loops.
The web app I work on currently has several places where we have that kind of loop, and it's frustrating because I know our performance issues are due to stuff like that, not the size of our data or anything about our business domain, but de-fooing that kind of stuff is never prioritized. There's a company priority issue in addition to the many failures of understanding. But yea it's pretty heinous - loop i covers 100k things, which is fine, but loop j covers 100 things and loop k covers up to thousands. Instead of 100k iterations - or even, gasp, rewriting the queries to fetch the data we actually need - we have somewhere between 10 million and a billion iterations just to chuck data out to the front end for display. It's appalling.
I learned about the Law of Leaky Abstractions pretty early on, but it never dawned on me just how much truth it holds and how deeply it affects almost everything we build. Since I started working as a professional dev I had so many situations where the culprit was some implementation detail leaking through, where it was promised that I don't need to care about it, and then I ended up needing to care about it after all cause it broke things. At the end of the day you should need to understand the systems you work with 2 - 3 levels deeper than what you write yourself, so that when something inevitably goes wrong or doesn't work as expected, you can fix it. But it seems like most of my colleagues don't seem to think like that, even ones that have decades more experience than me. They just stumble their way through any problem and wonder why their unstructured giant mess is error prone and runs unusably slow.
@@MrAbrazildo Strings can be deceptive, because some languages try to treat them almost like a primitive type. If you don't understand that a string is actually an array, you're gonna get really confused when you start getting performance issues doing large scale string construction/manipulation. Its not a well hidden abstraction, but I've seen new programmers not make the connection immediately.
@@Norphesius I took that as a weird example, because to me string has a lot less layers of abstractions than networking or any "concept" from higher level langs.
The materials science analogy is brilliant imo, never thought of it like that I feel this urge to go and start classifying a bunch of different types of code right away, would be interesting to see how the materials-science-code-types correlate with the language. I'm a java guy so maybe most of the java code would be like some sort of abrasive breeze block, rough and ugly but ultimately a core ingredient of any decent building lol
Twenty seconds in and Luke already said one of the greatest truths in programming. Abstractions in programming are like having to deal with electronic aids on cars and bikes that are too invasive when you have a bit of racing driver's experience and control: they just get in the way.
It's funny, if you learn math or physics, you have all kinds of abstractions, but you never have abstraction "layers". It's a purely IT engineering thing.
Just got this vid recommended right now and funnily I said something very similar just a few hours ago: my style or programming is probably closer to how I wrote 25 years ago. In between there have been the GoF Javaesque patterns everywhere, the template meta programming and the functional abstractions phases. Now I am back to "just make 3 ifs and thats it". Mostly because over the years I have akmost never seen that it actually really became nexrssary to "add another implementation" to something. And the few times it did, they were often so fundamentally different that the abstraction fell apart anyway (like the whole crap replaced by a single neural network)
@@brokula1312 thanks, taking that as a compliment. Picture is about 4 years old now, I am 41. First professional work for me was age 19 where I started as embedded dev but been programming since age 12 and did a vocational "EDP electronic data processing" school from 14 to 19. Retrospectively the time when I was around 17 and have read the Scott Meyers books, tons from Carmack and friends and Hargrove's Code on the Cob... well the time was a better time than the subsequent Java Enterprise indoctrination;).
The purpose of abstractions, if done right, is to allow the programmer to no longer think about the abstracted things he is using. Imagine there is something like "ToBytes" for a set of classes. You do not need to know how it happens, it just happens. You call it, and it returns a byte array. Ideally it would be something that can be easily replicated, so that you can create new classes and give them that feature. If using abstractions makes things more complicated rather than easier (as the meaning of the word), you have a problem. You are not abstracting really, you are just adding complexity using means of abstraction.
Right, but sometimes you need to know how the abstracted things work to fix bugs or optimize your code. And in any large program that doesn't care about abstraction cost, there's typically deep chains of (black box) abstractions that you'll be afraid/overwhelmed to dig into. E.g. imagine ToBytes(T) did a deep copy instead of just a pointer cast and array size multiplication, and you thought it'd just be a handy cast.
If you can't trust the abstraction, then yes you have to hold that complexity in your head as you're stepping through the code. But that's an issue with the abstraction, not necessarily that there is an abstraction. The purpose of the abstraction is to not require the user to dig into it to understand what it's doing. You need to trust the abstraction, because it's a very well tested, documented, and widely used piece of software. If you don't, and you have to dig down into it, then that's an issue. Solve why you don't trust the abstraction, and then move forward.
@@ChrisCox-wv7oo I agree with your first paragraph, except that someone will always have to occasionally dig into an abstraction to understand it. Many "modern" abstractions are black boxes, which makes that much harder or impossible. As far as trusting abstractions goes, "widely used" isn't a great metric for maintainability, in my experience. Popularity is mostly good for knowing what might be the most viable choice for shipping your first piece of software in that realm, if you're not yet an expert. In my experience, many times the issue with the abstraction is that it's far too complicated and generalized to debug subtle issues - and that the API lacks the granularity that allows increased flow control. The typically picked solution is to do complicated workarounds that adds additional complexity, because the abstraction is too large that anyone dares to replace it. And if those workarounds are abstracted too, then you get even more brittle software.
I blame OO frameworks and design patterns. Patterns are scabs over gaps in the underlying language, and frameworks are someone else's idea of how the world is divided up, not how it really is in the corner you're trying to work. Even the libraries are abstracted to a level suitable only for textbook exercises -- so generic that they are unreadable and drowning in dispatch overhead.
OOP is hard to understand. It seems like the concepts of OOP gets the center, rather than what they may represent. A lot of developers actually have problems thinking abstractly, as they are working in existing structures.
It is not that simple. Our team is communicating using english, because that is the language what everyone understands. We also use english naming and commenting in code in very same reason. Sure we can use chinese, arabic or whatever language but that makes things harder. Programming language is very often choose that it has syntax that other developers understand. There are also technical considerations for language but there a lot of software written where language is chosen purely to ease communication. Programming language mainly defines syntax level and standard libraries are.. small. That is when we need semantic level in communication so opionated frameworks, component libraries, names in design patterns and architectures define semantic level how to communicate. That is the reason why projects chose frameworks with coding standards and conventions. That is also not enough so we also wrote glossary for naming things in business domain. Decades of code and books written are defined programmers vocabulary witch is kind of english like thingy having words with formal meaning that doesn't exists in formal language we used to program. Frameworks are just filling that. I don't think ready frameworks works every case but these exists to standardize conventions and offer documentation. Interesting stuff is usually written more like functional paradigm but don't underestimate importance of naming things. Naming is one of the hardest thing in programming, other hard thing is to know what to code in first place.
The reality is most people will abstract code at some level, they just don't like when other people build abstractions on top of their code. I do that too. The problem is when 2 people (for example, the easiest use case) don't communicate about adding abstractions. Most things don't require abstractions, they just require more sensible defaults and some sensible ways to modify those defaults. And "sensible", more often than not, means "using primitives" or "using things close to being primitives". Just make sure there's a very good fucking reason for adding abstractions instead of using primitives in a clever way.
Abstraction layers have a cost and a benefit. I rather blame the people for ignoring the requirements they have regarding the code. There are hard requirements regarding the hardware restrictions and various softer requirements. Just weigh your priorities. There is no wrong or right only suitable and unsuitable priorities for your context.
I see a lot of comments defending abstractions but even something as simple as a long long can cause C abi headaches for most languages which rely on it. Putting uint64_t instead would increase clarity and robustness but removes the abstraction of a numerical data type. Over a long run you can't have useful abstractions without arbitrary standards people agree to. Hiding complexity with abstraction is akin to sweeping trash under a rug.
1:18, if an abstraction added complexity, it wasn't well made. 2:44, failed projects have 1 thing in common: lack of abstractions. If it has them, and good ones, you can decompose the problem in smaller ones, making things easier to understand.
@@RenamedChannel I know they weren't directly against abstractions. However, I know where this kind of talk will end. So, I already shielded abstraction against commonly wrong thoughts about it.
Jonathan Blow is often providing interesting thoughts but his rage against abstractions seems quite misguided. My own take on it is that Blow has seen people abstract things related to extremely performance-sensitive things(basically game rendering) and it has resulted in bad things, so he views all abstractions as bad since in this particular case you have to appreciate the abstraction level of low level hardware utilization regardless... But he then takes this idea to something like word processors, and makes it seem like if word processor opened up few milliseconds faster, we'd live in utopia, similar to saving few milliseconds on rendering pipeline. Which is silly, but I've yet to see him make any attempt to distinguish his preferred topic of rendering pipelines from cases where the interesting problems are on abstraction layers far removed from cpu register utilization and ram layouts
John was talking about the complexity of the entire system, not just within theory space like what your claim necessitates. It is impossible to add an abstraction without making the system as a whole more complex, since the system with the abstraction is larger than the system without. You can argue about tradeoffs and if certain abstractions are worth it (they are and John thinks they are), but misrepresenting the point due to basic conflation is just dumb.
@@gJoniiI feel like his point is that slow software is a symptom of shoddy design choices, which is hard to argue against. Bad and slow software go hand in hand.
I know this is a passion channel and I love the substance. However, your manner of looking away constantly when talking or asking questions becomes a little annoying for a viewer.
