13 ms·

A Plea for Lean Software (1995) [pdf]

146 points by dvfjsdhgfv 5y ago

dvfjsdhgfv 5y ago
One of the key quotes: > Another important reason for software complexity lies in monolithic design, wherein all conceivable features are part of the system's design. Each customer pays for all features but actually uses very few. Ideally, only a basic system with essential facilities would be offered, a system that would lend itself to various extensions. Every customer could then select the extensions genuinely required fora given task.
- sidlls 5y ago
  Such a system sounds nice in theory. In practice it leads to a byzantine nightmare of configurable interfaces, support systems, and so on, with a result that is ultimately fatter and harder to maintain.
  - CraigJPerry 5y ago
    I disagree with that - what i’d call a plugin architecture - leads to a very nice separation of components.
    - interactivecode 5y ago
      plugins works for things that are plugins. Most people seem to equate separation of concerns with everything should be a plugin. Otherwise you get massive issues actually working across each plugin (or package). So unless your component is actually used in multiple core products it's not a component, it's just a part of your monolith. Making it a separate component usually, just spreads your monolith across several git repo's
  - Jtsummers 5y ago
    I don’t know. It sounds similar to a lot of IDEs. Produce an interface that plugins can make use of, then people can extend the system to support new languages and capabilities. Seems to work well in a lot of cases.
  - mysterydip 5y ago
    That was my first reaction, but I think it can work in some cases. Take for example plugins in a paint program, or dissectors in wireshark. Both of those can have any number of user-created extensions for different packet types or editing that the general populace doesn't need. However, to your point, when wireshark changes their API every few versions, all the plugins have to change as well or you either break your dissectors or are stuck on an old version. The base program should be designed with extension maintainability in mind.
  - jcelerier 5y ago
    As an user, all the software that I take actual pleasure in using and make me productive, are large plug-in based software. As a developer of a mainly plug-in based application, the iterating ability it gives is pretty incredible - nowadays for a large majority of my feature requests, I don't have to touch the original codebase at all, just create a small plug-in for the feature.
  - vendiddy 5y ago
    If the interfaces are defined poorly, it can result in what you are describing. But I've seen systems do this well and the result is something far less complex. I agree with the author's view that good interfaces require iteration. So expect that several irrational will have incorrectly drawn boundaries and poorly defined interfaces. This kind of design takes time, but if you expect the system but if you expect that it will need to evolve over the years, it pays for itself.
  - 7952 5y ago
    Well it depends on the level of abstraction you use. You could think of the operating system as the platform, and each piece of software as a plugin. That can work well enough. I can save a PNG in photoshop, and then open it in other programs and it just works. But the file paradigm has lost popularity and there are probably some good reasons for that.
  - fouric 5y ago
    Emacs is a system that adheres to this theory, being a small C core that implements an elisp runtime, and then the rest of the built-in functionality (as well as the entire plugin ecosystem) implemented as easily-tweakable elisp on top of that - but has not turned into "a byzantine nightmare of configurable interfaces, support systems, and so on". It's quite the counterexample to this claim.
    - taeric 5y ago
      I'd argue that emacs is more monolithic in is main focus of text editing and elisp execution. It doesn't just build a plugin architecture. It literally built a platform and does most of it's work in the same way that user code can run.
- necrotic_comp 5y ago
  Isn't this more or less the idea behind Gentoo ? I know that when I initially started setting my system up, it was a bit of a mess trying to figure out what USE flags I needed/etc., but once it stabilized, it was great to know that I had a system that worked and there was no trace of software or libraries I didn't want or need. It definitely is a bit more legwork to do up-front, but I feel like the idea of "this is what I want, please build only to that spec" has saved me a bit of heartache as I've been using my system and while the leanness doesn't matter per se, it feels like it's helping my system be a bit more organized.
