Comment by agumonkey
2 years ago
There's a strange dance of IDEs coming and going, with their idiosyncracies and partial plugins.. you still have to invest and devest everytime a new wave comes. Meanwhile emacs is still mostly emacs. I understand the dread emacs can impose on you, from old keybinding cultures and elisp but there's something timeless and freeing in emacs.
> There's a strange dance of IDEs coming and going [...]
Intellij IDEA 1.0 was released in 2001 - is still in active development - and as far as I know the keyboard shortcuts are still the same (depending on the configuration one chooses)
The first Microsoft Visual Studio release was in 1997. XCode was first released in 2003.
Fog of the future not withstanding; most people aren't going to have been using IDEA since 1.0.
If you learned Java between 2001-2012 then the default was Eclipse or netbeans.
So you should not be comparing IDEA from 2001 to today (or any individual IDE), you should be comparing the IDE landscape or ecosystem of 2001 to today, and part of that analysis should be a requirement to weight IDE's based on popularity and the recommendations of established institutions (academia, companies).
So you've changed IDE once in 22 years? That doesn't change the argument in any meaningful way.
3 replies →
I was using Visual J++ in 1998.
We did a bakeoff of Eclipse, NetBeans and IDEA upon its beta in 2001. IDEA won hands down and is still the IDE of choice among the developers who work on our codebase.
My first java IDE was Visual Cafe by Symantec 1999 - and if I remember correctly I started using IDEA around 2002 (and still do - incl. Rider, etc).
5 replies →
> There's a strange dance of IDEs coming and going, with their idiosyncracies and partial plugins.
The Language Server Protocol [1] is the best thing to happen to text editors. Any editor that speaks it gets IDE features. Now if only they'd adopt the Debug Adapter Protocol [2]...
[1] https://microsoft.github.io/language-server-protocol/
[2] https://microsoft.github.io/debug-adapter-protocol/
One of the nice things today is that DAP and LSP (while very much designed around VS Code's internal extension APIs), the things that use them are basically duct taped to tiny VS Code extensions over JSON RPC. They can and will outlive VS Code as the IDE of choice.
While on the surface that means that language support doesn't have to be designed for a particular editor/IDE, what's less obvious is that LSP (in particular) can be used as a generic IDE plugin API. I've heard of some non-language support extensions (ab)use LSP to get cross-editor support with the same codebase.
Yes I used emacs at school 15 years ago, and I agree that it was great for development ; with OCaml at the time (and also C with gdb integration, and 68k assembly later on) we shared a few tips with other students and the workflow was convenient for dev.
But vim is ubiquitous which is a huge plus when you are like me always connected remotely on a different machine. Once I learned a few shortcuts I never went back (and never dug into the tool itself actually, I can't even run a macro ; I'm still faster than most people I know with an IDE).
The only thing I was impressed with is I think phpstorm, watching a laravel dev crafting an SQL query. If I ever get serious about developping I would look into this kind of things (not just for SQL but also framework and module functions), especially if I can get vim movers, and a screen that isn't bloated. VSCode displays like 15 things and I'm only interested in 1 of them 99% of the time for example.
i never used vim in a large codebase though, do you ? I understand the remote edition appeal, and I use vim 90% of the time in cli
Again I'm not a dev but :
- for ansible on reasonably large projects (a dozen of roles) it was never a problem ; you have to understand how the project has been structured and be able to use grep and find though
- when I was playing around with os161 I don't remember it being an issue. Although for this particular case I did use the cscope vim plugin which is helpful to navigate through the codebase (there are equivalents for various languages). Not sure if os161 would qualify as "large codebase" but it's a bunch of files in a bunch of folders.
If you’re dealing with a large C or C++ codebase, Vim’s native cscope support scales way better to large codebases than the newer language server solutions from visual studio code, etc.
It is not really the learning curve, but it takes just too much time to set up to match VSCode or VS or Jetbrain IDEs, plus it requires too much muscle memory to use it effectively. It's difficult to stick unless one uses it frequently. I simply can't afford it.
TBH everything on Linux/Unix variant (except MacOS) is like that, there is no open-box solution. There is always too many configurations and even begin with (even VSCode is too configuration heavy for my taste but I use it as my Linux VM is light). This is definitely good in its own sense (more powerful), but most of time I just want something to work and concentrate on what I really want to learn. I mean, if I really want to learn how an editor works, I'd go ahead to build one myself, but in the mean time I just want to write a toy compiler so please just let me do it.
You can use Jetbrains IDEs on Linux.
Yeah I'm going to try it out when I purchase a dedicated Linux machine. Usually I ran from a 4GB-6GB VM so it's a bit stretchy.
> you still have to invest and devest everytime a new wave comes
Not really... When a new editor/IDE comes and replaces the rest, it's because it seduces the original userbase of the previous IDE, so usually the transition is smooth (same shortcuts, similar functionalities and ergonomics). Moreover, I find it weird to "invest" time in an IDE, usually you don't really need to, you learn the basics of it and you're good to go for years.