Comment by dahwolf
3 years ago
Fully agree with the premise. Most youngish users have never even experienced true performance. Our software stacks are shit and rotten to the core, it's an embarrassment. We'll have the smartest people in the world enabling chip design approaching the atomic level, and then there's us software "engineers" pissing it away with an inefficiency factor of 10 million %.
We are very, very bad at what we do, yet somehow get richly rewarded for it.
We've even invented a new performance problem: intermittent performance. Performance isn't just poor, it's also extremely variable due to distributed computing, lamba, whichever. So users can't even learn the performance pattern.
Where chip designers move heaven and earth the move compute and data as closely together as is physically possible, leave it to us geniuses to tear them apart as far as we can. Also, leave it to us to completely ignore parallel computing so that your 16 cores are doing fuck all.
You may now comment on why our practices are fully justified.
The reason is that the money people don't want to pay for it. We absolutely have the coding talent to make efficient, maintainable code, what we don't have are the available payroll hours.
10x every project timeline and it's fixed, simple as.
Granted, the big downside is, you have to keep your talent motivated and on-task 10x as long, that's like turning a quarter horse into a plough horse, it's not likely to happen quickly, if at all. You'd really need to start over with the kids who are in highschool now writing calculator apps in python by making them re-write them in C and grade them on how few lines they use.
ie, it's a pipe dream, and will continue to be until we run out of hardware capability, which has been "soon" for the last 30 years, so don't hold your breath.
> 10x every project timeline and it's fixed, simple as.
I'm skeptical. I've seen too many developers write poorly performing code purely out of indifference. If you gave them more time they'd have a lot more Reddit karma but I'd still be finding N+1 problems in every other code review.
Indifference... or lack of knowledge. I've conducted hundreds of interviews and it's interesting how many people know their O notation and how they can write code that theoretically is "efficient"... but performance is in the details and in knowing the stack top-to-bottom, and most people just don't know that. And the real problem is that they don't know what they don't know.
You'd say that code reviews is where this stuff should be caught, but unfortunately, code reviews are performative in most cases or the reviewers also don't know / care about these details either.
3 replies →
Is it really indifference or are employees responding to incentives? Few places reward code performance. Companies are getting exactly what they pay for and missing a deadline to improve efficiency is irrational under current comp strategies.
“Premature optimization…” we’re taught early on not to waste time on investigating performance.
Or they'll write an engine so they don't ever have to write any boring code again.
When you have more time and budget for a project you can teach junior developers to optimize code better.
> 10x every project timeline and it's fixed, simple as.
> Granted, the big downside is, you have to keep your talent motivated and on-task 10x as long [...]
No, the big downside is that you have to tell your client it'll be 10x times as expensive because you want better performance.
Oh sure, I can justify this easy.
Labour productivity vs wages doubled since the 1970s and the trend seems to be continuing. It was about 150% in 2000 so we can use Excel as as the benchmark.
This means that an accountant today can wait for Excel to load for 2 whole hours of their 8 hour shift, and still be as productive as an accountant from 20 years ago!
Isn't that amazing! Technology is so cool, and our metrics for defining economic success are incredible.
Yeah, agreed ... but[1], in purely financial terms, we are leaving money on the table, right?
Just because an accountant can burn two hours a day waiting for the computer, doesn't mean that we should burn those two hours.
I think that most of the tech stack is there technology-wise, just not aesthetic wise.
If you are happy with how UI widgets looked an behaved on Windows 7, you can have sub-millisecond startup times now for many apps. Trouble is, people would rather wait and look at pretty things than have an uninterrupted workflow.
[1] You knew there was gonna be a "but", right? Why else would I respond?
I mean, we don't have to work 8 hours a day, we can work 10 right? 12? 18? We don't need to work 5 days a week we can work 6, maybe 6.5? It's pretty common in Japan to work 6 days a week. People like pocketing productivity bonuses and they become baked into labor expectations. It's how living standards rise.
> Just because an accountant can burn two hours a day waiting for the computer, doesn't mean that we should burn those two hours.
I think the problem is there is no economic incentive to hire people that would make excel take less than two hours. If good enough gets you the sale, then why spend money getting anything more.
1 reply →
People give push back when I tell them they should drop PHP for Go or Python for Rust.
It doesn't matter that it would be better for everyone and the planet. It's a prisoners dilemma. I only get rewarded and promoted for shipping stuff and meeting deadlines even if the products are slow.
Thank God for open source. Programmers produce amazing libraries, frameworks, languages and systems when business demands and salary is out of the picture.
Meanwhile some people have been using C# and Java for decades which perform better than Go on many benchmarks and their software is still slow as shit.
I was a little skeptical of this claim, so I looked it up. C# winning happens in a handful of cases, but it's extremely rare. Go practically always wins on memory usage, even if it doesn't win the cpu benchmark.
See: https://programming-language-benchmarks.vercel.app/go-vs-csh...
I tried finding more, but most benchmarks I could find were of poor quality.
Java and C# tend to be used for big, hairy, old projects. Thats far less common with Go.
I spent years designing and implementing a new data management system where speed was its main advantage. I painstakingly wrote performant code that relied on efficient algorithms that could manage large amounts of data (structured or unstructured). I tried to take advantage of all the hardware capabilities (caching, multiple threads, etc.).
I mistakenly thought that people might flock to it once I was able to demonstrate that it was significantly faster than other systems. I couldn't have been more wrong. Even database queries that were several times faster than other systems got a big yawn by people who saw it demonstrated. No one seemed interested in why it was so fast.
But people will jump on the latest 'fashionable' application, platform, or framework often no matter how slow and inefficient it is.
I'm sorry I didn't get to see it.
Anyone can download it and try it out. https://www.Didgets.com
The wonderful thing is that the hardware performance is there if you just dare to toss the stack. One of my long-standing projects is to build a bare metal (at least as far as userspace is considered) programming language called Virgil. It can generate really tiny binaries and doesn't rely on hardly any other software (not even C!). As LLVM and V8 and even Go get piggier and piggier, it feels more magical every day.
Is LLVM piggy?
It may be big, but at the end of the day it will produce some fast binaries if fed the right thing.
Build it from source and estimate the number of CPU instructions that required.
2 replies →
from your page
Is that basically Swift's ARC?
You pulled that from the UCLA site, which is the microcontroller version from 15 years ago. That version actually burned the entire heap into the binary and did not allow dynamic allocation. In that case, no GC, write barriers, allocation, etc was necessary.
Today's Virgil (on GitHub) does allow dynamic allocation, but you can still initialize an arbitrarily large heap at compile time. It's not really related to ARC.
1 reply →
Isn't LLVM being a piggy good? As in only pay a hefty computational time price once upfront to stuff as many optimizations as you can in your binary, and make it fast forever after.
It takes 21 minutes to build on a 32 core machine because it's so enormous. It's a that thing translates text into binary. I love compilers; I could go into a long, drawn-out technical explanation of what it does, but really, it's a monster of insane complexity than no one can grok anymore.
2 replies →
I keep threatening to write a GUI IM app that has 90% of what people use slack for, and make every action (other than waiting on the network) instant.
Too many people are arguing that things like Slack and Linen are performing as well as could be expected due to the functionality they are providing.
It existed, a startup that went under, was fully macOS native. I think this was it, "quill".
https://9to5mac.com/2021/02/23/quill-chat-team-messaging-iph...
> It existed, a startup that went under, was fully macOS native. I think this was it, "quill".
I remember that. I wonder why it didn't take off ...
I wasn't intending to make an economically successful chat application. I just want something to point at whenever someone goes "Of course it has to be electron-like; how else are you going to make it cross-platform?"
I want to demonstrate that, yes, you can have fast cross-platform applications without much more effort than going with electron-type designs.
I want to show the source code for it, I want to have a reasonably easy to follow explanation of that source code, and I want it to be reasonably low-effort.
2 replies →
I'm sure you could do this in a browser if there was actually desire. A browser may be many levels of abstraction up from a native app but it is still fairly easy to make apps that respond instantly (except maybe startup time). It's amazing how much extra current apps are doing to slow it down.
Remember that you have to add JS integrations, emoji and gif support. It's useless without it.
> Most youngish users have never even experienced true performance
Most of them have never experienced the level of instability and insecurity of past computing either. Those improvements aren’t free. In the past, particularly with Windows (since this is what the videos recorded) it would be normal for my computer to freeze or crash every other hour. It happens much less today
The video is about Windows NT which did not crash or freeze every other hour.
It still did compared to Windows 10.
1 reply →
I have absolutely no idea what you are talking about "true performance" - maybe you are from an alternate reality? I don't think of the 2000s as "true performance" but rather crashes and bugs and incredibly slow loading times for tiny amounts of data.
I can grep through a gigabyte text file in seconds. I couldn't even do that at all back in 2000.
Nah, the smartest people in the world are working on ads. And ways to track you to serve more ads.