Re:What I would do differently if I was learning to program ...
by emodendroket on Monday July 09, 2018 @01:17PM
(#17491795)
The on-the-fly error and smell checking Emacs does is better than nothing but it's on a different level than a good IDE.
Re:What I would do differently if I was learning to program ...
by marcosdumay on Monday July 09, 2018 @06:34PM
(#17493955)
Hum...
It marks the failures found by the CLI compilers and linters, exactly like any "good IDE" out there. What IDE are you referring to?
Re:What I would do differently if I was learning to program ...
by emodendroket on Monday July 09, 2018 @07:07PM
(#17494143)
I'm mostly an IntelliJ (and variants: RubyMine, Webstorm, Rider, PhpStorm, etc.) user, although I also use Visual Studio. In my experience, Emacs plugins for many languages often have a feel of working more on looking for matching words in the code rather than "understanding" what the code is doing, let alone suggesting good refactors.
Re:What I would do differently if I was learning to program ...
by marcosdumay on Monday July 09, 2018 @09:24PM
(#17494751)
IntelliJ's linters are indeed unusually rich on the deepness and complexity of their rules. But not on the universality, the reason that I consider them unusable, since I just don't like to turn rules off.
Anyway, that's a feature of their linters. It just happens to be packaged with their IDE, but it's a completely different tool.
Re:What I would do differently if I was learning to program ...
by emodendroket on Monday July 09, 2018 @10:53PM
(#17495079)
In practice the great linters and refactoring tools are kind of a package and it's nice to have them integrated (there's the "I") into your development environment. I find the IntelliJ emulation of Emacs key bindings good enough for me.
1 - Autocomplete and automatic code, those are the main benefit. Turns out that if your computer can write code for you there is something wrong with either your language or your code. Code generation is a bad replacement for code abstraction.
2 - On the fly error checking. Turns out that vi and emacs do that too.
3 - Coherent access to compiling and debugging tools. As long as you want to use the IDE tools and nothing better, at the price of loss of productivity every time you must reconfigure it, or share an environment with anybody.
4 - In place documentation. Again, vi and emacs do that just fine too.
If you are using a language that requires an IDE (that's a big language flaw, but most people don't get to choose), and wants to use a very standard and non-extensible toolset, go ahead and get that IDE. But the people disagreeing with you, it's not they that don't know something.