uniqueuid 5y ago
Previously (with comments): https://news.ycombinator.com/item?id=8301511 https://news.ycombinator.com/item?id=8301511 https://news.ycombinator.com/item?id=24059704 https://news.ycombinator.com/item?id=24059704 https://news.ycombinator.com/item?id=17872400 https://news.ycombinator.com/item?id=17872400
- deleted 5y ago
  [deleted]
- dang 5y ago
  Thanks! I've added one small one: A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=24059704 https://news.ycombinator.com/item?id=24059704 - Aug 2020 (137 comments) A plea for lean software (1995) [pdf] - https://news.ycombinator.com/item?id=17872400 https://news.ycombinator.com/item?id=17872400 - Aug 2018 (100 comments) A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=8537970 https://news.ycombinator.com/item?id=8537970 - Oct 2014 (3 comments) Niklaus Wirth: A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=8301511 https://news.ycombinator.com/item?id=8301511 - Sept 2014 (12 comments)
slver 5y ago
Pleas don't work. What works is restrictions. This is why when iOS restricts apps from eating up the entire physical RAM on the device, and developers complain that this is not like on the mac/PC, they should realize Apple is extremely familiar that it's not. And it'll never be. When you let go of restrictions, applications bloat up to take the available resources while adding almost nothing in terms of functionality.
- cle 5y ago
  To me an interesting question is why they bloat up. Is it all mindless waste or is there a tradeoff being made here?
  - legulere 5y ago
    Optimizing software costs developer time, so it’s only done when needed.
    - fredsir 5y ago
      So its about core values, it’s about principles. It’s because people focus on something else than craftsmanship and creating great things. Obviously, it’s because of how our society and culture is oriented. But I’d like to see that change.
      - legulere 5y ago
        You can put almost infinitely much effort into optimization. When do you stop? Do you test every user-interaction takes less than 100 ms below which it can be considered good?
        deleted 5y ago
        [deleted]
        loup-vaillant 5y ago
        I would hope so actually: someone needs to test every user interaction at least once, at which point we can notice if it's too slow.
ChrisMarshallNY 5y ago
> Another important reason for software complexity lies in monolithic design, wherein all conceivable features are part of the system's design. This is really a call for modularity. I'm a believer in modularity, but it is not a cure-all. Modularity brings a lot of baggage with it, like duplication of code and lifecycle management, along with increased resource usage (ironic, as the article is mainly about reducing resource usage). But I am still a believer in it. In my experience, it makes for a massive increase in system stability, quality, agility, and speed of development.
- numbsafari 5y ago
  > Modularity brings a lot of baggage with it, like duplication of code and lifecycle management If the operating system and standard libraries provide better facilities for the common parts, that can go a long way to solving these problems.
  - ChrisMarshallNY 5y ago
    Exactly. But these days, everyone likes to bundle in dependencies. Also, for cross-platform SDKs and libraries, the provider may be forced to "reinvent the wheel." That may well be worth it, as developer bandwidth, and time-to-market are important variables.
    - numbsafari 5y ago
      > But these days, everyone likes to bundle in dependencies. If the OS and standard libs provide those dependencies, then I don't need to bundle them. I'm thinking of things like the Go or Python standard libraries, or OTP in Erlang. On iOS you have a rich set of built-in frameworks, etc., etc.
      - ChrisMarshallNY 5y ago
        ...and you have a huge number of folks that program for iOS in JavaScript, with dozens of dependencies in each project. This can lead to some rather...overfed...applications, and four- or five-digit bug counts.
RcouF1uZ4gsC 5y ago
A good counterpoint to this is Joel on Software’s post about “Bloatware” https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv-bloatware-and-the-8020-myth/ https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...
- jhgb 5y ago
  I don't see how this vulgar reduction of the problem in question to just size of binaries has anything to do with what Wirth is talking about in that article, which are among other things the factors of maintainability, cognitive load, reusability and such.
