Why Oh My Zsh is completely broken (article)
-
http://zmwangx.github.io/blog/2015-05-03-why-oh-my-zsh-is-completely-broken.html
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.
-
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!
-
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.
-
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?
-
- 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?
-
-
-
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.
-
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".
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.
-
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...
-
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...
-
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.
-
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?
-
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.
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".
-
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.
-
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.
-
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.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?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.
-
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?
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.
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?
-
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.
-
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.
-
-
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...
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?
-
Too easy
Shouldn't that be a giant pro for this solution?and sometimes impractical.
git pull --ff-only
and you're guaranteed nothing breaks. And if you don't like the changes anyway, you can dogit reset --hard HEAD^
(or lookupgit reflog
if you want to go back more than one commit).Which branch am I in?
git status
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.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™.
-
Shouldn't that be a giant pro for this solution?
Do you understand sarkasm?
git pull --ff-only
git reset --hard HEAD^
git status
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.
-
Do you understand sarkasm?
Well, some people like to do hard things, for the sake of doing hard things.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.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.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.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.
-
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......
-
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".
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.
-
-
The downside is, you get information creep in your terminal you cannot easily disable for a moment.
-
<is invalid>PS1=" "
-