Ask HN: Buridan's ass paradox when choosing tools | Hacker News Reader

Ask HN: Buridan's ass paradox when choosing tools

1 pointmmiliauskas4 comments

I constantly struggle with having to choose between two different but also equally powerful tools, where it is hard to see a clear winner. Whilst working I just keep bouncing between using one of them for a while, then rewriting or doing some other project with the other. What makes matters worse is that I constantly have this debated in my head on which one to choose. This really feels like Buridan's ass paradox :D Just instead of being frozen in indecision, I keep re-doing stuff in some other language or framework barely progressing forward.

I know flipping a coin won't work here. The only two options that sound reasonable are: 1. Choose the "worst" one, since they are all clearly pretty equal anyways. This way you just trick your brain to stop "optimizing". 2. Choose the most "popular" -- use external referee to break my deadlock. Basically, I assume that this is a case of game with correlated equilibrium and I need an external tiebreaker.

Anybody else had any experience with this and found some tricks that work?

Are the tools pretty much exactly the same? If there are differences, even minor, think about them in the process.

For example, I love clisp because that's pretty much what I learned to program Common Lisp in, and it starts up so fast, making it ideal for scripting. It's also more forgiving on input/output buffering for whipping up quick hacks. But I also use sbcl because although it is almost punishing in its strictness, it has a few features that take it over the top, such as compiling to native binaries. I prefer a lot of things on the command line, so both of them have that as plus points. Basically I can hack something together in clisp, and then polish it up in sbcl to make sure it works more universally.

And then I also use LispWorks because it can create windowed UIs out of the box that work on both Linux, Mac and Windows without modification. And I love its much-nicer-than-emacs editing and debugging. I've actually been using it a lot more than clisp and sbcl for development lately because there are so many conveniences in the LispWorks GUI.

Having said that, I find sbcl's debugger warnings far more easy to work with than LispWorks. So I do tend to use sbcl for trying to work out particularly pesky bugs in non-graphical functions.

I often have 2 different ones running at the same time because I really like to play up to their strengths. But regardless, nearly all my non-graphical code works equally well on clisp, sbcl and LispWorks - effectively the same / competing tools, but in my workflow there are different purposes at hand.

So, I guess I'm questioning whether you need to omit one tool at the expense of the other, so long as your workflow allows them to play nice together.

Instead of focussing on effectiveness or market share, focus on the aesthetics of using the tool. The one you simply enjoy using more is the one you should go with. It might be something as simple as a color scheme or a type face that pushes you, ultimately.

In any case, I think that our brains naturally amplify small differences to make these choices easier, just as our visual system sharpens edges. Go with your gut.

My gut gets nostalgic, that is the problem :D

Pursue interoperation. Can you use a tool A part in a tool B system?

Reply on news.ycombinator.com