Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What do you really get from IDE-driven development?

briandfoy.github.io

Post reply on HN
Print view View original

81–90 of 143 posts

Re: What do you really get from IDE-driven development?

#81

Post by rendall »

seanmcdirmid wrote: post #79

Auto completion has always worked well as a way to discover methods, not as a way of writing code. It’s like…”so where can I go when I’m here?” without having to pour over a bunch of API docs. No one ever presses the “I’m feeling lucky button” on the auto complete suggestions unless it’s an API they recognize. I get the feeling that co-pilot wasn’t really designed with usability in mind, more like it was just a cool…

> Auto completion has always worked well as a way to discover methods

I think that was exactly the criticism in the article, though, that discovery via IDE is limiting, and for many developers this method of discovery supercedes actually reading documentation. I'm not sure he's wrong.

Re: What do you really get from IDE-driven development?

#82

Post by userbinator »

pvorb wrote: post #2

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…

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.

Re: What do you really get from IDE-driven development?

#83

Post by userbinator »

thrower123 wrote: post #43
dmitriid wrote: post #25

All these anti-IDE rants strike me as coming from people who have never actually used an IDE beyond "oh it's an editor with an autocomplete".

They take pride in their masochism

It's called exercise. Plenty of people do a lot of physical exercise when they could be content to stay still, but it's good for health.

In this case, mental exercise keeps the brain healthy.

Re: What do you really get from IDE-driven development?

#84

Post by setr »

rendall wrote: post #81
seanmcdirmid wrote: post #79

Auto completion has always worked well as a way to discover methods, not as a way of writing code. It’s like…”so where can I go when I’m here?” without having to pour over a bunch of API docs. No one ever presses the “I’m feeling lucky button” on the auto complete suggestions unless it’s an API they recognize. I get the feeling that co-pilot wasn’t really designed with usability in mind, more like it was just a cool…

> Auto completion has always worked well as a way to discover methods I think that was exactly the criticism in the article, though, that discovery via IDE is limiting, and for many developers this method of discovery supercedes actually reading documentation. I'm not sure he's wrong.

Just from a visual efficiency measure, it’s a good steeping stone between discovery and actual docs, especially if the autocomplete also includes the first bit of description - most functions of an API are quite obvious, and ideally aren’t doing anything surprising in them anyways that the name + minidisc would actually lead you astray.

Of course, a stepping stone , at the end of the day you still need to understand the core model and operations — but then you’re just dealing with age-old problem of RTFM; a problem that has existed long before autocomplete’s general availability, and long after. The only real change autocomplete brings in that regard is that people might accidentally read something while scanning a manual for the API calls… but that’s really never been good enough anyways, so it’s not much of a loss

Re: What do you really get from IDE-driven development?

#85

Post by greiskul »

userbinator wrote: post #82
pvorb wrote: post #2

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…

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 w…

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

Re: What do you really get from IDE-driven development?

#86

Post by rendall »

I think the main point of the article, to question whether using an IDE actually improves our work, is valuable to at least ponder, if not just as a way to improve IDEs in future. As an aside, I don't think the author steal-manned his argument by using a few illustrative anecdotes, but he's not completely wrong, either.

My objection to the article is to the sentiment expressed:

> "But, a lot of code doesn’t matter because Sturgeon’s Law informs us that 90% of the code is crud. He was talking about science fiction, but it feels true of just about anything. All of that code learning is parroting the bad habits of the 90% crud."

I strive for empathy with my colleagues, and I have mostly* won the struggle against harshly judging the code that I read and maintain, and judging the people who wrote it. Judging code can be a terrible distraction that turns programming from a lovely, interesting and fun task into a grind.

Is it true that "90% of code is crud"? It is, if you want it to be. Or, perhaps we all as a community and a society are slowly learning how to program, and the best of the code written 5 years ago uses ways and means that we are abandoning. I think specifically of the movement away from Object Oriented programming toward immutability and Functional Programming, which is arguably an overall improvement. Also, the No Blame movement, which assumes that the engineer at the time is making a smart decision given all of the constraints. But we're not done, and the code of today will look quaint in 5, 10, 20 years.

It helps me to have "warrior mind", which I interpret to mean that completing a programming task is a mission, and I can feel upset about the circumstances, or I can put all of that aside and help complete the mission (or fail to complete the mission, which happens), without ego or drama.

So, I would say, "90% of code is crud" belies an attitude that would benefit from correction. All code contains a lesson.

Re: What do you really get from IDE-driven development?

#87

Post by greiskul »

RcouF1uZ4gsC wrote: post #38

> 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. This post reminded me of the story of Mel. http://catb.org/jargon/html/story-of-mel.html So Mel, not only did not use IDEs, he did not use compilers, or even an assembler because they got in his way of deep knowledge of the instruction set of the computer…

And Mel is a great story, but it is also misses that engineering is about tradeoffs. And in many, many programs, space and time efficiency is actually way, way less important than maintainability, extensibility, etc. There will always be the cases where deep knowledge of the fundamentals of computers and computer science will make or break a program. But for a large part of most programs, premature optimization is still the root of all evil.

Re: What do you really get from IDE-driven development?

#89

Post by jolux »

voidhorse wrote: post #70
jolux wrote: post #9

This is an argument against programming by autocomplete, not an argument against programming with IDEs. IDEs make this method of programming possible , but they don't make it mandatory. The primary thing I use autocomplete for is to insert method calls that I already know that I want. Secondarily I use it like a documentation browser to read the documentation for every function that I could call if I'm trying to figu…

Agreed. I don’t think programming with autocomplete is even a problem so much as learning to program with autocomplete is a problem. I think everyone should start out with a barebones text editor to get used to thinking things through and not relying on advanced IDE features as crutches.

I mostly agree. It's a little hard for me to remember how I started because I'm almost fully self-taught and I never restricted myself like that. I think it's best to start people off with a friendly and helpful but minimal environment. Scratch is good for younger kids and is what I started with, and DrRacket is close to ideal for anyone older than maybe 10.

Re: What do you really get from IDE-driven development?

#90

Post by chrischen »

voidhorse wrote: post #70
jolux wrote: post #9

This is an argument against programming by autocomplete, not an argument against programming with IDEs. IDEs make this method of programming possible , but they don't make it mandatory. The primary thing I use autocomplete for is to insert method calls that I already know that I want. Secondarily I use it like a documentation browser to read the documentation for every function that I could call if I'm trying to figu…

Agreed. I don’t think programming with autocomplete is even a problem so much as learning to program with autocomplete is a problem. I think everyone should start out with a barebones text editor to get used to thinking things through and not relying on advanced IDE features as crutches.

I use Ocaml and the type system and language server basically remove the need for things like a debugger, or even run-time testing while developing, that you might need in some other language. It tells you type of every function, variable, etc. While it's not needed, the language server works in tandem with the type system to basically tell you exactly what's happening in your code.
Post reply on HN