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.
Leaky Abstractions
51–60 of 119 posts
Re: Leaky Abstractions
#52Re: Leaky Abstractions
#53It'd be interesting to now what lead to the architectural decision of wear to cut that abstraction. It feels like a Microsoft team balkanization issue (the explorer team and POs being different from the NT kernel ones, I assume?), but it's near impossible to know without inside knowledge.
Re: Leaky Abstractions
#54For example, the zip folder could realise that deletion is an expensive task, and defer the job till later. It would tell the kernel that the raw bytes of the zip file are only available to other applications after this operation is complete (so that emailing someone the zip file can't represent the pre-deferred-operations state).
The tree of deferred operations can then be optimized - for example, deleting multiple files in a zip file could be combined into one. Deleting stuff in a zip file, and then deleting the whole file can likewise be combined.
Kinda like peephole optimisations for stuff your OS does.
Re: Leaky Abstractions
#55Another 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 b…
Re: Leaky Abstractions
#56Another similar and good article: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
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 abstraction. The windshield wipers abstraction isn't leaking - the wipers were designed for rain, not a hurricane. Abstractions ignore details - that's the point. Reality doesn't cease to exist.
If your car isn't fast enough for the race, the car, steering wheel, accelerator pedal are not a leaky abstraction. You just don't have a fast enough car! If you have to worry about stuff like shifting gears, then an automatic transmission isn't the abstraction for you. The abstraction isn't leaking, you just chose the wrong one.
Abstractions are great.
I've never had to worry about CPU instructions or assembly code in the code I've written - the programming language abstraction is perfect as far as I'm concerned. Somebody handles it. I've never had to worry about the electricity powering my machines in the Cloud etc where I deploy. Perfect abstraction. Somebody handles it. My web browser chugs through hundreds of megabytes of JavaScript daily. Perfect abstraction. I've never needed to concern myself with the implementation of say V8. I've had my share of SQL performance investigations, but most of the SQL I've written didn't need any performance tweaking (there's a different abstraction for performance that works great - indexes).
Leaking is a matter of perspective.
Re: Leaky Abstractions
#57Having written a shell namespace extension, I now use the concept as a great example of making the wrong abstraction interestingly enough. Shell namespaces are a odd win32 concept rather than a filesystem concept and cause a lot of headaches (read support calls) when people see that they work in explorer, but not from arbitrary applications depending on how they use the underlying APIs. If you're trying to abstract t…
I just want to create, read, update and delete some resources :)
Re: Leaky Abstractions
#58Having written a shell namespace extension, I now use the concept as a great example of making the wrong abstraction interestingly enough. Shell namespaces are a odd win32 concept rather than a filesystem concept and cause a lot of headaches (read support calls) when people see that they work in explorer, but not from arbitrary applications depending on how they use the underlying APIs. If you're trying to abstract t…
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 :)
"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 interesting topic for discussion but instead basically expected). It's that they broke their own abstraction a decade later by implementing the multiplextion in a layer totally contrary to what the user expects. 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.
Re: Leaky Abstractions
#59Another 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 b…
Re: Leaky Abstractions
#60Earlier 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.
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?