Formatting code should be unnecessary • Hacker News Board

Re: Formatting code should be unnecessary

#481

Post by _ea1k » Tue, Sep 09, 2025, 10:22 PM UTC

kolme wrote: post #338

automatoney wrote: post #50

I've never understood why people care so much about the linter settings. It's so obviously bikeshedding, just make a choice, run the linter automatically and be done with it. I'm too busy doing actual software engineering to care about where exactly everything goes - I promise after a week you'll just get used to whatever format your team lands on.

I did that when I was young and naive. I'll tell you why I did it. I thought I was very smart. Like, really really smart, maybe the smartest programmer in the team. And as such my opinion was very important. Maybe the most important opinion in the team. Everyone had to listen to it! That is all. Also, I was wrong.

I feel like a _lot_ of us have been through this cycle. It is so easy to think we've discovered the one true way to do something.

Time and experience often tell us that it was just one of many, and maybe not even the best one of many.

Re: Formatting code should be unnecessary

#482

Post by AdieuToLogic » Tue, Sep 09, 2025, 10:47 PM UTC

_mu wrote: post #386

stavros wrote: post #123

Earlier quoted context omitted.

Right, but it's obvious they meant "formatter".

Why build understanding when you could be pedantic?

> Why build understanding when you could be pedantic?

Why try to share knowledge and give people an opportunity to learn the difference between two distinct concepts when they may not be aware of same?

Is that pedantry or an attempt to "build understanding"?

Re: Formatting code should be unnecessary

#483

Post by sirwhinesalot » Wed, Sep 10, 2025, 7:23 AM UTC

igouy wrote: post #479

sirwhinesalot wrote: post #439

Earlier quoted context omitted.

Indeed, putting related code together in the same source file is one of the ways we cope with complexity. Though it too breaks down, because the relations between various bits of code may be so complex that there's no good way to "linearize" them. And you should be documenting your code, but documentation comments take up space on the screen since they are linearly arranged in the same file, so you see less functions…

> we should be able to do better than text files https://gtoolkit.com/ ?

Glamorous Toolkit is a lot more inline with what I'm thinking, being all about custom visualizations, but it's actually one level below where the tooling I want should be.

The issue with Moldable Development is that it adds a substantial additional cost in development time that is then hopefully paid back with much improved debugging and analytics.

That's a tough sell. The sort of tools you see in other engineering domains have tons of custom visualizations and such already built in, for all sorts of domains, even ultra niche ones (like battery design). That's why they can charge so much. Since all that stuff is just there ready to use, the cost is 0 (in effort, they cost a lot of money).

Because GT needs to adapt to all the insane sorts of existing use cases and programming languages, it can't possibly implement all visualizations itself (nor even know what those visualizations should be like).

What I'm thinking of is one level higher, where the entire development experience for a particular domain (which could be very broad) is entirely designed from the ground up with visualization in mind. Enso Analytics is a pretty good example.

GT could be used to build something like that, but is not itself that.

Re: Formatting code should be unnecessary

#484

Post by einpoklum » Wed, Sep 10, 2025, 1:50 PM UTC

Moomoomoo309 wrote: post #286

DonHopkins wrote: post #267

Earlier quoted context omitted.

You're missing what the bike shedding metaphor is about. It's not about having bike sheds or not, it's about coloring bike sheds, which every day bike riders in their right mind really don't give a shit about, because it doesn't affect their life in any tangible way.

No, the original metaphor is they were planning to build a nuclear reactor and they spent significantly more time than expected on the details of the bike shed because it was simple to understand and change, unlike the details of the reactor which were complex and required expertise and had lots of constraints. Who cares what color the bike shed is, we're building a nuclear reactor here!

Indeed, that's the original metaphor. The thing is, we are not building a nuclear reactor here, we're building a bike transport system. :-\