[miki123211]

(not a Java developer, no dog in this fight)

I'm not sure I like the module import system very much. I think `import *`-like constructions make code a bit easier to write, but much harder to read, especially for developers new to the language / codebase.

C# and Nim love that style, and it makes them almost unreadable without a good IDE.

Personally, I much prefer Python's "short aliases" style, e.g. `import torch.nn.functional as F`

[pie_flavor]

I have never understood complaints about language constructs that don't make sense without an IDE. You have an IDE, it is where you are viewing the code. People that don't have an IDE are causing their own problems and should stop. People viewing the code on GitHub are not really analyzing it at the level that requires finely tracing through references usually and the terseness drastically outweighs the occasional annoyance when you are.

[anal_reactor]

> You have an IDE

No, I don't.

For some reason there exists a group of programmers that refuse to acknowledge use cases like "let me write a small program in nano over SSH" or "let me change one hardcoded variable and recompile the project and never touch its source code again". If your code is unreadable without IDE, it means that either IDE should be shipped with the compiler because it's an essential part of the language, or the language is garbage because its designers literally admit "we're too stupid to figure out how to solve this issue, hope that IDE does something smart because we can't".

[Dylan16807]

If you would stop complaining if the IDE shipped with the compiler, then just install them at the same time and consider it "shipped with". Splitting them is for convenience and choice, not because the designers are stupid. You can handle installing two things.

(And since we're on the subject of Java, let's not forget how they used to split up JRE and JDK downloads in a very similar way.)

Having the IDE ready to go takes care of the use case of changing one variable, but you didn't need the IDE in the first place. That one's fine either way.

For the use case of making a whole new program in nano, I acknowledge and reject it. You'll be fine. Use cases that exist only out of stubbornness don't need to be catered to. You have the IDE one click away.

[troupo]

> use cases like "let me write a small program in nano over SSH" or "let me change one hardcoded variable and recompile the project and never touch its source code again".

1. This is an infinitesimally small use case

2. Often those same programmers somehow are completely fine using C++ or Rust

3. Even more often those same programmers deny the usefulness of IDEs just because they need those use cases once every 10 years or so, and keep using subpar tools

[Permik]

Bro hasn't been employed at any natsec-level project to even _try_ to suggest the first option.

[zbentley]

C’mon, why don’t you like the authorized secure development workflow? You know, the triple-nested RDP Rube Goldberg machine that connects you to a 15yo desktop environment running on a Pentium III over a dial-up link to the moon (that can only run the IDE that time forgot, most of whose non-obsolete features don’t work because of the eighteen competing antimalware services running).

It’s ATO’d and everything, and it works for all the other contractors. They have no trouble shipping on time, give or take a decade or so; what’s your problem?

[zbentley]

While I don’t agree, I do think there’s merit to the arguments you made (edit remotely, change a line and forget about it). Many anti-IDE arguments boil down to “I like a particular workflow and want to generalize it to all contexts” which is weak (you made the choice, you do the work to integrate e.g. Maven dependency awareness with your hyper customized vim environment or whatever).

However, I don’t think your arguments are sufficient to outweigh the benefits that can be obtained by making a language platform with features that assume the presence of IDE support.

Either way, I’m just one person, so you do you.

[deepsun]

In large codebases the main problem with imports is "where that thing comes from" -- you really want explicit imports. Especially if something broke in build and you're not sure you have correct versions of dependencies (what dependency that name came from).

In small codebases anything would work.

PS: why do you even look at imports? Any decent editor just hides it, you never need it, you navigate just by clicking/hotkeys on names directly from code.

[bob1029]

> C# and Nim love that style, and it makes them almost unreadable without a good IDE.

I think a lot of what turns people off to the C# developer experience is not using full-blown Visual Studio. VSCode is great but I would never open csproj or sln files using it unless I needed to manually edit their actual XML contents.

It's not broadly advertised that you can buy a perpetual & fully licensed copy for $500 [0]. No subscription or other cloudy scam stuff is required, although Microsoft's product pages will initially lead you to believe it is.

[0] https://www.microsoft.com/en-us/d/visual-studio-professional...

[spixy]

There is Jetbrains Rider.

[mdaniel]

Now available to even more audiences than before https://www.jetbrains.com/rider/#:~:text=free%20for%20non-co...

[samus]

AFAIK it's mostly intended to make writing single source file programs easier.

[dionian]

so module imports looks to be different from normal imports and actually helps reduce the number of imports the developer needs to write. FWIW Scala (which runs on java) does have import renaming and also type aliases which can do what you mentioned.

[keltex]

C# supports the "using alias" like this:

  using Project = PC.MyCompany.Project;

https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...