Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Leaky Abstractions

textslashplain.com

Post reply on HN
Print view View original

61–70 of 119 posts

Re: Leaky Abstractions

#61

Post by chenglou »

chii wrote: post #49
lmilcin wrote: post #18

Earlier quoted context omitted.

Yes. Functional world is not impervious to leaky abstractions. I am personally of the opinion that, to be a good developer, you have to have mental model of what happens beneath. If you are programming in a high level language it is easy to try forget about the fact that your program runs on real hardware. I know, because I work mostly on Java projects and trying to talk to Java developers about real hardware is usel…

The funny thing is that in the old days, it is required to know how the machine worked - you coded assembly against physical memory. But that was incredibly hard, and error prone (and comes with tonnes of limitations). The fact that today, it's very easily possible to write working programs without knowing any of the underlying details, is a marvel. If i were to hire a truck driver, i wouldn't expect to have to ask h…

There’s a much vaster gulf between a truck driver and a truck engineer, vs a Java programmer and a programmer one layer below. Per your analogy, the truck driver is the program user here, not the program maintainer.

Re: Leaky Abstractions

#62

Post by korijn »

austhrow743 wrote: post #60
dhosek wrote: post #50

Earlier quoted context omitted.

The problem is that computer science ≠ software engineering, especially in academic contexts.

I've seen this a lot on here combined with cs degrees being frequently mentioned and software engineering degrees rarely mentioned. Are people widely choosing computer science over software engineering and then being surprised they aren't studying software engineering or is it rare for institutions to offer software engineering as an option?

I am not aware of anyone with a software engineering degree. Is that really a thing?

Re: Leaky Abstractions

#63

Post by austhrow743 »

korijn wrote: post #62
austhrow743 wrote: post #60

Earlier quoted context omitted.

I've seen this a lot on here combined with cs degrees being frequently mentioned and software engineering degrees rarely mentioned. Are people widely choosing computer science over software engineering and then being surprised they aren't studying software engineering or is it rare for institutions to offer software engineering as an option?

I am not aware of anyone with a software engineering degree. Is that really a thing?

Was where I went. Two separate degrees:

https://www.newcastle.edu.au/degrees/bachelor-of-software-en...

https://www.newcastle.edu.au/degrees/bachelor-of-computer-sc...

Looks like there's even a "computer systems engineering" as well.

https://www.newcastle.edu.au/degrees/bachelor-of-computer-sy...

Re: Leaky Abstractions

#64

Post by lmm »

tacitusarc wrote: post #55
lmm wrote: post #46

Earlier quoted context omitted.

IMO that article is the most damaging thing to happen to programming culture in 20 years. It's not hard to write a valid abstraction, and none of Joel's examples actually hold up (yet he generalises it to a supposedly universal law). Of course abstractions are garbage-in, garbage-out - yes, TCP won't give you a reliable connection if you unplug the network cable, but an application written to use UDP won't fare any b…

It sounds like you completely missed the point he’s trying to make...

Maybe, but if so so did many of my colleagues over the last ten years. I've seen so much bad code written in the name of avoiding abstractions, with that article as direct inspiration.

Re: Leaky Abstractions

#65

Post by lmm »

klodolph wrote: post #59
lmm wrote: post #46

Earlier quoted context omitted.

IMO that article is the most damaging thing to happen to programming culture in 20 years. It's not hard to write a valid abstraction, and none of Joel's examples actually hold up (yet he generalises it to a supposedly universal law). Of course abstractions are garbage-in, garbage-out - yes, TCP won't give you a reliable connection if you unplug the network cable, but an application written to use UDP won't fare any b…

TCP won’t give you a reliable connection if you tunnel TCP over TCP, paradoxically, but you can tunnel TCP over UDP, UDP over TCP, or UDP over UDP. Leaky!

Not "leaky", the conditions that a TCP connection needs its underlying transport to satisfy are explicitly documented, and TCP doesn't conform to them.

Re: Leaky Abstractions

#66

Post by redsparrow »

I don't know why but "your CAB archive is a folder" really took me back. It's nice to read something that makes me nostalgic for a time when Windows was a big part of my life. I don't know that I ever loved Windows, but we were intimate.

Re: Leaky Abstractions

#67

Post by ithkuil »

