5 ms·

It's "abstractions" that led to this: https://youtu.be/kZRE7HIO3vk https://youtu.be/kZRE7HIO3vk [The Thirty Million Line Problem] And Apple is one of the compa

It's "abstractions" that led to this: https://youtu.be/kZRE7HIO3vk https://youtu.be/kZRE7HIO3vk [The Thirty Million Line Problem] And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing. It's all so deeply entrenched - the hardware, abstraction layers, languages, culture - that it's difficult to imagine ever being able to extricate ourselves from this mess. We need another 'quantum leap' in technology, or some new paradigm...

bsaul 3y ago
i don't like to be overly enthusiastic, but an obvious instrument i see right now that would be capable to refactor 30 million lines are LLM. They might be a good tool to provide superhuman code simplification.
- eska 3y ago
  I don’t think that throwing even more complexity at not only our problems but also our solutions is the lesson from that.
  - bsaul 3y ago
    it's a one-time shot though. You see what suggestions the LLM is producing, and decide or not to apply them. Once the code is refactored, you get back to regular coding.
    - flohofwoe 3y ago
      That doesn't sound like it's less work than an "AI free" approach. The tricky part with refactoring isn't figuring out what needs to be changed and how, but to implement the change in a way that it works with the rest of the system, while at the same time actually improving things (and not just applying a different coding style).
- deleted 3y ago
  [deleted]
