441–450 of 564 posts
As a systems administrator who has been doing this for a while, I can attest to this becoming more and more of a problem. I've worked with CUDA programmers who weren't aware of what "architecture" means in the context of computing until I asked them to consider running binary code meant for NVIDIA on AMD GPUs. I've worked with network administrators who couldn't conceive of the simple math behind something like singl…
Having many abstractions on top of each other leading to inefficiencies is a problem, but that is not a problem of the number of abstractions, but rather the poor composition.
Abstractions are like tech debt. When you consume an abstraction, you also get all the klocs (thousands of lines of code) that it represents, they have a price. When you have multiple sources (as in suppliers) of that abstraction this greatly lessons the risk. As does have an abstraction which is total. The post and the url reminds me of the Unix Hater's Handbook. https://web.mit.edu/~simsong/www/ugh.pdf The problem…
Earlier quoted context omitted.
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…
> 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 think there needs to be a clearly defined difference here between professionals and experts. You can be a professional in the field, but until you understand all the layers of abstraction, you aren't an expert. You can't diagnose those deep problems and fix them. Professionals are paid to work in an area, and are thought to know enough not to be horribly dangerous. Experts, on the other hand, are supposed to unders…
Earlier quoted context omitted.
its more than just time. the sad part about this evoluation is that younger people are enculturated to believe that the foundations that they are standing on represent some sort of inviolate physics and not just some technical decision someone made 20 years ago. i think whats required to move forward isn't just some dusty studying of these physics, but a reawakening to an understanding that these are just systems wit…
> younger people are enculturated to believe that the foundations that they are standing on represent some sort of inviolate physics and not just some technical decision someone made 20 years ago. This is simply not my experience of young people or of being young. There's a reason why radical movements are led and populated largely by the young—to the extent they err, it's on the side of "let's tear it all down and s…
Wow what a cool article I feel compelled to share my thoughts. > 338 comments. Nvm all good.
Meh. Unless something very unexpected happens, human programmers aren't going to be a thing anymore, starting in a not-too-far future. And programming AIs will neither have trouble understanding all those layers of abstraction, nor will they add additional ones, since their main purpose is to help limited human minds cope with the inherent complexity of problem domains. So the only way the mounting complexity of soft…
As a 15+ years webdev my recent projects in the front-end are almost pure "vanilla JS" (Just JS) + Html, and CSS with only Petite Vue / Alpine on top. I find the modern Vue, React etc. stacks absolutely insufferably complex and prone to breaking in 1000 places each time you upgrade some package, or change som random thing in the already stupidly complex "Tooling/Build" chains people are setting up by default. And it'…
What are you using server side? I've been looking outside the JS world for an alternative for doing full stack dev and Laravel Livewire seems like an amazing alternative for like 80-90% of use cases. Something like Alpine, vanilla, or even Lit for the more sophisticated interactions.
I’ve been sold these same sorts of promises before (yeah you write backend code and we put some glue in and then everything works like it’s running in browser) and usually it’s a case of a very narrow happy path and indescribable horror once you’ve fallen off and have to wade through or work around the “magic”. I did not go into Livewire with high hopes.
Everything I tried to do with it basically just worked. Coming from a background where I’ve worked with PHP/Laravel/Blade quite a bit already, it was really easy to pick up.
For stuff that Livewire isn’t necessarily the right fit for, alpine fills the gap perfectly and integrates well with Livewire.
My Livewire component has one PHP class that contains, basically, the “controller” that exposes the BE actions for the component and a blade template that contains the “view”, including any basic FE interactivity inline by way of alpine. I use Tailwind and Tailwind UI pretty heavily, so all my styling is inline as well. I’ve found this pretty simple and easy to follow, reason about, and maintain.
I’m pretty sure it’s the most fun I’ve had working on FE code in a long time. It’s definitely the most productive I’ve been. It takes no time to stand something up.
"Abstraction" is a misnomer. This word has its useful meaning in math and art, but in software engineering, all what we call "abstraction" is automation in disguise. When you write a piece of "abstract" code, you only delegate writing the piece of concrete code to your compiler or run-time type deduction. And as soon as this is clear, the attitude follows. Should you know how every aspect of your code is compiled or…
If what you claim were actually the case, the names we assign these "abstractions" wouldn't matter, they could be any arbitrary sequence of characters, since all you'd be doing is grouping code into procedures for the sake of automation. But the names we assign things obviously do matter, not only to make the reader grasp what the abstraction is about, but to decouple the abstraction from its implementation; two diff…
And I'm being nitpicky because the word "abstraction" brings in false connotations. It implies that you can reason about things on different levels as if they were equivalent. But in software, they never are. And I agree with the author in that this pretence of equivalency just doesn't hold and adding more and more abstractions on top of each other is not the way to go if you want to understand how things work and how to make them work predictably and efficiently.
I don't see how my claim diminishes the importance of naming.