TeMPOraL wrote: post #16
lmilcin wrote: post #11

Earlier quoted context omitted.

It is easier to abstract (at least nively). First, you abstract moving a single file, then you create abstraction for "all files" basically by repeating same operation for all files. You could do this for a subset of files and so on. As to slow operations... that is more likely because of synchronous implementation. The popular, naive implementation is, as above, to repeat same simple operation over and over again: r…

> The popular, naive implementation is, as above, to repeat same simple operation over and over again: read from source, write to destination, read from source, write to destination. Reminds me of the kind of patterns functional programming languages introduce, where you process data by describing operations on individual items and assembling them into "a stream". I'm always wary of those - without a good implementat…

Rust for example does indeed apply lots of black compiler magic to really cut the cost of those abstractions (I've seen the output of complex iterator chains compiled down to exactly the same machine code you'd write without the abstractions). However man is it slow to compile. Pick your poison.

Re: Leaky Abstractions

#68

Post by DharmaPolice »

kinjba11 wrote: post #56
zbendefy wrote: post #14

Another similar and good article: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

It feels to me that this blog post is pointing out the obvious. The examples are a bit forced in my opinion. I would expect it to be about badly designed or architected code, but. Iterating works. SQL works. Windshield wipers work. The iteration abstraction isn't leaking - the hardware and memory architecture isn't part of the abstraction. The SQL abstraction isn't leaking - the performance isn't part of the abstract…

Abstractions are great but I think that's sort of the problem in some cases. You see a pattern like this in SQL from time to time - someone creates a view called dbo.GlobalReport which has all the joins and query logic they need for their reports. Next person comes along, sees the dbo.GlobalReport object but it's missing something so they wrap that in a view dbo.NewGlobalReport, joining a bunch of tables to the original dbo.GlobalReport. And this works. And then the next person comes along...and so on. Eventually someone has problems so they look at the query plan and their jaw drops. In theory, you shouldn't have to worry whether dbo.GlobalReport is a table or a view (if you're just querying it) but in practice you do (sometimes).

Likewise, in an enterprise setting a (Windows) user shouldn't have to worry when saving a file to X:\ what kind of drive/storage X is. And 99.9% of the time, that abstraction works. But then someone tries to save a 500GB video and suddenly it does matter what kind of drive X is, where it is, how it's connected, the filesystem it's using etc.

I think the issue in both cases is that the distinction is fairly obvious if you're in the know but not necessarily for anyone else (until they try it).

Re: Leaky Abstractions

#69

Post by teddyh »

monocasa wrote: post #58
bhawks wrote: post #57

Earlier quoted context omitted.

The traditional posix filesystem is yet another leaky abstraction. Inflexible ACLS and metadata, a horrible and confusing consistency story, an inability to reliably / cleanly rename files, interfaces that are painful to implement performantly without surprises, don't even get started on fsync... I just want to create, read, update and delete some resources :)

But at least there I can expect programs run as the same user to see the same files. "Why can I see the files in explorer and not this program I run to use those files?" isn't an answer you have to burn support time on because it's not ultimately implementing an FS layer in special GUI components. It's not that I don't like their FS abstraction (there's a lot of abstractions I don't like; as an engineer that's not an…

> Like if FUSE was implemented entirely in Gnome components and anything that used open(2) broke as not seeing the veneer files but you could see them in every system application.

Oh, you mean exactly like Gnome GVfs?

Re: Leaky Abstractions

#70

Post by monocasa »

teddyh wrote: post #69
monocasa wrote: post #58

Earlier quoted context omitted.

But at least there I can expect programs run as the same user to see the same files. "Why can I see the files in explorer and not this program I run to use those files?" isn't an answer you have to burn support time on because it's not ultimately implementing an FS layer in special GUI components. It's not that I don't like their FS abstraction (there's a lot of abstractions I don't like; as an engineer that's not an…

> Like if FUSE was implemented entirely in Gnome components and anything that used open(2) broke as not seeing the veneer files but you could see them in every system application. Oh, you mean exactly like Gnome GVfs ?

They at least stick a fuse module in too so it exists in the normal filesystem and non gnome apps can work with normal filepaths still. But yeah, agreed that it's also a case of this being implemented at entirely the wrong layer, probably following in the windows shell extension's footsteps blindly.
Post reply on HN