Live data from Hacker News

What do you really get from IDE-driven development?

briandfoy.github.io

121–130 of 143 posts

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

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

I'm currently mentoring someone from scratch and they're using autocompletion a lot. Have mixed feelings about it to be honest. I'm not a big fan of tools like Copilot and it'll be really hard for someone to convince me of its value.

On one side, it's as you mentioned. If you randomly pick a "solution" and hope that it works, you won't understand why you use that specific solution. And sure enough, many times they'd use autocomplete and get a solution that doesn't really solve the problem.

One particular problem I remember was a type difference issue. They had a string and needed to compare it with a string in an object. Easy, just do something like myObj.myVar == "string" right? But autocomplete suggested myObj.equals("string") instead. This is java code. Then I had to explain why it didn't work as intended even though the code compiled.

But observing it more, I decided not to stop them from doing it for now. I think it can be useful for learning purposes especially at the start. It's not that great for understanding but it does help them familiarize with all the different syntax and possibilities.

At the end of the day, I don't think it's that much different from randomly copying solutions from stack overflow until one works.

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

#122
What you really get from IDE is higher productivity, based on a sample of few hundred people I've worked with. It won't make bad engineers good or vice versa, it would just make everyone more productive.

If I were hiring an engineer who claimed not to use IDE on principle, I would be very careful and maybe even suspicious: a craftsman who doesn't care about using best tools for the job, may have problems.

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

#123
post #112
post #65

Earlier quoted context omitted.

Actually, modern IDEs are super helpful with JS and Python, especially with type hints. I can export a function or class in a big JS project, go to any file, start typing the method name, and Webstorm will suggest the import. With JavaScript! Not as great as the Java integration but still pretty nice.

Completely agree. I recently had to work on an unfamiliar JS codebase. After initially pulling my hair out trying to understand what objects were being passed where, I decided to define some types and parameters using JSDoc . VsCode picked them up instantly and it was like coding with a language server after that.

Also recommend this to learn a new code base which will log every function call:

https://www.npmjs.com/package/@phenomnomnominal/debug

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

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

I'm currently mentoring someone from scratch and they're using autocompletion a lot. Have mixed feelings about it to be honest. I'm not a big fan of tools like Copilot and it'll be really hard for someone to convince me of its value. On one side, it's as you mentioned. If you randomly pick a "solution" and hope that it works, you won't understand why you use that specific solution. And sure enough, many times they'd…

> One particular problem I remember was a type difference issue. They had a string and needed to compare it with a string in an object. Easy, just do something like myObj.myVar == "string" right? But autocomplete suggested myObj.equals("string") instead. This is java code. Then I had to explain why it didn't work as intended even though the code compiled.

Actually, you need to use `.equals()` for value equality on reference types in Java (like Strings). Using `==` will give you reference equality, which is almost never what you want. You probably wanted `myObj.myVar.equals("string")`

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

#125
Just because you’re using an IDE doesn’t mean your should read the documentation, and know what’s available, what’s in the latest versions and what’s coming up. The IDE is just a tool to make typing faster wherever that’s through code completion or refactoring tools.

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

#126

It seems like the author understands, or perhaps his criteria is based on, only a thin layer of what an IDE can provide. Here's the highlights: - Data flow to/from here (where did the value of this variable come from/go to) - Call hierarchy (up and down) - Class hierarchy (up and down) - Class structure (including all inherited fields, methods) - Checking your code against an actual database schema, perhaps one autom…

As a 30-year vi user who recently switched his C# programming to Rider over the summer of 2020, I'm a bit of an IDE convert now, for all of these kinds of reasons.

What really sold me on it is the ease of refactoring. Makes it easy to rearrange code and clarify names and things as you build the project up.

And then the code quality stuff taught me some things that I didn't know like the allocations that happen in C# with closures being passed to functions.

And then there's just the accuracy bits like greying out unreachable code which usually points out typos.

It also integrates well with the nullable checks in >C# 9.0

The IDE can teach you to be an expert and catch little gaps in your understanding of the language along making you a lot faster and doing a lot more in-editor, and letting you spend more mental effort on all the rest of software development.

Since C# is also object oriented, it also leads towards doing lots of boilerplate for interfaces and delegation which IDEs are pretty critical for (And I'd argue that Go's verbose error handling though also can benefit greatly from macros in an editor at least before anyone hops off this comment into an anti-OO rant).

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

#127
post #63
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…

> This is an argument against programming by autocomplete, not an argument against programming with IDEs. Exactly. IDEs fulfil an important function of removing repetitive and mundane tasks. The goal is to be you, the programmer, to know what you want to do and the tool, IDE, to make it happen as efficiently as possible. That can happen through parsing code, showing documentation, showing references, alerting to obvi…

There is an arrgument that the details matter a lot in code.

i mostly am familiar with network side of things, but little stuff like how you handle connection timeouts or retries, for example, make a really big difference to the overall quality of the system. Not thinking about a network call each time is setting up a system that will randomly fail in avoidable ways (excessive retries keeping a system from recoverying; excessive buffering in the face of latency; unbounded memory queues causing failure propagatin; having best effort code handle connect failure quickly but not have good rear time outs, etc)

The higher level problems often emerge from the exact nature of the lower levels.

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

#128
post #73

Earlier quoted context omitted.

I use PhpStorm by JetBrains and am totally blown away by how powerful it is. It does all of the GP’s list and way more.

Powerfull, but sloooow. I really want a faster Jetbrains IDE.

Usually when people have speed problems with Jetbrains IDEs it's one of two things:

1. Heap size is too small and it's GCing a lot without the user realizing. Open IDE VM options and double the -Xmx setting.

2. Using a 4k display on macOS. Try the new JBR17+Metal builds. They aren't shipped yet but switch it to using Metal to render. Makes it a lot faster.

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

#129
post #32

Earlier quoted context omitted.

One thing I've learned over 10 years of doing this is how much code is actually required to do anything, having more expressive language is one thing but tools that can help me cram out this stuff are also appreciated.

One thing I've learned over more than 10 years of doing this is how much code actually should be deleted instead of fixed. Thanks for giving me a reliable source of income ;)

The joke is that a new programmer is happiest when adding code and the senior programmer is happiest when removing code.

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

#130
post #63

Earlier quoted context omitted.

> This is an argument against programming by autocomplete, not an argument against programming with IDEs. Exactly. IDEs fulfil an important function of removing repetitive and mundane tasks. The goal is to be you, the programmer, to know what you want to do and the tool, IDE, to make it happen as efficiently as possible. That can happen through parsing code, showing documentation, showing references, alerting to obvi…

There is an arrgument that the details matter a lot in code. i mostly am familiar with network side of things, but little stuff like how you handle connection timeouts or retries, for example, make a really big difference to the overall quality of the system. Not thinking about a network call each time is setting up a system that will randomly fail in avoidable ways (excessive retries keeping a system from recoveryin…

> There is an arrgument that the details matter a lot in code.

The details of resulting code. Not the details of how exactly you wrote it.

Post reply on HN