> 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?
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.
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
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.
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.
"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.
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 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:
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.
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.
48 comments
[ 2.9 ms ] story [ 94.7 ms ] threadBut as the author also printed a newline, it looks very different.
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.
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.
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
wed()? mate()? ...or for the fanfic'ionados, ship()?
(from a comment to TFA: imbricate()?)
That'd be Cartesian product.
I personally would be fine with line_up() or side_by_side().
Pair up?
Or if that's too long, int(), or leave()
And if you don’t know how to zipper merge you really need to.
[[1,2,3,4,5],[6,7,8,9,10]]
Becomes
[[1,6],[2,7],[3,8],[4,9],[5,10]]
(I guess that's just the same as "paste", but British English, so maybe not the best idea!)
If you zip something irl, without context, what are you doing? I can see it being either sealing a bag or merging.
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.
* 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.
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.
>[ZIP] implied speed ("zippy") and sexiness ("zipper")
TIL!
Skeuomorphism, whether visual or linguistic, is just making things more confusing.
From a mathematical viewpoint, 'zip' is just transpose, and therefore its own inverse. But because of the zipping metaphor, this feels perfectly normal:
While this feels like black magic: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.
A zipper also interleaves matching (in order) pairs, not just random items anywhere on each side!