Live data from Hacker News

What do you really get from IDE-driven development?

briandfoy.github.io

111–120 of 143 posts

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

#111

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…

Indeed. My attitude is that people should use tools that work for them but without compromising on code quality, productivity, or impacting other team members with their tool choices.

The latter is a big caveat when working on Kotlin/Java code bases because standards are high regarding things like code formatting, style, etc. People will notice when you skip some of the things Intellij does. The few cases I've seen of people not using the right tools for the job, they thought they were doing a great job. And then I did a code review and showed them how bad it was because clearly they were blissfully unaware of warnings, had never run a static code analyzer, were clearly not refactoring their code base, and were generally doing a lot of things that were bordering on "probably wrong; definitely not optimal".

IDEs provide several big buckets of essential functionality:

- Code criticism: warnings, static analysis, deprecations, dead code, etc. You can use external tools to stay on top of this as well. But having mistakes pointed out to you as you are making them saves a lot of time. Also, since these are preventable problems, there is zero excuse for having any of them. So, whatever you use, make sure you stay on top of this. If this is tedious, consider using better tools or fixing the ones you have.

- Intelligence and situational awareness: Syntax coloring, code navigation & documentation, find uses of, etc. When stuff doesn't work, this is a real time saver. Bottom line here is that there are things that you need to know how to find out about your code. If you can script things together using grep and other command line tools; great. As long as you are productive. But you have no excuse for ignorance.

- Automatic program transformations: This goes way beyond refactoring (which is also useful of course and for which renames are merely the simplest example) and also includes things like using quick fixes for common problems, automatically applying replacements for deprecated functions, adding all the missing branches to a when statement, managing lists of imports, converting between different syntax alternatives for the same thing (e.g. convert between when and if, invert an if, ...), etc. For languages like Kotlin and Java, there are hundreds of these and they are super useful. I use them all the time. Use them or don't use them. But you should not allow your tool choices to impact your code quality. So, if it needs refactoring, do it. Do it manually if you must. But you don't get to skip it. Edit your imports like a caveman if you must, but make sure you do it properly (no wildcards, sorted correctly, remove unused imports, etc.).

- Tool integration: Build tools, debuggers, de-compilers, code formatters/linters, etc. Nice to have that at your finger tips. If you do this via the command line, be my guest. But make sure you know how to use your tools and that you do use the tools that are available to you.

On projects I manage, I'll judge people on their code quality, not on how they produce their code. But I'm a harsh judge when it comes to that. Do it whatever way pleases you but do it right. And with some editors, that just means performing a lot of manual labor.

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

#112
post #65
post #61

Earlier quoted context omitted.

I think a lot of people's views have been influenced by their use of languages where the type system or overall language framework is either too weak (eg: Python, Javascript) or in some cases too complex (eg: C++) for more than a thin layer IDE experience to be possible. If you use those kind of languages then it's true, IDEs buy you a limited set of functionality and you don't need much more than a basic language se…

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.

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

#113
post #108

Earlier quoted context omitted.

Well, what's the old saying - nothing can parse Perl, but Perl? As for JS and IDEs, you should try an IDE again. Far better.

Haha I've not heard that one. Perl is very much an unreadable code soup. I will have to try on next time I'm in plain JS. It doesn't happen often. I have a preference for strongly typed languages. I suspect I have something similar to dyslexia. I mix the spelling of words and sometimes even the words. Strong typing is the tool that makes that problem go away.

> Perl is very much an unreadable code soup.

It has been said that perl is the only language which looks the same both before and after RSA encryption.

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

#114
post #26
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 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…

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.

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

#115
post #91

Earlier quoted context omitted.

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.

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

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

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

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.

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

#117

Earlier quoted context omitted.

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.

It's called working smart, not working hard.

I would absolutely fire someone who refused to use the mechanized tree harvester I provided and insisted on felling trees with an axe, and that's about where I stand with respect to insisting on using PDP-10 era text editors over an IDE.

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

#118
All these suggestions and options are total distractions to me trying to get work done. It impacts the ability to get work done. I go with the mantra if you’re trying to code your way to a solution then you’re going about it wrong. Write down what you’re trying to do in a few sentences first. If you can’t then how can you code something? This is why code structure suggestions make no sense to me.

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

#119
post #81

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.

Maybe it's limiting but in practice are you going to read up about the hundreds or thousands of symbols exported by every library you're using in a project? There's only so much time you can spend reading documentation (when it exists) or books.

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

#120
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.

They're working on a new, faster underlying architecture with an IDE called Fleet. It looks like it may be a long-term foundational replacement for their other IDEs including PhpStorm.

https://www.jetbrains.com/fleet/

Post reply on HN