klelatti 5y ago
> Time pressure is probably the foremost reason behind the emergence of bulky software. Indeed, but for startups now I'd add easy scaling. With the public cloud why worry about efficiency now (vs time to market) if you can easily scale up later.
deleted 5y ago
[deleted]
econner 5y ago
I feel this. I just upgraded MacOS 11 Big Sur and to XCode 12.5 (from 12.4). Both updates were 12 GB.
deleted 5y ago
[deleted]
bigbillheck 5y ago
The 'inflated' software Wirth complains about is the same as is often fondly remembered in places such as here by people talking about the Good Old Days.
Flex247A 5y ago
I mean, some software can really get rid of bloatware without losing much functionality. For example: The AMD Adrenalin driver takes about 1GB of disk space and comes bundled with a browser. The control panel takes forever to start, even on a laptop with NVME SSD. This is why I have switched to installing drivers through Windows Settings.
andrewmcwatters 5y ago
I don’t know how you would do this, other than setting core affinity, but I’m surprised I can’t limit processing power or RAM per process on any modern OS. Both for setting restrictions per another comment here, but also for testing purposes. Like, I’d love to be able to run an executable with equivalent processing power to that of a specific CPU generation.
- Etheryte 5y ago
  On macOS, there is a legacy CPU throttler called AppPolice [0] which as of right now still works on Catalina, despite the last release being made in 2016 (!). The user experience is very flaky, but it can help out when it's really needed. I haven't tested it on Big Sur. Definitely agree though, this is something that should be baked into the OS as a first class citizen, especially in the modern era of Electron-all-the-things. [0] https://github.com/AppPolice/AppPolice https://github.com/AppPolice/AppPolice
- delusional 5y ago
  On linux you could use cgroups and cfs_quota: https://www.kernel.org/doc/html/latest/scheduler/sched-bwc.html https://www.kernel.org/doc/html/latest/scheduler/sched-bwc.h...
- phaemon 5y ago
  Surely you can with cgroups? Isn't that exactly what they're for?
- opencl 5y ago
  On Linux there's a tool called cpulimit that does this, or you can use cgroups as others have mentioned. https://manpages.ubuntu.com/manpages/xenial/man1/cpulimit.1.html https://manpages.ubuntu.com/manpages/xenial/man1/cpulimit.1....
  - andrewmcwatters 5y ago
    Thank you for this insight!
coliveira 5y ago
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!"
fisensee 5y ago
I've found the part where the author talks about "arbitrarily overlapping windows" and "fancy icons" as "cute but not essential" pretty telling. Find me someone on the street and ask them if these things are "cute but not essential". Sometimes I feel like software engineers forget what world we live in. In the virtual world all these things are obviously not needed and wasting precious computing power on them is a disgrace to the "craftsmanship". In the real world most applications are made for flawed humans with needs and preferences which stem not from logic and reasoning but from emotions and experience. This doesn't excuse shoddy engineering in any way (everybody has some horror story of somebody not understanding runtime complexity or something, so there certainly is a lot of it). But especially with the examples the author brings up like text editors and operating systems I find these critic/plea severly lacking. Are the core features of ed and visual studio code the same? Absolutely, you edit text. Are the extra ressources used for visual studio code compared to ed a waste? For some people here probably, but I would bet quite a lot that for most the answer would be no. In the end I often find that discussions about optimatization are often more for people to show off and prove that they are a "real engineer" than any real concern about performance.
- delusional 5y ago
  Do you disagree that they aren't essential? Can you not do the computing without them? Obviously you can, although you may not want to. That's exactly the point of the article. You WANT arbitrarily overlapping windows, but that comes at a cost. You HAVE to pay that cost if you WANT the feature. In the very next chapter, the author even says as much: "Increase in complexity results in large part from our recent penchant for friendly user interaction." What makes such a realization interesting is that if you don't need the "friendly user interaction", say you're making a POS system or some embedded device, you don't need all that extra complexity. A lot of POS systems run full Windows systems. Do they NEED arbitrarily overlapping windows? If not, then why do they carry around that extra complexity?
  - tonyedgecombe 5y ago
    >What makes such a realization interesting is that if you don't need the "friendly user interaction", say you're making a POS system or some embedded device, you don't need all that extra complexity. Why would a POS system not require a friendly user interface. This attitude towards users is why corporate software stinks so much, it's based on the idea that the developers have a captive audience so have no choice in the matter, they should just accept what they are given and stop complaining.
