I can see that by using an abridged and edited version of my analysis of the data for this blog post that I’ve unintentionally spread confusion. I’d like to clarify the intention behind my comments on developers and IDEs. For me, if developers don’t understand what IntelliJ IDEA gives them as a fully-featured IDE, that’s a failure on my part, since it has been my job for six years to educate developers on what an IDE (specifically IntelliJ IDEA) can do for you. I feel very strongly that one should never blame users, or prospective users, for failing to understand a product.

My personal viewpoint on IDEs for Java developers comes from having been a Java developer for 20+ years, working on production Java projects large and small. I can’t imagine trying to create a complex enterprise application without the considerable help you get from an IDE like IntelliJ IDEA. I have also seen lots of developers using VSCode and I completely see the use cases that code editors cover well. There’s always room for more than one tool in your toolkit, and understanding what a tool does well helps us pick the right one for the right job.

I work on an enterprise project with 100+ gradle projects and a pile of targets for docker containers, kubernetes deployments, DB schemas, Redis stuff, etc..

Eclipse is incredibly slow in this use case compared to IntelliJ and would frequently gobble 10GB of Ram. I switched from Eclipse to IntelliJ earlier this year after years on this project and IntelliJ is amazingly better.

But if you're using some different build system and a different type of project configuration maybe it's the other way around..

I think the thing with these

This was back in 2011 though. Obviously things have changed.

The difference between Eclipse and IntelliJ was like night-and-day, however, in terms of performance.

I don't love eclipse, not a person to get too attached to an IDE, but it is an incredible piece of open source software. It works.

Also too much effort in rewiring keyboard shortcuts that have made their way to my muscle memory. So eclipse it is.

For longer sessions that's not a problem, but when you're on battery or quickly hopping into the project to look something up it makes a lot of difference. Also, opening up a foreign project is two clicks and one second, compared to project creation and then loading+indexing when using IntelliJ.

I love the IntelliJ line of IDEs. But VSCode outcompetes it in simplicity by far. Especially when we're talking about something like a simple Node project, where compilation+execution is far simpler than something with a full build pipeline with artefacts.

I wouldn't blame that on VS Code but on the relevant extension. Go to Definition is instantaneous for me when I'm working in TypeScript

When you start a longer session, the overhead is very much worth it, I agree fully.

As someone who wishes they could drop everything else and just use Kate or VS Code, I disagree. IDEs like those that JetBrains offers have refactoring tools that are unmatched by what VS Code and its plugin ecosystem currently provide.

More widely used langs have better experiences though I'm pretty sure. And maybe Rust support has gotten better? Seems that other commenters in this thread had positive experiences.

https://www.jetbrains.com/rust/

and of course, there is the GoLand IDE

https://www.jetbrains.com/go/

Which I personally like alot.

VSCode doesn't interpolate HTML variables for me. Its the small features that add up over time I miss whenever I try to switch development environments.

VSCode has a really good TypeScript/JavaScript and admittedly Python developer story, and the ecosystem has produced some pretty robust Style editing extensions, but if you want things like autocompletion for your template variables, I've always found you have to look elsewhere, whether it be handlebars, django templates, Jinja templates etc (and this is one example, among many)

VSCode doesn't autoload JSON schema (need an extension or hope for the best)

VSCode Extensions are also suffering from some pretty serious lack of maintenance too. Lots of extensions, very little movement on updates. I've had more than one of them break on me in major ways.

Something as simple as opening a file of code requires IDE, because everything is hidden behind `./src/main/java/com/whatever` nonsense. The language was designed for IDE.

In Rust there is hardly any need for IDE (or a debugger), as long as your text editor has LSP support. Hell, even without LSP support it feels quite OK to write Rust code.

I use Intellij for Java, and Kakoune for Rust, and I really dislike working with Java. The fancy refactoring features don't make up for how verbose, clunky and inexpressive Java is.

The Rust way is to have great modular and reusable tooling for everything. Even stuff like complex refactoring can be achieved without an IDE with something like https://github.com/google/rerast

VScode is a very nice middle ground where the defaults make sense and you can get powerful extensions for everything else you want, there's a reason it's so popular.

HotSpot, under a typical configuration, eats up about 250MB just sitting there doing nothing. I don't know what Electron does under similar circumstances because I've never tried to measure it, but I know that I regularly see Electron apps using less than 70MB, so we can estimate an upper bound on Electron's typical contribution to bloat as being no more than ~30% of Java's.

For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB. I doubt that much of that difference is actually attributable to using a browser rendering engine for GUI layout. In fact, I'm guessing that Chromium's net impact on the situation falls below the noise threshold of this comparison. So, yeah, not worried about it. FWIW, vscode also started up quite a bit faster, and I experience less keyboard lag when using it.

