Why is an IDE for Interpreted Languages "Overkill?"

Josh Hawkins on October 28, 2018

So often I hear the words "an IDE is overkill for Python/Ruby/JavaScript, just use Vim/Emacs/Nano/IDLE." Why is that? I write interpreted langua... [Read Full]
markdown guide
 

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 way, so is Vim with a fancy setup. The problem with most IDEs is the ridiculous overhead. And I'm perfectly fine with writing C applications in Notepad, it's just that I don't really do that. ;-)

That said, if you need an IDE (why not Acme?) to understand your code, you should really consider refactoring it. Good code needs no colors.

 

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!

 

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.

 

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.

 

I totally agree with you on Vim & Emacs being IDEs.
The point is that it's an IDE you built by yourself, choosing the plugins you want, and which is well integrated with the other tools of your dev toolbox.

For me, the best IDE is tmux. But i's off topic :)

 

At the end of the day just do whatever makes you more productive. If an ide makes you code faster and with less bugs than by all means use it regardless of language. Really the biggest downside of an ide is just that you need a more powerful machine to run it which is not too big of a problem in my opinion.

I use PHPstorm at work and I feel it is very helpful particularly when you have to work on someone else's 8 year old code in a part of the code base you have never looked at before.

 

This is a fair question. I think it's because the peeps writing 'compiled' languages are used to type hints and all that mess, while those who write 'interpreted' languages are used to not getting all of that mess. I think a lot of this is tied up with having a compiler - the compiler will provide some static analysis as a part of compilation. So editors with a good relationship with the compiler will tend towards becoming IDEs. It's a bit of a guess.

Pedantic point: there are no interpreted or compiled languages - just languages with compilers and languages with interpreters. Or both.

This isn't my area of expertise, but it strikes me that there's no reason an IDE/language couldn't provide the a lot of the same information for most languages. And if the issue was one of getting type information, well - dynamic languages could easily be extended to add declarations that could be read by the analyzer.

Anyway, back to listening to IntelliJIdea make the fans whir on my Kotlin project...

 

That brings up an interesting point - is it by conditioning? Are most javascript, python devs in their first-language? Are they not yet knowing how to use build tools like compilers to their advantage, and see compiler/linter errors/warnings as the enemy still? I don't know, I feel like I'm thinking too extreme, but you bring up some really good thoughts in your first paragraph, thanks!

Pedantic point:

Sure - but we all know what I mean, right? In the "old days", that was less true, but today, it strikes me that to say a language is interpreted is to say that its reference implementation is implemented via an interpreter, as opposed to an ahead-of-time compiler. I dunno.

 

I think that might be because interpreted languages are, well, interpreted, so making meaningful assertions about their parts requires evaluation rather than static analysis. Besides the obvious syntax highlighting.

 

That's not exactly true, though. Thinking primitively for a second, IDEs can still make approximations, as do linters like Rubocop. They can't provide guarantees in all cases, but at least approximations for types, lifetimes/scopes, signatures...

Just look at PyCharm, RubyMine. Both do a stellar job of reading between the lines to tell all of this for you via static analysis.

Some languages even provide language servers to do just this without evaluating the code. Even though it's a compiled language, Go IDEs do it this way, for instance. In fact, tons of languages have language servers to do this via static analysis, if I understand correctly: langserver.org/

 
 

I use VSCode to write Ruby. I think like most advice on programming people overstate their case. IDEs are very useful tools and I use one whenever it integrates well with the language I'm using at the time.

I think the main difference is whether the language is designed for static analysis since languages amenable to static analysis tend to have better IDE support. For more dynamic languages like Ruby I usually have a REPL open and I'm trying snippets of code because Ruby is not as amenable to static analysis so the IDE is less useful.

P.S.: My VSCode is configured with vim emulation because I like to use vim in the terminal and don't like "context switching" when I jump back and forth.

 

You’re right. It’s total bullshit. Why is using an IDE for C# okay, but not Python? The only difference is whether or not you compile your code before you run it.

 

I think it depends on your use case.
I mean, for python and Javascript I use Sublime. Just because I make shorts scripts un those languages, and I don't really need a whole IDE just for this.

code of conduct - report abuse