Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

Post reply on HN
Print view View original

411–420 of 788 posts

Re: Software development topics I've changed my mind on

#411

Post by ge96 »

dtquad wrote: post #168

>Frontend development is a nightmare world of Kafkaesque awfulness I no longer enjoy As a backend/systems engineer I recently had to look at a React + Typescript + MobX app from 2019/2020. It is true that that some things, especially the webpack config and Typescript loading, were outdated but the overall design and architecture of the app was still understandable and modern. With some help from ChatGPT it took very…

I'll be the Steve Ballmer saying "I love JavaScript" but man it is great, I have made so many apps in different forms: web, deskop, mobile. If I needed to I can go into XCode and work on Swift. I have stuck with one stack though just ReactJS/NodeJS/ReactNative/ElectronJS or PWA. I prefer including SASS styles.

I still think TS is annoying to work with but I'm coming around since I have to use it at work and libraries like React Native are using it by default. Swift/C++ has typing but yeah, I like plain JS for speed development and typing can get annoying especially for a personal app.

Re: Software development topics I've changed my mind on

#412

Post by taeric »

Terr_ wrote: post #2

> Java is a great language because it's boring [...] Types are assertions we make about the world This is less of a mind-was-changed case and more just controversial, but... Checked Exceptions were a fundamentally good idea. They just needed some syntactic sugar to help redirect certain developers into less self-destructive ways of procrastinating on proper error handling. In brief for non-Java folks: Checked Excepti…

The problem with checked exceptions is they are best explained and utilized in a single threaded execution model where the exceptions can be bubbled up to the operator.

This is not, of course, the only way that checked exceptions can be utilized. But, all too often, that is by far the easiest way to reason on them. They represent a decision that needs to be bubbled up to the operator of the overall system.

Worse, the easy way to explain how the system should resume, is to go back to where the exception happened and to restart with some change in place. Disk was full, continue, but write to a new location. That is, having the entire stack unrolled means you wind up wanting the entire process reentrant. But that is an actively hostile way to work for most workflows. Imagine if, on finding a road was closed, a cab driver took you back to pick up location to ask what you want to do about it.

If it is not something that you want to unwind the stack, or bubble up to the users, then you go through effort to wrap it so that it is another value that is being processed.

Re: Software development topics I've changed my mind on

#413

Post by maxwell »

maleldil wrote: post #111
secondcoming wrote: post #54

Earlier quoted context omitted.

This is what we did with clang-format on our code base. The result is occasionally ugly code and nobody is 100% happy but at least it's consistent.

Gofmt's style is no one's favorite, yet gofmt is everyone's favorite.[1] [1] https://go-proverbs.github.io/

While everyone has a favorite ES Lint ruleset but few agree on which to use.

Re: Software development topics I've changed my mind on

#415

Post by daxfohl »

daxfohl wrote: post #403

Abstractions are a failure in most libraries too. Invariably something will come up that breaks the abstraction. Either new instances come up that don't quite match, or clients want new functionality that doesn't apply to all instances, or whatever. I've come to the conclusion that in almost all cases, you should avoid providing any abstraction from your own library / service, and let consumers figure out what abstra…

Half of my team's work right now is changing our abstractions because a couple clients want something slightly different, without breaking existing clients. The other half of my team's work is KLO forced on us by our dependencies needing to change their own abstractions.

> When you build the abstraction, it seems like you're doing your consumers a favor.

"The road to hell is paved with good intentions."

Re: Software development topics I've changed my mind on

#416

Post by 9rx »

devmor wrote: post #381
VyseofArcadia wrote: post #161

Earlier quoted context omitted.

Iterative work is THE way to work in large legacy codebases. The minute you wade into the code, all of your planning is moot. You don't know what's lurking below the surface. No one knows what's lurking under the surface. Except maybe Dave, because he vaguely remembers about 15 years back talking to some guy who wrote some code 30 years back about it. Greenfield, absolutely design up front you lucky devils, but itera…

As someone who's spent 12 years working on legacy codebases, I strongly disagree with this. Iterative work in a large legacy codebase is how you end up making your large legacy codebase larger and even less understood. Your planning should "wade into the code" from the start. I have always gotten better results by charting out flow diagrams and whiteboarding process changes than just "diving in and changing stuff". F…

> I have always gotten better results by charting out flow diagrams and whiteboarding process changes than just "diving in and changing stuff".

In terms of a broad population, I am not sure there is a meaningful difference, though. You can iterate on your ideas on the whiteboard or you can iterate on your ideas in code, but the intent is the same. Either way you are going to throw it all away once you have settled on what should be the final iteration anyhow.

It just comes down to where you are most comfortable expressing your ideas. Some like the visuals of a diagram, others are more comfortable thinking in code, some prefer to write it out in plain English, and I'm sure others carry out the process in other ways. But at the end of the day it is all the same.

Re: Software development topics I've changed my mind on

#417

Post by bob1029 »

> It's very hard to beat decades of RDBMS research and improvements

This is further complicated by the fact that not all RDBMS engines are created equally.

It took me 2 decades to develop appreciation regarding why one would actually want to pay for something like SQL Server when options like SQLite and Postgres are free and easy to use.

Re: Software development topics I've changed my mind on

#418

Post by WesolyKubeczek »

latexr wrote: post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

People, though, tend to spiral down into the bikeshedding abyss. It’s one thing to stand your ground about a linting rule that has proven effective in combatting certain classes of errors that you encountered in the field. It’s another thing to make every discussion be about linting rules.

I cannot put it into words right, but you can see there’s usually a vibe. It will be different coming from an experienced developer knowing what they are talking about from lived experience, and from a clueless one who has seen shit but is hell bent on process and rules.

Re: Software development topics I've changed my mind on

#419

Post by marsovo »

bryanrasmussen wrote: post #53
latexr wrote: post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

as others note, most of this minutia can be automatically enforced. Anything that can be automated is not craft.

Heartily disagree. I have had to fight with others over automated formatting because it obscured intent or clarity. For example (C#) mandating `var`, mandating one and only one line of whitespace between lines of code, mandating the => syntax for single-line functions (instead of

Function(vars) { ... } )

I would say, when to use one or the other of each of those options is very much a craft.

Re: Software development topics I've changed my mind on

#420

Post by alternatex »

lijok wrote: post #153
latexr wrote: post #22

> Most won't care about the craft. Cherish the ones that do, meet the rest where they are > (…) > People who stress over code style, linting rules, or other minutia remain insane weirdos to me. Focus on more important things. What you call “stressing over minutiae” others might call “caring for the craft”. Revered artisans are precisely the ones who care for the details. “Stressing” is your value judgement, not neces…

Video game logic: Everyone worse than me is a noob. Everyone better than me has no life.

Today Steam gives us the option of verifying whether a certain player has no life. Only half joking.
Post reply on HN