3 ms·

You can tell without reading it all because he links to Joel's retarded article about "leaky abstractions". What's so retarded about Joel's concept of "leaky"

You can tell without reading it all because he links to Joel's retarded article about "leaky abstractions". What's so retarded about Joel's concept of "leaky" abstractions?

jrockway 17y ago
"TCP is a leaky abstraction because it can't recover from cut network cables." OK, technically true, but the issue is the scope of the abstraction, not that it is leaky. You could say that C is a leaky abstraction because C programs don't work if you shut off the underlying CPU. Technically true. Completely irrelevant. C can't control your power button. TCP can't control crazy people with scissors. Both are out of the scope of the abstraction; inside the scope of the abstraction, TCP ensures that packets arrive in the correct order, and C ensures that your program can work on a variety of CPUs. Finally, I don't think that ORMs are leaky. With enough effort, all object graphs can map to a relational model. Most people don't want to exert that much effort, but that doesn't mean object/relational mapping is a leaky abstraction. It doesn't really mean much of anything. (I agree that polymorphism and graph structures are hard to model, and that's why I generally use object databases. But that is mostly irrelevant.)
- arohner 17y ago
  > Both are out of the scope of the abstraction; inside the scope of the abstraction, TCP ensures that packets arrive in the correct order, and C ensures that your program can work on a variety of CPUs. But that's exactly Joel's point. inside the scope of the abstraction, the following properties are true. The whole point is that outside the abstraction stuff breaks, and the kicker is that in many cases, the only practical way to know what is inside the abstraction and what is outside the abstraction is to know the details about the underlying abstraction, exactly what it was supposed to help with! Yes, cutting the network cable is a poor example, but there are many good ones. With C, you can do stupid bit manipulation in ways that will be non-portable across architectures. With ORMs, an easy example is the N+1 select problem. ORMs are typically very leaky, in the sense that to write good quality code, you have to know the details about how your ORM works, and they usually aren't a 100% replacement for knowing SQL. The more you have to know about how the level below you works, the more leaky the abstraction. I think Joel's could have made the point clearer if he had distinguished between how much typing the abstraction saves you, and how much knowledge it absolves you from knowing.
  - jrockway 17y ago
    My experience is different. (I mostly use DBIx::Class.) I am not good at remembering SQL's syntactic quirks, which means I can't sit down and write a query for exactly what I want. But with DBIx::Class, I can walk my objects to get the data I want, and it "compiles down" to one database query. So that's not leaky -- I don't know SQL, I do know OO, and DBIx::Class lets me use my knowledge of one to extract data with the other.

You can tell without reading it all because he links to Joel's retarded article about "leaky abstractions". What's so retarded about Joel's concept of "leaky" abstractions?

jrockway 17y ago

"TCP is a leaky abstraction because it can't recover from cut network cables." OK, technically true, but the issue is the scope of the abstraction, not that it is leaky. You could say that C is a leaky abstraction because C programs don't work if you shut off the underlying CPU. Technically true. Completely irrelevant. C can't control your power button. TCP can't control crazy people with scissors. Both are out of the scope of the abstraction; inside the scope of the abstraction, TCP ensures that packets arrive in the correct order, and C ensures that your program can work on a variety of CPUs. Finally, I don't think that ORMs are leaky. With enough effort, all object graphs can map to a relational model. Most people don't want to exert that much effort, but that doesn't mean object/relational mapping is a leaky abstraction. It doesn't really mean much of anything. (I agree that polymorphism and graph structures are hard to model, and that's why I generally use object databases. But that is mostly irrelevant.)

arohner 17y ago
> Both are out of the scope of the abstraction; inside the scope of the abstraction, TCP ensures that packets arrive in the correct order, and C ensures that your program can work on a variety of CPUs. But that's exactly Joel's point. inside the scope of the abstraction, the following properties are true. The whole point is that outside the abstraction stuff breaks, and the kicker is that in many cases, the only practical way to know what is inside the abstraction and what is outside the abstraction is to know the details about the underlying abstraction, exactly what it was supposed to help with! Yes, cutting the network cable is a poor example, but there are many good ones. With C, you can do stupid bit manipulation in ways that will be non-portable across architectures. With ORMs, an easy example is the N+1 select problem. ORMs are typically very leaky, in the sense that to write good quality code, you have to know the details about how your ORM works, and they usually aren't a 100% replacement for knowing SQL. The more you have to know about how the level below you works, the more leaky the abstraction. I think Joel's could have made the point clearer if he had distinguished between how much typing the abstraction saves you, and how much knowledge it absolves you from knowing.
- jrockway 17y ago
  My experience is different. (I mostly use DBIx::Class.) I am not good at remembering SQL's syntactic quirks, which means I can't sit down and write a query for exactly what I want. But with DBIx::Class, I can walk my objects to get the data I want, and it "compiles down" to one database query. So that's not leaky -- I don't know SQL, I do know OO, and DBIx::Class lets me use my knowledge of one to extract data with the other.