4 ms·

A personal pet peeve is when people refer to having lots of features as "bloat." It's generally very nice to have lots of features all in one place without havi

A personal pet peeve is when people refer to having lots of features as "bloat." It's generally very nice to have lots of features all in one place without having to do things manually, or find somebody's potentially-sketchy plugin/app. My test for "bloat" – 1. Has the project grown so large that it's starting to run into real-world performance issues? (I can't imagine this could be the case with even the largest of shell configurations except on very low-end embedded devices). 2. Has the project grown so large that bugs are popping up faster than the developers can do maintenance? Is there no or only one person who can read and understand the entire codebase? (AFAIK, no and no). 3. Are there many undocumented/poorly-documented features? Are there features that are both undocumented/poorly-documented and dangerous? Are there many deprecated or outdated features that have yet to be removed? (AFAIK, no, no, no). 4. Are there many features that both duplicate and do not improve on functionality found elsewhere? (Debatable and mostly subjective).

mbell 11y ago
> Has the project grown so large that it's starting to run into real-world performance issues? oh-my-zsh is noticeably slower than prezto on multiple 'high end' machines I have with the same 'capabilities', i.e. plugins that provide the same feature set on both.
- smitherfield 11y ago
  Noticeably slower at doing what? I haven't noticed any issue, but I'm maybe a bit naive; I rarely use the shell for anything that isn't near-instantaneous and isn't just waiting for some other process to complete (e.g. curl, compilers). For more complicated stuff I usually write something in a scripting language.
  - soohyung 11y ago
    Occasionally just opening the shell can be slow with oh-my-zsh. It can be a bit annoying (especially if you need a few more plugins). However I have not really noticed as much of a slowdown lately so perhaps it has been improved - I haven't really tested it, this is just my own perception.
  - mbell 11y ago
    Opening a new shell can take ~5s with oh-my-zsh, it's <1s with prezto. Tab completion is also noticeably slower with oh-my-zsh.
    - smitherfield 11y ago
      Hm. I'll take a look at Prezto then. For me a new shell takes approx .5 seconds and tab completion is instant, but I'm on a 2014 MacBook Pro and use iTerm2 instead of the native terminal (not sure if that makes any difference). I don't recall it being any worse on the 2012 MacBook Air + iTerm2 I had previously, but maybe I just didn't know any better.
      - 0xCMP 11y ago
        No it's noticeable. There is no hesitation in the responses. I recently switched because I setup something for Emacs which needed to run a shell on start up and I noticed just how slow it was because Emacs is not Async and would hang for that shell to boot to run a simple command. On a side note, while prezto is faster, another culprit of slowness is nvm which when I disabled it made the terminal much faster to load.
        sillysaurus3 11y ago
        ... nvm has been the thing slowing down my terminal loads? Thanks.
    - Freaky 11y ago
      > Opening a new shell can take ~5s with oh-my-zsh Heh. I remember when zsh first got its fancy completion system, compinit would add so long to zsh startup on the dinky little machines of the day that people literally started adding progress bars and the like to their zshrc. I stuck with the old-style completion for a long time.
      - phaedrix 11y ago
        Have you cleared out your ~/.zsh_history recently? I periodically need to reset mine to increase init time.
