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

91–100 of 143 posts

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

#91

Post by pvorb »

UglyToad wrote: post #46
morvita wrote: post #26

Earlier quoted context omitted.

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

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…

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

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

#92

Post by pvorb »

zem wrote: post #5
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…

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

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.

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

#93

Post by musingsole »

rendall wrote: post #86

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

> Is it true that "90% of code is crud"? It is, if you want it to be.

You're being way too generous from a false sense of compassion. Most code is not written from a place of serene comprehension. It's written under the pressure of getting features out the door fast enough to justify a paycheck.

Add in that programming is a task that is rapidly changing over time -- so what's good today, is a naive implementation tomorrow...yeah, practically all code ever produced or ever to be produced will be crap from any reasonable perspective.

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

#94

Post by theshrike79 »

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.

I use multiple languages every day. I can't be arsed to memorize whether the length of an array in this language was .length or .size or something else. And IDE helps me with that.

If myArray.l... doesn't autocomplete, I'll try with myArray.s... Compared to opening a browser and browsing through the language API docs it's exponentially faster.

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

#95

Post by mrweasel »

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.

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

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

#96

Post by rendall »

musingsole wrote: post #93
rendall wrote: post #86

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

> Is it true that "90% of code is crud"? It is, if you want it to be. You're being way too generous from a false sense of compassion. Most code is not written from a place of serene comprehension. It's written under the pressure of getting features out the door fast enough to justify a paycheck. Add in that programming is a task that is rapidly changing over time -- so what's good today, is a naive implementation tom…

Kind of my main point, I just choose not to think of it as "crap", but as the best expression of the coder's intent given the all the constraints at the time it was written, including deadline pressure, context, experience. Try it out. Now instead of "wading through crap" you can think of it as "sifting for nuggets of wisdom". Or whatever you like.

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

#97

Post by gordaco »

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…

Yeah. Autocomplete is about the least useful function of an IDE. The real killer features IMHO are the automatic refactoring tools (method renaming, addition of function arguments, etc) and, in languages that support it, the continuous build that points out errors and warnings as you type them. Code navigation features (go to definition, find every place where this function is called, open file by class name...) are also huge time savers. Autocomplete has its uses but ultimately it's not such a big deal. 99% of the time I use it, I already know what I want to write, and I just use it when I don't remember exactly the order of some function arguments or something like that.

EDIT: I'd like to add that the real speed comes when you have lots of keyboard commands ingrained in your muscle memory. There is a learning curve and it takes some time, but when you're comfortable with mapping certain very high level operations to a combination of 2 or 3 keys, the increase in speed is tremendous. The downside is that changing IDEs becomes a bit painful, so you built some kind of dependence. But this is not what the article is about.

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

#98

Post by smaudet »

chrischen wrote: post #90
voidhorse wrote: post #70

Earlier quoted context omitted.

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.

Type systems are half of the equation, but what do you do when the algorithm is wrong? Type systems don't constrain you from writing incorrect solutions to the echo cancelation problem...you need real world data and runtime tooling for that. This is where IDE type tooling shines, nobody cares about the editor or the code in the end...

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

#99

Post by seanmcdirmid »

setr wrote: post #84
rendall wrote: post #81

Earlier quoted context omitted.

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

Auto completion also has the perverse effect of APIs developers relying on its existence to build large APIs that would be hard to use without autocomplete. I once counted 232 methods for a UI button in Java available through the auto complete menu. There is just no way to use that API by RTFMing, but with auto complete, you can just search for what you need as you need it.

Alot do the reason Java is the way it is is probably because auto completion gained in popularity at the same time it did.

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

#100

Post by raducu »

gordaco wrote: post #97
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…

Yeah. Autocomplete is about the least useful function of an IDE. The real killer features IMHO are the automatic refactoring tools (method renaming, addition of function arguments, etc) and, in languages that support it, the continuous build that points out errors and warnings as you type them. Code navigation features (go to definition, find every place where this function is called, open file by class name...) are…

I have ADHD and have terrible memory for names. I'm not even using autocomplete that much, but the navigation in IDE really helps.... or hinders me from learning class/method names.

I have a very wiered and convoluted style of search and navigation, all to avoid remembering names, people who see me coding are really stunded by the way I navigate code.

The upside is I do really well with new languages/projects, unless we are talking millions of lines of code and hundreds of modules, then I begin to struggle again.

Post reply on HN