loading...

re: Why is an IDE for Interpreted Languages "Overkill?" VIEW POST

TOP OF THREAD FULL DISCUSSION
re: So often I hear the words "an IDE is overkill for Python/Ruby/JavaScript, just use Vim/Emacs/Nano/IDLE." Emacs and IDLE are, arguably, IDEs in a ...
 

Totally agree, the "fancy vim" setup I was referring to is when someone installs vim plugins or configures cscope to get back what they're missing from an IDE to bridge the gap between text editor and IDE, though maybe still lacking a debugger.

Overhead though, sure. I could see that, but I still don't see why that overhead is more deserved when running compiled languages.

Good code needs no colors.

Not to derail this (acme seems like a bold take at what you do best!), but I disagree. Syntax highlighting isn't to look pretty (though it can), but to point out typos and syntax errors before I sit down and run rake test or gcc. Fact is, we type the wrong thing or misunderstand computers once in a while, so syntax hints about it are handy for me, personally. So I like IDEs (or vim plugins if you prefer) for this!

 

Fun fact! There is literally psychology research on whether syntax highlighting improves code comprehension. ppig.org/sites/default/files/2015-...

Most studies find a weak but real effect. In other words, syntax highlighting doesn't help much, but it does help. The effect tends to get lessened the more experienced a programmer is. That said, as a pretty experienced programmer: I will take all the help I can get.

That’s interesting, thanks! I would have thought a little more than a “weak” help as it helps you quickly recognize code blocks and find definitions and weed out comments without having to read the code and comprehend it.

Come to think of it, an eye-tracking study would be really neat to see on this...

 

I still don't see why that overhead is more deserved when running compiled languages.

Overhead should always be kept low.

 

So I like IDEs (or vim plugins if you prefer) for this

Indeed. Computers are inherently much better suited for this kind of thing. It's the same reason why we have statically typed languages (or in fact any language above byte code), unit tests, CI workflows, and at the end of the day computers themselves: human fallibility is best resolved by taking the human out of the equation, with the added benefit that said human can put their focus and energy to better use.

code of conduct - report abuse