James BennettDoing a twist on the meme that's going around:
One favorite on this post = one hot (or at least lukewarm) take on tech.
ORMs are fine, actually. Manually querying and transforming DB data to/from your application's data structures is tedious and error-prone and you can skip it.
The pursuit of "testable" code has diminishing returns, especially as all the decomposition and extra layers of abstraction/indirection make the code harder to understand.
The primary utility of static typing is not in automated correctness checks, it's in forcing you to write *something* resembling documentation for how to use your code.
A lot of tech that comes from huge companies is like birds on remote islands: highly evolved for an ultra-specialized niche, and won’t do so well when transplanted somewhere else.
Instead of doing "Agile", read Fred Brooks and implement his recommendations for how to build software and manage software projects.
His advice is concrete, actionable, and correct, and "Agile" misses on at least two of those adjectives.
Test coverage is useful. Not as a target, but as a warning sign: if it suddenly *drops*, that's a reliable sign something has gone wrong.
Object-Oriented Programming is good, actually. Having a *thing* that carries both some data and the logic to work with it is a really useful idea and a lot of allegedly non-OOP languages adopted it anyway and pretended they didn't.
The "function color" problem is a tradeoff, and what you get in exchange is increased ability to reason about what might happen. I find this a strong enough benefit to outweigh the "color" issue.
Jonathan Yu@ubernostrum Is this referring to Bob Nystrom's post? I'm not sure the tradeoff here, and maybe it's different based on runtime/language. Synchronous code definitely seems easier to reason about, but can result in worse performance and bottlenecks in concurrency (if it's a fixed-size thread pool.) Things like await and virtual threads help, so you can write asynchronous code but get async-like performance
@jawnsy The issue is that async/await approaches are always dismissed with "now you have a function coloring problem!" and/or a link to the post.
In other words, regardless of authorial intent, other people use the post as a way to argue: "if you do async/await, you have a problem; if you do threads -- whether they're "real" threads or green/virtual/etc. -- you don't have the problem; therefore you shouldn't do async/await and you should do threads".
But when you do threads you most certainly DO have problems. You have monstrously difficult problems that people go and invent things like Rust to try to solve.
The actual trade-off of async/await is that, yes, you have two "colors" of functions with, generally, different calling conventions, but in return for that all the functions in your codebase, and all the places in those functions, which might suspend and resume execution are syntactically marked, making it easy to find them and easier -- compared to any form of threading -- to reason about program execution.