Losing Metaphors: Zip and Paste | Hacker News Reader

Losing Metaphors: Zip and Paste

jefftk.com

43 pointspavel_lishin46 comments

"zip" as a metaphor for compressing something makes even less sense than the zip in functional programming - actually "zip" for compression doesn't make any sense at all. But maybe zip in the context of compression was never meant as a metaphor.

I don't think it was a metaphor, I grew up with it so I always imagined a bag being zipped up.

That deemphasises the compression aspect though.

I wonder if this influenced 'tarball', or maybe it's just human nature to think of objects in those terms.

http://www.bbsdocumentary.com/library/CONTROVERSY/LAWSUITS/S...

>[ZIP] implied speed ("zippy") and sexiness ("zipper")

TIL!

“Unzip, expand, explode... What pervert came up with this?” - unknown

$ unzip; strip; touch; finger; grep; mount; fsck; more; yes; fsck; fsck; umount; clean; sleep

I always thought about zipping an overfilled suitcase closed to make it smaller.

It's best to have grown up with correct understanding of those terms, thanks to age and English being a second language. E.g. I knew what "zipping" in context of .zip was before I knew the word "zipper" (fastener). Or, it took me many years to learn that "icons" aren't just the tiny pictures on computers, but also paintings of saints. Etc.

Skeuomorphism, whether visual or linguistic, is just making things more confusing.

The first time someone told me about an "array of satellite dishes" I was positively confused (and then briefly enthused that space types used a CS term for their space scanner). Also wait, the stress is on the second syllable?

I'm not sure I agree that 'zip' is lost. I would say the metaphor has always been ambiguous.

If you zip something irl, without context, what are you doing? I can see it being either sealing a bag or merging.

Which is not far from the metaphor. If you seal a bag, you take two strands and you basically match them one for one.

If you merge (or close a zipper) as the essay points out it’s a bit iffier because they interleave constructs, but at the same time a zipper keeps a clear distinction of right and left, so it’s pretty close.

Strictly speaking “buttoning” might be a better match for the semantics, but I don’t think it’d be clearer. Then again I’ve long integrated zipping so I’m way biased.

I think the problem isn't that you can't come up with story which makes sense. Problem is that you if you focus on other aspects of process for example opening/close part instead of mechanism how it's closed, or other meanings of word zip as making certain sound or a fast movement and come up with other equally meaningful metaphors. Once multiple of them get used you have a problem, even worse some of those uses can form new associations. That's how you end up with 5 completely different meanings associated with a word:

* zip(sound)<->zip(quick movement) no idea of history

* zipper <- zip(sound)

* zip tie <- zip(sound?)

* zip(function) <- zipper(side by side interleave)

* pkzip <- supposedly from zip(quick movement), although some other sources suggest similarity with opening/closing a container aspect. Which also somewhat makes sense as you can more easily extract or add individual files to a zip archive, which many other archive supports don't support. Seems like some of the early software packaging had illustrations of zipper, so I guess they embraced the multiple meanings of zip.

* zip(general compression) <- pkzip

* zip drive <- quick?

* zipper -> plastic teethless zipper (closer to zipping function) -> Ziploc -> strengthen the open and close meaning without zip sound or interleaving

Does anyone have any sources of origin for computer science use of zip meaning combining multiple lists? All the examples using actual word "zip" in wikipedia are from somewhat modern programming languages no earlier than 1990, lisp is older but it doesn't seem to use the word zip.

I agree they're both lost metaphors, and also that zip is really not very good. If you grok it, then sure. If you forget it, then its just a random TLA functioncall.

I'm not sure what I think zip() should be. pair() ? smooge()?

Kill ring, and the Yank buffer in Emacs are also misnamed. you don't kill things you put in the kill ring, you are doing the opposite of yank when you put things in with ^Y

⍉, of course.

wed()? mate()? ...or for the fanfic'ionados, ship()?

(from a comment to TFA: imbricate()?)

> ship()?

That'd be Cartesian product.

I personally would be fine with line_up() or side_by_side().

Isn't "lining up" usually done "against a wall"?

Pair up?

Well, I've got a couple things lined up for this weekend and since I'm almost certain I will end up executing them... hmmm.

Interleave().

Or if that's too long, int(), or leave()

Or if you're working with a list of lists, the wonderful: ↓⍉↑ will do

Also the 'continue' statement in most programming languages does the opposite.

It does in the context of a border guard saying "continue", rather than taking you to a back room with a rubber glove.

In programming languages where it was not already taken, 'next' would have been a better choice.

Maybe "join" like in databases?

join already does something else

It is a join on element index, could be a default if a join field is not set?

