[pvorb]

I'm not sure I buy his argument. I see many programmers who produce inferior code with an IDE and many programmers who produce excellent code with an IDE. I'm in the Java ecosystem, where IDEs are pretty much ubiquitous. But I've used plain editors in the past mostly for other languages.

All in all, I don't see the link between using an IDE or not and the quality of the outcome. But I do see the link between using an IDE and development speed, where refactoring is just so much faster and less error prone if you have a decent IDE.

I haven't tried copilot yet, so can't say much about it.

[morvita]

I actually ran up against this exact problem of IDEs being ubiquitous in the JVM ecosystem at a previous job.

The company had just released a new SDK to access a data repository. Since it was a brand new library, they only had Java/Scala versions, with plans to support other languages (JS, Python being the next two on their roadmap) in the few quarters. My team, primarily researchers who only knew Python, needed to use some of this data for a new project. I figured, what the hell, I've been looking for an excuse to learn some Scala, I'll see if I can throw together a utility for my team to use to get access to this data sooner. I fired up Sublime Text and opened up the docs for the SDK and got to work. The documentation was terrible and I really struggled to do basic tasks with this SDK. Simple things like what types were expected for function parameters was just non-existent. Since this SDK was planned to be released publicly to customers, I thought I'd do my co-workers a favour and sent them a message with some feedback about places where I particularly struggled with understanding how to use their SDK, thinking I could help improve the documentation before this went out to paying customers. Their response was that if I just used a proper IDE for my development, I wouldn't have these problems since the code completion/suggestions would let me know what the types of parameters were.

That experience completely soured me on the JVM ecosystem and I walked away from learning it. When I finally came back two years later, I discovered that I actually really like working in Scala (admittedly I do use Intellij for it now), but that many library's documentation is still quite poor compared to what I've come to expect for Python libraries.

[UglyToad]

So full disclosure, I don't tend to write or read documentation that is external to the in-IDE documentation.

But why is documenting the types helpful? The IDE, and for Java/JVM there's a choice of multiple, will tell you. Why waste precious hours of life rewriting what is already documented in the type system?

Sure I'd document the why of something but the idea types should have any form of documentation external to an IDE that can parse the language just seems... redundant.

Whenever I hop over the fence to dynamic languages sure I have to read documentation and large amounts of it is rubbish that could just be inferred from source but that's why I don't hop over there often.

[digisign]

Docs are typically built from source on modern platforms. There's not reason to restrict type information to a particular set of tools when you are bothering to build documentation. Otherwise might as well save your time.

[pvorb]

I think it just depends on how many users your library expects. When there's a huge user base, proper documentation pays off.

[watwut]

Rather, how many users not using Eclipse or Idea you expect. And in the context of java, the answer is "few outliers".

[watwut]

I mean, they have been 100% right. There is no point in writing down parameters types, because you see them in the IDE. That sort of docs is completely redundant.

[zem]

his argument is pretty specific:

8x--------------

He’s a really good programmer, but that’s not why his solutions were better. Since he didn’t have suggestions to guide him, he read the docs and by simply perusing them, was aware of methods and other features that the IDE did not suggest. There were better ways in the libraries they were using that weren’t apparent in the IDE. And that makes sense: in the interface for a suggestion in an editor, how much complexity can you really manage?

8x--------------

it makes sense to me - if the API is large and complex enough that you can discover good ways to do things via serendipity, IDE autosuggestions will stick you in a local maximum.

[conductr]

It’s not mutually exclusive though right? For instance, google search has auto complete/recommendation to nearly any query. I use that when helpful and know when to ignore it as well and type in my entire query. (Genuinely curious as I don’t use these IDE features.)

[zem]

no, not mutually exclusive, but the author had at least one anecdotal datapoint to suggest that people who relied on the IDE did not discover "unusual" functions that were better for the specific task

[sockpuppet69]

Is the 8x meant to be scissors?

8<———————

Looks nicer.

Never seen it before. Good idea. Gonna use it from now on instead of quotes or > on every line!

[tym0]

Wow you just made me realise why they picked that symbol for usage in git commit messages...

[zem]

yeah, it's a habit I picked up on usenet! useful for sites that manage quoted text awkwardly.

[rendall]

I usually format it this way. I like the scissors, though. Interesting.

> "He’s a really good programmer, but that’s not why his solutions were better. Since he didn’t have suggestions to guide him, he read the docs and by simply perusing them, was aware of methods and other features that the IDE did not suggest. There were better ways in the libraries they were using that weren’t apparent in the IDE. And that makes sense: in the interface for a suggestion in an editor, how much complexity can you really manage?"

[rendall]

I did find that argument compelling. I'm not sure if I will yet abandon my IDE, but it's a check in that column.

[pvorb]

I'm using an IDE, but I read the docs anyway. I also just jump into the implementation and figure if the docs are correct. I don't know why the IDE should prevent anyone to do that. Again, it doesn't depend so much on the tool but more on the type of programmer you are.

[userbinator]

I'm in the Java ecosystem, where IDEs are pretty much ubiquitous.

All in all, I don't see the link between using an IDE or not and the quality of the outcome.

That seems to be a pretty good link to me already...

I worked (briefly, fortunately) with Java for a short while a long time ago. The fact that even "small" Java projects are often ridiculously overengineered and so complex that an IDE is almost obligatory to work with the code in any meaningful way should itself be a sign of what dependence on IDEs tends to cause. The article mentions that too, and my experience agrees.

[pvorb]

So you're thinking less of Java in general. I won't argue on that, because neither of us will change their mind.

But the author was basically saying that you can write better Java in an editor than if you were using an IDE. And this doesn't make sense to me. The code a skilled programmer will write with or without an IDE won't be that different.

[greiskul]

Try working with Kotlin. Much saner language then Java, way less verbose, but with equally good IDE support.

[mrweasel]

> I'm in the Java ecosystem, where IDEs are pretty much ubiquitous.

Isn't that because dealing with the complexity of many modern Java frameworks and surrounding tooling is pretty much impossible without an IDE?

[pvorb]

Not impossible, but very inefficient.