3 ms·

Everything you write I see the other way around. I've been using IDEs for nearly 30 years, from QBasic in DOS, Turbo Pascal, Visual Basic, Delphi, Visual Studi

Everything you write I see the other way around. I've been using IDEs for nearly 30 years, from QBasic in DOS, Turbo Pascal, Visual Basic, Delphi, Visual Studio, Eclipse, RubyMine, IntelliJ... and every time my career shifts a bit, I ended up learning a new IDE with new keystrokes and new idioms. Changing IDE every 3 to 5 years gets old after a while. You learn not to learn too much of the IDE, because a lot of stuff beyond the basics of text editing won't come with you to the next IDE. Emacs changes that. You can stay with Emacs for a whole career, because it's so malleable and extensible it can adapt to new trends, languages, etc. When you say "stuck in the past", I say "stuff I did 20 years ago still works". You say fresh blood and concepts are spreading their influence: I don't see that as new, that's always been the case. YMMV. I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs. [1] IntelliJ is far inferior to Eclipse for incremental compiles and running tests, but Eclipse has a horrific UI, weird modal system, and a parallel project management universe in workspaces. Neither have editors as good as Emacs.

brlewis 7y ago
> YMMV. I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs. If you tried and rejected lsp-java I'd be interested in your experience. I've been eyeing it as a way to get rid of my last non-emacs editing.
- barrkel 7y ago
  I've tried it. It mostly works and completion is alright, though a bit clunky visually and interactively. I haven't tried to tune the UI much - it would need a bunch of tuning to be good enough for me - but I haven't because it's brittle in the face of switching branches out from underneath it. It gets its project structure confused, and the workspace dir needs blowing away. Dismissing the "server crashed" notification every time I opened up a Java file to make a tweak on an git commit (using magit) made me disable it for a while. I still have hope. It's definitely improved from where things used to be, with eclim (Eclipse Vim plugin thing).
- bennofs 7y ago
  Tried lsp-java with a gradle-based project, and couldn't get it to properly figure out the project model (so imports wouldn't be found and nothing worked). Tried with both Emacs and VS Code, no luck.
- fiddlerwoaroof 7y ago
  I’ve been using lsp-java recently instead of IntelliJ (I’ve not used IntelliJ for so long now that my license expired). Ive found that you turning off lsp-sideline-mode makes the UI significantly better but, otherwise, I’ve had a fairly good experience using it in a large maven project.
- Arcsech 7y ago
  I tried the LSP-based Java extension for VSCode on a large project (~2M lines, large Gradle build) and it was unusably slow. More than 30s for a "Go To Definition" command with my CPU pegged the whole time. Caveats: It's possible the VSCode implementation was bad, but I think it was the LSP, and this was a few months ago, so things might be better now, but it would need to have orders of magnitude of improvement in performance to be tolerable. IntelliJ handles this project pretty much without breaking a sweat.
mapgrep 7y ago
Yes -- at first I saw emacs' age as an annoyance, now I find it to be its greatest strength. Yes, elisp could be more "modern," even by lisp standards. Yes, twiddling a bunch of global vars and then calling global functions is not an ideal way to program to an API (this is at least sometimes the case in emacs). But the payoff for accepting these shortcomings is you get to draw on literally decades of development and a large pool of knowledgeable ongoing contributors. I've seen calls to have emacs support Rust, JavaScript, python, etc. But the X in "emacs should support X" seems to change almost yearly. Learning to accept elisp means learning to respect all the work that went before, all the code that just silently runs and works every day. Which in turn means your own contributions are much more likely to be doing some good for years and years.
slightwinder 7y ago
> Emacs changes that. You can stay with Emacs for a whole career, because it's so malleable and extensible it can adapt to new trends, languages, etc. If you are at the point where you use emacs for everythings, then it doesn't matter anymore how alien emacs is. But until then it's a long path, and not many are willing to walk it. But even then you must accept some sacrifies and ignore that what emacs can't do. If you are with it for so long, you likely don't know and miss all the fancy new stuff, and at this point you don't need it anymore. But new user are differnt there. > You say fresh blood and concepts are spreading their influence: I don't see that as new, that's always been the case. I would not say always, there were times when development of emacs was much much more worse then today. I jsut think those darkest times are completly gone and what in the past were single drops of blood is now a steady river for the next decacde.
- barrkel 7y ago
  Every IDE is alien when you come into it. It took me ages to get used to Eclipse, and even then I greatly enjoyed jumping ship to IntelliJ. Visual Studio deeply irritated me with its different key bindings and editor behaviour to Borland IDEs, I ended up writing a bunch of VBA macros to take care of some of the more subtle differences, until VS stopped integrating VBA!
  - slightwinder 7y ago
    > Every IDE is alien when you come into it. I don't think so. Most modern Apps follow established lingua and concepts on the fundamental and often middle levels. But Emacs is not even doing that. Simply because it was made long before this lingua and concepts were established. Vim is similar in that regard, though not much as worse as emacs, if we ignore the conceptional difference. Any complex application has it's quirks and special parts. But with emacs you have on top that even the basic parts are special and full of quirks. So instead of needing to adapts to 10% or 50% new ground, it's more like 80% or 100%, and for many this can be too much.
    - ska 7y ago
      Most modern Apps follow established lingua and concepts on the fundamental and often middle levels. You can repeat that statement in 2020, 2010, 2000, 1990 ... the only problem is that outside of a very small subset what is "established" has changed. And likely will again.
