Why Oh My Zsh is completely broken (article)



  • Terrible practices inside codebase of "Oh My Zsh", a popular theming library for the zsh shell.

    • You can find four-space indents and two-space indents mixed in the same file;
    • You can find function definitions with the function keyword and without in the same file;
    • You can find 167-character-long lines mixed with early-broken lines (yes, sometimes in the same file);
    • You can find completely commented out blocks of code in the core lib, where the average user is not supposed to touch;
    <!-- -->

    This one single function intended to be invoked from a precmd hook (basically executed every time the prompt is printed), calls grep a staggering 14 times inside command substitutions, forking the process 28 times — while all the greps can be replaced with pattern/regex matching right within the shell.



  • TRWTF is a shell that needs a "configuration framework" to be usable.


  • Winner of the 2016 Presidential Election

    I'm fine without one. Took a look at oh my zsh years ago and immediately wondered why anyone would use that piece of crapconfiguration framework. It's not that hard to configure zsh yourself.



  • Zsh is a rather complicated shell (compared to Bash)

    About 1% more complicated. But still!!!

    it doesn't look as sweet as it could be out of box

    But even without any configuration, it's still much better than Bash.

    Most mortals, me included, want an interactive shell that's sweet and "just works"

    Out of the box, Zsh Just Works™. Only if you want fancy stuff like prompt telling you if you can ff-merge your current git branch with remote without any conflicts, you need Oh My Zsh.

    Oh My Zsh brings the worst of community-driven development, where the "community" knows not of what it is doing, and just wants to get things done in the sloppiest way possible.

    Well, duh! It's shell scripts, after all! It's literally impossible to write Bourne-compatible-shell scripts that are at all maintainable without inducing heart attack every other second!


  • Discourse touched me in a no-no place

    @Gaska said:

    It's literally impossible to write Bourne-compatible-shell scripts that are at all maintainable without inducing heart attack every other second!

    A good start to testing whether the developer of some code is an idiot is to do:

    mkdir "Documents and Settings"
    cd "Documents and Settings"
    

    If that breaks something, someone somewhere needs a cluebat For Great Justice. :doing_it_wrong:



  • How about mkdir " && rm -rf --no-preserve-root . "?



  • For better effect, replace && with ; and put # before closing quote.



  • Ok, i read the article, but i still don't get it. I kept waiting for the bottom line: they have poor programming practices, and the effect of this is ... ? But the most meaningful issue was “once they took 20 days to implement significant changes in response to a new version of grep”. And the rest just a bunch of snobbery about superficial shit. I mean, style is definitely important in programming, but not to the point of form over function. And if you want to talk about the worst in community programming or whatever, how about people who identify a code base that's in need of attention and write a scathing blog post instead of pitching in?



  • @cartman82 said:

    - You can find four-space indents and two-space indents mixed in the same file;

    • You can find function definitions with the function keyword and without in the same file;
    • You can find 167-character-long lines mixed with early-broken lines (yes, sometimes in the same file);
    • You can find completely commented out blocks of code in the core lib, where the average user is not supposed to touch;

    I'm fairly sure none of those four things cause code to break. Sure, they make it easier for programmers to break the code, but they don't actually break the code themselves.



  • If they CBA to make their code look even half-decent, how can I trust them that their code works at all?



  • How can you trust anyone's code to work at all?


  • area_can

    @Gaska said:

    how can I trust them that their code works at all?

    No one's code works. At all.


  • Discourse touched me in a no-no place

    @Buddy said:

    How about mkdir " && rm -rf --no-preserve-root . "?

    That's the evolved form…



  • @immibis_ said:

    How can you trust anyone's code to work at all?

    The moment I answer this question, I'll develop logizomechanophobia, fall into depression, lose my job and probably commit suicide.



  • @Buddy said:

    And the rest just a bunch of snobbery about superficial shit.

    I wouldn't say the lack of meaningful plugin architecture, horribly inefficient code and inability to fix any of it due to maintainers being asleep at the wheel are "superficial shit".

    @Buddy said:

    And if you want to talk about the worst in community programming or whatever, how about people who identify a code base that's in need of attention and write a scathing blog post instead of pitching in?

    The difference is, shit codebases is something you are forced to deal with on the dayjob, not something you want it to be your hobby.



  • @cartman82 said:

    the lack of meaningful plugin architecture, horribly inefficient code and inability to fix any of it due to maintainers being asleep at the wheel

    I think I saw this before...



  • @cartman82 said:

    The difference is, shit codebases is something you are forced to deal with on the dayjob, not something you want it to be your hobby.

    Alternatively: I spend a lot of time working really hard at work to keep the shit out of the code base. When I'm hobby coding...


  • BINNED

    Dunno, when I'm hobby coding I usually have more time to be real nitpicky about ultimately inconsequential stuff.



  • It depends. But I like to present the contrarian point of view. And annoying gifs.


  • Winner of the 2016 Presidential Election

    @Gaska said:

    Only if you want fancy stuff like prompt telling you if you can ff-merge your current git branch with remote without any conflicts, you need Oh My Zsh.

    Nope, just write the prompt yourself. Trust me, it's not hard, I've done it before.



  • How about just pulling the changes?



  • @cartman82 said:

    You can find four-space indents and two-space indents mixed in the same file;
    You can find function definitions with the function keyword and without in the same file;
    You can find 167-character-long lines mixed with early-broken lines (yes, sometimes in the same file);
    You can find completely commented out blocks of code in the core lib, where the average user is not supposed to touch;

    So you open it up and hit Control-E, D.

    What's the big deal? If people are bitching about bad formatting, that just means they're using shitty development environments. Because for those of us with dev tools that don't suck shit, it's been a solved problem for years and years and years.

    @cartman82 said:

    This one single function intended to be invoked from a precmd hook (basically executed every time the prompt is printed), calls grep a staggering 14 times inside command substitutions, forking the process 28 times — while all the greps can be replaced with pattern/regex matching right within the shell.

    Ok that's more of a WTF.



  • I thought those were meant to be ironic? They're incredibly unimportant "issues".



  • @blakeyrat said:

    So you open it up and hit Control-E, D.

    What's the big deal? If people are bitching about bad formatting, that just means they're using shitty development environments. Because for those of us with dev tools that don't suck shit, it's been a solved problem for years and years and years.

    Except then it goes into a pile of pull requests, waiting to be accepted. And screws up all the other pull requests waiting in the queue.



  • Then I guess your development methodology sucks shit. Also your source control technology. Also your ugly face.



  • @blakeyrat said:

    So you open it up and hit Control-E, D.

    Be careful about meaningful spaces, though. This is one of the reasons why shell scripts just can't be good.



  • @cartman82 said:

    maintainers being asleep at the wheel

    It's that true? I went to the repo and I saw 42 closed issues for 4 opened in the past week. Nowhere near the number of prs there supposedly were back in march.

    @cartman82 said:

    horribly inefficient code

    Is that true? I didn't see any numbers. If performance isn't measurably bad, what would be the point of replacing grep with builtins? Showing everybody how clever you are?

    @cartman82 said:

    lack of meaningful plugin architecture

    Is that true? Because they already have over 200 plugins; adding a plugin is as simple as adding the plugin's name to an array in the rc file. Not sure how much more meaningful you can get in shell.



  • @Buddy said:

    It's that true? I went to the repo and I saw 42 closed issues for 4 opened in the past week. Nowhere near the number of prs there supposedly were back in march.

    Don't know, is it?

    @Buddy said:

    Is that true? I didn't see any numbers. If performance isn't measurably bad, what would be the point of replacing grep with builtins? Showing everybody how clever you are?

    Did you ever use a shell prompt function? Every millisecond counts.

    @Buddy said:

    Is that true? Because they already have over 200 plugins; adding a plugin is as simple as adding the plugin's name to an array in the rc file. Not sure how much more meaningful you can get in shell.

    Wait, why do I see bzr.zsh, git.zsh, and even nvm.zsh in the core lib? Why are all of these mandatory (all files in lib are sourced from oh-my-zsh.sh)? Why should I load bzr.sh and nvm.zsh when I don't use Bazaar or NVM at all?1 Moreover, since we already have bzr.sh, git.zsh and nvm.zsh in the core library, why don't we also have hg.zsh, rvm.zsh, svn.zsh and virtualenv.zsh, just to name a few?


  • BINNED

    @Buddy said:

    Is that true? I didn't see any numbers. If performance isn't measurably bad, what would be the point of replacing grep with builtins? Showing everybody how clever you are?

    I use fish so no direct experience, but co-worker confirmed terrible performance when using Oh My Zsh when I gave him that link today.



  • Then they should have led with that. Go from the problem to the cause, not the other way around.


  • Winner of the 2016 Presidential Election

    @Gaska said:

    How about just pulling the changes?

    Too easy, and sometimes impractical. I personally feel like having information about the current branch in my prompt helps me a lot. Otherwise, it's way too easy to forget about the current state of the repo. (Which branch am I in? Do I have stashes? Am I in the middle of a rebase, maybe?) At the very least, it's cool to show the prompt to your colleagues.



  • @asdf said:

    Which branch am I in?

    Git for Windows even does this (git bash mind you)


  • Winner of the 2016 Presidential Election

    @swayde said:

    Git for Windows even does this (git bash mind you)

    Most of this is possible in bash as well (except from using RPROMPT, which I personally use a lot). No idea how much harder or easier it is to reproduce the same in bash vs zsh.



  • The title struck a mental chord...

    :musical_note:
    Oh where oh where has my Zsh gone,
    Oh where oh where can it be...
    With its quality short,
    And its runtime quite long...
    Oh where oh where can it be?



  • @asdf said:

    Too easy

    Shouldn't that be a giant pro for this solution?

    @asdf said:

    and sometimes impractical.

    git pull --ff-only and you're guaranteed nothing breaks. And if you don't like the changes anyway, you can do git reset --hard HEAD^ (or lookup git reflog if you want to go back more than one commit).

    @asdf said:

    Which branch am I in?

    git status

    @asdf said:

    Do I have stashes?

    git stash list. But long-lived stashes (to the point you forget about them, ie. more than few hours) are a bad idea anyway.

    @asdf said:

    Am I in the middle of a rebase, maybe?

    git status. But if you entered rebase on purpose, and it takes so long you forgot why, You're Doing It Wrong™.


  • Winner of the 2016 Presidential Election

    @Gaska said:

    Shouldn't that be a giant pro for this solution?

    Do you understand sarkasm?

    @Gaska said:

    git pull --ff-only

    @Gaska said:

    git reset --hard HEAD^

    @Gaska said:

    git status

    @Gaska said:

    git stash list

    So many commands I never have to execute* because I see everything I need to know instantly. It's like having a git GUI on your command line.

    Do you also prefer command line + vi to IDEs? Just asking, because you seem to be arguing that convenience is not worth anything…

    *Okay, maybe I execute git reset --hard once in a while.



  • @asdf said:

    Do you understand sarkasm?

    Well, some people like to do hard things, for the sake of doing hard things.

    @asdf said:

    So many commands I never have to execute* because I see everything I need to know instantly.

    Wowzers, fifteen seconds saved everyday! The downside is, you get information creep in your terminal you cannot easily disable for a moment.

    @asdf said:

    It's like having a git GUI on your command line.

    Considering every single git GUI I've ever seen in my life sucked hard, it's not exactly a thing I want in my .zshrc.

    @asdf said:

    Do you also prefer command line + vi to IDEs?

    I despise vi. But I prefer simple notepad-like tools over full-blown IDEs if I can't make the latter work with the codebase (and at my work, I can't, so I use medit instead of Eclipse or something). Considering I can pipe grep's output to xargs to open all files, my efficiency doesn't drop much. Mind you, if Eclipse (or Netbeans, or Qt Creator, or Visual Studio, or Code::Blocks, or CodeLite) could index our codebase and not hang up every other second, I would gladly use them instead.

    @asdf said:

    Just asking, because you seem to be arguing that convenience is not worth anything…

    You forgot that convenience is very subjective. For me, the question "what branch I'm on?" is one I ask only once or twice every few days, because usually I remember, so having it always visible has minimal usefulness to me.


  • SockDev

    @asdf said:

    Which branch am I in? Do I have stashes? Am I in the middle of a rebase, maybe?

    $> curl -L https://raw.github.com/git/git/master/contrib/completion/git-prompt.sh > ~/.bash_git
    $> echo "source ~/.bash_git" >> ~/.bashrc
    $> echo PS1="'"'\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]$(__git_ps1 " (%s)") $'"'" >> ~/.bashrc
    

    substituting your PS1 line to taste of course.

    i'm sure that can be adapted to other shells, but i only know bash so......


  • Winner of the 2016 Presidential Election

    @Gaska said:

    The downside is, you get information creep in your terminal you cannot easily disable for a moment.

    It all easily fits in one line, I don't even need a multi-line prompt. (I hate those.) And thanks to RPROMPT, half of the stuff disappears when you need the space to type your command. On the left side, my prompt only shows user & host name, like the standard one. Not exactly "information creep".

    @accalia said:

    i'm sure that can be adapted to other shells, but i only know bash so......

    ZSH version:

    Autoload zgitinit, query the git status with those nice little helper functions and set PROMPT and RPROMPT depending on the result. ~20 LOC (setup + update function), does everything I ever wanted.


  • SockDev

    @asdf said:

    ZSH version:

    I knew someone would have done it for ZSH as well. :-D



  • @Gaska said:

    The downside is, you get information creep in your terminal you cannot easily disable for a moment.

    :doing_it_wrong: :question:



  • PS1="                                                         "
    
    <is invalid>

  • kills Dumbledore

    @Gaska said:

    some people like to do hard things, for the sake of doing hard things

    :giggity:


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.