And, if we're looking for mature and full-featred cross-platform GUI toolkits, that's about it for your options. Yes, there's QT, but, with a sticker price of $4000/developer/year, it's hard to criticize people for not choosing it. And there's GTK+, which is fine, I suppose, but not exactly everyone's cup of tea.

Long story short: This Electron-flaming meme is getting old. If you don't like JavaScript, just come out and say it. If you don't like how Chromium is eating the world, that's a fair point, too. But stop scapegoating Electron for things like how Slack's desktop app used to leak memory at an astonishing rate. That was always the app developer's fault, not Electron's.

This is much lower in newer jdk's [0].

> For a slightly more apples-to-apples comparison that's also quite a bit more apples-to-jicama, if I open vscode and IDEA on the same project (a small one I'm just getting started on), vscode and all its helpers are using 316MB, and IDEA is using 1.08GB

I believe this to just be intellij bloat and not JVM because it just does too much. I run VSCode with the Java plugins and ZGC (read: eclipse language server, which is all jvm) and the language server only ends up using around 250mb of ram.

[0] https://cl4es.github.io/2019/11/20/OpenJDK-Startup-Update.ht...

Somewhat related, back when I was a C# developer, I spent a long time being confused over the community's somewhat polar opinions on whether Visual Studio is slow and bloated, or lean and snappy. Eventually I realized that the difference of opinions was because some people's employers buy them copies of ReSharper, and others don't.

Mmmm, I have two projects open in IntelliJ right now, one of which is quite large, quite a few tabs, and it's using 366mb of heap.

You have to watch out though - Java won't collect garbage if it doesn't have to. This fools a lot of people. They look at memory usage and assume it must really be using that much memory, even when it's not. From the perspective of the JVM if the memory is there, it may as well be used, because freeing RAM just to leave it pointlessly empty just wastes CPU time, battery, generates waste heap etc. Why not use it? The only time it matters is if you have something else that wants the memory and it can react to that I believe. Or if you're measuring it against other tools of course.

I guess over time this will go away as a talking point because the JVM is getting more aggressive at collecting memory even when there's RAM spare, partly because of containers and partly because of threads like this one.

> Long story short: This Electron-flaming meme is getting old.

No I think it remains perfectly relevant today. And Electron products are not really enough shit that they so well deserve.

Citation needed. Because right now we're running most our Apache TomEE and Tomcat applications in prod on a 64m or 128m heap and handle hundreds of requests or messages per second. And this is on an ancient JDK1.8. On JDK11, we're thinking of running between 16m and 32m heaps.

So no, I don't think there's any truth to the claim "Hotspot always uses an extra 256m of memory". Sounds like the kernel is doing what it's supposed to: free memory is wasted memory.

Electron isn't the problem. All of the technologies it is built on are the problem. They require extreme measures to control quality and maintain performance for anything larger than a trivial crud app.

If you want the QtGui module, look north of $100k buy-in.

Which to be fair is a very impressive piece of technology

You say that, but IntelliJ is not exactly slouching on resource usage. I see far lower memory usage in VS Code than I do IntelliJ opening the same projects.

I see this critisism of VSCode a lot - but the job of a browser engine is to render text really fast! Rendering text is something you want to do in a text-editor is it not? Why not use the best tool for the job?

You're probably right that something like Sublime Text is faster - but that's a massive undertaking that would take a lot of engineering to get right.

The point of Electron is to allow people to develop UIs quickly, leveraging their experience with the web. Electron is extremely bloated & slow. To some degree it has to be.

If browsers were about speed, they wouldn't interpret Javascript. I'd argue they'd probably force the UI to be specified in a form that explicitly disallows inefficiencies and probably isn't turing complete. I'd argue a domain-specific solution for rendering highlighted code specifically could be a lot faster than a browser, like multiple orders of magnitude. We know that's the case by virtue of the fact we could even do it at all in the 80s.

That would be so far beyond impractical you wouldn't last an afternoon.

The way of the future is definitely lightweight code editors loaded with as much or little customisation as the user desires. Monolothic IDEs are long dead outside of the Enterprise™© world.

Funnily enough, I also found myself using Java and .net less and less. I never had much love for Java, but C# was an amazing language that somehow got gobbled up by the Enterprise black hole and it's a huge shame.

I spend all day navigating and reasoning about the codebase I'm working in, so I need strong tools that aide me in that. That's where VSCode doesn't hold a candle to Rider IME. So Rider is my daily driver at work.

The responses from some devs leave me wondering what their env/projects/work day actually look like and how does their tooling actually work for them in practice.

It would be incredibly interesting to see the landscape of different work envs and tooling and do a comparison of what happens in each given env when you swap out the tooling.

A typical work day has me working in at least two different projects. Visual Studio/Rider is so heavy that I don't want to keep two instances of it running all the time and it's so slow that switching between projects in a single instance carries a heavy context switching cost. I also have a set of markdown files that I use as a second brain which I like to open periodically to check notes or jot down ideas.

