Could you please communicate instead of just replying? I have no idea what you're talking about and would appreciate a fully expressed thought instead of a one liner or a vague 6 word phrase.
Thanks to extension spaghetti, there isn't a single OpenGL API, it is like programming for the Web or UNIX flavours, you end up with multiple code paths depending on the extensions available, thus it is like programming against multiple APIs even if it says OpenGL in the box.
Whisper large-v3-turbo is still the SOTA non-cloud model? Damn. I'm wanting to move away from it to something smaller/better but based on this comment it seems like I made the right move by sticking with whiser.cpp this whole time. It's been 2 years since large-v3-turbo was released...
I worked at bigcorp for half a decade before all of the LLM stuff and there was exactly one time I really had to give a shit about algorithmic complexity in that entire tenure. Obviously some developers needed to care more than others, but the vast, vast majority of work and roles just didn’t really need to care about this. 9 times out of 10 you’re using the off the shelf library that already has the optimized bubble sort of whatever for your job
Working at bigcorp for 14 years so far and I struggle to think of a single day where I didn't need to consider algorithmic complexity or efficiency. Do you not write code that fetches things from a database? Do you not need to make tradeoffs between how much data you fetch at once, which fields you load, which things you cache, whether your query joins on the db or materializes things separately, whether you lazy or eager load, whether you are doing a O(1) or O(n^2) lookup and the tradeoffs, whether you can use a db index or not, memory/latency/compute/storage tradeoffs, etc? I feel like in even a simple bigcorp SAAS you need to consider this stuff daily.
Unless you are dealing with data at true scale, and not many people are, often the imperfections are hidden because they run fast, even if they are quadratic. I'm more referring to being actually forced to sit down and write out your own algorithm in a novel way.
Yes, during my BigCorp tenure I had to think about complexity all the time, but 99 times out of 100 there was an off the shelf tool available for my specific data structure and I didn't have to think about the algorithm at all beyond "oh there's a library that solves this for my specific data structure, and it's O(N)log n that will be fast enough". Whereas so much attention in interviewing traditionally was based on these "write a bubble sort algorithm from scratch" type questions which your average engineer basically never has to do on the job unless they are operating in a very high performance/scaling type of role.
How often you have to take algorithmic complexity into account depends on what level of the stack you're at, but even at the application level, I think understanding algorithmic complexity is still important.
I was working at Company X around 2013, and we had a Rails ecommerce site. Trivial in the algorithmic sense. Had a contractor that pushed a change that somehow made everything crawl. When we did profiling together, it turned out he had written an O(n^2) algorithm when looking up country codes or something. Sometimes, there's no off-the-shelf library, and it's the minimum a dev should know not to do.
I'm not saying it should be a maniacal focus, but it should be taken into account. Of course, it's with judgement. We get shittier and shittier software if it's not taken into account at all.
>I worked at bigcorp for half a decade before all of the LLM stuff and there was exactly one time I really had to give a shit about algorithmic complexity in that entire tenure.
Conversely, I've got a PhD in math, and all my tenure (whether it was bigcorp - Google, etc - or smallcorp) was about algorithms and performance where off-the-shelf library does not exist, and you can't throw compute at the problem to do it the dumb way.
I don't know man. Being able to reason about DS&A was pretty useful before the advent of ML Code Generation. If only to pass the interviews at Google/Facebook (when they were in their prime circa 2004-2016).
Also, didn't the parent comment say he went back to college?
They used to be able to. I don't think they can anymore. The iPhone 6 was 3 years after Jobs died. Apple's corporate/engineering culture has had 12 additional years to rot since then. If the Scott Forstall situation, Chris Lattner situation, etc, tells you anything, it's that Apple cannot make basic, common-sense tradeoffs anymore. All they can do is copy whatever the wider industry is doing.
All of the excuses people are coming up with in these comments are just that: excuses. Look at the sibling comment by musictubes, for example. Citing these ethereal "critics" and "most people" when in reality Walt Mossberg was the only critic whose opinion mattered.
Occam's Razor: The Innovator's Dilemma. It's a rotting, bloated megacorp with too much to lose, that doesn't take risks, and can't change direction. The direction it's in is "bigger phones", for whatever reason. So we're gonna keep getting bigger phones. It's that simple.
I just don't think he realizes how saturated it got over the years. Or maybe he knows at a conscious level, but not subconsciously.
In 2000 (his era), it would have been really smart to study the source of Linux or Apache. Would have paid dividends over decades. Cuz that knowledge was so rare. The number of people hacking on LLMs now dwarfs the number of people hacking on web servers 30 years ago, by several orders of magnitude.
And if you turn back the clock even more, I mean just even having access to a computer, let alone owning one, would have put you at a massive advantage.
I don't know what to call it. The pioneers should be respected obviously, but at the same time you need to understand that for them, the game wasn't nearly as played out as it is now.
I just don't think you can afford to be dicking around with LLMs like you could afford to dick around with random Linux distros 20 years ago. Too many people willing to do it for free these days.
You don't wanna end up being the 2030 equivalent of a certain SNES emulator developer, or maintainer of a package manager for jailbroken iPhones, I mean the list goes on and on. Being a hacker doesn't automatically give you a path to being rich, or even making a decent living. It hasn't been that way for a while.
If you look at one of the studio sessions between Drake and 40 (look up "100gigs" on youtube), there's this flow between the two, almost like an implicit language that they invented together, that lets them collaborate at an insane speed.
The problem is you need to fully trust your collaborators, and that's really hard to find in this industry. Most people never find it. I haven't.
I've seen it though. It exists. Very rare. I know two guys who used to participate in Ludum Dare over 10 years ago who would have loved something like Zed if it existed back then.
By contrast, at your 9-5 where you don't know if your coworker is gonna stab you in the back for a promotion (which I suspect is most people in the comments here) then Zed is probably not a great tool. Git would be a better fit for that. After all it was made to develop Linux, which is one of the lowest-trust collaborative environments out there.
For me it's less about trust and more about practicality. If you are coordinating live in person while collaborating that is a bit different than trying to edit a doc multiple people are in, all remotely. When I had said it's not fun that's the case I had in mind.
Linus actually mostly deals only with trusted subsystem leads. They may choose to deal with less trusted contributors, but I wouldn't say the Linux kernel development process is low trust. Many of those folks have worked together for decades.
reply