3 ms·

The two things IDEs do well are debugging and code refactoring. To help implement these types of features the IDE embeds a version of the language inside of it

by jussij 14y ago

The two things IDEs do well are debugging and code refactoring. To help implement these types of features the IDE embeds a version of the language inside of itself. The problem with this is you then need a new IDE for each new language. Because a good programmer's editor will try to be language neutral it does not have that luxury. But as a bonus, because the editor is not carrying around all that extra language baggage the editor will always be faster than the IDE.

coldtea 14y ago
>The problem with this is you then need a new IDE for each new language. Well, it would be nice if we had some "IDE framework" to take care of all the barebones stuff (editor pane, basic UI, loading files, encoding, high level abstract support for highlighting, refactoring, embedding a terminal, etc) and people could hook it into their language to make an IDE for it. And it would have to be written in C, to not usable from all languages with a C ABI/FFI, and not be dog slow like Eclipse.
- gphil 14y ago
  Isn't this Emacs? I love Emacs but it's not exactly an IDE out of the box--and it took me a while to figure out that it's pretty much a DIY IDE. The (relatively) recent addition of a built-in package manager goes a long way in making it easier to set up IDE-like functionality though.
  - coldtea 14y ago
    Not really, because Emacs is not hooked up to other languages, the extension part mostly come in elisp. I was describing a "toolkit" like approach, not an extensible base. Think of it as a "set of libraries" vs a "framework". Emacs makes what I describe difficult. You cannot change the editor. You cannot add a different GUI on top. You have to do most of the extension work in elisp, etc. I would prefer a set of libs a Ruby guy can hook up with Ruby and extend, a Python guy with Python, etc. Not a one-size-plus-extensions-fits-all.
- dsego 14y ago
  How about protocols? E.g. there is a server for Javascript auto-complete running in the background. The editor has a plugin for the protocol and just sends a request for a list of completion options.
  - jussij 14y ago
    The gocode autocomplete uses this approach and it works very well.

by jussij 14y ago

coldtea 14y ago

>The problem with this is you then need a new IDE for each new language. Well, it would be nice if we had some "IDE framework" to take care of all the barebones stuff (editor pane, basic UI, loading files, encoding, high level abstract support for highlighting, refactoring, embedding a terminal, etc) and people could hook it into their language to make an IDE for it. And it would have to be written in C, to not usable from all languages with a C ABI/FFI, and not be dog slow like Eclipse.

gphil 14y ago
Isn't this Emacs? I love Emacs but it's not exactly an IDE out of the box--and it took me a while to figure out that it's pretty much a DIY IDE. The (relatively) recent addition of a built-in package manager goes a long way in making it easier to set up IDE-like functionality though.
- coldtea 14y ago
  Not really, because Emacs is not hooked up to other languages, the extension part mostly come in elisp. I was describing a "toolkit" like approach, not an extensible base. Think of it as a "set of libraries" vs a "framework". Emacs makes what I describe difficult. You cannot change the editor. You cannot add a different GUI on top. You have to do most of the extension work in elisp, etc. I would prefer a set of libs a Ruby guy can hook up with Ruby and extend, a Python guy with Python, etc. Not a one-size-plus-extensions-fits-all.
dsego 14y ago
How about protocols? E.g. there is a server for Javascript auto-complete running in the background. The editor has a plugin for the protocol and just sends a request for a list of completion options.
- jussij 14y ago
  The gocode autocomplete uses this approach and it works very well.