> Do you work on multiple things that don't require coding?

I also write documentation, answer emails, review PRs, occasionally modify art assets, maintain team documents, etc. I don't always want Visual Studio/Rider hogging all of my memory or chewing up the CPU.

> Why does launch-time matter at all?

I hope what I already wrote made it clear but TL;DR I jump between projects, don't want multiple instances consuming all my resources, and (bonus) I frequently need to restart Visual Studio because it can get in to a weird state when working in C#/F# hybrid projects.

What IDEs have going for them is that the features are generally constructed by people who know what they are doing and test them at the same time. Whereas a plugin could be written by anyone. Also there's a great "works on my machine" when it comes to performance: the plugin author will just test the plugin on its own rather than with a bunch of other plugins, so their performance target is artificially low.

What in the world do you mean by this? C# is more amazing than ever...

No matter how amazing the language is, it has become hard associated with enterprise work and not much else. It didn't need to be that way, that's Microsoft's doing.

Maybe you are right on that, but why do you consider that a bad thing? Different languages are for different things.

Your statement of non-enterprise projects off by a factor of 10-100x is partly because people jumped on the non-statically typed mess that Python is. Especially with all the AI related stuff.. yeah if you are doing some random little research project and you are a math person but don't want to take the time to do programming "correctly", then sure you can jump into python, use some libraries and get some results. It has it's purpose.

I don't know it's just silly to bulk everything together and pretend you can compare them.

Also saying .net is dying in enterprise is basically laughable.

The time of bloated IDEs is over. And you're right, I need to be able to run all CI tools the same I do on my development machine and the CI server.

Obviously, WYSIWYG and other graphical builders will always need a specific IDE in order to do RAD, but these are special cases, not the norm anymore.

Nothing prevent jetbrains from selling CLI tools that perform all the tasks in their IDE, especially when many of their IDE do rely on open source CLI tools at first place.

But If I'm developing say an Android app and I'm not the design integrator, I shouldn't have to fire an slow and heavy IDE just to write a bunch of Java classes. I have my maven manifest and it should be all I need to compile a project.

I find this pretty dumbfounding considering the amount of efforts that goes into IDEA, Eclipse, Visual Studio, and X Code on a daily basis.

Also, watch how VS Code (and other text editors) are slowly turning into full blown IDE's as well.

The code we write today has never been more complex, it requires matching complex tools.

And Intellij's products come from decades-old thinking about how to manage that complexity.

They're not good enough; for many people they don't help manage complexity. They just increase the confusion.

I don't know why it died, WYSIWYG and GUI-friendly IDE's allowed higher productivity in that "one-man-bands" (small staff) could do the entire project. Now development is often layered into specialists. Things like UI design and ORM's have longer learning curves, which emphasizes specialists. But staff is larger per feature: less productive. (There are many times I wanted to shoot Bootstrap in the head when I couldn't get it to act how I wanted. Something in WYSIWYG that would take 20 seconds becomes a 2 day trial-and-error session in Bootstrap.)

WYSIWYG/GUI-IDE saved money. Most businesses don't run their internal productivity software on mobile anyhow. "Progressive" UI's are a money sink in practice.

The trend predictors got it WRONG: desktops live on in biz. Our anti-state-GUI web standards don't help. Businesses really want cheap rich desktop-like GUI's for productivity software.

I'm not against flow-based layouts, but they should be an option, along with WYSIWYG.

Can I ask where you you see this demand, is it industry specific?

I was under the impression that the benefits (easy deployment to a known runtime aka the browser, open ports (80/443) in the firewall, large developer pool, potentially cross-platform use) outweigh the UI shortcomings and budgets were shifted to web-based productivity software.

End users who care about productivity want rich GUI's. Rich GUI's use screen real-estate better than "progressive" web apps and have abilities like right-click, rollover text, etc.; and it's cheaper to develop because they (optionally) can use WYWIWYG for many parts of it. WYWIWYG is just plain cheaper and easier to get right. You don't need "flow layout" specialists who can tame sucky CSS/DOM, which makes alchemy look logical.

Remember that businesses don't really care how software works as long as it does the job and is affordable in creation and maintenance. The bloated web stacks are not. It's too much code to do the same thing UI-fit tools did with less because they were closer to the CRUD/GUI domain itself. Web stacks are too fucking layered such that you spend most of the time managing communication between layers instead of on real biz logic. I stand by this and if you look at the code you should agree.

We DEVOLVED. Current web standards may be fine for social media, but not real work. We let the "cool stuff" pollute real work in cubicle-land. Oh, and git off my lawn! ;-)

I remember when ExtJS was positioned in the late 2000s to mimik rich desktop UIs and I think there are still lots of component based frameworks to use and pay for, if Bootstrap doesn't cut it. The prices are steep though.

