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