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

41–50 of 119 posts

Re: Leaky Abstractions

#41

Post by tester756 »

zbendefy wrote: post #14

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

this article is indeed cool and almost all examples are good, but this example is in my opinion heavily forced or even wrong?

>And you can’t drive as fast when it’s raining, even though your car has windshield wipers and headlights and a roof and a heater, all of which protect you from caring about the fact that it’s raining (they abstract away the weather), but lo, you have to worry about hydroplaning (or aquaplaning in England) and sometimes the rain is so strong you can’t see very far ahead so you go slower in the rain, because the weather can never be completely abstracted away, because of the law of leaky abstractions.

Re: Leaky Abstractions

#42

Post by amichal »

This article is about the details of zip file handling in the Shell Extension... Reading the first few paras I thought they would talk about the struggle it was to implement a shell namespace extension. I did a somewhat crappy one 20-something years ago and I still remember how confusing it was. At the time is spent all my days writing various COM things. I was very comfortable doing things like hand editing IDL headers to avoid changing GUIDs. NSEs were still the most baffling, brittle and confusing interfaces I've ever seen

Re: Leaky Abstractions

#43

Post by userbinator »

jakub_g wrote: post #17
genpfault wrote: post #5

Earlier quoted context omitted.

> doing similar operations to a connected android phone MTP is terrible[1]. [1]: https://en.wikipedia.org/wiki/Media_Transfer_Protocol#Perfor...

Oh boy. I was thinking USB 2.0 is main reason for Android Windows copying of photos to suck so much, but the rabbit hole is much deeper. It's sad that with cloud being the solution for everything those days, this will probably never be improved within next decade.

It's ridiculously wasteful and slow to have to upload to a cloud server who-knows-where, then download it again to the computer several feet away. Yet with Android having removed USB mass storage, that's often the easiest way. It's against the interests of those who profit off selling cloud storage to make local transfers easy.

Re: Leaky Abstractions

#44

Post by belden »

tester756 wrote: post #41
zbendefy wrote: post #14

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

this article is indeed cool and almost all examples are good, but this example is in my opinion heavily forced or even wrong? >And you can’t drive as fast when it’s raining, even though your car has windshield wipers and headlights and a roof and a heater, all of which protect you from caring about the fact that it’s raining (they abstract away the weather), but lo, you have to worry about hydroplaning (or aquaplanin…

I think it’s contrived simply for a pun:

> leaky abstractions > > hydroplaning >

hydroplaning requires:

- water (“leaky”)

- sliding (“...traction”)

- lack of _brakes_ (“abs...”)

Well, and speed too.

Re: Leaky Abstractions

#45

Post by ping_pong »

25 years without major bugs and still being extremely useful is a complete win in my book! This is definitely a bug, but I wonder if Microsoft will think it's worth it to even update it, it doesn't seem like it happens enough to cause widespread issues.

Re: Leaky Abstractions

#46

Post by lmm »

zbendefy wrote: post #14

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

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 better in that case.

Re: Leaky Abstractions

#47

Post by ericlaw »

dsego wrote: post #22

Unless I'm mistaken, this seems to be the original programmer on youtube: Dave's Garage - Secret History of Windows ZIPFolders https://youtu.be/aQUtUQ_L8Yk

As noted in the blog post, he's the author of the Shell Namespace code, but not the ZIP code beneath.

Re: Leaky Abstractions

#48

Post by chii »

an1sotropy wrote: post #30
zbendefy wrote: post #14

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

Another common leaky abstraction: floating-point numbers as an abstraction of the real numbers. It works nearly all the time, until you have to really know about numerical precision, or where a NaN came from. https://www.johndcook.com/blog/2009/04/06/numbers-are-a-leak...

i wouldn't call floating point numbers an abstraction on real numbers. It's a representation - like char[] is a representation of strings, which is itself an abstraction used to manipulate human readable text!

Re: Leaky Abstractions

#49

Post by chii »

lmilcin wrote: post #18
TeMPOraL wrote: post #16

Earlier quoted context omitted.

> 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…

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 him to understand how the truck itself worked (e.g., fuel injection when he presses the accelerator). He only needs to know how to operate the truck from the interface (steering wheel!). Why isn't this the same for a java programmer?

Re: Leaky Abstractions

#50

Post by dhosek »

Rerarom wrote: post #38
yurishimo wrote: post #2

These are the kinds of articles I love to see on HN! I think it's so interesting to see how different OS' have approached these long lived operations over the years. Arguably, *nix OS' have been able to move past these problems since it appears that package management is much more of a first party concern. "Oh, you want to upgrade this utility? Well, I rely on these other things so you should update them too." I'm a…

This is the kind of stuff I expected to study in my CS degree

The problem is that computer science ≠ software engineering, especially in academic contexts.
Post reply on HN