Hacker News new | ask | show | jobs
by zmmmmm 2605 days ago
This reminds me of the more generalised "I do not use IDEs". It's a fascinating kind of phenomenon similar to ludditism to me where programmers reject the very premise of their own existence: that computers are capable of adding value or assisting with a task. It feels to me that this is its own form of dogma, no better justified than people who lean on the IDE or the debugger to do everything.

I don't pull out the debugger very often, but knowing how and when to do that, and do it well is a significant tool in my arsenal. There are times when I can guarantee you I would have spent a massive number of hours or maybe never properly resolved certain bugs without doing it.

7 comments

This comment sounds, to me, borne of hatred and scorn more than anything else. Carefully chosen words, like “ludditism” and “dogma” do more to evoke feelings in people, and less to inform us. This comment is a true disservice to the conversation.

There’s a mental cost to every tool you learn how to use. It makes no sense to try and learn every programming tool, you’ll never get any work done. I see no reason why we should scorn people who leave “IDE” or “debugger” off their own personal list of tools that they work with. Calling it “ludditism” is name-calling, same as “dogma”.

I’ve used Visual Studio, even for extended periods of time, with its fantastic debugger. I’ve used older IDEs that weren’t as good. I’ve used various text editors and environments. What I don’t like about using a debugger is how rarely it helps more than the alternatives—so every time I need to use it, I need to learn how to use it again in whatever environment I happen to be programming in. Perhaps if you’re writing code in the same environment, the calculus is different. But no need for name calling.

Same with IDEs. Somehow, by some series of accidents, I use Emacs for about 95% of my coding. There are a couple key bindings in Emacs which I’ve set to match the default keybindings in Visual Studio or Xcode. But because I’m often programming in different environments, using Emacs instead of Visual Studio means that I can get by with learning fewer tools, and spend that effort elsewhere. No need to call it ludditism.

Eh, as a non-IDE user myself, I think you’re being a bit harsh as I don’t think that was the spirit of the author’s comment at all. In fact I found it to ring quite true and if there was any name-calling, I certainly did not feel offended. The fact is there is a certain luddite-esque aesthetic to working in a simple modal editor like Vim (or Emacs in your case) and everyone invents their own dogma to follow, to a certain extent. I happen to find that there is merit in using simple tools, and latent benefits like really getting to know a code-base in a way that predictive fuzzy autocompletion will not allow me to do. There is no global optima when it comes to people’s workflows, just individuals finding what works best for them.
Mental costs, name-calling.. also seem choosen words for your argument.

Just to show you how diverse our work and workflows can be, I've find the opposite of your experience. Using a debugger served me often better and faster than printlining, but using all three techniques help: print, log and interactive debug, as you need..

I think my problem with debuggers and IDEs is the same. You should write your code to be maintainable without using those tools. If you do that, I have no problem with using them to increase productivity. (Except when the IDE decides stop working; that does give me problems).
Yes, I agree. I think a lot of people who dislike IDEs feel that if the code is well designed then having a tool to handle complex code adds little value. On the other hand, if the code is poorly designed, no kind of tool can make up for that and indeed, an IDE just adds to the complexity of the system. So by that logic an IDE is never useful.

But as you say, I think the first premise is false. IDEs can improve productivity a lot independently of whether the code is poorly designed / maintainable etc. In fact, an IDE can help to achieve the very maintainability that is being sought.

It depends of the language and/or the stack you use.

Typed, verbose and compiled languages users tends to use an IDE by default because the amount of tooling and things to keep in mind to write executable code is higher than with dynamic, concise and interpreted languages.

People proficient with the latter categories of languages will know what is lacking in their text editor and will extend it with whatever they need (coercive linting, git integration, macros, new layout etc...) on a case to case basis. They end up with a tool that suits their strengths/weaknesses/taste, is faster than IDEs and avoid eventual problems from tools IDEs chose for you.

Chosing a text editor is not about refusing to get help from technology. It is about having a good typing experience first and around it being free to pick the tools you need.

Also, a lot of tools that both IDE and text editor users use (like git integration) do things that can be well done with good command line proficiency. So it really is about your needs

Really it is a debate similar to "Batteries-included frameworks vs multiple librairies" so there is different answers for different situations

You seem to be making assumption dynamic languages are more concise than statically typed ones. In modern statically typed languages with type inference it is no longer true. E.g. I find Scala more concise and expressive than Python.

As for IDE usage - programmers of dynamic languages keep away from IDEs, because traditionally IDEs failed to provide the same level of support as they did for static languages. E.g. autocomplete, error highlighting and refactoring were absent or at best not reliable. So if the value add over plain editors was so low, then why bother?

Having said that, I do see more and more people using IDEs with dynamic languages these days. Probably because the good ones have some limited autocomplete and error checking for dynamic languages now (e.g. PyCharm, PhpStorm).

I didn't assume that dynamic languages are more concise. I only said that each of both (with the addition of interpreted languages) usually require less tooling and less to keep in mind than their respective opposite

How much you need autocomplete and refactoring to be reliable also depends on your situation (language/framework, app structure and number of contributors).

More people use IDEs with dynamic languages because Visual Studio Code now exists so people who always prefered IDEs now have a good option

Not surprisingly someone made a debugger discussion into a dynamic vs static language issue.
I do not use any dedicated IDE, I use my system (Linux) as an IDE: vim for editing, multiple terminal windows for various tasks (compilation, debugging, running grep, find, sed). This is merely a practical choice, backed by experience in various environments.

When I was using DOS, which does not have any of these facilities, then an IDE was indeed a great choice.

That IDEs are supposed to assist doesn't mean that they are always doing a good job. They can be slow, have low to no benefit, but still enforce a certain constrain on how the user is supposed to work. And on the other side it's relativ simple to add the important integrations into an editor.

At the end it depends on whether you really need assistance.

Some people develop on laptops with only 16gb of RAM, and have other processes running that need it more.
It's a fascinating kind of phenomenon similar to ludditism to me where programmers reject the very premise of their own existence: that computers are capable of adding value or assisting with a task.

No, a computer can't assist you if you don't know what you want it to assist you with, and that is the whole premise of the main argument surrounding the anti-debugger/IDE/etc. thought, which can be summed up in one sentence: How can you tell the computer what to do, if you don't know exactly what you want it to do either?