Oracle Forms kind of worked like this (mostly before Java era), although its GUI control language was proprietary and not XML. Oracle Forms had its warts, but was a good proof concept for the GUI browser. Developers got a lot of work done under it.

But when I want to write my code, get correct linting, inline documentation, Java-to-Kotlin conversion of old code, the whole range of interacting with the device I am running my code on, management of my Gradle tasks, VCS integration, Task contexts, remote connections to test databases (and the whole other metric ton of features I wont get into) I will always take Android Studio over what ever flavour of the year text editor.

I really enjoy using VS code, but it is no IDE.

I have Webstorm with 15 projects open using 500mb of ram, and IntelliJ using about 800 on a larger Java project.

The key selling point of Intellij IDEA is they come with semantic refactoring tools, for something like "move this method into its parent class" or "extract the selected methods to a new interface", which is still rarely seen in the wild, and didn't get mentioned at all in your list, but it saves real time.

If you structure things differently - say, by steering clear of subclass inheritance, or keeping interfaces small, or not using the Bean pattern, then you can pretty quickly discover that there aren't all that many IDE refactorings that you actually use.

At this point, most the refactorings and code actions that I'm actually using exist in vscode as well; IntelliJ's main advantage is that I'm (somewhat) more able to use them efficiently without taking my hands off the keyboard.

VSCode with its flexible plugin system got this right. Even though it isn't a speed wonder itself, it's still better on average than most "heavy weight IDEs" I've seen).

- I go to fix some issue and my IDE shows me that the code is copy-pasted in 3 places so I knew I have to extract a function, do some cleanup and fix all 3 affected places.

- bug appeared other a refactor, checking the code in the IDE I can see a red variable name, it was red because it was undefined(this is in JS code)

- sometimes when using soem inner function I would try to do something like "this.something" but the IDE notices it and warns me that in this scope "this" is soemthing else

I am also impressed that it can most of the time understands frameworks and libraries like angular or jQuery

Of course, it sounds like there is no real testing or review before your team commits to master anyway, so there is your low-hanging fruit.

I would be interested to read more on how to add such a strict CI to an existing project.

VS Code is particularly smart in that will pull in TypeScript definitions for libraries and use those for auto-completion even if you are not using TypeScript (and are using plain JavaScript).

I think this makes a big difference. I also have 16GB RAM and a fast SSD, but I'm on a 2-core MacBook processor. I find that with all of the various different projects I have to interact with in a day (I'm the tech lead at my company) I can't leave an IntelliJ-based IDE open without it slowing the rest of computer down to the point that it's impacting my productivity.

Also nice advantage of Intellij hints is that most times they also offer auto-fixer so it's very safe to apply the fixes.

…minutes, hours or sometimes even days after the code was written. Not every project can run its CI pipeline in seconds, incrementally, or on the developer’s system.

The advantage of any IDE is the “integrated” part. Linting is one thing, showing the results in a way that makes it as easy as possible to act on them is where an IDE beats a DE that does the linting in a “decoupled way”.

I don't know how long ago you tried Rider, but after more than a decade of using Visual Studio I had had enough of the lag, broken features and instability - I moved to Rider, and couldn't be happier. In fact, I'd say it's one of my favourite ever pieces of software. It obviously loads much slower than VS Code, but then in operation if feels snappier and never lags. I've also never once had a release version crash, which for such a complex tool is pretty impressive.

True, QtCreator performance is fine. But I found the whole toolchain integration (Kits?) and cmake integration a bit weird if I remember right.

The fact that it played so nicely with CMake was an added bonus.

But having a language that enables the functions of an IDE is a big advantage. A good text editor that manipulates characters efficiently is absolutely valid. But an IDE that treats code as an AST gives you a lot. After all when you think of code you think of it in trees/graphs: You go to fix a bug, one of the first things you will probably ask is "what calls this code?". Being able to do that, right up to the top of the call hierarchy, instantly, without having to run the system is a huge advantage.

An IDE gives you the tools to reverse engineer the design (or lack of it) from the code.

This is indeed useful, and languages with semantic IDE tools are indeed better at it. But this works for me in JavaScript 90% of the time with just text-based (and I think it probably tracks imports) tooling.

Also it’s not 2000. A Java IDE will work fine on any computer you can buy.

Your runtime and tooling will always be a dependency, and you will always have to learn enough to troubleshoot it regardless of the language. PHP, JavaScript, Ruby and Python are no different to Java - the SDK must also be installed and kept upgraded, you still have to fix your application to work with a newer runtime when the language changes or when fixes are backwards-incompatible, and your SDK version might still clash.

