Skip to Content

Hate Your Tools

Posted on

If you want to evangelize a tool or process or technology, you should be able to answer two questions:

  1. What negative thing do you have to deal with?
  2. What positive thing do you have to give up?

These have to be serious, decision-changing problems, not humblebrags like “the community is small” or “it has this microscropic rough edge its alternative doesn’t.” Otherwise you haven’t used the thing enough to get mad at it nor have researched the alternatives for something better. You’re only an authority on something when you’re painfully aware of its shortcomings.

Here are some of mine. I love everything I’m about to talk about, but still have reasons to unrecommend them to people.

Vim

  • Lose: IDE functionality. I know the whole “It’s a text editor, not an IDE” argument, but there isn’t an easy way to replicate the missing functionality, even with other unix tools. For example, you can sorta hack in Replace-In-Project with :grep and :cdo, but you lose all of the context-aware information that makes those things safe in IDEs.
  • Gain: Scripting. Vim can be extended with scripted written in VimL, and VimL is terrible. Writing simple plugins is hard. Writing complex ones is damn near impossible. If you don’t believe me, look up any syntax indentation file. It’s gonna be several hundred lines of regex parsing.

TLA+

  • Lose: TLA+ is slow. Not like “Java is slower than C” slow. TLA+’s slowness is measured in orders of magnitude.
  • Gain: It’s infuriatingly inconsistent. Should the call be F[x] or F(x) or F x? Depends! -> and |-> do radically different things but are used in the exact same places. Whitespacing is sometimes significant. {} is both a set definition and a scope definition.

Python

  • Lose: I miss blocks whenever I’m writing python. I also miss optional types.
  • Gain: I’m firmly in the “syntatically significant whitespace is bad” camp. Sure, it makes the code look a lot nicer, but it also makes it really annoying to refactor. Example:
if False:
print("spam")
if True:
print("spam")

When I reindent, am I supposed to put the second conditional in the scope of the first conditional or outside it? Contrived example, I know, but similar things can happen when you move around code or run an indent script at the wrong time. Usually you can quickly work it out. It’s still frustrating.

I’ll probably throw up more if I think of them. Assume that if a tool isn’t here and I rant about it, my arguments are wrong and nonsensical. If a tool is here the arguments might still be wrong and nonsensical.