32 ms·

The big problem we have is that people don't care just about software features, but about software bugs. The biggest example is the web. We could have something

The big problem we have is that people don't care just about software features, but about software bugs. The biggest example is the web. We could have something that implements the features of a web browser relatively clearly, but what about the bugs that are treated as features? There are billions of pages that depend on bugs of current browsers to display correctly. The same for other areas such as word processors, operating systems, etc.

klysm 5y ago
I would say backwards compatibility and ossification of terrible APIs is a larger concern.
cogman10 5y ago
I don't know that I agree with this assessment. I think the bigger issue isn't "bugs" per se but rather that we keep accruing capabilities. Take the web as an example. HTML3 was so simple that we had hobbyist implementing it. It could be ran by 100MHz computers with 16mb of ram. Now, the HTML5 spec is impossibly large. So large that we are starting to see big major companies consolidate parts of the browser because it's too complex and too big for 1 multibillion dollar company to keep up to date. It's so large that a team of engineers which worked primarily on browsers never really finished a from scratch rendering engine (Servo) even after several YEARS of effort. The same thing happened to the PDF spec. This happens with a bunch of desktop/consumer products that get old. Excel can still open xls docs from the 90s, even though there's been about 30 different changes to the spec since it was first created. Consider what that does to a product. Even microsoft windows runs into exactly this problem. Microsoft can still run games from the 90s. Considering they completely changed out the kernel, imagine how crazy that is. By and large, they accomplish this feat by keeping around dlls from the 90s and reusing them. This is a primary reason why windows installs are now pushing 10+gb. They can't throw out support or there would be a corporate mutiny. And before we give MS too much shade for doing this, consider what we've done in the linux world. In order to get applications running consistently across OS versions we've decided the best way to do that is shipping almost all of an operating system along with our runnable (Hello docker images)! It's not a question of bugs. It's a question of behavior. And as time goes on, new behavior and capabilities are added to software. The longer it lives as a product, the more true that is. This is where bloat comes from. And consider this, as a software developer, arguing to remove capabilities is almost always a losing proposition. Imagine, for example, if photoshop decided "you know what, nobody really uses JNG anymore, so we should remove it from our products." Any PO worth there salt would say "Hold it, why should we remove this? Is it costing us anything to have it? Just a few MB? Then we keep it!"
- Koshkin 5y ago
  > I don't know that I agree... per-say... hobbiest... accomplish this feet I hole-hardedly agree, but allow me to play doubles advocate here for a moment. For all intensive purposes I think you are wrong. In an age where false morals are a diamond dozen, true virtues are a blessing in the skies...
  - cogman10 5y ago
    Fixed for you.
- badsectoracula 5y ago
  > By and large, they accomplish this feat by keeping around dlls from the 90s and reusing them. This is a primary reason why windows installs are now pushing 10+gb. Not really. I mean, sure, from my Win10 installation (which is around 11GB), 6.8GB are DLL files HOWEVER pretty much all of them are inside the WinSxS which aren't the "DLLs from 90s", but duplicates of various DLLs that applications bring along. Outside of WinSxS the only other place with lots of DLLs is System32, the bulk of which is taken by AMD's drivers and the rest of the DLLs take around 800MB. Then there is SysWOW64 where a similar layout can be found with most of the space being taken by AMD's drivers and around 500MB or so for the rest of the DLLs. Inside other Windows directories there are also around 900MB of various .NET installation DLL. So in total, the Windows DLLs, including .NET are probably around 2GB. However keep in mind that i have a ton of stuff installed, with pretty much every VC and .NET runtime that existed and my installation is a bit older than 3 years old, on a fresh Win10 installation will probably have less stuff in there.

klysm 5y ago

I would say backwards compatibility and ossification of terrible APIs is a larger concern.

cogman10 5y ago

I don't know that I agree with this assessment. I think the bigger issue isn't "bugs" per se but rather that we keep accruing capabilities. Take the web as an example. HTML3 was so simple that we had hobbyist implementing it. It could be ran by 100MHz computers with 16mb of ram. Now, the HTML5 spec is impossibly large. So large that we are starting to see big major companies consolidate parts of the browser because it's too complex and too big for 1 multibillion dollar company to keep up to date. It's so large that a team of engineers which worked primarily on browsers never really finished a from scratch rendering engine (Servo) even after several YEARS of effort. The same thing happened to the PDF spec. This happens with a bunch of desktop/consumer products that get old. Excel can still open xls docs from the 90s, even though there's been about 30 different changes to the spec since it was first created. Consider what that does to a product. Even microsoft windows runs into exactly this problem. Microsoft can still run games from the 90s. Considering they completely changed out the kernel, imagine how crazy that is. By and large, they accomplish this feat by keeping around dlls from the 90s and reusing them. This is a primary reason why windows installs are now pushing 10+gb. They can't throw out support or there would be a corporate mutiny. And before we give MS too much shade for doing this, consider what we've done in the linux world. In order to get applications running consistently across OS versions we've decided the best way to do that is shipping almost all of an operating system along with our runnable (Hello docker images)! It's not a question of bugs. It's a question of behavior. And as time goes on, new behavior and capabilities are added to software. The longer it lives as a product, the more true that is. This is where bloat comes from. And consider this, as a software developer, arguing to remove capabilities is almost always a losing proposition. Imagine, for example, if photoshop decided "you know what, nobody really uses JNG anymore, so we should remove it from our products." Any PO worth there salt would say "Hold it, why should we remove this? Is it costing us anything to have it? Just a few MB? Then we keep it!"

Koshkin 5y ago
> I don't know that I agree... per-say... hobbiest... accomplish this feet I hole-hardedly agree, but allow me to play doubles advocate here for a moment. For all intensive purposes I think you are wrong. In an age where false morals are a diamond dozen, true virtues are a blessing in the skies...
- cogman10 5y ago
  Fixed for you.
badsectoracula 5y ago
> By and large, they accomplish this feat by keeping around dlls from the 90s and reusing them. This is a primary reason why windows installs are now pushing 10+gb. Not really. I mean, sure, from my Win10 installation (which is around 11GB), 6.8GB are DLL files HOWEVER pretty much all of them are inside the WinSxS which aren't the "DLLs from 90s", but duplicates of various DLLs that applications bring along. Outside of WinSxS the only other place with lots of DLLs is System32, the bulk of which is taken by AMD's drivers and the rest of the DLLs take around 800MB. Then there is SysWOW64 where a similar layout can be found with most of the space being taken by AMD's drivers and around 500MB or so for the rest of the DLLs. Inside other Windows directories there are also around 900MB of various .NET installation DLL. So in total, the Windows DLLs, including .NET are probably around 2GB. However keep in mind that i have a ton of stuff installed, with pretty much every VC and .NET runtime that existed and my installation is a bit older than 3 years old, on a fresh Win10 installation will probably have less stuff in there.