Hacker News Reader

Comment by pavlovskyi | Hacker News Reader

I was always intrigued by how other people paying attention to posibilities that each IDE gives you. For me it was always a simple vim, which I can use on any machine with simple predefined .vimrc file (can be done mainly from scratch with a few seconds). Sometimes, where I am talking to other people about some tech likes, they alwas make a big eyes where I am talking that i use vim, nano, emacs etc. I think that comfort and convenience are playing a very important role, sometimes too important imo.

View on HN

I think you underestimate how much modern IDEs, especially in languages like Java, C#, Kotlin can help the programmer.

Check these https://www.jetbrains.com/help/idea/extract-superclass.html and https://www.jetbrains.com/help/idea/extract-into-class-refac... for some examples of what modern IDEs can do. Note it can extract bits of code into separate class, taking into account many things such as private/public methods and variables.

Similarly, if I change the name of a class or a variable, it will change the name of the class in all files that use it. And it renames the uses of this actual class, not all identifiers that have the same name, so it's much better than just using sed.

I agree, I am far away from criticize how modern IDEs works and looks like. My point is that this extensions are jump on at the startup without stricly specyfing new user needs. Extension linked by you are really cool, all best!

> Note it can extract bits of code into separate class, taking into account many things such as private/public methods and variables.

This is nice but all of these refactoring tools require a statically compiled language because only then the IDE is able to perform the kind of static analysis that is necessary to make these features work.

My colleagues and I are working on a web application using a diverse set of Perl, SQL, lots of JavaScript and React.js — that’s why for all those dynamic languages my colleagues fancy IDEs (VScode is quite fashionable these days) do not provide them with much of an advantage over emacs. On the contrary, VSCode uses quite a lot of memory and CPU to essentially just edit plain text files. It’s always funny when they complain loudly about MS Teams being a CPU hogging Electron monster but then talk delightedly about their shiny editor.

I was able to use my rather limited Emacs setup quite productively for all the environments mentioned. Usually, it required only some minutes to google around to find the right major mode extensions to support a new syntax and then a flymake minor mode extension for convenient on-the-fly linting. I would download extension directly in emacs using Melpa and then customize them using Emacs‘ built-in customization GUI. I only rarely need to edit .emacs directly. So that’s why I am stuck with Emacs.

> This is nice but all of these refactoring tools require a statically compiled language because only then the IDE is able to perform the kind of static analysis that is necessary to make these features work.

Not at all. This analysis is possible on any kind of language, although much easier on static languages.

For example, IntelliJ also supports refactoring on JavaScript. It's not as powerful as on Java (it's had a fraction of the effort put into it), but it's still really useful.

> Not at all. This analysis is possible on any kind of language, although much easier on static languages.

I don't think so. Hovering over an untyped variable like "var foo = bar;" might show you a list of possible methods available on the object "bar" but only if the context of this line contains a constructor call like "bar = new Baz()" making it possible to apply a heuristic guess by the IDE. If it is passed as an argument to a function with untyped signature, on the other hand, there is no way an IDE can reliably autocomplete possible actions on this piece of code because the variable is bound to an object only at runtime.

This is what I meant with IDEs' refactoring tools would require static analysis. The "Language Server Protocol" might make it much easier to support different languages in an editor but it does not avoid the problem of being able to know what object a variable is bound to.

AFAIK even modern, popular statically typed languages like Golang support "interfaces" revealing the true identity of a variable only at runtime.

EDIT:

Just to make myself clearer: "Automatic refactoring" meaning renaming a method in a class and making the IDE to walk over the entire code base and to rename every invocation accordingly, can only work reliably if the IDE knows a variable will always be bound to a value of a certain type or class at compile time. This is impossible for dynamically typed languages, at least in general, for the reason I tried to explain above.

That's why I believe fans of IDEs and automatic refactoring tools are almost exclusively users of languages like Java or C#. They are also the ones who love static typing. Developers working in dynamic languages usually prefer basic editors and avoid IDEs and never quite get why the other groups have so much love for static typing.

Spend a day using a Smalltalk derivative like Pharo, or surviving Common Lisp commercial offerings from Lisp Works and Allegro.

Not really, most of the refactoring tools were born on Smalltalk and Interlisp-D, copied into XDE and Mesa/Cedar and then kid of grew into other industry endeavours.

> I think that comfort and convenience are playing a very important role

Absolutely. Learning new tools is cumbersome, and programs like Vim and Emacs are not just different but also completely unfamiliar for newcomers. Everything you know from the usual text editors is at least partially useless and when you can't even press Ctrl-S to save the file it seems hard to justify learning the basics from scratch.

It's easier to just install VS Code and click on a couple plugins. And I mean it's hard to see the benefits beforehand. Some people I met thought Vim is just some ancient editor with the featureset of Notepad and needlessly complicated controls. That those controls could be really intuitive doesn't come to mind.

Reply on news.ycombinator.com