Performance is not an issue in practice. I only ever noticed IntelliJ being slow on a machine that was too slow to run a web browser, and I don't think that such machines would be very common because people would just get rid of them. Resource use has ballooned over the past few years due to the rise of Electron, so your machine already needs to be powerful enough to run Discord, Slack, Postman, or whatever other applications you wish to run in parallel. Adding a JVM alongside that is not much of an ask, given that IntelliJ consumes around 500 MB with two fairly sizable projects open.

why in earth would you think that. we get further as a species because we develop more complex tools to achieve our goals, be they nuclear reactors, smartphones, etc.

Simplest tool that gets the job done does not mean it is simple. There's still the the part that gets the job done, so it still can be essentially complex tool.

Accidental complexity, on the other hand, will only slow you down in the future, or even make you incapable to continue further development.

Simple tools are only appropriate for cheap, low-value projects (e.g. don't set up an IDE and build automation when some trial and error with Maven to compile something occasionally is enough).

So, like we should all build houses with straws and mud, since that is the simplest and gets the job done (creates a habitable structure) too?

For all intents and purposes a modern brick might as well be carbon fiber compared to ancient bricks.

How much assistance are you used to or do you consider worthwhile? Where do you draw the line?

Which is not to say that my understanding of Java extends to working professionally in it; I'm a functional programmer and broadly unfamiliar with modern Java's specific patterns.

I assume you mean reflection - this would be very untypical for normal business logic code and would get smashed very quickly in any code review. It's also far from nice and easy code. You can program "dynamically" in Java, but it gets ugly quickly which in itself discourages you from doing that habitually.

Reflection is used mostly in frameworks only.

> When not doing this, they are usually creating interfaces with a dozen implementations that wrap and delegate to one another.

Sure, Java devs have so much time that they don't implement the business logic once, they create dozen different implementations just for the fun of it. Again, this situation (one interface, many implementations) happens mostly in frameworks and rarely in business code.

If you want to hate on Java, use some real arguments ...

No, a lot of java critics complain about it being hard to tell what's calling what at the framework-to-user-code boundary

That means not only reflection, but also most Dependency Injection (Spring autowiring, Guice...), anything that runs on annotations (including @Test and JAX-RS), any code auto-generation (e.g. Protobufs, Jooq), most mock libraries (e.g. Mockito) and most configurable logging, especially the logging libraries that try to auto-detect one another.

Of course, some would say those problem are with Corporate Java Culture choosing to use all those things, rather than the Java language itself.

I understand that Java wants to remain conservative with its development roadmap, but the fact that the majority of an ecosystem uses a third-party framework is a good reason incorporate something similar into the language.

That's rather an industry criticism since these problems exist everywhere and are often direct consequence of trade off for looser coupling.

There are also often alternatives - e.g. Dagger for DI and MapStruct for mapping which go the code generation path which allow you to statically inspect the whole code path, you can also always trade the looser coupling for more directed paths e.g. for logging by avoiding the wrapper and using a logging library directly.

No they don't. Java is just not expressive enough, so library/framework authors have to decide between bloat or magic and they often choose magic for better or worse. There are languages that doing better in this regards.

Such as?

I'm not sure this is necessarily a culture, either. Java tends to be picked more for applications with more demanding/richer requirements, and so they need to do a lot. This demand for features drives a demand for richer frameworks. You see this exact thing happening with JS on the client. So to the extent this is a problem, perhaps it is a general software design problem.

I previously asked in another forum about this sort of thing and heard that I should read the docs. I suppose when working at a big company ships internal libraries that expose annotations and use inheritance extensively, but do not have docs, I should just pretend that I am not actually in such a situation, or something.

Intellij can show you which aspects have been applied for e.g. AspectJ or Spring AOP.

I mean if you or your company really insist on writing your own metaprogramming library then yes, IDE can't do much to help you, but that hardly represents industry practice.

You might be thinking this is pretty awful, but hey, software is complicated, you have to understand the code you're working on —- fine. It's reasonable to put this amount of effort into the code you are actually working on. But when you're working on service A and have a question about service B, it's nice to be able to pop over to service B's source code and find the answer without investing a lot of time understanding the technologies underlying it.

This is why "enterprise" Java programmers end up obsessed with anointing "best practice" frameworks. Me relying on a big magical framework for everything I do is only problematic because some other people don't use it. Solution: let's establish my framework as the "de facto standard," and then nobody can complain that it's ridiculous overkill for simple applications. Let's make proficiency with my preferred framework part of the definition of being a professional Java developer, and then nobody can complain about how time-consuming it is to get up to speed with it.

The alternative is to use libraries instead of frameworks, use as little magic as possible, and work in a language that is powerful enough that you can write straightforward code and still say everything you need to say in a reasonable amount of space.

Consider the simple, ubiquitous case of writing a method to implement a POST endpoint in a database-backed CRUD web service. Suppose you need to authorize the request according to some business logic, deserialize the entity body, validate the body according to some business rules, get a database connection, construct a query, run the query, process the query results into a response object, set the status code and headers for the HTTP response, and serialize the response body. Why shouldn't all of this functionality be discoverable in the code via chains of method calls from the method that implements the endpoint? With a concise language and a well-organized codebase, this is entirely possible. Readers of your code can see: here's where to dig in if I want to see how the request is deserialized, here's where to dig in if I want to see how the database query is constructed. If your code becomes exhaustingly verbose when you express it in this straightforward way, then your language is failing you.

As a fan of Scala, I have to admit that Scala introduces a similar difficulty with implicits (and the horrible practice of using wildcard imports to import entire menageries of implicit methods and values, which is epidemic in FP-style Scala.) Implicits are indisputably widely abused, but at least IDEs can show you how implicits are resolved at compile time, and in your own code, you can make implicits reasonably readable without IDE support by declaring them in an enclosing scope with a good name.

[0] I'll make an exception for one style of annotation: annotations that point you directly to the relevant code, like @ExceptionMapper(MyExceptionMapper.class). This is almost always all the information I need, the only exception being if the person who wrote MyExceptionMapper misunderstood some subtlety in how it gets wired in via ExceptionMapper.

The question is: why? Why would you not use an IDE? Looking at refactoring capabilities alone you'd want those for any language [1] And on the fly actionable code analysis [2]? Why would you not want that for a programming language?

[1] https://www.jetbrains.com/help/idea/refactoring-source-code....

[2] https://www.jetbrains.com/help/idea/list-of-java-inspections...

How does Java need strong IDE more than other languages?

The only thing I can think of is the (long) import handling, but that's hardly a "strong" IDE feature, more like bare bones IDE feature.

And because Java is statically typed, this enables you to do things like changing the name of the "save" method in 83 of the different 132 instance, namely the method from class "Widget" and all its subclasses. And, of course, update the right callers.

If you are doing Python or JavaScript, you often don't have much of a clue what the type of "foo" is in that "foo.save(a, b);" call, and so you don't know which of the "save" methods are being called. And you know that when creating your app, so you stay clear of class hierarchies that require this IDE functionality to untangle :-)

