scriptorium 0.0.3 → 0.7.2

data/doc/old-posts/0010-immutable-data-ditching-the-wax-tablet.lt3

@@ -0,0 +1,142 @@
+.mixin liveblog
+
+.post 10
+
+.title Immutable data (ditching the wax tablet)
+.pubdate 2015-08-25
+.views computing
+.tags
+
+.pin computing
+
+.teaser
+A couple of weeks ago, I went to Phoenix training prior to the Lone Star Ruby
+Conference in Austin. I was talking with Bruce Tate, and he shared with me 
+some thoughts about functional programming in general. 
+.end
+
+Obviously Bruce isn't responsible if I misquote him. My memory is faulty.
+
+"Functional programming is the future," he told me, "and OOP is dying." 
+He pointed to the ever-increasing popularity of multi-core machines and the 
+increasing irrelevance of conserving memory.
+
+He said that OOP was all about optimizing for memory usage, and that was 
+no longer such a big concern. I wasn't sure what he meant. I thought about it
+later, and decided I was probably missing some profound points. 
+
+But at the same time, I thought I saw something with a clarity that I hadn't
+before. I have wrestled with the concepts of FP over the last year or two; as
+a procedural and OOP type, it hasn't always fit into my brain quickly or
+easily. 
+
+At times it felt that I was taking a step backwards technologically, back into 
+procedural thinking. On the one hand, that isn't really true. On the other
+hand, I think we all know what backtracking is for. If you've ever gotten lost
+in a strange town, you know that sometimes you have to back up to a known
+point and try going off in a different direction. 
+
+If you're interested, you could make some fine analogies here between human 
+technological advances and things like game theory and machine learning. It's
+hard to imagine navigating a maze or implementing a chess-playing program
+without the concept of backtracking. But that's not my point here.
+
+One of the key concepts in functional programming, as I understand it, is that
+of immutable data. I have spent hours puzzling over this, because it hasn't 
+been immediately intuitive to me.
+
+There was a quote I read once that the GOTO statement caused difficulties 
+because it left us with the question, "How did I get here?" And mutable data
+leaves us with the question, "How did I get to this state?" That made sense
+to me, at least a little.
+
+It got me to thinking about a more remote time, when I taught programming 
+concepts to beginners (using BASIC). In an effort to explain how a program
+worked, I would run through an exercise on the whiteboard which I called 
+"playing computer." Variables were represented by little boxes which more or 
+less corresponded to memory locations. As I manually stepped through the execution
+of some simple program, I would erase and update the contents of these boxes.
+
+It was nice and effective, but I sometimes did it another way. I expressed the
+same information in the form of a table, with variable names across the
+columns and time increasing down the rows. This made it clear not just what
+values the variables had, but what values they used to have (and how/when they
+changed).
+
+As an aside, I'm one of those people who believes that an education should not
+be merely deep but also broad. I believe a good vocabulary, like a good
+education in general, enhances our experience of life. 
+
+And as I thought about my old whiteboard shenanigans, the word that came to me
+was _palimpsest -- a beautiful, useful, poetic word that we rarely see nowadays.
+It's sometimes used figuratively; but the literal definition is _(a document on )
+_(which the original writing has been erased and replaced with new writing).
+
+I thought about the many older modes of writing, such as clay and wax tablets
+and papyrus. Some materials such as papyrus and parchment (vellum) were rather
+limited in availability or moderately labor-intensive to produce; people wanted 
+to re-use them. It was natural to wipe (or scrape or clean) such a material 
+once the writing on it was no longer relevant. The term "blank slate" _((tabula rasa)) 
+was once very literal; the stuff we wrote on was the same as the building material.
+
+By the way, what is deemed relevant may change over the course of 1,000 or 2,000 
+years. Many an archaeologist or linguist has spent countless frustrating hours
+trying to decipher the original writing under some later inscription. In a 
+similar way, art experts have gone to enormous lengths to uncover artworks
+which someone painted over rather than start a new canvas.
+
+But what if writing materials were cheap? Today we are much more likely to
+have notepads on our desks than little erasable slates or wax tablets. 
+
+Let's extend the analogy to computer memory. There was a time, perhaps four
+decades ago, when it was expensive and limited in availabilty. I recall seeing
+an information sheet about a mainframe ("What's a mainframe?" asks everyone
+under 40) that listed its specs, almost bragging about its memory, which was
+448K. Yes, that is less than half a meg. That computer ran a medium-sized 
+university. Within seven years, of course, people were carrying around floppy
+disks that held three times that much. ("What's a floppy disk?" asks everyone
+under 30.)
+
+It was only ten years or so prior to that time that the world saw the creation
+of this curious thing called UNIX (a play on the name MULTICS). Some of you
+reading this may have wondered (or not) why UNIX and its offspring stored a
+conceptual newline as a single linefeed character (rather than the somewhat
+more sensible "carriage return + linefeed" combination. The answer is that
+the designers wanted to save RAM and disk space. For every line of text, they
+saved an entire byte in this way. When a linefeed was sent to a device such
+as a terminal or printer, the OS typically converted it to a "real" CRLF pair.
+This all happened because memory was scarce and expensive.
+
+It isn't true anymore. In some cases, we may have learned bad habits and 
+forgotten how to conserve memory. But in general, we have more imortant things
+to worry about now.
+
+But let's think a minute. If memory is cheap and available, why are we
+turning it into a palimpsest? Isn't there something to be said for the idea of
+leaving data alone, never overwriting information, always writing new data
+somewhere else?
+
+If we do that, we have a "history" of what has happened in program execution,
+like a trail of breadcrumbs. More importantly, pieces of code that run
+concurrently need not worry about stepping on each other's data. One process
+(or thread or fiber) will never write over an item that another process is
+reading. If this doesn't eliminate synchronization issues, it at least
+mitigates them greatly.
+
+So I'm starting to see where immutable data could be a good thing. And I'm 
+starting to see how it's good for concurrency. And concurrency really matters,
+because it is the limiting factor of this generation of computing just as
+memory scarcity was a limiting factor one or two generations ago.
+
+In fact, I'll speculate a little about memory in general. Let's look 10, 20, 
+or even 50 years into the future. (My crystal ball, like everyone else's, is 
+very cloudy.) 
+
+I can imagine a time when memory is simply never erased at all. We're seeing
+the crude beginnings of this already. Source control systems and databases
+preserve far more history than they used to. My laptop's OS encourages me to
+think of my backed-up data as a sort of limitless archive of past versions of
+files. It's mostly an illusion, but it needn't always be. Why should any
+document, any image, any video ever be erased? 
+
+Food for thought. Chow down, friends. 

data/doc/old-posts/0011-computer-science-as-a-lost-art.lt3

@@ -0,0 +1,117 @@
+.mixin liveblog
+
+.post 11
+
+.title Computer science as a lost art
+.pubdate 2015-09-17
+.views computing 
+.tags
+
+.pin computing
+
+.teaser
+An old friend of mine asked me this in email last night...
+.end
+
+.quote
+ Thanks for taking the time here.  My younger son is interested in pursuing 
+ a career in computer science.  He's a freshman at Kennesaw State right now, 
+ but he really struggles with the idea of taking two years of classes that 
+ he has very little interest in.  There are three schools in Atlanta with 
+ 8- to 16-week full-day immersive courses that focus solely on technology: 
+ The Iron Yard, Digital Crafts, and General Assembly.
+
+ In the world of computer science, what is the opinion is of programs like 
+ this?  Is a 4-year degree viewed as more valuable? 
+.end
+
+*[This morning, this was my off-the-cuff answer:]
+
+Well, here is my opinion... I'm speaking as someone with two degrees and
+therefore six years in comp sci, as well as 30 years' experience. In other words,
+I'm old-fashioned, a freaking dinosaur.  :)
+
+There is a whole generation of computer people who are very different from the
+previous generation. CS used to be (and really still is) a very deep and demanding
+field.
+
+But two or three things have happened. First of all, computers are pretty much
+universal now. Do you know anyone under 80 who doesn't have one? Second, the
+World Wide Web (born in 1989 as a "face" on the more bare-bones Internet)
+started being invaded by the general public in 1995 or so. As usage became more
+common, it became more important to everyday life. And third, the tools we use
+to create applications have gotten a bit more sophisticated. It's easier to use these
+tools, just as it's easier to drive a car now than it was in 1905.
+
+What all this means is that there are more kinds of "computer person" than there
+ever were before. There are many thousands of "programmers" who never took
+a programming course. This is both good and bad.
+
+It means that a person can get the little things done while knowing very little. But it
+also means that this person probably will never learn enough to get the big things done.
+
+To be honest, I get secretly frustrated with the lower-level people who now exist
+in giant hordes. (I rarely tell anyone that.) To me, they are like people who have
+decided to learn 5% of their field in order to get a few things done, have some fun,
+and make a living.
+
+These people use tools to create little applications for everyday use. But remember:
+The tools themselves are also software. But they are a level of software far beyond
+anything these people could dream of creating. They use languages, editors,
+compilers, and operating systems; but they don't have the first clue about how to
+create any of these things or even how they really work.
+
+In 20 years, some race car driver is going to hold a kid in his lap, and the kid is
+going to say, "Well, I can drive a car, too. Everybody can drive a car. You just
+push the green button and say, 'Take me to Wal-Mart.'" And I kind of feel like that
+race car driver sometimes.
+
+Bringing it back to computers... My friend had a 7-year-old who used a fancy tool
+that he learned by himself, and he created a game for the iPhone. Sure, it was a
+simple game. But he did something by himself that a PhD could barely have done
+30 years ago (and not on a handheld device).
+
+To some extent, my complaints are valid. And to some extent, it's just me being
+an old-timer and a curmudgeon.
+
+Sometimes I interact with certain people and their complaints and questions show
+where they have reached the boundaries of their knowledge. And sometimes it's
+shocking to me. I think: You should have learned that in your first computer science
+class in your first semester. And then I remember: This person never had a real
+computer science class at all.
+
+Of course, generations before me look at me the same way. In the 1940s, you
+pretty much had to have a degree in electrical engineering in order to see or touch
+a computer. In the 70s and early 80s, you just had to be a science or engineering
+major. In the 90s, you just had to have a credit card (or have parents with a credit
+card).
+
+I'm very lost with hardware, by the way. I live on the keyboard. Every time I ever
+opened up a computer to try to change something, I screwed up two other things.
+I'm strictly a software guy. I've known people who made fun of me for that, and
+even older people who laughed a little at me because I didn't know how to use a
+soldering iron.
+
+It all depends really on what a person really wants to do. If you want to make
+online stores and shopping carts and web forms and pretty pictures and social media
+apps, then you don't need a degree in computer science anymore. Not even an
+associate's degree.
+
+If you want to make really interesting exciting things that have never existed before,
+if you want to make a tiny little difference in the industry and change the world just a
+little bit, then you do need that degree. If you want to make the tools and libraries
+that the lower-level people use, you do need that degree.
+
+Or look at it this way: If you want to build doghouses, just pick up some skills with
+hammer and nails, and then go for it. If you want to be an architect who designs and
+builds skyscrapers, then go get a degree in architecture first. But please (speaking
+again as a curmudgeon), don't learn to build doghouses and call yourself an architect.
+
+I hope this silly rant is helpful in some way. :) 
+
+Ask me any more detailed questions if you want to.
+
+Cheers,
+
+Hal
+