zip makes much more sense to me. It interleaves two sequences same like two halves of a zipper interleave.

It’s like zipper merging in a car.

And if you don’t know how to zipper merge you really need to.

But it doesn't interleave? You get a sequence of pairs.

Touche

transpose? In the sense that

[[1,2,3,4,5],[6,7,8,9,10]]

Becomes

[[1,6],[2,7],[3,8],[4,9],[5,10]]

Woa! Of course!

And if you use PyTorch, its O(1) operation. You just change how you index into the data.

I believe numpy introduced ndarrays with user-specified strides, that made this a O(1) operation. Even if not, it certainly predates pytorch in this regard. Pytorch (and other tensor libraries) just used the ndarray concept from numpy.

Thanks yeah I didn’t mean to imply that Pytorch invented the idea

What about "glue" instead of "zip"?

(I guess that's just the same as "paste", but British English, so maybe not the best idea!)

>It's not perfect, since a zipper interleaves instead of matching pairs, but it's pretty good.

A zipper also interleaves matching (in order) pairs, not just random items anywhere on each side!

The original Unix systems were really memory-constrained, and the standard utilities for processing text files often couldn't handle "long" lines (usually over 2048 bytes, sometimes less). So the `cut` utility divided an input file up into separate files each containing a section of each line. To put the file back together, the `paste` utility would merge the sections of each line from those files back together.

Thanks for that. I was wondering how paste was useful enough to be included based on the article. I’ve spent my share of time in shells but haven’t ever encountered paste as far as I remember.

I also believe that the 'zip' name hurts intuition by favoring `zip(long_list1, long_list2)`, when `zip(*pairs)` is just as useful.

From a mathematical viewpoint, 'zip' is just transpose, and therefore its own inverse. But because of the zipping metaphor, this feels perfectly normal:

    pairs = zip(sources, destinations)

While this feels like black magic:

    sources, destinations = zip(*pairs)

It's also worth considering metaphors that don't cause confusion because of e.g. conflict with other computing concepts that use the same terms, but fall short of their analog.

I'm surprised drag and drop hasn't been improved, especially since the proliferation of touch devices.

The idea behind drag and drop is that you should be able to grab something like in real life, but the way it's implemented in almost every system is lacking. In real life, I can grab something, start to move it, notice that something else needs to be shifted around, put the first thing down, focus my attention on the second thing and deal with it, then pick the first thing back up and complete my original goal from where I left off. It doesn't work like this on the desktop. If you notice midway through your journey from source to destination that the destination isn't actually ready for the drop, your dragged item goes flying back to the source and the whole thing is canceled. You have to then prepare the destination, return to the source, start dragging it again, and then release it to complete the drop. The modality of dragging leads to anxiety. It's worse on touchpads, because I fear accidental releases and running out of space in the direction my finger is traveling.

I want drag and drop to be completed by an independent mouse click, not on release. You start dragging. That should create an icon of roughly the same size as a desktop icon. If you release it anywhere it'll stay in that position, allowing you to shuffle through windows, sidebars, etc. When you know your destination is in a state that's ready to receive the dropped item, you pick it back up, bring it to its intended drop point, release it from the cursor, and complete the drop with an additional tap/click to actually "approve" it, i.e. "send" it to the destination—otherwise it stays sitting around waiting for you to e.g. pick it back up again, dismiss it, etc. This would also afford programmers the ability to add context menus to drag and drop items, which would lead to people (users and programmers) better modeling them in a truer object-oriented way.

Paste is a lost metaphor? My kids cut and pasted for 20 mins today during craft time. The one time tangible spam is worth getting in the mail.

I did a zipper merge yesterday and the cars then were in pairs, one from each lane.

But as the author also printed a newline, it looks very different.

> I did a zipper merge yesterday and the cars then were in pairs, one from each lane.

Up until the point of zipping, when they suddenly became misaligned. The outcome of zipper merge isn't pairs of cars, glued by their side doors, going down a single lane. The outcome is cars from both input lanes interleaved, forming a 2x longer line on the output lane.

Wait, you two are not actually talking about using SIMD instructions in a LISP implementation when working with several lists simultaneously, but about actual road transportation and vehicles instead?

It's lost in the sense that "paste" means something very different on a computer today than what the unix "paste" program does.

In fairness, pasting as a metaphor works very poorly for what Unix used it for.

In the days that these metaphors were designed, you would literally cut and paste documents to lay them out. So the metaphor is lost in the specific document creation sense.

For early school projects I did the text in a word processor leaving holes for the pictures. My parents worked at a graphic design place so they had a scanner and colour printer to print prictures which were cut and pasted in.

Reply on news.ycombinator.com