Deep inheritance trees came out of fashion (everywhere, not just in Java) long time ago. Inexperienced developers can misuse inheritance in Python just like in Java.

> And because Java is statically typed, this enables you to do things like changing the name of the "save" method in 83 of the different 132 instance, namely the method from class "Widget" and all its subclasses. And, of course, update the right callers.

As opposed to Python or JS where "we don't know for sure so it's gonna be safer to not refactor".

> And you know that when creating your app, so you stay clear of class hierarchies that require this IDE functionality to untangle :-)

That's an extremely optimistic view.

I haven't seen inheritance more than one level deep in JavaScript for years. And most code isn't using it at all.

(unless you mean prototype based inheritance which is very different beast)

All inheritance in JS is prototype based inheritance. The class syntax is just syntax sugar prototypes. In theory you can do all sorts of crazy things with prototypes. In practice people use them just like classes. The reason people don't use inheritance in JS has nothing to do with browser support.

And async/await is promise based yet it results in quite different programming style. It doesn't matter which primitives are used for feature implementation.

> The reason people don't use inheritance in JS has nothing to do with browser support.

I don't think so. Since the advent of ES6/Babel/TypeScript I see inheritance on frontend daily.

Throw something like eclipse/Jetbrains at it and the whole thing has an aneurysm .

If your language requires an IDE, you've already failed

That said, when I need to work on a Java or C# project I put Emacs aside and reach for my preferred IDE. There is overlap between a text editor and an IDE; certainly I can _make_ a text editor do _most_ of what I get from an IDE but is it really worth the effort?

In my opinion, IntelliJ is on point here in some cases; I suspect developers coming from a background in front-end or a language like Python or Ruby are very comfortable with their text editor and tend to use these same tools for work with Java or C#. In this case it is likely that they are to some degree unaware of the benefits of a more integrated IDE.

In terms of CI integration, in my experience this has never been a problem (I have never really used Eclipse). My Java IDE uses the Maven configuration to manage the project and the CI process calls Maven from the command line. In the C# environment, the command line tools works in a similar way.

At work, I deal with JS, Python, and Java. I don't really care to spend the effort to configure Emacs to handle all the oddities of a super old codebase reliably. I just grab vscode or intellij. They're fine.

I sort of mix and match depending on what works best for a given project.

The disconnected VSC model - main company in charge of the editor, and third parties in charge of certain language plugin[s] - puts some languages' support at risk of being insufficiently developed.

I "only really want advanced editing + syntax highlighting + language server", and use VSC, but, while its support for "statically typed languge #1" is ok, the support for "dynamic language #2" is atrocious, to the point of being unusable (poor "go to definition", editor aggressively misaligning lines of code, etc.). I'm not sure it will ever reach sufficient support.

