←back to thread

Software development topics I've changed my mind on

(chriskiehl.com)
873 points belter | 4 comments | 05 Feb 25 09:50 UTC | HN request time: 0.001s | source
Show context
naasking ◴[05 Feb 25 14:16 UTC] No.42948752[source]▶
> You literally cannot add too many comments to test code (I challenge anyone to try)

I think it is possible, depending how you write them. If you write long comments interspersed with the code, you have a lot of scrolling to do follow the control-flow. Long block comments should go at the top to "set the stage", and then lightly interspersed comments throughout to remind of the specific steps, where necessary.

> Very few abstractions exist in general application development. Just write the code you need

I think they exist, but they're either not well known or are hard to engineer because of missing context; good abstractions are just hard. Solve the immediate problem and you'll maybe, eventually converge on the abstraction and you'll have your "aha!" moment.

replies(1): >>42949008 #
1. naasking ◴[05 Feb 25 14:36 UTC] No.42949008[source]▶
> ORMs are the devil in all languages and all implementations. Just write the damn SQL

I'm re-evaluating this again. I used to be all-in on ORMs, eventually became annoyed with the shortcomings and the performance problems, but am realizing the disadvantages of foregoing them as well.

* ORMs Bad: ORMs often lead to deep object graphs and tight coupling if you don't know what you're doing / don't factor the model properly. This has serious performance implications.

* ORMs Good: you get a unified, consistent view of all of your data on which you can enforce invariants in a holistic way.

* Only SQL Good: you can easily return and operate on only "slices" of the data, which is great for performance and rapidly iterating on features.

* Only SQL Bad: because you're only operating on "slices", you don't get a unified view of the data on which you can declare invariants. You can declare invariants on the slices and then stitch all of the properties together in your head to make sure you covered everything important (and write what tests you can to validate this), but this is error-prone and less necessary with ORMs.

So yeah, there's no single, clear winner here yet.

replies(1): >>42960516 #
2. Shorel ◴[06 Feb 25 09:05 UTC] No.42960516[source]▶
> enforce invariants in a holistic way

This sentence is golden, it advances the bullshit bingo score better than the rest.

But honestly, in SQL the invariants should be constraints and triggers, enforced by the DB, not just by the application layer.

replies(1): >>42962503 #
3. naasking ◴[06 Feb 25 14:15 UTC] No.42962503[source]▶
Constraints and triggers are more limited than the kinds of invariants you can enforce in code.
replies(1): >>42997067 #
4. Shorel ◴[10 Feb 25 04:54 UTC] No.42997067{3}[source]▶
Only by convention. You can write anything in a PL/SQL function, and that function can be called in a trigger.

Really, I can't imagine anything that can't be put in a trigger.