6 ms·

The IDE Divide (2004)

38 points by hatmatrix 6y ago

DougBTX 6y ago
The dynamics change a little now that the language server protocol is becoming more popular, as it drops the cost of developing new tooling, though there's lots more work to do.
- ktpsns 6y ago
  I think this comment thinks still too much "within" the box. Sure, there is a large class of programming languages with similar idioms where mostly only the syntax is different. I think the rise of multi paradigm languages makes this even more obvious. Nowaday, an IDE will support you with OOP, module/package structures and functional programming. However, nobody has said that the world has to end there. What about, for instance, declarative languages, domain specific languages, logic programming, computational notebooks? We still have special purpose tools for that, something which you typically don't see in a standard IDE. (Of course you could argue that IDEs as modular software just integrate all this special purpose stuff) For my perspective, one best works with an IDE if one is d'accord with all the core principles of the IDE and software ecosystem it proposes. Whenever you want to do something out of the box, the IDE reduces to nothing more then a bulky text editor. That's why I think real innovation doesn't happen in IDEs.
  - throwaway_pdp09 6y ago
    I believe you misunderstand. The LSP is not about syntax. "The Language Server Protocol (LSP) is an open, JSON-RPC-based protocol for use between source code editors or integrated development environments (IDEs) and servers that provide programming language-specific features. The goal of the protocol is to allow programming language support to be implemented and distributed independently of any given editor or IDE." https://en.wikipedia.org/wiki/Language_Server_Protocol https://en.wikipedia.org/wiki/Language_Server_Protocol
    - rocqua 6y ago
      So basically "write your language support for an IDE once, have it work everywhere (that uses LSP)"?
      - marcosdumay 6y ago
        That's the idea. It's reasonably well supported now and its use is only increasing. The standard is very OOP centered. It's not much that it won't work on other paradigms, but that it's limited to what is useful for OOP, so it won't lead to a perfect IDE to them.
        throwaway_pdp09 6y ago
        May be wrong but I don't believe that's true. It provides language info for a language, there's nothing (?) that ties it to OO especially.
        IggleSniggle 6y ago
        I don’t understand this comment. The syntax provider can be written in any language, and is basically just an abstraction for IDE behavior. Given that the instructions for how the IDE should represent any given code block, user behavior, or reactiveness in the IDE are defined by the language provider, what exactly is lacking for any arbitrary language? The only thing I can think of is that a given language may not have suitable representation in the IDE, eg a data-flow visual language when most of the IDEs features are centered around text.
kencausey 6y ago
Discussed previously in 2012 with 49 comments: https://news.ycombinator.com/item?id=4728862 https://news.ycombinator.com/item?id=4728862
meredydd 6y ago
This article is dated because these days, even the people who exclusively use vim are mostly "tool mavens" - because most people are driving the Web, and the only way to make the Web bearable is to load yourself up with huge toolchains. It's the worst of both words: Even if you're using vim, you spend an awful lot of your time using (or debugging) tools like webpack, minifiers, live-reloaders, and of course the in-browser dev tools. BUT, you still don't get the benefits of an old-school IDE, because no IDE can reason about a modern web stack reliably! Take something basic like click-to-code: "where is this attribute defined?" The web is such a Turing Tarpit[0] that, if that data comes from the backend, that question is literally undecidable. Between the database and that JS object are ORMs, backend frameworks, REST requests, microservices, JS frameworks, templating engines, and possibly CSS frameworks as well. At best, you can build good IDEs within one layer of the stack (I love WebStorm, and the VSCode+code-server stuff is cool - but they break down completely at stack boundaries). [0] https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit And it's been like this for so long that new web developers don't even remember what it was like to have full autocomplete, everywhere in your project! I have a dog in this fight - I founded a startup (https://anvil.works https://anvil.works) to make web-dev tools, and we realised that to reason automatically about a web app you basically have to replace the whole stack. We went with Python - by doing Python front-end and back-end, replacing REST calls with function calls, and building a UI toolkit rather than generating HTML, it turns out you can have actual, real click-to-code, across your whole program. And full-stack autocomplete (I gave a talk about that one[1]). If the Web is going to turn us all into tool mavens, at least we should do it right! [1] https://anvil.works/blog/python-autocompleter-pycon17 https://anvil.works/blog/python-autocompleter-pycon17
- dgb23 6y ago
  I think this is the right approach. Use one language to rule them all, integrate the whole UI related stack into it, from backend to frontend, and drive the integration by well defined protocols (data/types). Python seems to be a sensible choice. Others, that are already almost there, would be JS, Rust, Clojure, and I think people do similar things in Haskell as well.
  - 6y ago
