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

131–140 of 143 posts

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

#131

Post by e2e4 »

I found the following interesting

""" As a postscript, I’ve heard several stories about people who leave Google or Facebook and have a hard doing being productive at the next place. Both of those companies have planetary-scaled systems and the amazing tools to handle that. The next place doesn’t have those tools, and suddenly you have to know how to do things at much lower levels. If you never learned those levels, you are practically starting over and your previous experience isn’t that important. Their tools do their things, not general things, and certainly not someone else’s things. """

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

#132

Post by EdwardDiego »

xupybd wrote: post #108
EdwardDiego wrote: post #102

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.

I use Intellij and it really does its level best to bring code insight to dynamic languages.

But I fully agree wrt types. Even if I'm not using an IDE, types, or type hints a la Python, help me understand what's going on far better.

I once heavily refactored a hand-rolled build tool written entirely in Python that read and write JSON. Everyone was terrified of touching it.

Introducing Pydantic to replace dicts of dicts of dicts with dicts of App instances that had Environments immediately made the code far easier to understand.

Then introducing type annotations and mypy completed the transition of a business critical tool from one everyone previously approached in what I called a "special forces" manner (get in, achieve your very narrow goal, get out before anyone notices you) to something where code flow was easily understandable.

Immediately, the tool received a lot of attention and refactoring. Something like 20% of it was dead code, amd there was some functionality that, had it been used, would've corrupted the build state or just flat out died.

And it was simply adding types that made this obvious, and made the code accessible to people who wanted to refactor it fearlessly.

(Unit tests were entirely absent, but without the understanding of the code that types brought, how would you even start?)

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

#133

Post by rektide »

kcb wrote: post #60
rektide wrote: post #58

Earlier quoted context omitted.

I want to improve & grow, get better at computing. This idea of being good enough, embracing mediocre capabilities for life & only focusing on shirt term output forever is exactly the local minima this post is warning against. Selling yourself a compromised future, being a passive consumer of technology, is anathema to the greater objectives of life & computing, in my view. Selling yourself on comprimise, swearing yo…

We build on the shoulders of giants and there's nothing wrong with that. The terminal is just one abstraction down of an abstraction of an abstraction of an abstraction of an abstraction of an abstraction. Not very impressive.

Linux disagrees with you. A process is a core thing to the OS, not just "another abstraction". The terminal is an extremely shallow/direct interface to the OS, in a way distinctly more clear & certain than most other abstractions.

There's no better way to see real truth in computing. The shell exposes the base truths of the OS abstraction directly: processes, environment variables, stdio, signals, pipes. This is the fundamental toolkit of computing, and what higher-level abstractions we see (from language's stdlibs, to things like Kafka or SQS queues) are better understood in terms of the base computing fundamentals. The base unix tools define a clear set of capabilities we should be familiar with, & to call them just another abstraction, to focus on our own local platforms, ignores the base root that all computing so far eminates from.

This abstraction-relativism you present is highly dangerous. Arguing we shouldn't care about anything because there are abstractions everywhere ignores a realer truth, that some abstractions have been around & underpin nearly all systems & likely will continue to do so. We're only barely starting to play around with alternative conceptions, in projects like Fuschia. But this is a rare, novel, & just-emerging break from our common frameworks of computing. One that would behoove people to gain some competency in.

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

#134

Post by fuzzythinker »

winrid wrote: post #123
kitd wrote: post #112

Earlier quoted context omitted.

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

The repo has zero documentation. Do you use it on client, node, or both? Does it renders the calls in a tree?

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

#135

Post by Aeolun »

native_samples wrote: post #128
Aeolun wrote: post #73

Earlier quoted context omitted.

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.

Huh. Nr 2 is applicable to me. Will give it a try. Can’t see how it’ll fix my permanent indexing, but maybe it’ll at least feel faster.

My heap size is already at 3GB, which I feel should be enough for opening a bunch of 5kb text files :/

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

#136

Post by croo »

jolux wrote: post #124
michaelsalim wrote: post #121

Earlier quoted context omitted.

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

Nitpick! You should always use the constant for the first part of an equality check so you won't get NPE if myobj is null: "string".equals(myobj);

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

#137

Post by [deleted] »

croo wrote: post #136
jolux wrote: post #124

Earlier quoted context omitted.

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

Nitpick! You should always use the constant for the first part of an equality check so you won't get NPE if myobj is null: "string".equals(myobj);

[deleted]

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

#138

Post by musingsole »

rendall wrote: post #96
musingsole wrote: post #93

Earlier quoted context omitted.

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

Alright, I can accept that. We're mostly describing the same thing, and it's a question of focusing on the silver lining -- golden nuggets -- over the rest of the thing, which could be seen as crap or could be seen as the casing of a gold nugget.

Given that framing, what expectation can there be that an automated platform like CoPilot can acquire the wisdom to recognize gold from dirt? I believe it may be a question of does the overlapping, correlated portions of code from the corpus of repos signal the gold or signal the common dirt encasing the gold?

I largely expect it's the latter, and that the trends copilot is likely to recognize and use as foundations for its suggestions are motivated from dirt. To accept them and to learn from them is to internalize a horse without a cart philosophy.

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

#139

Post by native_samples »

Aeolun wrote: post #135
native_samples wrote: post #128

Earlier quoted context omitted.

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.

Huh. Nr 2 is applicable to me. Will give it a try. Can’t see how it’ll fix my permanent indexing, but maybe it’ll at least feel faster. My heap size is already at 3GB, which I feel should be enough for opening a bunch of 5kb text files :/

If you're permanently indexing something is very wrong and that will indeed break your IDE. That's just a bug. Try wiping all your caches from the menus and see if that helps. Otherwise file a bug in YouTrack.

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

#140

Post by pvorb »

mrweasel wrote: post #95
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?

Not impossible, but very inefficient.
Post reply on HN