data/doc/old-posts/0012-ruby-day-in-turin-italy.lt3

@@ -0,0 +1,26 @@
+.mixin liveblog
+
+.post 12
+
+.title Ruby Day in Turin, Italy
+.pubdate 2015-11-10
+.views computing 
+.tags
+
+.teaser
+I'm honored to be speaking on Friday at Ruby Day in Turin, Italy.
+See http://rubyday.it for the schedule.
+.end
+
+I love my career, and I love traveling. It's nice when I get to
+combine them. This is one of those times.
+
+I'll be presenting a talk entitled "Elixir for the Rubyist" (the
+same as the title of the book I'm working on).
+
+If you're a Periscope user, be aware that I might try to stream
+some of this event (as well as some of my travels around the city).
+
+I'll also try to post a link to my slides later (and a video if
+they happen to make one).
+

data/doc/old-posts/0013-rubyday-was-a-success.lt3

@@ -0,0 +1,28 @@
+.mixin liveblog
+
+.post 13
+
+.title RubyDay was a success
+.pubdate 2015-11-23
+.views computing
+.tags
+
+.teaser
+On November 13, I attended Ruby Day in Turin, Italy. It was well worth the trip.
+.end
+
+Like any other Ruby conference, there was an eclectic assemblage of people. I only
+attended the English language talks, as my knowledge of Italian is very minimal.
+
+My own talk "Elixir for the Rubyist" was reasonably well attended and well received.
+I'll post a link to the slides and video later.
+
+I was personally very impressed by Ju Liu's talk on Sonic Pi. His style of teaching
+was an excellent example of what I call _incremental learning_ (for which there is
+probably a "real" term that I don't know). Additionally, it's hard to imagine anyone
+watching that talk and _not_ wanting to play with Sonic Pi.
+
+I also greatly enjoyed the talks by Ramon Huidobro and James Kiesel. Once those videos
+are up, I'll post links to those as well.
+
+Turin is a beautiful city. I look forward to going back sometime.

data/doc/old-posts/0014-working-on-the-blogging-software.lt3

@@ -0,0 +1,42 @@
+.mixin liveblog
+
+.post 14
+
+.title Working on the blogging software
+.pubdate 2016-04-14
+.views computing
+.tags
+
+.teaser
+Everyone warned me not to go down this road. I didn't listen.
+.end
+
+
+What I've heard is that once you start working on your own 
+blogging system, it's a rabbithole. You spend more time working
+on the code than you do blogging.
+
+I think I believe it. But is that really so bad? Coding, after all, 
+is fun. Isn't that one of the reasons we do it?
+
+It's true that I'm spending a lot of time reinventing the wheel (and
+doing it badly). But I'm also implementing features that I've never
+seen anywhere else. 
+
+And I like those features. They work for me.
+
+Besides, working on the Elixir book is plenty of writing. It doesn't 
+leave me with much energy for blogging.
+
+The big problem, of course, with "eating my own dog food" (as the 
+saying goes) is that it only has to be palatable to _(me). It is 
+unlikely that my blog code will ever really see the light of day, 
+because people would say, "You mean it doesn't even have feature X?"
+
+To which I could only reply, "I didn't want feature X."
+
+Or, "You mean it doesn't even catch this simple error condition?" To
+which I would have to reply, "I know not to make that error." 
+
+The first 90% of a software project is fairly easy. It's the second
+90% where it starts to get painful.

data/doc/old-posts/0015-ok-its-not-really-a-lost-art.lt3

@@ -0,0 +1,137 @@
+.mixin liveblog
+
+.post 15
+
+.title OK, it's not really a lost art
+.pubdate 2018-07-31
+.views computing
+.tags
+
+.pin computing
+
+.teaser
+I was surprised to learn that an old blog entry was 
+being discussed on reddit. Maybe I should update my comments a little.
+.end
+
+It seemed odd to me that a blog I had abandoned (_[mea culpa])
+had generated three emails to me in a single week. Finally
+someone pointed out to me that it had been reposted and was
+getting a little bit of attention.
+
+I haven't read all the responses from the numerous redditors.
+Maybe I'll read more later. This is my tentative response.
+
+Many have suggested that the speckled background is ugly and
+hard to read. Ugly, probably. Hard to read-- well, it looked
+OK on my screen. But, point taken, it's gone.
+
+Someone used the term "elitist sour grapes." That is probably
+largely correct. :)
+
+Someone else said you shouldn't trust someone who claims to be
+a web developer but doesn't know CSS. That, I would say, is 100%
+correct.
+
+But you see, I do not claim to be a web developer. In fact, I 
+specifically claim that I do _not know web development. 
+
+I realize that web guys have collectively made billions, maybe 
+even trillions of dollars over the years. And it is an absolutely
+necessary part of modern society, and I don't want to demean the
+people who are good at it and who want to do it.
+
+But web coding as such just doesn't interest me. I'm not good at it,
+and I don't _want to be good at it. I'd rather do other things.
+
+I'm not a programming "god" or "rock star," by the way. I'm 
+just a guy who's been doing this a long time, but has not stuck
+to one thing long enough to be considered brilliant. 
+
+The user LondonPilot raises some very interesting points. I wish I 
+could buy him a beer or six (or substitute beverage of choice). 
+
+In fact, his argument is sort of the flip side of mine-- and arguably
+the more important angle on the whole situation. I would even say that 
+I have made the same argument at different times and places in the past.
+
+Here's a good example. I recall a time in the early 90s, when personal 
+computers were less common, I had two friends who had recently got 
+married. He was an electrical engineer, and she majored (I think) in 
+English. This was 1992, when Windows 3.1 was hip and trendy in some
+circles, and DOS was still very much alive.
+
+Jon slightly bemoaned the fact that Joyce used a Mac rather than a PC.
+He made the comment that "people don't learn anything about computers
+that way." I suspect from his hardware-oriented point of view, the DOS
+command line was pretty super-high-level.
+
+In some ways, I sympathized. But I made the counter-argument that a 
+toaster is meant to toast bread, not to teach us about electricity. 
+(He hated this analogy.) But I often felt the computer should become 
+invisible-- that the proper response to "What are you doing?" should 
+be "I'm writing a paper" or "I'm designing a graphic" or whatever-- 
+it should never be "I'm using the computer." And we've made some great
+progress there in recent decades.
+
+Let me amend what I said before. I don't _mean to backtrack (though I 
+probably will), but to clarify and expand. 
+
+First of all, there _are in fact certain small lessons from computer
+science that even a modern "clean hands" developer should know. I 
+cannot _count the number of times I have seen a programmer (and I 
+really wanted to put quotes around that) who was absolutely _incensed
+that `[(2.0/3.0)*3.0] was only `1.99999999 or thereabouts. I have seen
+people who were _livid and demanded that this bug be fixed.
+
+I have also had difficulty explaining that no matter how fast your
+processor is, an algorithm that is `[O(N^2)] can eventually bite you. 
+I have seen people who didn't know that hard disk access is typically
+slower than memory access. I could go on.
+
+Having said that: You can get an awful lot done these days without any
+CS coursework. You can create things that are useful, worthwhile, and
+certainly financially successful. 
+
+And there is nothing magical about a degree anyway. What counts is 
+domain knowledge-- and I mean enough knowledge to be truly effective, 
+not just "enough to fool your manager" (and perhaps not just "enough
+to pass a boot camp").
+
+So getting back to the excellent comments by LondonPilot-- I think
+perhaps there should be another field or discipline split off from
+computer science. This would be parallel to what I believe happened
+with electrical engineering and computer science. 
+
+I studied CS for 6 years, and as far as I recall, I only had two or
+three EE courses (including one lab). To the generation before mine, 
+that might seem like a horrifying concept.
+
+So let's imagine a new major. I don't know what to call it-- maybe
+"High-Level Computing"? Not a great neologism, but I'll run with it
+for now. An HLC major would certainly have one or two courses that
+were from traditional CS (just as I myself had my fleeting glimpse
+at EE material). But the rest would be more pragmatic, more about
+gluing this piece of tech to that one, properly trusting that the
+components were created and tested by CS people-- just as I properly
+trust that my CPU works as advertised and never try to build my own.
+
+As LondonPilot said, this is not a bad thing. This is how human
+progress works.
+
+I do wish that more web developers had deeper knowledge. But (and 
+here I may truly be backtracking)-- it does not have to be super-
+deep knowledge. I probably said it did, but I was wrong, of course. 
+As long as there are cars, there will be people who understand the 
+workings of the engines; but a self-driving car will be perfectly 
+useful in getting from point A to point B. Part of the point of 
+technology is to make it easier to accomplish tasks with less effort
+and less specialized knowledge.
+
+So my modest proposal would be: Let CS give birth to a new field
+just as EE gave birth to CS. EE did not die, and CS will not die 
+in the imaginable future. Let's just admit these are different
+ways of thinking now, and should perhaps be different tracks.
+
+Thank you to all who responded. Maybe I'll dust off this blog again
+soon.

data/doc/old-posts/0016-an-in-operator-for-ruby.lt3

@@ -0,0 +1,142 @@
+.mixin liveblog
+. ^ get rid of this later
+
+.post 16
+ 
+.title An 'in' operator for Ruby
+.pubdate 2019-11-13
+.views computing
+.tags 
+ 
+.pin computing
+
+.teaser
+I have had two fairly small changes I wanted to make in Ruby. The first
+was realized years ago. 
+.end
+
+Hashes now preserve insertion order and iterate in a predictable way.
+That's fairly minor, but it did/does have some use cases, and it had no impact
+on performance.
+
+Here's another one. Personally, this is a bigger thing to me.
+
+<b>I've always believed personally that Ruby should have an `in operator.</b>
+
+I've mentioned this in speaking (including lightning talks) and in writing.
+It's not a _giant big deal for me, but it is one of my personal favorite ideas.
+Here are some details.
+
+ *[My proposal]
+
+I propose to let `[ x in y] be syntax sugar for `[y.include? x]
+
+ *[You may ask: Why?]
+
+<ul>
+  <li> `include? is backwards from common usage -- if the _item is our focus, we don't ask whether a group includes an item, but whether an item is in a group. The same is true of a container.</li>
+
+  <li>Ruby isn't English; and more generally, programming languages aren't human  languages. But programming languages are <i>based<i></i></i> on human languages and on  everyday experience. We do sometimes ask questions like "Does this container  or group include this item?" We are asking a question <i>about the group</i>.  <br><br>   `[if barrel.include? rotten\_apple       # Is barrel going bad?]   <br><br></li>
+
+  <li>But we also -- perhaps more often? -- ask questions like "Is this item part of this group?" We are asking a question <i>about the item</i>.  <br><br>    `[if fruit in [:apple, :pear, :peach\]    # Is this fruit something I like?]  <br><br>
+
+  <li> `[include?] is backwards from mathematical usage -- we ask whether a member is in a set ("epsilon"-like notation), not whether a set contains a memeber.
+
+  <li>I ran across someone else a couple of years ago (I wish I could remember who it was!) who bemoaned the absence of this operator. His argument was that he would have a "conversation" with an object, for example, when he tested it repeatedly. Here's a contrived example I just made up.
+
+.code
+    if foo == var1        ||
+       foo =~ var2        ||
+       foo < var3         ||
+       var4.include?(foo) ||  # <== This is the ugly part
+       foo > var5]
+.end
+
+To quote him as well as I remember: "I was having this perfectly nice conversation 
+with ``foo, and then `var4 interrupted it..."
+
+Better:
+
+.code
+    if foo == var1 ||
+       foo =~ var2 ||
+       foo < var3  ||
+       foo in var4 ||
+       foo > var5]
+.end
+
+  <li>I prefer to put the tested entity earlier in the statement:</li>     
+.code
+    if [GA, VA, MS, TX, MD, NC].include? state      # ehhhh
+    if state in [GA, VA, MS, TX, MD, NC]            # better</tt>
+.end
+
+  <li>Also a "variable/constant" issue -- I tend to put the variable data on the 
+      left and the constant on right; this is unlike  people who say `[if 5 == x]. 
+      (After all, `5 is only equal to `x very  rarely; `5 is <i>always</i> equal to 5, 
+      even for very large values of 5.)
+
+  <li>Also a question of focus: Whatever entity you are really dealing with, 
+      name that one first.
+
+  <li>Many languages already have an `in operator -- notably Python, Pascal, 
+      even SQL. It is familiar to users of those languages as well as those 
+      who use mathematical notation.
+
+  <li> `in is already a reserved word in Ruby -- used in the `for loop (syntax 
+      sugar for `[each]). Let's increase the justification for its presence.
+
+  <li>An `in operator would sometimes make parentheses unnecessary:</li>     
+.code
+   if (10..100).include? x   # Need parens
+   if x in 10..100           # Don't need parens -- also prettier code
+.end
+
+  <li>The newer language Elixir (which I'm happy to report occupies a lot of my 
+      time lately) also sports this operator. This is yet another reason to 
+      love that language.
+</ul>
+
+  <b>Frequently Whined Whines</b>
+  <p>
+  <ul>
+  <li><b>I'd prefer a method.</b> I understand this, but I find it to be 
+      needlessly ugly. I like less punctuation, more whitespace. And I 
+      find this inappropriate for something that is conceptually an operator.
+
+.code
+    if x.in mylist    # ugly   
+    if x.== 5         # also ugly   
+    if c1.and c2      # ugly - if it worked    
+    if x == 5         # better   
+    if c1 and c2      # better   
+    if x in mylist    # better
+.end
+
+  <li><b>I'd prefer a method with a</b> <tt>?</tt> <b>on it.</b> I understand 
+      the concept, too, but I find it inappropriate for what is inherently a relational operator.
+
+.code
+     if x.in? my\_set   # very ugly   
+     if x.==? 5         # very ugly - if it worked
+
+     if x in my\_set    # natural
+     if x == 5          # natural
+.end
+
+  <li><b>What about</b> `[for x in list] <b>? Would this evaluate as </b> 
+      `[for true] <b> or </b> `[for false] <b>?</b> Certainly not. It's a matter 
+      of parsing. The `for loop itself is just syntax sugar.
+
+  <li><b>I'll bet you like junctions, too.</b> No, in fact, I dislike junctions greatly. I don't even know Perl. Are junctions still a thing?
+
+  <li><b>If you like SQL's</b> <tt>in</tt> <b>, you must like</b> <tt>not in</tt> <b><b>also.</b></b>  No, I don't condone its use of "not in":
+
+  <tt>if item not in collection  # travesty!</tt>  <tt>if ! (item in collection)  # ok</tt>
+
+  <tt>if x not == y              # horrible Ruby travesty - if it worked</tt>    Yes, I say this even though <tt>! ( item in collection)</tt> requires parentheses.    See the comment about parentheses on ranges.
+
+<li><b>What about precedence?</b> I would place <tt>in</tt> at the same level of precedence as the (other) relational operators <tt>< > <= >=</tt> etc.</ul><b>Conclusion</b>
+<p> 
+People have ignored me on this for at least ten years. They probably still will.
+That, as they say, is life.