On an IDE, this doesn't happen, because the developing company must, within a certain qualititative extent, take care of all the functionalities.

OTOH:

1. it encourages the main company to simplify and/or extend the plugin API to make writing plugins v simple, or even possible in the first place.

2. it gives a smoother path for the inclusion of new trending technologies into the IDE.

3. it encourages devs to offer improvements to features that aren't high priority for the large IDE company.

For the latter, I'm thinking of Lombok support which, via a plugin, is much better in VSCode than it is in either Intellij or Eclipse.

Studying how the IDE made use of Turbo Vision was a good introduction to OOP ideas.

Also, many things in VSCode can be done in-proc as well if one so desires, including debuggers and language servers. Most extensions do them out-of-proc because it gives them more flexibility (esp. wrt implementation language for those components), and because it's easier to test such isolated components.

Personally, I use VSCode for generic text editing, scripting, taking markdown notes, general purpose review/browsing repos (e.g., opening up a project to review a couple of python classes), etc. It's nice for switching between a variety of languages and use cases. I like the integrated terminal, the directory search feature (so much less clunky than the equivalent Mac Jetbrains IDEs' features), the multiselect text editing experience, the ease of configuration, and the general responsiveness.

But if I need to do a deep dive on a language, I generally switch to a fully featured IDE. For example, if I need to refactor 10000 lines of C#, I'm definitely going to switch to Rider or VS with Resharper where the built-in refactoring, debugging, and static analysis tools are so much more powerful.

So really I see them as different tools for different use cases. VS Code is nice for my fluffier, tech lead work, where I tend to bounce around between fifty disparate tasks in fifty different contexts. Rider, Pycharm, CLion, etc. are more useful for me when I have to fall back into doing deep dive technical work personally.

Seriously? They should have a look into what VS Code (and friends) can actually do! Once you outsource your refactoring machinery into something like TypeScript or Roslyn (C# Compiler) you suddenly have these features available everywhere. And in that regards, the should also just look what their Resharper Product is doing in Visual Studio and JetBrains Rider.

I think the only lack in editors is visualizations. I think that will be soon a theme in VS Code ;)

VSCode, when it works, gives one a glimpse of what you be a good IDE (Visual Studio proper, JB Rider), yet is light-years away of being one.

I was addressing the c# refactoring s. They were delivered with roslyn to VS and exposed to VS Code via OmniSharp. The gap of C# refactoring in the VS 2008/2010 era is due to the Roslyn project blocking all other efforts. So C# refactoring are only realized via Roslyn Analyzers and with that available to VS Code.

And VS Code is executing them nicely. There is no gap.

[1]: https://charlespetzold.com/etc/DoesVisualStudioRotTheMind.ht...

You really don't want to add ephemeral designer tools to your list of hard project dependencies.

The Delphi, C++ Builder, Forms/WPF/UWP, Swing/JavaFX soul in me begs to differ.

In fact that is the biggest pain in Web projects to this day and I can hardly wait for stuff like Uno and Blazor to bring "Flash" back, if Web Components don't do it first.

Still no idea. Seems to be a synonym of IDE, but not really?

For example in Lazarus, Delphi and C++ Builder when you edit components in the visual editors (be it the form editor for making a GUI or a data module editor for non-visual components - e.g. editing the routing for HTTP requests in an fcl-web application) you are actually editing live objects which are serialized as part of your application when you save the project (contrast this to something like Qt Designer, Gtk's GLADE or wxFormBuilder for wxWidgets, which only create stand-in controls that pretend to be what you are designing). The IDE exposes the properties and events of those components by using their RTTI information of the object instances directly (instead of hardcoded knowledge of using some configuration file) and it has full knowledge of the source code you are editing so that it can automatically create event handlers, functions, variable declarations, etc for you (no need for special comments or whatever) as you edit the components and the code (this isn't just for component editing btw, in Lazarus you can do something like start writing a `for I:=0 to 100 do` loop, then move the cursor to the `I:=` part, press a key and have the IDE deduce the type and declare the `I` variable if it is missing).

One way to think of it is like if you are making a game in Unreal or Unity where you also work with live objects, but instead of those objects being levels, pick up items and monsters, they are forms, modules and buttons for your application.

I personally find IDEs are way too complex and cluttered for my personal tastes. To boot, a code editor allows for unified workflows across a broad swathe of languages in ways that IDEs simply can't replicate. It's a pity Jetbrains has long held a dismissive attitude[2] toward developers that don't want a full blown IDE, but that's what you get when there are financial incentives attached.

[0]: https://microsoft.github.io/language-server-protocol/

[1]: https://github.com/fwcd/kotlin-language-server

[2]: https://discuss.kotlinlang.org/t/any-plan-for-supporting-lan...