throwaway_pdp09 6y ago
This is a false dichotomy. My high-level functional programming etc etc is all there but I love emacs and (rather against my instincts) Visual Studio has some very nice features; for example not having to request a compile to get errors. This can be a huge timesaver. I therefore flip back and forwards between emacs and VS pretty freely. VS to get instant mistake-feedback and fix them, emacs to do most anything else. You can be a maven for both, but I don't think you can be a complete language expert for multiple languages. Then again, perhaps you don't have to be, just a solid grasp without knowing the dark corners is quite sufficient to get real work done. Edit: emacs has omnisharp which provides some instant feedback and some refactoring, but it's a lot better in VS.
- dgb23 6y ago
  VSCode is getting better w/o me doing anything, almost magically. I did three attempts to switch to emacs because I assume it would up my mechanics in the long term, but VSCode strikes a balance of being comfortable and powerful enough, and the community around it is very active.
  - throwaway_pdp09 6y ago
    I promise you, emacs FTW in certain things which is why I persist with it (I'm a pragmatist not a masochist). VS certainly in others. They complement, but if I could have VS's features in emacs, I wouldn't leave it.
    - IggleSniggle 6y ago
      Just FYI I assumed you were taking about Visual Studio, not VSCode (a very different product), when you said VS. Every now and then I see emacs features that I wish existed in VSCode, and often I feel like VSCode extensions are reinventing the wheel but less well and more expensively...and yet, I’ve mostly given up and just use VSCode, because what it does right is make it relatively easy for anybody to write whatever feature they might want to exist, for the most part in whatever language with a small adapter to JavaScript, and package it as an extension.
k__ 6y ago
In my opinion, the main reason for using one or the other is the language in question. For a statically typed language an IDE makes much more sense than for a dynamically typed one. When PHP got more static typing features over the years I switched to an IDE and it was awesome. When I started using JavaScript in 2011, an IDE didn't help that much.

38 points by hatmatrix 6y ago

The dynamics change a little now that the language server protocol is becoming more popular, as it drops the cost of developing new tooling, though there's lots more work to do.

ktpsns 6y ago
I think this comment thinks still too much "within" the box. Sure, there is a large class of programming languages with similar idioms where mostly only the syntax is different. I think the rise of multi paradigm languages makes this even more obvious. Nowaday, an IDE will support you with OOP, module/package structures and functional programming. However, nobody has said that the world has to end there. What about, for instance, declarative languages, domain specific languages, logic programming, computational notebooks? We still have special purpose tools for that, something which you typically don't see in a standard IDE. (Of course you could argue that IDEs as modular software just integrate all this special purpose stuff) For my perspective, one best works with an IDE if one is d'accord with all the core principles of the IDE and software ecosystem it proposes. Whenever you want to do something out of the box, the IDE reduces to nothing more then a bulky text editor. That's why I think real innovation doesn't happen in IDEs.
- throwaway_pdp09 6y ago
  I believe you misunderstand. The LSP is not about syntax. "The Language Server Protocol (LSP) is an open, JSON-RPC-based protocol for use between source code editors or integrated development environments (IDEs) and servers that provide programming language-specific features. The goal of the protocol is to allow programming language support to be implemented and distributed independently of any given editor or IDE." https://en.wikipedia.org/wiki/Language_Server_Protocol https://en.wikipedia.org/wiki/Language_Server_Protocol
  - rocqua 6y ago
    So basically "write your language support for an IDE once, have it work everywhere (that uses LSP)"?
    - marcosdumay 6y ago
      That's the idea. It's reasonably well supported now and its use is only increasing. The standard is very OOP centered. It's not much that it won't work on other paradigms, but that it's limited to what is useful for OOP, so it won't lead to a perfect IDE to them.
      - throwaway_pdp09 6y ago
        May be wrong but I don't believe that's true. It provides language info for a language, there's nothing (?) that ties it to OO especially.
      - IggleSniggle 6y ago
        I don’t understand this comment. The syntax provider can be written in any language, and is basically just an abstraction for IDE behavior. Given that the instructions for how the IDE should represent any given code block, user behavior, or reactiveness in the IDE are defined by the language provider, what exactly is lacking for any arbitrary language? The only thing I can think of is that a given language may not have suitable representation in the IDE, eg a data-flow visual language when most of the IDEs features are centered around text.

kencausey 6y ago

Discussed previously in 2012 with 49 comments: https://news.ycombinator.com/item?id=4728862 https://news.ycombinator.com/item?id=4728862

meredydd 6y ago

This article is dated because these days, even the people who exclusively use vim are mostly "tool mavens" - because most people are driving the Web, and the only way to make the Web bearable is to load yourself up with huge toolchains. It's the worst of both words: Even if you're using vim, you spend an awful lot of your time using (or debugging) tools like webpack, minifiers, live-reloaders, and of course the in-browser dev tools. BUT, you still don't get the benefits of an old-school IDE, because no IDE can reason about a modern web stack reliably! Take something basic like click-to-code: "where is this attribute defined?" The web is such a Turing Tarpit[0] that, if that data comes from the backend, that question is literally undecidable. Between the database and that JS object are ORMs, backend frameworks, REST requests, microservices, JS frameworks, templating engines, and possibly CSS frameworks as well. At best, you can build good IDEs within one layer of the stack (I love WebStorm, and the VSCode+code-server stuff is cool - but they break down completely at stack boundaries). [0] https://en.wikipedia.org/wiki/Turing_tarpit https://en.wikipedia.org/wiki/Turing_tarpit And it's been like this for so long that new web developers don't even remember what it was like to have full autocomplete, everywhere in your project! I have a dog in this fight - I founded a startup (https://anvil.works https://anvil.works) to make web-dev tools, and we realised that to reason automatically about a web app you basically have to replace the whole stack. We went with Python - by doing Python front-end and back-end, replacing REST calls with function calls, and building a UI toolkit rather than generating HTML, it turns out you can have actual, real click-to-code, across your whole program. And full-stack autocomplete (I gave a talk about that one[1]). If the Web is going to turn us all into tool mavens, at least we should do it right! [1] https://anvil.works/blog/python-autocompleter-pycon17 https://anvil.works/blog/python-autocompleter-pycon17

dgb23 6y ago
I think this is the right approach. Use one language to rule them all, integrate the whole UI related stack into it, from backend to frontend, and drive the integration by well defined protocols (data/types). Python seems to be a sensible choice. Others, that are already almost there, would be JS, Rust, Clojure, and I think people do similar things in Haskell as well.
- 6y ago

throwaway_pdp09 6y ago

This is a false dichotomy. My high-level functional programming etc etc is all there but I love emacs and (rather against my instincts) Visual Studio has some very nice features; for example not having to request a compile to get errors. This can be a huge timesaver. I therefore flip back and forwards between emacs and VS pretty freely. VS to get instant mistake-feedback and fix them, emacs to do most anything else. You can be a maven for both, but I don't think you can be a complete language expert for multiple languages. Then again, perhaps you don't have to be, just a solid grasp without knowing the dark corners is quite sufficient to get real work done. Edit: emacs has omnisharp which provides some instant feedback and some refactoring, but it's a lot better in VS.

dgb23 6y ago
VSCode is getting better w/o me doing anything, almost magically. I did three attempts to switch to emacs because I assume it would up my mechanics in the long term, but VSCode strikes a balance of being comfortable and powerful enough, and the community around it is very active.
- throwaway_pdp09 6y ago
  I promise you, emacs FTW in certain things which is why I persist with it (I'm a pragmatist not a masochist). VS certainly in others. They complement, but if I could have VS's features in emacs, I wouldn't leave it.
  - IggleSniggle 6y ago
    Just FYI I assumed you were taking about Visual Studio, not VSCode (a very different product), when you said VS. Every now and then I see emacs features that I wish existed in VSCode, and often I feel like VSCode extensions are reinventing the wheel but less well and more expensively...and yet, I’ve mostly given up and just use VSCode, because what it does right is make it relatively easy for anybody to write whatever feature they might want to exist, for the most part in whatever language with a small adapter to JavaScript, and package it as an extension.

k__ 6y ago

In my opinion, the main reason for using one or the other is the language in question. For a statically typed language an IDE makes much more sense than for a dynamically typed one. When PHP got more static typing features over the years I switched to an IDE and it was awesome. When I started using JavaScript in 2011, an IDE didn't help that much.