Comment by skydhash
1 day ago
The things is that languages that need intellisense that much are language that made it too easy to construct complex systems. For lisp and C, you can get autocompletion for free, and indexing to offer docs preview and signature can be done quite easily as well. There's also an incentive to keep things short and small.
Then you have Java and C# where you need a whole IDE if you're writing more than 10 lines. Because using anything brings the whole jungle with it.
Hmm, I think all languages, regardless of verbosity, could be better with IntelliSense. I mean, if the IDE can reliably predict what you intend to type based on the context, regardless of the complexity of the application involved, why not have it?
Seems like languages like Java and C# that encourage more complexity just aim to provide richer context to mine. Simple example, given an incomplete line like "TypeA foo = bar.", the IDE can very easily figure out you want "bar.getBlah(baz)" because getBlah has a return type of "TypeA" and "baz" is the only variable available in the scope. But to have all that context at that point requires a whole bunch of setup beforehand, like a fine-grained types supported by a rich type system and function signatures and so on, which incentivizes verbosity that usually scales with the complexity of the app.
So yes, that's a lot of verbosity, but also a lot of context. To your point, I feel like the philosophy of languages like Java and C# is deliberately based on providing enough context for sophisticated tooling like IntelliSense and IntelliJ.
Unfortunately, the languages came before such sophisticated tooling existed, and when good tools did exist they were expensive, and even with those tools now being widely and freely availble, many people still don't use them. (Plus, in retrospect, the language designs themselves genuinely turned out to be more complex than ideal in some aspects.)
So the current reputation of these languages encouraging undue complexity is probably due to their philosophies being grounded in sound reasoning but based on predictions that didn't quite pan out as expected.
The thing is we did have nice tooling before those languages came to be. If you look at Smalltalk, it has this type of context in an even more powerful way. You can browse the whole library in a few click and view its code. And it has a Playground element where you can try and design stuff. And everything was inspectable.
Same with Lisp. If you take emacs has an example, you have instant documentation on every functions. Another example can be python where there’s an help system embedded into the language.
Java is basically unwritable without a full indexer and completion. But it has a lot of guardrails and its verbosity discourages deviation.
And today we have Swift and kotlin which is barely better. They do a lot of magic behind the scene to reduce verbosity, but you’re still reliant on the indexer which is now coupled with a compiler for the magic stuff.
Better languages insists on documentation, contextual help, shorter programs, no magic unless created by the programmer, and visibility (inspection with a debugger and traceability with the system source available, if possible).