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

81–90 of 119 posts

Re: Leaky Abstractions

#81

Post by TeMPOraL »

ptman wrote: post #72
TeMPOraL wrote: post #28

Earlier quoted context omitted.

Speaking of old Windows and CDs, Windows had some crazy trick to turn CD-R ( not CD-RW) into rewriteable medium. I'm guessing they simulated a regular file system on top of an append-only representation. I never dug into the details back in the day, because I never used this feature. Unfortunately, IIRC, this trickery was enabled by default when copying files to CDs - which was a problem, because nothing else could r…

UDF? https://en.wikipedia.org/wiki/Universal_Disk_Format

I think so. IIRC it was this:

https://en.wikipedia.org/wiki/Live_File_System

which is apparently the same thing as UDF.

Re: Leaky Abstractions

#83

Post by [deleted] »

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?

[deleted]

Re: Leaky Abstractions

#84

Post by cryptica »

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 without changing the abstraction (the plugin system) is proof that the abstraction is not leaky.

A leaky abstraction would leak implementation details from the plugin to the caller and thus make it impossible to replace or modify the plugin without modifying the caller's logic. It doesn't appear to be the case here. It seems like the issue can be resolved just by changing the plugin's logic; the caller's logic would stay the same. This sounds like an excellent abstraction and could be the reason why the core logic hasn't had to be changed in 1998... It should be hailed as an achievement, not shunned as 'leaky'.

Re: Leaky Abstractions

#85

Post by 4gotunameagain »

redsparrow wrote: post #66

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.

Stockholm syndrome ♡

Re: Leaky Abstractions

#86

Post by drran »

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?

Yep, I'm the software engineer with diploma. I have master degree in Computer Sciences (Software Engineering Department). I'm from Ukraine.

Re: Leaky Abstractions

#87

Post by MillenialMan »

dhosek wrote: post #50
Rerarom wrote: post #38

Earlier quoted context omitted.

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.

I don't think that's the problem. The problem is that Universities aren't punished for teaching inadequately. And when challenged, people justify it by saying, "ah, but this course that 90% of you took so that you could be prepared for a career as a developer wasn't really about being a developer."

Re: Leaky Abstractions

#88

Post by ithkuil »

lmilcin wrote: post #78
ithkuil wrote: post #67

Earlier quoted context omitted.

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.

> Pick your poison. I pick Rust every time. I have this concept of easy problems and hard problems. Every decision to choose technology is a compromise and comes with its own problems. It is your job to know whether these are easy or hard problems. Compilation time is easy problem. Just put more hardware to it or modularize your application or schedule your coffee breaks correctly. Building reliable abstractions to p…

> just put more hardware to it or modularize your application

This is not that easy as it seems.

Rust compilation is not embarrassingly parallel as a lot of what's going on seems to be deferred at the link stage.

Modules inside a crate can't be compiled in parallel because of some reason I don't truly understand, please educate me.

Crates can be truly compiled in parallel, crating projects with hundreds of crates is quite a pain for other reasons.

The result is that a change single line of code in the project I'm working in can take more than 2 minutes on my last gen MacBook pro.

I have a M1 Mac mini where the compilation is twice as fast but I don't have enough RAM there and I'll have a hard time to convince my manager to make an exemption to my companies laptop refresher policies "because of rust".

If I have to take a coffee break every time I need to wait for an incremental compilation my heart would explode.

My current solution is:

1. Multitask. Do somethings else while I'm waiting.

2. Split the code that I'm iterating on in a new project. With minimal dependencies and copy the code back in the main project when I'm done (or just import it as a crate if it makes sense)

Both options suck and I wish they weren't necessary. Please let me know what else could I do. What hardware should I buy etc

(I already use zld on Mac and use minimal debug symbols, iirc debug=1)

Re: Leaky Abstractions

#89

Post by m4lvin »

toast0 wrote: post #23
bentcorner wrote: post #4

I wonder why it's implemented as a per-file copy+delete instead of a "copy all files" then "delete all files". I also have a gut feeling that doing similar operations to a connected android phone (e.g., moving photos from your phone to your PC over USB) is also slow, probably for similar reasons.

copy + delete one at a time makes a lot of sense if you're working on a filesystem without a way to move without copying (I don't think you can actually move a file in fat32), because copy all could require more space than is available. The same could be true here where you're moving from a zip file to probably the same filesystem the zip files is in; if removing a file from the zip file is actually an in-place move…

> copy + delete [...] I don't think you can actually move a file in fat32

Wait, does that mean that a file which is larger than half of the partition in fat32 cannot be moved? Or not even be renamed?

Re: Leaky Abstractions

#90

Post by Zababa »

ithkuil wrote: post #67
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…

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.

From what I understood the problem with Rust compilation time are more with LLVM and monomorphization of generics. I know that OCaml has a generics system that's kinda like Rust but doesn't monomorphize functions and is really really fast at compiling. OCaml also has its own backend.
Post reply on HN