scriptorium 0.6.1 → 0.7.2

data/doc/old-posts/0008-concerning-the-term-monkeypatching.lt3

@@ -0,0 +1,105 @@
+.mixin liveblog
+
+.post 8
+
+.title Concerning the term "monkeypatching"
+.pubdate 2015-08-10
+.views computing 
+.tags
+
+.pin computing
+
+.teaser
+There have been many "dark days" in the Ruby community, some much darker than others.
+.end
+
+Guy Decoux died, \_why the lucky stiff\_ left us (without dying), Jim Weirich died. (Yes, I count
+actual deaths as the darkest moments of all.)
+
+But I count another dark moment that many of you will not. When I had been using Ruby a
+little more than six years, in December 2005, the term "monkeypatching" was introduced
+into our circle.
+
+It was a post by Drew Mills, quoting a blog from a Python person who apparently hated Ruby.
+I don't blame Drew. I don't suppose I "blame" anyone. But I regret that this slang has entered
+our culture.
+
+The post Drew quoted was this:
+
+.quote
+  It's the second generation that's going to be less enthused,
+  that's going to stare in bafflement at these classes that
+  mysteriously spawn methods, and trying to figure out what's
+  going when there's an exception in dynamically generated
+  code. You can monkeypatch code in Python pretty easily, but we
+  look down on it enough that we call it "monkeypatching". In
+  Ruby they call it "opening a class" and think it's a cool
+  feature. I will assert: we are right, they are wrong.
+.end
+
+Before I go on to my main point, I'll make an observation that is arguably much more interesting.
+If you read again, it sounds like the Python person (Ian Bicking) was talking about dynamic method
+dispatch (the use or abuse of method_missing) rather than actual open classes.
+
+Someone later in that thread decried the "ignorance" of Bicking with regard to this -- that he didn't
+even know enough Ruby to know the difference between dynamic dispatch and open classes. I
+wonder if the original pythonism meant something different? Since I never completed my Python
+studies, I can't comment.
+
+At any rate: Back to my story.
+
+I still recall the revulsion I felt, almost physical nausea, when I read this the first time. That's probably
+a somewhat extreme response on my part.
+
+I regarded open classes as a programming technique that is potentially very powerful but easy to misuse.
+This sounds like a "good and yet bad" argument. But let me rephrase that sentence.
+
+Open classes are a technique that is potentially very powerful _(and therefore) easy to misuse. That is
+the point. Any tool that is powerful enough is prone to misuse by people who are unskilled.
+
+The term "monkeypatching" is obviously a pejorative term. Upon seeing it, my first thought was, "I am
+not a monkey, and I am not 'patching' anything."
+
+After all, that is the implication. The term implies that the developer is a monkey, and that the work he is
+doing is sloppy or shoddy. It is an insult both to the quality of the developer's work and to the developer
+himself.
+
+So it bothered me because it was a pejorative and it was insulting to us as programmers. It was also
+(arguably) an insult to Ruby itself and therefore by extension an insult to Matz.
+
+I dislike being clannish, though perhaps sometimes I am. After all, Ruby is not (supposed to be) anyone's
+religion or cultural heritage. It's only a programming language, and I think it's very much like Python. But it
+also bothered me that this neologism originated _outside our community, in particular with the Python
+community.
+
+Generalizations are always wrong. (Yes, that's a joke.) And stereotypes as such are at least useless if not
+actually hurtful. And yet I always heard about the arrogance and rudeness of Python programmers, and I
+occasionally saw real evidence of it. And though I dislike the word "nice" in general, I always found it interesting
+that Ruby coders were labeled as "nice" (as in the abbreviation MINASWAN, "Matz is nice, and so we are nice").
+
+So when this usage was introduced, I felt rather as though someone had opened my front door and dumped a
+large piece of dog manure onto my carpet. What is worse, it has wormed its way into common usage in our
+community, even in documentation. A lot of this happened in the early days of Rails, when fate dumped a huge
+influx of newbies onto the Ruby community. Not to disparage the Rails people in general, but at the time this
+felt much the same as it did back when AOL (America Online) made its debut and dumped millions of (insert
+noun here) into the Internet and Usenet communities.
+
+It's impossible to stop this usage now (like so many other usages in the English language having nothing to do
+with computing). But I still protest, and I still stand against it.
+
+The term "monkeypatching" appears only once in more than 800 pages of _[The Ruby Way]. It occurs when  I
+say I don't condone this term, and it won't be used further in the book.
+
+As an aside: The "refinements" which exist in recent versions of Ruby make open classes stricter and safer. I'll blog
+about that later. But this isn't much of a technical post. It's just a reminiscence and a rant.
+
+So basically I hate the term "monkeypatching." I am polite to people who say it to me (e.g., in asking a question), but
+secretly I want to just ignore them.
+
+The last time I saw Jim Weirich, in New Orleans, he and I talked about this. He agreed it was a pejorative term,
+and it was a shame it had entered the common dialect, though there was really nothing to do about it. But being
+much more level-headed and good-natured than I am, he wasn't bothered much by it.
+
+I really miss Jim, by the way. He was a truly brilliant developer and an amiable and wonderful person in general.
+If it would bring him back, I would gladly change the book's name to _[The Art of Monkeypatching].
+

data/doc/old-posts/0009-announcement-coming-soon.lt3

@@ -0,0 +1,20 @@
+.mixin liveblog
+
+.post 9
+
+.title Announcement coming soon...
+.pubdate 2015-08-11
+.views computing
+.tags
+
+.teaser
+Maybe this will stir your curiosity a little. I hope it does.
+I've started working on a project with someone else, and I 
+think it will be really worthwhile.
+.end
+
+This will be launched within 48 hours and announced at the
+Lone Star Ruby Conference in Austin, Texas (October 15).
+Maybe it will be leaked a little before then, too.
+
+Sit tight 48 hours or so... 

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.