Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

461–470 of 788 posts

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

#461
post #416
post #381

Earlier quoted context omitted.

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…

I have never really thought about it that way, but you're right.

Ultimately what matters is the final changeset. How you get there doesn't really matter.

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

#462
post #273

Earlier quoted context omitted.

I think that’s more of a problem of changing the function signature. Not specific to checked exceptions.

What's specific in checked exceptions is that if you don't handle or silently ignore the new exception, you must change the signature. Then your callers must do the same thing. Then their callers etc. sometimes right down to your public static void main.

And that is extremely good compared to the same function-writer adding or changing their non-checked exception, for which an 1+ levels removed consumer gets no warning at all until the pager goes off because the system broke in production.

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

#463

> Typed languages are essential on teams with mixed experience levels I like this one because it puts this endless dilemma in a human context. Most discussions are technical (static typing ease refactoring and safety, dynamic typing is easier to learn and better for interactive programming etc.) and ignore the users, the programmers.

Even when I am alone, I have "mixed experience levels", for example I can learn something niche, write some algorithm that works in that, then 2 years later I may have forgotten it. Types are essential for me.

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

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

I dont care about style as long as you can give me a document that specifies all the rules. It can be a simple text file, but don't expect me to remember them all from one convo.

At least with Python I just push everyone to follow PEP-8 makes it easier.

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

#465
post #375

For the most part, I agree with a lot of this, but there were a couple points I raised an eyebrow on. > There is no pride in managing or understanding complexity To the point that intentionally creating complexity or allowing it to continue to exist where it can be simplified, I agree - but some systems are necessarily complex and having pride in understanding and managing them is a good thing. If no one had pride in…

you don't need microservices to accomplish that - a library with a well designed public api and a language that lets you enforce private functions/methods are good enough,

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

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

>Revered artisans

This may point to the dividing line. Software is required to be functional, not simply "artistic". You can certainly make the argument that there are non-functional considerations in its construction: readability, maintainability, extensibility, etc. And, these absolutely intersect with style, so it's tempting to apply words like "artistry".

But, is there a point where details veer into personal preference and insistence on style for the sake of style? I think so, and many of us have seen this. For those who haven't yet, stick around!

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

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

I'm not a fan of checked exceptions because they force you to use a verbose control structure (try-catch) that distracts from the actual logic being expressed. Typically, checked exceptions are also not exceptional, so I prefer working with monadic exceptions, like Rust's Option/Result, because they encourage error recovery code to use normal control flow, keeping it consistent with the rest of the application.

I also find that generally exceptions can't be meaningfully caught until much higher in the call-stack. In which case, a lot of intermediary methods need to be annotated with a checked exception even though it's not something that matters to that particular method. For this reason, I've really come around on the Erlang way of doing things: throwing runtime exceptions in truly exceptional situations and designing top level code so that processes can simply fail then restart if necessary.

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

#468
post #462
post #273

Earlier quoted context omitted.

What's specific in checked exceptions is that if you don't handle or silently ignore the new exception, you must change the signature. Then your callers must do the same thing. Then their callers etc. sometimes right down to your public static void main.

And that is extremely good compared to the same function-writer adding or changing their non-checked exception, for which an 1+ levels removed consumer gets no warning at all until the pager goes off because the system broke in production.

Unless the library upgrade is also fixing a 9.9 CVE.

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

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

"Have you ever noticed that anybody driving slower than you is an idiot, and anyone going faster than you is a maniac?" -- George Carlin

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

#470
> ORMs are the devil in all languages and all implementations. Just write the damn SQL

My take on this would be: ORMs are the devil in all languages and all implementations. Static SQL queries with parameters will have a lot of duplication (lots of similar queries), whereas dynamically generating complex SQL will be hard to debug and maintain (e.g. myBatis). Write some good DB views in SQL. Generate some dumb ORM entities against those views for passable querying/filtering/pagination and do whatever works for altering it. Don’t go fully into the opposite direction either and don’t put 99% of your business logic into the DB, that will be hard to work with because the tooling isn’t very good (e.g. stored procedures).

Post reply on HN