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

111–119 of 119 posts

Re: Leaky Abstractions

#111

Post by Beldin »

MillenialMan wrote: post #97
korijn wrote: post #62

Earlier quoted context omitted.

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

At least in the UK, "Software Engineering" degrees are just Computer Science degrees with a different name and a restricted subset of course options. From what I can tell, they're a marketing gimmick, but even respectable universities will offer them. The more questionable universities will also offer actual specialised courses under that moniker (in the same vein as "games design" degrees), but they aren't great. So…

My uni offers both a one-year MSc SE, and a two-year MSc CS. For organisational reasons, the 2 yr program is basically SE+MSc Information Science.

Students can pick their final subject; there is no difference in subjects between the two programmes, though we obviously expect some difference in result. After all, you should show some proficiency in both masters if you're doing the 2yr programme.

I'm currently supervising a student (SE) on file recovery, to whom I'll definitely forward the link. It's right up his project's alley.

Side remark: had he been enrolled in the 2yr programme, the subject would have been the same. I'd just expect him to extend his current work with a research question towards information science.

Re: Leaky Abstractions

#112

Post by JohnL4 »

On a quick scan, I'm not seeing any mention of OS/2, but I feel like this extensible behavior of the shell first showed up there. Not sure if that was an IBM thing or a Microsoft thing (or both), but it was WAY WAY WAY different from what came before.

Re: Leaky Abstractions

#113

Post by klodolph »

lmm wrote: post #107
klodolph wrote: post #101

Earlier quoted context omitted.

If you're going into the details of what conditions a TCP connection needs, you're no longer talking about an abstraction.

An abstraction doesn't mean you can close your eyes and everything will work by magic. They're extremely useful tools, but like I said: garbage in, garbage out.

> An abstraction doesn't mean you can close your eyes and everything will work by magic.

Right... that's why they're called "leaky abstractions". Because when you don't pay attention to the implementation details and their constraints, things break.

If it weren't leaky, you'd call it a "specification" instead of an "abstraction".

Re: Leaky Abstractions

#114

Post by lmm »

klodolph wrote: post #113
lmm wrote: post #107

Earlier quoted context omitted.

An abstraction doesn't mean you can close your eyes and everything will work by magic. They're extremely useful tools, but like I said: garbage in, garbage out.

> An abstraction doesn't mean you can close your eyes and everything will work by magic. Right... that's why they're called "leaky abstractions". Because when you don't pay attention to the implementation details and their constraints, things break. If it weren't leaky, you'd call it a "specification" instead of an "abstraction".

Requirements are not the same thing as implementation details. 2 + 2 = 4 is a sound abstraction, the fact that 1 + 2 doesn't = 4 doesn't make it "leaky".

Re: Leaky Abstractions

#115

Post by chii »

an1sotropy wrote: post #105
chii wrote: post #48

Earlier quoted context omitted.

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!

Read the link above about FP as a leaky abstraction of the reals; it explains it better than I can. FP is not really a representation of reals, because you can't represent the entire number line with a finite number of bits. It is a representation of a cleverly chosen subset of the reals, so well-designed that many people forget that they're not dealing with real numbers. That intelligent people can write code with F…

> I don't think people manipulating char[] representations of strings are ever at risk of forgetting that it's just an array of chars

and yet, when people start adding unicode text under this representation, and the program fails to work properly. Or when counting characters, and assume the glyph count would match the char array length.

or any number of other string issues.

Re: Leaky Abstractions

#116

Post by klodolph »

lmm wrote: post #114
klodolph wrote: post #113

Earlier quoted context omitted.

> An abstraction doesn't mean you can close your eyes and everything will work by magic. Right... that's why they're called "leaky abstractions". Because when you don't pay attention to the implementation details and their constraints, things break. If it weren't leaky, you'd call it a "specification" instead of an "abstraction".

Requirements are not the same thing as implementation details. 2 + 2 = 4 is a sound abstraction, the fact that 1 + 2 doesn't = 4 doesn't make it "leaky".

2 + 2 = 4 isn't an abstraction. I think we just have a different idea of what an "abstraction" is, which is fine.

Re: Leaky Abstractions

#118

Post by an1sotropy »

chii wrote: post #115
an1sotropy wrote: post #105

Earlier quoted context omitted.

Read the link above about FP as a leaky abstraction of the reals; it explains it better than I can. FP is not really a representation of reals, because you can't represent the entire number line with a finite number of bits. It is a representation of a cleverly chosen subset of the reals, so well-designed that many people forget that they're not dealing with real numbers. That intelligent people can write code with F…

> I don't think people manipulating char[] representations of strings are ever at risk of forgetting that it's just an array of chars and yet, when people start adding unicode text under this representation, and the program fails to work properly. Or when counting characters, and assume the glyph count would match the char array length. or any number of other string issues.

yea good point. Unicode does overwhelm simplistic ideas about string representation. Love those grapheme clusters.

Re: Leaky Abstractions

#119

Post by cryptica »

ericlaw wrote: post #98
cryptica wrote: post #84

It's an interesting article but the term 'Leaky abstractions' is not suitable here. This abstraction is not leaky at all. It sounds like a great abstraction in fact. It's just the implementation that's slow and it's not because of the abstraction. The author himself admits "it’s relatively easy to think of ways to dramatically improve the performance of this scenario". That fact that the issue can be easily resolved…

The abstraction leaks because the performance characteristics are inherently impossible to mask from the higher layers. There are other places where the abstraction leaks as well (try to add a file with a Unicode name to a Compressed Folder). It's true that you could add more and more code to try to make the abstraction leak less.

It's not impossible because the author of the article themselves admit that there are many ways to fix this. I can already think of one possible way they could speed up the copy-paste from the zip file; by waiting until all files have been copied to the file system before deleting files from the zip in one go. The fact that solutions do not require a change to the interface is a sign that this is not a problem with the abstraction.

Is it the abstraction which is forcing the files to be copied 1 byte at a time? It doesn't seem like it. It's an implementation issue. The interface allowed the plugin to have been implemented in many other ways, the implementer of the plugin just happened to go about it the wrong way.

Post reply on HN