I like the really powerful code completion and refactoring tools a good IDE brings to the table but this one strikes me as extremely odd. In 2020, I would want all IDEs to remove this kind of functionality because I don't want to deploy from my IDE ever and I don't want teams that work with/for me to ever use it either. I want to push my git commit and have everything building in my CI/CD pipeline.

It's absolute pain to write Rust/Java/C++ in any of those. No safe refactorings (moving classes? good luck), completely random code completion, 0 awares of available libs/SDKs, and so on.

It would seem that most of the developers have no clue what's the difference between a lightweight editor and a full-featured IDE. I think it's just Dunning–Kruger effect on a scale.

I understand that I'll be voted down into oblivion but it really rubs me the wrong way when people confuse some kind of server/application server (???) integrations with an IDE that can offer sophisticated refactorings, a proper type inference, and can infer which functions from which lib/SDK I am using.

No, I don't need or use all the IDE features. I don't use the integrated shell, I don't use the git integration, I don't have it handle my packages. I don't see a need for these things when I always have multiple terminals open anyways, but proper code intelligence is not something an editor+plugins can provide like a real IDE can.

I don't care at all if someone prefers IntelliJ over Emacs (that's a pure matter of taste) but the idea that it's impossible for an editing environment that isn't delivered as a single, integrated monolith to expose powerful language-specific tools such as interactive lints, large scale refactorings, debuggers (check out DAP for the debugging equivalent of LSP), etc was never true as a technical matter and is increasingly untrue in the real world.

One of the best developments in dev tooling in recent years is that it is starting to be seen as the norm for new languages to provide canonical language server implementations. Long may that trend continue.

What makes LSP not 'integrated' in the sense of the I in IDE is the fact that it is decoupled from the editor, allowing one editor to work with many language servers and one language server to work with many editors.

Seems like you haven't used VSCode in a long time. It is my primary everyday editor for Typescript, and it has all of those things you listed: I can move a class to a separate file in one click, code completion always follows type system, it is aware of all packages that I have in package.json and offers to import them, and so on.

The IDE/editor distinction really doesn't have as much meaning as it once did.

My biggest problem with vscode is lack of UI configuration. You can have only one panel which is huge waste on big screen. Some useful features compete for screen space (outline vs. project explorer, project explorer vs. debug window etc.). This makes me way less productive than using heavyweight configurable IDE.

I've tried it for more serious development for Rust, Python, and TypeScript. While for Typescript the inference is barely acceptable it complete sucks for Rust/Python.

But the thing is this is all hypothetical - it is possible if somebody invests those thousands of hours into it. But so far it did not happen for most languages and Intellij IDEs are still vastly superior to VSCode for e.g. Java, Python or C++ development.

My guess is that was intended as hyperbole, like saying you think they are "crazy" for doing so. Still, I'm thinking you'd be more likely to get interesting feedback by stepping it down a bit.

I find it incredibly pompous that you believe that people who have been writing C++/C even Java for decades in editors like Emacs, Vim or even Sublime don't know what they are doing. The IDE vs Editor argument is nearly as old as Emacs vs Vim.

As a personal anecdote, I've seen people switch from vi to IDEA after a pair programming session. In that session they learned that IDEA has full understanding of the frameworks, configurations, code annotations and bindings etc. that we used in a project, and that you don't need to spend 15 minutes furiously searching in files for stuff when you have to change something in two or more places.

> In the web space it is understandable to use an editor as web developers are typically working with dynamic languages

> But in Java, especially professional Java, you really get a lot out of a good tool

What are the reasons that make you intentionally "lose" the advantages of the IDEs?

What do you have in return?

I think the issue is more how snappy/bloated they are. I don't mind all the integrated features, but IntelliJ has gotten slower and slower over the years, and its starting to get annoying, especially on anemic laptops.

I personally saw no value in intellij compared to what vscode offers.

VScode has won both the intellij Vs eclipse AND vi Vs Emacs holy wars for me. Nothing else matters anymore (unless you need to SSH directly into a box and make edits there of course, for which we have vi) - it really is an amazing editor in my view.

I can't see the need for an IDE like intellij at all when you have an "editor" as capable as vscode.

I still use Netbeans for Java. It's simply the best.

I'd particularly like to see a use-case laid out where something like VSCode + Extensions wasn't actually enough. I've been using IntelliJ nearly every day for the past 4 years and I still don't understand how it is any different from a text editor + extensions. IntelliJ is even architected similarly with so many different "plugins" adding full fledged language support for other langages. Goland, Pycharm, etc, are basically extensions for the intellij text editor.

Personally I really like the freedom to switch editors.

I've been recently using VSCode with TypeScript (and Prettier/ESLint). TS is pretty neatly integrated with VSCode, and I've been wondering how similar the VSCode + TS combo is to writing Java on an IDE like IntelliJ?