NoGravitas 7y ago
> I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs. I'm in a similar boat to you, in a different language environment. With OmniSharp, I'm able to do 80% of my C# development in emacs, and could probably do more if we were on .NET Core rather than .NET Framework. But I still have to go into Visual Studio for managing project files, and occasionally for debugging. While working remotely, I intensely wish I could just SSH into my Windows workstation and do my work in Emacs rather than having to use the kludgy remote desktop software we use.

brlewis 7y ago

> YMMV. I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs. If you tried and rejected lsp-java I'd be interested in your experience. I've been eyeing it as a way to get rid of my last non-emacs editing.

barrkel 7y ago
I've tried it. It mostly works and completion is alright, though a bit clunky visually and interactively. I haven't tried to tune the UI much - it would need a bunch of tuning to be good enough for me - but I haven't because it's brittle in the face of switching branches out from underneath it. It gets its project structure confused, and the workspace dir needs blowing away. Dismissing the "server crashed" notification every time I opened up a Java file to make a tweak on an git commit (using magit) made me disable it for a while. I still have hope. It's definitely improved from where things used to be, with eclim (Eclipse Vim plugin thing).
bennofs 7y ago
Tried lsp-java with a gradle-based project, and couldn't get it to properly figure out the project model (so imports wouldn't be found and nothing worked). Tried with both Emacs and VS Code, no luck.
fiddlerwoaroof 7y ago
I’ve been using lsp-java recently instead of IntelliJ (I’ve not used IntelliJ for so long now that my license expired). Ive found that you turning off lsp-sideline-mode makes the UI significantly better but, otherwise, I’ve had a fairly good experience using it in a large maven project.
Arcsech 7y ago
I tried the LSP-based Java extension for VSCode on a large project (~2M lines, large Gradle build) and it was unusably slow. More than 30s for a "Go To Definition" command with my CPU pegged the whole time. Caveats: It's possible the VSCode implementation was bad, but I think it was the LSP, and this was a few months ago, so things might be better now, but it would need to have orders of magnitude of improvement in performance to be tolerable. IntelliJ handles this project pretty much without breaking a sweat.

mapgrep 7y ago

Yes -- at first I saw emacs' age as an annoyance, now I find it to be its greatest strength. Yes, elisp could be more "modern," even by lisp standards. Yes, twiddling a bunch of global vars and then calling global functions is not an ideal way to program to an API (this is at least sometimes the case in emacs). But the payoff for accepting these shortcomings is you get to draw on literally decades of development and a large pool of knowledgeable ongoing contributors. I've seen calls to have emacs support Rust, JavaScript, python, etc. But the X in "emacs should support X" seems to change almost yearly. Learning to accept elisp means learning to respect all the work that went before, all the code that just silently runs and works every day. Which in turn means your own contributions are much more likely to be doing some good for years and years.

slightwinder 7y ago

> Emacs changes that. You can stay with Emacs for a whole career, because it's so malleable and extensible it can adapt to new trends, languages, etc. If you are at the point where you use emacs for everythings, then it doesn't matter anymore how alien emacs is. But until then it's a long path, and not many are willing to walk it. But even then you must accept some sacrifies and ignore that what emacs can't do. If you are with it for so long, you likely don't know and miss all the fancy new stuff, and at this point you don't need it anymore. But new user are differnt there. > You say fresh blood and concepts are spreading their influence: I don't see that as new, that's always been the case. I would not say always, there were times when development of emacs was much much more worse then today. I jsut think those darkest times are completly gone and what in the past were single drops of blood is now a steady river for the next decacde.

barrkel 7y ago
Every IDE is alien when you come into it. It took me ages to get used to Eclipse, and even then I greatly enjoyed jumping ship to IntelliJ. Visual Studio deeply irritated me with its different key bindings and editor behaviour to Borland IDEs, I ended up writing a bunch of VBA macros to take care of some of the more subtle differences, until VS stopped integrating VBA!
- slightwinder 7y ago
  > Every IDE is alien when you come into it. I don't think so. Most modern Apps follow established lingua and concepts on the fundamental and often middle levels. But Emacs is not even doing that. Simply because it was made long before this lingua and concepts were established. Vim is similar in that regard, though not much as worse as emacs, if we ignore the conceptional difference. Any complex application has it's quirks and special parts. But with emacs you have on top that even the basic parts are special and full of quirks. So instead of needing to adapts to 10% or 50% new ground, it's more like 80% or 100%, and for many this can be too much.
  - ska 7y ago
    Most modern Apps follow established lingua and concepts on the fundamental and often middle levels. You can repeat that statement in 2020, 2010, 2000, 1990 ... the only problem is that outside of a very small subset what is "established" has changed. And likely will again.

NoGravitas 7y ago

> I use IntelliJ for editing Java these days, but it's the only IDE I tolerate [1], and I still switch to Emacs for complex text editing. I live in gentle hope that growing language server support will reduce the need to tolerate IDEs. I'm in a similar boat to you, in a different language environment. With OmniSharp, I'm able to do 80% of my C# development in emacs, and could probably do more if we were on .NET Core rather than .NET Framework. But I still have to go into Visual Studio for managing project files, and occasionally for debugging. While working remotely, I intensely wish I could just SSH into my Windows workstation and do my work in Emacs rather than having to use the kludgy remote desktop software we use.