jessaustin 11y ago
Has the project grown so large that bugs are popping up faster than the developers can do maintenance? https://news.ycombinator.com/item?id=11349316 https://news.ycombinator.com/item?id=11349316
zenlikethat 11y ago
What's an instance where people say a project is bloated but it doesn't meet some of these criteria?
- smitherfield 11y ago
  I don't think there's any non-trivial software that completely unambiguously passes all my tests (and a lot depends on how strictly one interprets "is more than one person able to read and understand the entire codebase" – I'd allow the proviso that the reader has access to the documentation, tests and commit history, and that inherently high-complexity software like an operating system can be broken down into its components); the question is more whether it clearly fails one.[0] Software that's prone to be subject to (arguably!) unfair charges of bloat includes old standbys that have lately been challenged by upstarts (e.g. jQuery, Apache), or that developers already dislike for reasons other than quality (e.g. Oracle, Microsoft products). --- [0] I'll demonstrate by applying my tests as I see it to everyone's favorite poster child for bloat – the C++ programming language. Has the project grown so large that it's starting to run into real-world performance issues? Compilers have, and how. The binaries they produce mostly haven't, although certain language features, particularly amongst those that didn't come from C, compare unfavorably to their equivalents in "slower" languages. And the language has become complex enough as to be pretty slow on the meta level of writing or learning it. I'll say ambiguous, leaning fail. Has the project grown so large that bugs are popping up faster than the developers can do maintenance? Well, the invalid pointer access meta-bug has been around for (CURRENT_YEAR - 1972) years... Personal view is it doesn't matter if the reason for failing this test is because the maintainers place artificial restrictions on their ability to fix stuff, so I'd say fail on this one, although others might disagree. Is there no or only one person who can read and understand the entire codebase? Hard to define in this case. Is it the standard? The most popular compiler? Every popular compiler? I'll say ambiguous, leaning pass. But few programming languages would pass this completely unambiguously. Are there many undocumented/poorly-documented features? "undefined behavior" FAIL Are there features that are both undocumented/poorly-documented and dangerous? "undefined behavior" FAIL Are there many deprecated or outdated features that have yet to be removed? FFFFF AAAAA I L !! F A A I L !! FFFF AAAAA I L !! F A A I L F A A I LLLL !! Are there many features that both duplicate and do not improve on functionality found elsewhere? [Dig trenches, commence C vs. C++ flamewar] --- In conclusion, yes, C++ is bloated.

mbell 11y ago

> Has the project grown so large that it's starting to run into real-world performance issues? oh-my-zsh is noticeably slower than prezto on multiple 'high end' machines I have with the same 'capabilities', i.e. plugins that provide the same feature set on both.

smitherfield 11y ago
Noticeably slower at doing what? I haven't noticed any issue, but I'm maybe a bit naive; I rarely use the shell for anything that isn't near-instantaneous and isn't just waiting for some other process to complete (e.g. curl, compilers). For more complicated stuff I usually write something in a scripting language.
- soohyung 11y ago
  Occasionally just opening the shell can be slow with oh-my-zsh. It can be a bit annoying (especially if you need a few more plugins). However I have not really noticed as much of a slowdown lately so perhaps it has been improved - I haven't really tested it, this is just my own perception.
- mbell 11y ago
  Opening a new shell can take ~5s with oh-my-zsh, it's <1s with prezto. Tab completion is also noticeably slower with oh-my-zsh.
  - smitherfield 11y ago
    Hm. I'll take a look at Prezto then. For me a new shell takes approx .5 seconds and tab completion is instant, but I'm on a 2014 MacBook Pro and use iTerm2 instead of the native terminal (not sure if that makes any difference). I don't recall it being any worse on the 2012 MacBook Air + iTerm2 I had previously, but maybe I just didn't know any better.
    - 0xCMP 11y ago
      No it's noticeable. There is no hesitation in the responses. I recently switched because I setup something for Emacs which needed to run a shell on start up and I noticed just how slow it was because Emacs is not Async and would hang for that shell to boot to run a simple command. On a side note, while prezto is faster, another culprit of slowness is nvm which when I disabled it made the terminal much faster to load.
      - sillysaurus3 11y ago
        ... nvm has been the thing slowing down my terminal loads? Thanks.
  - Freaky 11y ago
    > Opening a new shell can take ~5s with oh-my-zsh Heh. I remember when zsh first got its fancy completion system, compinit would add so long to zsh startup on the dinky little machines of the day that people literally started adding progress bars and the like to their zshrc. I stuck with the old-style completion for a long time.
    - phaedrix 11y ago
      Have you cleared out your ~/.zsh_history recently? I periodically need to reset mine to increase init time.

jessaustin 11y ago

Has the project grown so large that bugs are popping up faster than the developers can do maintenance? https://news.ycombinator.com/item?id=11349316 https://news.ycombinator.com/item?id=11349316

zenlikethat 11y ago

What's an instance where people say a project is bloated but it doesn't meet some of these criteria?

smitherfield 11y ago
I don't think there's any non-trivial software that completely unambiguously passes all my tests (and a lot depends on how strictly one interprets "is more than one person able to read and understand the entire codebase" – I'd allow the proviso that the reader has access to the documentation, tests and commit history, and that inherently high-complexity software like an operating system can be broken down into its components); the question is more whether it clearly fails one.[0] Software that's prone to be subject to (arguably!) unfair charges of bloat includes old standbys that have lately been challenged by upstarts (e.g. jQuery, Apache), or that developers already dislike for reasons other than quality (e.g. Oracle, Microsoft products). --- [0] I'll demonstrate by applying my tests as I see it to everyone's favorite poster child for bloat – the C++ programming language. Has the project grown so large that it's starting to run into real-world performance issues? Compilers have, and how. The binaries they produce mostly haven't, although certain language features, particularly amongst those that didn't come from C, compare unfavorably to their equivalents in "slower" languages. And the language has become complex enough as to be pretty slow on the meta level of writing or learning it. I'll say ambiguous, leaning fail. Has the project grown so large that bugs are popping up faster than the developers can do maintenance? Well, the invalid pointer access meta-bug has been around for (CURRENT_YEAR - 1972) years... Personal view is it doesn't matter if the reason for failing this test is because the maintainers place artificial restrictions on their ability to fix stuff, so I'd say fail on this one, although others might disagree. Is there no or only one person who can read and understand the entire codebase? Hard to define in this case. Is it the standard? The most popular compiler? Every popular compiler? I'll say ambiguous, leaning pass. But few programming languages would pass this completely unambiguously. Are there many undocumented/poorly-documented features? "undefined behavior" FAIL Are there features that are both undocumented/poorly-documented and dangerous? "undefined behavior" FAIL Are there many deprecated or outdated features that have yet to be removed? FFFFF AAAAA I L !! F A A I L !! FFFF AAAAA I L !! F A A I L F A A I LLLL !! Are there many features that both duplicate and do not improve on functionality found elsewhere? [Dig trenches, commence C vs. C++ flamewar] --- In conclusion, yes, C++ is bloated.