Hacker News Reader

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.

> 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).

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).

That's cool, I didn't know you were most programmers.

I only wanted to mention that certain IDEs still used today are not coming and going but have been around for decades and are still more or less the same (keybinding, etc).

Maybe I just don't understand your comment - even translated it still confuses me tbh. (I'm not a native speaker). Sorry if you feel offended I guess.

Not offended, but not understanding because of translation is fair.

My entire point was that it's unusual for someone, especially someone who is new to IDE's or programming in general, to pick something brand new. As educational institutions will take time to change from the popular thing and most companies will also need time to adjust.

Distilled: my point is that you should not compare IDE release dates to the stability of IDEs vs Editors. -- you must consider the entire ecosystem of each at the time.

Another perhaps good example to conclude this would be something like python backends. One could (unreasonably) argue that Python has been around since 1991; but backends typically were written in Perl or PHP for a very long time. It wasn't until 2008 or so that Python started making headroom for web backends (ruby around the same time) -- The possibility existed but the popularity wasn't there.

A similar argument could be made for Sublime text (which is uncommon these days) but was extremely common in 2010. Or Atom, which doesn't even exist any longer but took considerable market share from Sublime in its heyday.

It's not fair to say "x has been around for y time therefore it is not changing", the ecosystem does change and it has darlings and detractors.

The only exception to this ecosystem over tool argument I can think of is probably visual studio itself as that was a monoculture and stuck around because of that.

What do you consider the successor to Atom and Sublime today?

I would definitely say VSCode, I wonder if anything comes after it though. :)

I know there are many editors fighting for its market share, like Zed from the original Atom team or Fleet from Jetbrains.

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.

So you've changed IDE once in 22 years? That doesn't change the argument in any meaningful way.

I know my school has changed IDE recommendation 7 times in 22 years.

But my point is much, much broader than one persons experience.

> I know my school has changed IDE recommendation 7 times in 22 years.

Just so I understand you correctly - am I using your comment

> That's cool, I didn't know you were most programmers.

correctly here?

Clearly theres something I have failed to communicate, you have an experience that does not match the most programmers and I pointed that out.

As I stated in my post above, (after someone asked me a direct question) that: despite answering the question, it was the wrong question and not the point I was making.

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.

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.

> 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.

> 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/