291–300 of 375 posts
Earlier quoted context omitted.
The issue with not having a single source of truth is not the fact that you have to update code in 2-3 places, it’s that you have to know to update code in 2-3 places. Accidental divergence is the problem, not intentional.
Seems like this is a problem almost entirely solved by llm+vector database setup.
I believe that "single source of truth" is a principle that should always be followed. If there's duplicated code where it'd be a bug if they diverge, then you should refactor. It creates a long-distance coupling in your code that may be invisible to future developers until a bug emerges. But with that in mind, I mostly agree with the article: if it's not a violation of "single source of truth", then abstractions are…
Of course, in theory this is true. In practice people tend to avoid ANY duplication no matter what. Especially junior developers, as if duplication would be the root of all evil.
Earlier quoted context omitted.
Again, this is the opposite of what the author argues for, which is waiting for a couple instances before committing to an abstraction. Not duplicating a SQL query across hundreds of places. I would be curious if the previous coders you're talking about actually cited duplication as a good thing. You seem to be implying they are. But almost every instance I've seen of massive code duplication was just from bad progra…
> Again, this is the opposite of what the author argues for, which is waiting for a couple instances before committing to an abstraction. Not duplicating a SQL query across hundreds of places. Right. But this is a hypothetical, in-a-vacuum situation. In the real world, your two, three duplicates are in production. "We really should now de-duplicate this" "There is not the time or budget, just copy it again; we'll rep…
Earlier quoted context omitted.
Of course, in theory this is true. In practice people tend to avoid ANY duplication no matter what. Especially junior developers, as if duplication would be the root of all evil.
This is something I've seen repeated time and time again as a criticism of (misused) abstraction and DRY, yet I've never seen ONCE -- and this is not hyperbole, I mean it literally -- a junior making an abstraction with any thought to reuse, generalizing anything, or caring about not repeating code. Most juniors I've worked with are content to just churn new code without paying attention to the codebase at all. This…
I've seen it occasionally. There was one junior whose code I saw littered with DTO that're an exact copy of the business object and DAOs where every method is just a wrapper for a Hibernate method. But yeah it's rare.
Earlier quoted context omitted.
Of course, in theory this is true. In practice people tend to avoid ANY duplication no matter what. Especially junior developers, as if duplication would be the root of all evil.
This is something I've seen repeated time and time again as a criticism of (misused) abstraction and DRY, yet I've never seen ONCE -- and this is not hyperbole, I mean it literally -- a junior making an abstraction with any thought to reuse, generalizing anything, or caring about not repeating code. Most juniors I've worked with are content to just churn new code without paying attention to the codebase at all. This…
Earlier quoted context omitted.
Again, this is the opposite of what the author argues for, which is waiting for a couple instances before committing to an abstraction. Not duplicating a SQL query across hundreds of places. I would be curious if the previous coders you're talking about actually cited duplication as a good thing. You seem to be implying they are. But almost every instance I've seen of massive code duplication was just from bad progra…
> Again, this is the opposite of what the author argues for, which is waiting for a couple instances before committing to an abstraction. Not duplicating a SQL query across hundreds of places. Right. But this is a hypothetical, in-a-vacuum situation. In the real world, your two, three duplicates are in production. "We really should now de-duplicate this" "There is not the time or budget, just copy it again; we'll rep…
Earlier quoted context omitted.
This is something I've seen repeated time and time again as a criticism of (misused) abstraction and DRY, yet I've never seen ONCE -- and this is not hyperbole, I mean it literally -- a junior making an abstraction with any thought to reuse, generalizing anything, or caring about not repeating code. Most juniors I've worked with are content to just churn new code without paying attention to the codebase at all. This…
In the early 2000s I often saw juniors and students make staggeringly deep class hierarchies. The equivalent of: Shape::Polygon::ConvexPolygon::FourSidedConvexPolygon::Square::BlueSquare... "Intro to OOP" lectures/articles made a deep impression on some people in not quite the right way :)
I used to struggle with abstractions back in my OOP days but since moving pretty much to a purely functional approach I find that code duplication is rare. Just have a function and call it in two parts. The main abstraction issue is then data structures but with TypeScript interfaces being duck typing essentially I run into few problems there as well. So code duplication because of abstraction issues is rare. Code du…
> but since moving pretty much to a purely functional approach
Earlier quoted context omitted.
> Mike's talk argues that code solutions need not be modelled on the real world, and that different data creates different problems, which need different solutions. I've always found it odd when even fairly smart engineers sometimes prioritize real-world metaphors over the actual needs of the codebase. Years ago when I was only a few years out of school, I was implementing a connection pool in Rust, and the most reas…
This is somewhat related: I mention this a lot, but in researching Data-Oriented Design (what Mike was talking about), I came across Richard Fabian's DoD book [1] which talks a lot about database normalization and the like. I found that odd, because the low-level high-performance game code he was talking about certainly wasn't going to marshal data into a DB to run SQL queries on it. It turns out the relational model…
> My big issue is that doing DB-like operations is hellish in most programming languages, and if you really want to try and marshal your data into a real DB (say, SQLite or DuckDB via a library), then you have a big messy translation layer where you're trying to match things to SQL types and you have giant SQL strings everywhere.
Earlier quoted context omitted.
> Mike's talk argues that code solutions need not be modelled on the real world, and that different data creates different problems, which need different solutions. I've always found it odd when even fairly smart engineers sometimes prioritize real-world metaphors over the actual needs of the codebase. Years ago when I was only a few years out of school, I was implementing a connection pool in Rust, and the most reas…
This is somewhat related: I mention this a lot, but in researching Data-Oriented Design (what Mike was talking about), I came across Richard Fabian's DoD book [1] which talks a lot about database normalization and the like. I found that odd, because the low-level high-performance game code he was talking about certainly wasn't going to marshal data into a DB to run SQL queries on it. It turns out the relational model…
It's a reasonable take that changing the entire way that the database modeled everything under the hood is an overkill solution to the specific problem you mention compared to something like LINQ that can work on top of existing databases, but I can't help but wonder if there's a bit of inertia in how willing people are to challenge their usual ways of thinking about how data modeling might be possible to improve because a lot of people don't get exposed very much to anything other than the raw, string-like handling that you mention (which is annoying but at least SQL injections are a well-known thing nowadays and tend to be possible to avoid) or a full-blown ORM (which quite often ends up either being wildly inefficient or needing to drop back down into the raw SQL in some places to avoid the performance bottlenecks, which kinda defeats the entire point). A startup I worked at a few years ago actually had what I thought was a pretty clever solution to this problem, with their product generating OpenAPI/GraphQL APIs for a given database by inspecting the schema (with optional parameters to get back EXPLAIN data in the responses to verify that the query was what you wanted, and the ability to define custom routes with raw queries that were checked into shared version control with the schema migrations if you weren't happy with the query it generated as a way to properly separate concerns as an improvement over the traditional ORM workflow), but despite the idea seeming quite enticing to me from a technical standpoint, I guess it didn't show enough traction to be able to survive.