Someone 3y ago
> It's "abstractions" that led to this: https://youtu.be/kZRE7HIO3vk https://youtu.be/kZRE7HIO3vk [The Thirty Million Line Problem] > And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing. I’m not going to watch an almost two hour long video to check whether it supports that claim or not. Can you elaborate, especially on the “directly” and “insanity” parts?
mpweiher 3y ago
Hmm...Objective-C is exactly the kind of language that helps you prevent 30 million line problems. Of course it doesn't do this by itself. If you insist on using it like a C++ or a Java, you will get the same 30 million line problem, slightly worse, because Objective-C is not a good C++ or Java. But if you can use it right, as the good folks at NeXT did, then you can work magic (aka. a sufficiently advanced technology).
fractallyte 3y ago
Here's a summary of the video: Casey Muratori makes the point that we've had phenomenal growth in hardware power, but our software is not correspondingly better. Computers should be much more pleasant to use. We all know what he's talking about: laggy software, crashes, updates, driver issues, etc. Things are no longer coded from scratch - we pile code on top of code on top of code. Features accumulate, together with complexity - and bugs. How many lines of code does it take to read a text file, in a web browser? Across the whole stack - browser, website, OS, router - he estimates 56 million LoC. The OS alone takes 30 million lines of code! And yet, in the 90s, demo writers routinely produced literal operating systems on a single floppy disk. Remember Amiga demos? They 'hit the metal' because they weren't hobbled by drivers and other abstractions. But as hardware developed, the manufacturers removed that access, forcing developers to work through abstractions. A SoC is a super powered 1980s home computer, but we can't actually reach that hardware. And it's up to hardware people to start taking this problem seriously. And now my comments: Apple is one of those manufacturers. This article hit a nerve with me, because I dumped iOS development; because of the complexity and insanity. Swift is a sprawling behemoth of a language now, hugely complex, full of gotchas. In some senses, it has to be - because it's a reflection of the hardware. I'm not going to elaborate more. Quite simply: you can't program your iDevice, EVER, without going through Apple's prescribed programming language(s), frameworks, libraries, LLVM, and hardware drivers. That's Apple's fault. Computing should not be like this.
- flohofwoe 3y ago
  > And yet, in the 90s, demo writers routinely produced literal operating systems on a single floppy disk. Remember Amiga demos? They 'hit the metal' because they weren't hobbled by drivers and other abstractions. That was possible because the hardware was essentially a "game engine API" (e.g. the hardware was designed to be conveniently used directly, and was also designed with game requirements in mind). Whether that's good or bad is definitely debatable, for instance on the Amiga the need for hardware backward compatibility because of popular games that directly accessed the hardware was definitely stalling the Amiga's progress in the 90's. I don't disagree with most of your points though. We're definitely in an age of unnecessary software bloat, but I think the answer isn't to go back to accessing hardware directly. A lot can be gained by just applying some common sense when writing code. PS: Apple or the iPhone definitely isn't at fault though. The mess already started with the PC and Windows (but this mess also gave us increadibly fast hardware progress in the second half of the 90's by allowing hardware to evolve faster because of driver abstraction layers).

bsaul 3y ago

i don't like to be overly enthusiastic, but an obvious instrument i see right now that would be capable to refactor 30 million lines are LLM. They might be a good tool to provide superhuman code simplification.

eska 3y ago
I don’t think that throwing even more complexity at not only our problems but also our solutions is the lesson from that.
- bsaul 3y ago
  it's a one-time shot though. You see what suggestions the LLM is producing, and decide or not to apply them. Once the code is refactored, you get back to regular coding.
  - flohofwoe 3y ago
    That doesn't sound like it's less work than an "AI free" approach. The tricky part with refactoring isn't figuring out what needs to be changed and how, but to implement the change in a way that it works with the rest of the system, while at the same time actually improving things (and not just applying a different coding style).
deleted 3y ago
[deleted]

Someone 3y ago

> It's "abstractions" that led to this: https://youtu.be/kZRE7HIO3vk https://youtu.be/kZRE7HIO3vk [The Thirty Million Line Problem] > And Apple is one of the companies directly responsible for the explosion in complexity - and insanity - in modern computing. I’m not going to watch an almost two hour long video to check whether it supports that claim or not. Can you elaborate, especially on the “directly” and “insanity” parts?

mpweiher 3y ago

Hmm...Objective-C is exactly the kind of language that helps you prevent 30 million line problems. Of course it doesn't do this by itself. If you insist on using it like a C++ or a Java, you will get the same 30 million line problem, slightly worse, because Objective-C is not a good C++ or Java. But if you can use it right, as the good folks at NeXT did, then you can work magic (aka. a sufficiently advanced technology).

fractallyte 3y ago

Here's a summary of the video: Casey Muratori makes the point that we've had phenomenal growth in hardware power, but our software is not correspondingly better. Computers should be much more pleasant to use. We all know what he's talking about: laggy software, crashes, updates, driver issues, etc. Things are no longer coded from scratch - we pile code on top of code on top of code. Features accumulate, together with complexity - and bugs. How many lines of code does it take to read a text file, in a web browser? Across the whole stack - browser, website, OS, router - he estimates 56 million LoC. The OS alone takes 30 million lines of code! And yet, in the 90s, demo writers routinely produced literal operating systems on a single floppy disk. Remember Amiga demos? They 'hit the metal' because they weren't hobbled by drivers and other abstractions. But as hardware developed, the manufacturers removed that access, forcing developers to work through abstractions. A SoC is a super powered 1980s home computer, but we can't actually reach that hardware. And it's up to hardware people to start taking this problem seriously. And now my comments: Apple is one of those manufacturers. This article hit a nerve with me, because I dumped iOS development; because of the complexity and insanity. Swift is a sprawling behemoth of a language now, hugely complex, full of gotchas. In some senses, it has to be - because it's a reflection of the hardware. I'm not going to elaborate more. Quite simply: you can't program your iDevice, EVER, without going through Apple's prescribed programming language(s), frameworks, libraries, LLVM, and hardware drivers. That's Apple's fault. Computing should not be like this.

flohofwoe 3y ago
> And yet, in the 90s, demo writers routinely produced literal operating systems on a single floppy disk. Remember Amiga demos? They 'hit the metal' because they weren't hobbled by drivers and other abstractions. That was possible because the hardware was essentially a "game engine API" (e.g. the hardware was designed to be conveniently used directly, and was also designed with game requirements in mind). Whether that's good or bad is definitely debatable, for instance on the Amiga the need for hardware backward compatibility because of popular games that directly accessed the hardware was definitely stalling the Amiga's progress in the 90's. I don't disagree with most of your points though. We're definitely in an age of unnecessary software bloat, but I think the answer isn't to go back to accessing hardware directly. A lot can be gained by just applying some common sense when writing code. PS: Apple or the iPhone definitely isn't at fault though. The mess already started with the PC and Windows (but this mess also gave us increadibly fast hardware progress in the second half of the 90's by allowing hardware to evolve faster because of driver abstraction layers).