ape4 5y ago
Sorry if this is obvious - the article is by Niklaus Wirth - author of Pascal and other important languages.
- Koshkin 5y ago
  I feel like I can guess the name of the future lean programming language that will conquer the world. (It'll be worth the wait.)
  - nine_k 5y ago
    Very many ideas of Pascal, Modula, and Oberon live on in the lean (to me, excessively lean) language named Go, which got pretty popular during last decade.
    - titzer 5y ago
      Quite literally by pedigree. Robert Griesemer was a student of Wirth.
bigdict 5y ago
Niklaus Wirth on software girth.
- deleted 5y ago
  [deleted]
kwertyoowiyop 5y ago
In the past, all programs expanded until they included a bad email feature. Now, all programs expand until they include a bad social network.
ryaan_anthony 5y ago
1995 - the year JS was first released
coding123 5y ago
Meh - it will always be complicated and get more complicated going forward. Also has anyone looked at what it takes to build a home, let alone a hospital. I don't think software is any more complicated than our society allows other processes to become complicated.
lproven 5y ago
This is such a classic paper that I felt it deserved a more readable copy. So I copied the text into Word and cleaned it up a bit. May be easier for those with visual impairments etc. Here: https://www.dropbox.com/s/kmpo4c2q9klqx1e/A%20Plea%20for%20Lean%20Software.doc?dl=0 https://www.dropbox.com/s/kmpo4c2q9klqx1e/A%20Plea%20for%20L... (MS Word format, old .DOC version. Should be readable in anything.) Feel free to reshare.

146 points by dvfjsdhgfv 5y ago

One of the key quotes: > Another important reason for software complexity lies in monolithic design, wherein all conceivable features are part of the system's design. Each customer pays for all features but actually uses very few. Ideally, only a basic system with essential facilities would be offered, a system that would lend itself to various extensions. Every customer could then select the extensions genuinely required fora given task.

sidlls 5y ago
Such a system sounds nice in theory. In practice it leads to a byzantine nightmare of configurable interfaces, support systems, and so on, with a result that is ultimately fatter and harder to maintain.
- CraigJPerry 5y ago
  I disagree with that - what i’d call a plugin architecture - leads to a very nice separation of components.
  - interactivecode 5y ago
    plugins works for things that are plugins. Most people seem to equate separation of concerns with everything should be a plugin. Otherwise you get massive issues actually working across each plugin (or package). So unless your component is actually used in multiple core products it's not a component, it's just a part of your monolith. Making it a separate component usually, just spreads your monolith across several git repo's
- Jtsummers 5y ago
  I don’t know. It sounds similar to a lot of IDEs. Produce an interface that plugins can make use of, then people can extend the system to support new languages and capabilities. Seems to work well in a lot of cases.
- mysterydip 5y ago
  That was my first reaction, but I think it can work in some cases. Take for example plugins in a paint program, or dissectors in wireshark. Both of those can have any number of user-created extensions for different packet types or editing that the general populace doesn't need. However, to your point, when wireshark changes their API every few versions, all the plugins have to change as well or you either break your dissectors or are stuck on an old version. The base program should be designed with extension maintainability in mind.
- jcelerier 5y ago
  As an user, all the software that I take actual pleasure in using and make me productive, are large plug-in based software. As a developer of a mainly plug-in based application, the iterating ability it gives is pretty incredible - nowadays for a large majority of my feature requests, I don't have to touch the original codebase at all, just create a small plug-in for the feature.
- vendiddy 5y ago
  If the interfaces are defined poorly, it can result in what you are describing. But I've seen systems do this well and the result is something far less complex. I agree with the author's view that good interfaces require iteration. So expect that several irrational will have incorrectly drawn boundaries and poorly defined interfaces. This kind of design takes time, but if you expect the system but if you expect that it will need to evolve over the years, it pays for itself.
- 7952 5y ago
  Well it depends on the level of abstraction you use. You could think of the operating system as the platform, and each piece of software as a plugin. That can work well enough. I can save a PNG in photoshop, and then open it in other programs and it just works. But the file paradigm has lost popularity and there are probably some good reasons for that.
- fouric 5y ago
  Emacs is a system that adheres to this theory, being a small C core that implements an elisp runtime, and then the rest of the built-in functionality (as well as the entire plugin ecosystem) implemented as easily-tweakable elisp on top of that - but has not turned into "a byzantine nightmare of configurable interfaces, support systems, and so on". It's quite the counterexample to this claim.
  - taeric 5y ago
    I'd argue that emacs is more monolithic in is main focus of text editing and elisp execution. It doesn't just build a plugin architecture. It literally built a platform and does most of it's work in the same way that user code can run.
necrotic_comp 5y ago
Isn't this more or less the idea behind Gentoo ? I know that when I initially started setting my system up, it was a bit of a mess trying to figure out what USE flags I needed/etc., but once it stabilized, it was great to know that I had a system that worked and there was no trace of software or libraries I didn't want or need. It definitely is a bit more legwork to do up-front, but I feel like the idea of "this is what I want, please build only to that spec" has saved me a bit of heartache as I've been using my system and while the leanness doesn't matter per se, it feels like it's helping my system be a bit more organized.

uniqueuid 5y ago

Previously (with comments): https://news.ycombinator.com/item?id=8301511 https://news.ycombinator.com/item?id=8301511 https://news.ycombinator.com/item?id=24059704 https://news.ycombinator.com/item?id=24059704 https://news.ycombinator.com/item?id=17872400 https://news.ycombinator.com/item?id=17872400

deleted 5y ago
[deleted]
dang 5y ago
Thanks! I've added one small one: A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=24059704 https://news.ycombinator.com/item?id=24059704 - Aug 2020 (137 comments) A plea for lean software (1995) [pdf] - https://news.ycombinator.com/item?id=17872400 https://news.ycombinator.com/item?id=17872400 - Aug 2018 (100 comments) A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=8537970 https://news.ycombinator.com/item?id=8537970 - Oct 2014 (3 comments) Niklaus Wirth: A Plea for Lean Software (1995) [pdf] - https://news.ycombinator.com/item?id=8301511 https://news.ycombinator.com/item?id=8301511 - Sept 2014 (12 comments)

slver 5y ago

Pleas don't work. What works is restrictions. This is why when iOS restricts apps from eating up the entire physical RAM on the device, and developers complain that this is not like on the mac/PC, they should realize Apple is extremely familiar that it's not. And it'll never be. When you let go of restrictions, applications bloat up to take the available resources while adding almost nothing in terms of functionality.

cle 5y ago
To me an interesting question is why they bloat up. Is it all mindless waste or is there a tradeoff being made here?
- legulere 5y ago
  Optimizing software costs developer time, so it’s only done when needed.
  - fredsir 5y ago
    So its about core values, it’s about principles. It’s because people focus on something else than craftsmanship and creating great things. Obviously, it’s because of how our society and culture is oriented. But I’d like to see that change.
    - legulere 5y ago
      You can put almost infinitely much effort into optimization. When do you stop? Do you test every user-interaction takes less than 100 ms below which it can be considered good?
      - deleted 5y ago
        [deleted]
      - loup-vaillant 5y ago
        I would hope so actually: someone needs to test every user interaction at least once, at which point we can notice if it's too slow.

ChrisMarshallNY 5y ago

> Another important reason for software complexity lies in monolithic design, wherein all conceivable features are part of the system's design. This is really a call for modularity. I'm a believer in modularity, but it is not a cure-all. Modularity brings a lot of baggage with it, like duplication of code and lifecycle management, along with increased resource usage (ironic, as the article is mainly about reducing resource usage). But I am still a believer in it. In my experience, it makes for a massive increase in system stability, quality, agility, and speed of development.

numbsafari 5y ago
> Modularity brings a lot of baggage with it, like duplication of code and lifecycle management If the operating system and standard libraries provide better facilities for the common parts, that can go a long way to solving these problems.
- ChrisMarshallNY 5y ago
  Exactly. But these days, everyone likes to bundle in dependencies. Also, for cross-platform SDKs and libraries, the provider may be forced to "reinvent the wheel." That may well be worth it, as developer bandwidth, and time-to-market are important variables.
  - numbsafari 5y ago
    > But these days, everyone likes to bundle in dependencies. If the OS and standard libs provide those dependencies, then I don't need to bundle them. I'm thinking of things like the Go or Python standard libraries, or OTP in Erlang. On iOS you have a rich set of built-in frameworks, etc., etc.
    - ChrisMarshallNY 5y ago
      ...and you have a huge number of folks that program for iOS in JavaScript, with dozens of dependencies in each project. This can lead to some rather...overfed...applications, and four- or five-digit bug counts.

RcouF1uZ4gsC 5y ago

A good counterpoint to this is Joel on Software’s post about “Bloatware” https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv-bloatware-and-the-8020-myth/ https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv...

jhgb 5y ago
I don't see how this vulgar reduction of the problem in question to just size of binaries has anything to do with what Wirth is talking about in that article, which are among other things the factors of maintainability, cognitive load, reusability and such.

klelatti 5y ago

> Time pressure is probably the foremost reason behind the emergence of bulky software. Indeed, but for startups now I'd add easy scaling. With the public cloud why worry about efficiency now (vs time to market) if you can easily scale up later.

deleted 5y ago

[deleted]

econner 5y ago

I feel this. I just upgraded MacOS 11 Big Sur and to XCode 12.5 (from 12.4). Both updates were 12 GB.

deleted 5y ago

[deleted]

bigbillheck 5y ago

The 'inflated' software Wirth complains about is the same as is often fondly remembered in places such as here by people talking about the Good Old Days.

Flex247A 5y ago

I mean, some software can really get rid of bloatware without losing much functionality. For example: The AMD Adrenalin driver takes about 1GB of disk space and comes bundled with a browser. The control panel takes forever to start, even on a laptop with NVME SSD. This is why I have switched to installing drivers through Windows Settings.

andrewmcwatters 5y ago

I don’t know how you would do this, other than setting core affinity, but I’m surprised I can’t limit processing power or RAM per process on any modern OS. Both for setting restrictions per another comment here, but also for testing purposes. Like, I’d love to be able to run an executable with equivalent processing power to that of a specific CPU generation.

Etheryte 5y ago
On macOS, there is a legacy CPU throttler called AppPolice [0] which as of right now still works on Catalina, despite the last release being made in 2016 (!). The user experience is very flaky, but it can help out when it's really needed. I haven't tested it on Big Sur. Definitely agree though, this is something that should be baked into the OS as a first class citizen, especially in the modern era of Electron-all-the-things. [0] https://github.com/AppPolice/AppPolice https://github.com/AppPolice/AppPolice
delusional 5y ago
On linux you could use cgroups and cfs_quota: https://www.kernel.org/doc/html/latest/scheduler/sched-bwc.html https://www.kernel.org/doc/html/latest/scheduler/sched-bwc.h...
phaemon 5y ago
Surely you can with cgroups? Isn't that exactly what they're for?
opencl 5y ago
On Linux there's a tool called cpulimit that does this, or you can use cgroups as others have mentioned. https://manpages.ubuntu.com/manpages/xenial/man1/cpulimit.1.html https://manpages.ubuntu.com/manpages/xenial/man1/cpulimit.1....
- andrewmcwatters 5y ago
  Thank you for this insight!

coliveira 5y ago

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!"

fisensee 5y ago

I've found the part where the author talks about "arbitrarily overlapping windows" and "fancy icons" as "cute but not essential" pretty telling. Find me someone on the street and ask them if these things are "cute but not essential". Sometimes I feel like software engineers forget what world we live in. In the virtual world all these things are obviously not needed and wasting precious computing power on them is a disgrace to the "craftsmanship". In the real world most applications are made for flawed humans with needs and preferences which stem not from logic and reasoning but from emotions and experience. This doesn't excuse shoddy engineering in any way (everybody has some horror story of somebody not understanding runtime complexity or something, so there certainly is a lot of it). But especially with the examples the author brings up like text editors and operating systems I find these critic/plea severly lacking. Are the core features of ed and visual studio code the same? Absolutely, you edit text. Are the extra ressources used for visual studio code compared to ed a waste? For some people here probably, but I would bet quite a lot that for most the answer would be no. In the end I often find that discussions about optimatization are often more for people to show off and prove that they are a "real engineer" than any real concern about performance.

delusional 5y ago
Do you disagree that they aren't essential? Can you not do the computing without them? Obviously you can, although you may not want to. That's exactly the point of the article. You WANT arbitrarily overlapping windows, but that comes at a cost. You HAVE to pay that cost if you WANT the feature. In the very next chapter, the author even says as much: "Increase in complexity results in large part from our recent penchant for friendly user interaction." What makes such a realization interesting is that if you don't need the "friendly user interaction", say you're making a POS system or some embedded device, you don't need all that extra complexity. A lot of POS systems run full Windows systems. Do they NEED arbitrarily overlapping windows? If not, then why do they carry around that extra complexity?
- tonyedgecombe 5y ago
  >What makes such a realization interesting is that if you don't need the "friendly user interaction", say you're making a POS system or some embedded device, you don't need all that extra complexity. Why would a POS system not require a friendly user interface. This attitude towards users is why corporate software stinks so much, it's based on the idea that the developers have a captive audience so have no choice in the matter, they should just accept what they are given and stop complaining.

ape4 5y ago

Sorry if this is obvious - the article is by Niklaus Wirth - author of Pascal and other important languages.

Koshkin 5y ago
I feel like I can guess the name of the future lean programming language that will conquer the world. (It'll be worth the wait.)
- nine_k 5y ago
  Very many ideas of Pascal, Modula, and Oberon live on in the lean (to me, excessively lean) language named Go, which got pretty popular during last decade.
  - titzer 5y ago
    Quite literally by pedigree. Robert Griesemer was a student of Wirth.

bigdict 5y ago

Niklaus Wirth on software girth.

deleted 5y ago
[deleted]

kwertyoowiyop 5y ago

In the past, all programs expanded until they included a bad email feature. Now, all programs expand until they include a bad social network.

ryaan_anthony 5y ago

1995 - the year JS was first released

coding123 5y ago

Meh - it will always be complicated and get more complicated going forward. Also has anyone looked at what it takes to build a home, let alone a hospital. I don't think software is any more complicated than our society allows other processes to become complicated.

lproven 5y ago

This is such a classic paper that I felt it deserved a more readable copy. So I copied the text into Word and cleaned it up a bit. May be easier for those with visual impairments etc. Here: https://www.dropbox.com/s/kmpo4c2q9klqx1e/A%20Plea%20for%20Lean%20Software.doc?dl=0 https://www.dropbox.com/s/kmpo4c2q9klqx1e/A%20Plea%20for%20L... (MS Word format, old .DOC version. Should be readable in anything.) Feel free to reshare.