Live data from Hacker News

Software development topics I've changed my mind on

chriskiehl.com

281–290 of 788 posts

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

#281
post #85

Earlier quoted context omitted.

Yep. And the laptop excuse is not even valid, I used a 11" MacBook Air for 10 years and even back then 80 always felt extremely limiting for me. I just tested and: even when zooming +1 on VSCode and leaving the minimap open I can fit 140 chars without any horizontal scroll. People demanding 80 columns always have some crazy setups, like an IDE where the editor is just a minuscule square in the centre, like an Osbourn…

And 140 chars aren't enough for two files side by side with 80 chars. With a readable font size and a narrow font about 90 chars is a good limit on a 14" laptop screen. Coincidentally that same limit then allows for three files side by side on the average desktop screen - or a browser window at the side for reference. If you can live with a single file on screen that's great, but the utility of two is far greater tha…

If you do important work frequently on 14" screen and 2 files side-by-side (regardless of its resolution), then you are seriously self-limiting yourself and your efficiency, plus hurting your eyes which will inevitably bring regrets later. That's not how 'love for the craft' or ie efficiency looks like.

One reason I like longer lines, in those very few cases (way less than 1% of code lines) - it bundles logically several easy-to-read things, ie more complex 'if' or larger constructors. We talk about Java here just to be clear, for more compact languages those numbers can get lower significantly but same principles apply.

Doing overly smart complex one-liners just for the sake of it goes completely against what we write here, I've seen only (otherwise smart) juniors do those. Harder to debug, harder to read, simply a junior show-off move.

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

#282
post #151

Just personal opinions, I guess, I agree with most, but here are some I disagree with: - There is no pride in managing or understanding complexity Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity. - Java is a great language because it's boring That is if you write Java the boring way. A lot of Java code (looking at you…

> - There is no pride in managing or understanding complexity

> Complexity exists, you can't make it go away, managing it and understanding it is the only thing you can do. Simple systems only displace complexity.

I interpreted that one as a suggestion to avoid welcoming needless complexity because of the false sense of pride it gives you to successfully manage that complexity.

To give an example, I believe C++'s enduring popularity is mostly because of exactly this false sense of pride. You practically need a doctorate-level understanding of the language to use most of its features without stepping on the dozen landmines the language places in your way (I'm so smart because I: remembered to declare my destructors virtual and understand why; can interpret this 2MB of template errors in the compiler output; can """cleverly""" use operator overloads). It can feel nice to be a master of such a complex tool, but that's a false sense of pride. The complexity of your tooling is not the point; the end product is.

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

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

Yep, don’t change the function signature of depended on code. That’s the problem :)

It would be equally problematic to change the method name, or the argument arity or types (ignoring overloading for the moment).

It would be even more problematic if I kept the same function signature, but changed the meaning of the parameters. Then your breakage is silent.

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

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

No, focusing on code style is weird. It’s tablestakes it should be uniform in style and legible. Automate styling to vanilla defaults. Leave it.

It’s like obsessing over the font on the packaging of the marker you use to write to the whiteboard in a math seminar.

Now, weird is beautiful but it’s not usefull and mostly irritating in a professinal context.

Cherish your weirdness and celebrate when you can find people of same persuasion. But don’t bother your colleagues with it.

I’m saying this as a person with very deep weird personal interests as several here do - and I’ve learned this slowly and painfully.

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

#285
post #106

Earlier quoted context omitted.

I've been loving edgedb in my typescript side projects for a number of years now. I have always hated ORMs, mostly for performance and a little bit for elegance / ergonomics. Curious if you have thoughts on a solution like that?

I like EdgeDB. The only downside I see is the lock-in, that is less of an issue with SQL. While I have not used EdgeDB, I have used Hasura, which I really liked. Wrt the syntax of queries, I know of https://prql-lang.org which is kind of similar of EdgeQL. Funny that EdgeDB says on its page it tries to solve the ORM problem: I strongly believe ORMs do not solve any problem, they merely create problems (as I argue in…

If you like GraphQL and are looking at databases, try Dgraph community edition some day.

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

#286

Earlier quoted context omitted.

The solution is to have computers enforce the code style. Pick a linter, pick a set of rules, and then forget about them. Things I beleive: - If you're picking up on code-style in PRs then your toolchain is backward. - If you're changing linting rules every month then you're focussed on the wrong things - It's better to have a consistent style than a perfect style

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.

*cough*clang-format off*cough*

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

#287

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

I'm kind of wondering where the "mixed experience levels" part comes from. What is it about more homogeneously skilled teams that makes them less susceptible to the productivity boost that statically typed languages give in large code bases?

IMO it's like scrum: if your team is good and homogeneous, it doesn't really matter much what you do: it just works. Scrum and no scrum, types and no types. It's not about having rockstars or 10x engineers, it's just about having shorthands, shared knowledge, etc.

If your team is varied or too large, you need things to help you out with organisation and communication.

(Whether my examples of Scrum and Types are the answer: depends on the team unfortunately)

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

#288
Functional programming does not prevent you from using objects

Stop listening to functional programming bros. Watch someone like Zoran Horvat. While I can't cosign all of his opinions, he tries to bridge the functional/OOP gap for OOP programmers. OOP programmers urgently need to distance themselves from this binary narrative. Everyone should understand functional programming and how they can utilize functional approaches in every language or paradigm. For me it is a requirement of understanding software development.

Absolutely every institution teaches OOP practices, they also need to teach functional practices. These aren't sports teams.

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

#289
post #68
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…

There's another way to look at this: if you consider the school of thought that says that the code is the design, and compilation is the construction process, then stressing over code style is equivalent to stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor), instead of stressing over load bearing, material costs and utility of the space. I'm fond of saying that anythi…

> stressing over the formatting and conventions of the blueprint (to use a civil engineering metaphor)

This is incredibly important.

This is the kind of stuff that prevents shit like half the team using metric and the other half thinking they're imperial, or you coming up with the perfect design, but then the manufacturer makes a mirrored version of it because you didn't have the conventions agreed upon.

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

#290

Earlier quoted context omitted.

IMO, gofmt doesn't go far enough. It should sort imports and break lines automatically, or you end up with different people with slightly different preferences for breaking up lines, leading to an inconsistent style. Something like gofumpt + golines + goimports makes more sense to me, but I'm used to ruff in Python (previous black + isort) and rustfmt. I'd say that if you're manually formatting stuff with line breaks…

Be careful what you wish for. Sometimes leaving a line stupidly long is better for readability than awkwardly trying to break it up. If you have five similar statements somewhere with only one exceeding the linter's line length, breaking up that one can lead to code that is harder to parse than just leaving it jutting out by way of an exception to the general rule; especially if it contains some predictable bit of co…

Those would be edge cases where formatting can be turned off if needed. This would require justification during code review. Otherwise, we'd keep the automatic format, with a strong tendency towards the latter.

The general benefit of automated formatting outweighs these edge cases.

Post reply on HN