4 ms·

I'd like to point out that you don't need an IDE for error reporting. Most editors these days integrate with a language server for inline errors and linting. Ev

I'd like to point out that you don't need an IDE for error reporting. Most editors these days integrate with a language server for inline errors and linting. Even features such as jump-to have existed in Vim/emacs for many years. I would add graphical debuggers to your list. You can get by with command line debuggers and there are external attachable debuggers but neither is really comparable to an IDE.

IlliOnato 5y ago
Depends on a language. Perl for example is extremely difficult for an editor to get right, especially if you use OO framework other than Moose. On the other hand, as others pointed out, where is the line between an IDE and a sufficiently customized editor using language server?
IlliOnato 5y ago
... and you are right about graphical debuggers. I left them out because I very rarely use them, unfortunately. It's my personal vice, of sort. I tried to learn to use and love them, more than once, but never learned to be more efficient with them than without, and when a deadline hits, usually drop them and never look back. I grew up as a programmer without graphical debuggers, developed a rather sophisticated way to debug with essentially "print" statements, but on steroids -- I have a library of debugging utilities which I kind of recreate for any language I am working with. I've a habit to anticipate where they may be needed, and my code is usually peppered with commented out debugging statements (of course all of them generated via code snippets), which help me to be very efficient in debugging my code. I must say that some of my collaborators over the years hated it, others loved it, adapted my system and used it in their own code. I think it would be good to un-learn this habit and learn to use debuggers efficiently, and to produce a bit more conventional code. On the other hand, life is short, and there are only so many fights you can hope to win...
- dharmab 5y ago
  It's easier than you think! I picked up command line debugging in a couple days when working with software that was extremely difficult to printf debug.

IlliOnato 5y ago

Depends on a language. Perl for example is extremely difficult for an editor to get right, especially if you use OO framework other than Moose. On the other hand, as others pointed out, where is the line between an IDE and a sufficiently customized editor using language server?

IlliOnato 5y ago

... and you are right about graphical debuggers. I left them out because I very rarely use them, unfortunately. It's my personal vice, of sort. I tried to learn to use and love them, more than once, but never learned to be more efficient with them than without, and when a deadline hits, usually drop them and never look back. I grew up as a programmer without graphical debuggers, developed a rather sophisticated way to debug with essentially "print" statements, but on steroids -- I have a library of debugging utilities which I kind of recreate for any language I am working with. I've a habit to anticipate where they may be needed, and my code is usually peppered with commented out debugging statements (of course all of them generated via code snippets), which help me to be very efficient in debugging my code. I must say that some of my collaborators over the years hated it, others loved it, adapted my system and used it in their own code. I think it would be good to un-learn this habit and learn to use debuggers efficiently, and to produce a bit more conventional code. On the other hand, life is short, and there are only so many fights you can hope to win...

dharmab 5y ago
It's easier than you think! I picked up command line debugging in a couple days when working with software that was extremely difficult to printf debug.