Friday, November 22, 2019

On Writing (Code)

Introspection into my own process for making software has led me to believe that writing prose and programming are fundamentally the same. This was further highlighted for me when I read Stephen King's On Writing. I saw interesting parallels between the way he likes to work and the way I like to work. Also my code is a horror story.

King likes to write a first draft as quickly as possible. He does this to get the story out. He doesn't worry about character development or even holes in the plot. Those he will fix up in the second draft. The first draft is about getting onto paper the good bones of a story. Then he lets the first draft sit for a couple of weeks.

When he can come back to the first drift and it looks familiar but not quite—like it was written by his doppelganger—then he has enough distance to make the second draft. That's where any story issues are fixed and things are smoothed out and tightened up. His goal is to make the story 10% shorter.

When I write code:

  • I like to write code breadth-first so I can see all the moving parts and that everything fits together.
  • I like to let it sit for a couple of minutes, or hours, or days—whatever I can afford.
  • I like to smooth things out and tighten things up in the second draft—things like function names, refactoring, etc.

Maybe writing code isn't exactly like writing prose. Maybe it's more like knitting or woodworking or cycling or solving crimes. I think part of the reason that programmers tend to see their work in everything, is that programming is really just process for solving problems and giving form to thoughts. Those skills can be applied to many different domains. Maybe in that way it actually is more like writing than other hobbies?

At least I didn't say that programming is like gardening. I actually appreciate gardening as a hobby because of the fact that it is entirely different than making software!

Tuesday, November 12, 2019

How to Survive Life Undamaged

How does one survive life undamaged? Seriously... if you figure it out let me know. I particularly mean self-inflicted damage. You can't guarantee anything about how other people act or think.

Here is what I have tried (am trying):

1. Be willing to listen to others.

You don't have to listen to everyone, but be aware that you risk losing valuable perspective and insight, even if it is insight about how not to do things. You should probably be willing to listen to some people that you have shut out. If you are not uncomfortable, then you are not growing.

Everyone has a story. You can either imagine a person's story, categorize and label them, and treat them as if that story is true, or you can actually listen. You can listen to what someone believes while thinking about why they're wrong and how you will show them, or you can try to inhabit their space and see the world the way they see it. You don't have to stay there, but you will take lessons from it.

2. Be skeptical by default.

To listen to others and inhabit their space does not mean uncritically accepting their ideas. You can be empathetic, you can entertain an idea, without being swept away. You can also question if a person is wrong without imagining they are your enemy.

If some idea pushes through your skepticism, accept it. It is OK to move a little closer towards an "opposite" view.

3. Don't try to convince everyone.

This can be particularly painful when it is someone you respect and/or love. It may take time. Or it may never be. Life is sour sometimes. Don't make it more sour than it needs to be.

If you are skeptical by default, then maybe others are as well? If you are listening to others and inhabiting their space, then you must know that it will not be easy to convince everyone. You can let that bother you. You can turn it into an obsession, or you can focus on the good (what little you estimate there to be) and seek friendship.

These are three things you can try. If you refuse to listen to others and make it your life goal to convince everyone how they're wrong. You will have a life filled with stress and bitterness. Or you could listen--critically--and seek friendship over rightness.

Wednesday, November 6, 2019

Beyond Techniques

I firmly believe that writing software is a creative act. I believe that a construction project---or any other linerally presenting process---is the wrong analogy for software development. A much better one is writing prose, which is a process of writing and rewriting and rewriting, and sometimes throwing it all out and starting over. In the same way a software engineer names and renames, factors and refactors, etc., then extends the functionality by doing it all again. This all has to fit into the larger code base in a way that makes for a consistent whole. This requires judgement and taste.

To come at the argument from the other side, if you spent your days rewriting the same code over and over, then you would split it into more generic functions and perhaps a library. If you're solving the same problem that someone else has solved, then you would just reuse their software. This does in fact happen, and yet software engineers still get paid to work, and the value they generate is in the new stuff that requires creativity. Sure, there are some inefficiencies that mean people rewrite software that they could have just reused, and you could argue that the new things to be done are increasingly marginal, but on the whole software engineers would be out of work if there were not new things to create. Ergo writing software is a creative act.

The next reasonable question is: how does one create? I believe that fundamentally, and on average, one cannot directly induce creativity. This isn't entirely satisfying. I wish creativity was a predictable, mechanical process. Is it possible to discover and categorize tools for thinking? I'm still exploring that. Here's an example: to get a fresh perspective on your problem think not about how to solve it, but how to avoid failing to solve it. Instead of trying to figure out how to build a stronger bridge, maybe you'll gain insight by considering how to avoid building a weaker bridge. This technique for finding fresh perspective...does it not make creating into a predictable, mechanical process?

I actually like techniques. I believe the learning process is (or is best) technique based. Think about learning to cook. You start by following the recipe. Then you start to improvise. You understand that this ingredient is for flavor and can be adjusted to taste, but that ingredient provides aeration and messing with it too much will produce a dense, inedible result. Eventually you move beyond techniques and start to construct your own recipes from first principles. A poor education either starts with first principles, which a beginner does not have the experience to appreciate, or focuses too much on techniques divorced from context, which frustrates learners because they don't know how to properly apply techniques. I intended my book Clojure Polymorphism to position itself as a way to explore varied applications of the same tools and techniques, which I hope will guide readers from knowledge into wisdom.

The writing curriculum we use in homeschooling our children is technique based. A child reads an essay and creates an outline of the important points (there's a whole set of techniques for that). Then he will rewrite the essay from the outline applying techniques like "ly"-words, openers, and clinchers. This removes the hand wringing about what to write about. (Incidentally, if you read Ben Franklin's autobiography, this is the way he improved his own writing.) What if computer programming was taught this way? Here's a program that consumes a CSV file, changes some things, then writes it back out. First write out a high level algorithm for the program, then rewrite it using 3 of the 15 techniques you've learned (concurrency, multimethods, asynchronous channels, etc.). Repeat. I think this would produce wiser programmers.

However, eventually you need to move beyond techniques. Leaning on techniques is just shifting the problem elsewhere. Coining techniques is an attempt at mechanizing creativity, but instead of making creating mechanical, you are now faced with choosing which technique to apply to generate a creative solution. Now the creative leap must occur earlier in the process. You can try each technique in a brute force search, but I doubt many (if any) would consider that "creative," nor is it particularly efficient. The experience of repeatedly applying techniques should help you develop judgement and taste, so when you're faced with inventing from first principles, you have some gut sense or guiding aesthetic. That guiding aesthetic is not some set of rules for when to apply which techniques. If it were, then it would become a "library," so to speak. Anybody---or any machine--could evaluate the rules and perform the steps.

Techniques are great for broadening your learning, but they are not self applying. Learning all the techniques does not help you invent new techniques, nor will it induce creativity. You can know how to cut impeccable dovetails and square up lumber and drill straight holes, but that does not mean you will create beautiful furniture.

How does one develop this guiding aesthetic? You read a lot of other people's code. You write a lot of code. You read a lot of books. You work hard. Sorry, that's the best I've got. This is a continuing be continued.

However you do it, the end goal should be to move beyond techniques.

Wednesday, October 30, 2019

Virtual Machine Oriented Development

Most computing devices that we have today---desktop, laptop or phone---are capable of computing any program that can be computed. There's a bit of equivocation there. What is meant is that anything that a human can manually calculate via rote, mechanical process can also be done by computer. This is the Church-Turing Thesis.

I've never really stopped to think, but what would a non-universal computing machine look like?



Several years back I suffered a bout of jealousy. I thought about engineers in other fields who build roads or buildings or even cars. A civil engineer can imagine something they've build standing still amidst the blur of 100 years passing by. An automotive engineer can imagine a car they've designed still driving the roads in 20 years.

I don't think a single line of code that I wrote 3 or more years ago is still in production, and that's ignoring all the code that I wrote that never made it into production.

These are the kinds of things you start to ponder as you reach the ripe, old, programmer retirement age of 33.

But then a funny thing happened. I played Sam & Max Hit the Road ... on my Android phone.

Here was a game released in 1995 and I was playing it on my Android device in 2014. How did that happen? Well, when LucasArts designed the game "Maniac Mansion," they decided to create a scripting language and write the game in that language, and they used that scripting language for many of the games they made. I have several original LucasArts games on CD. Some are PC versions some are Mac versions.

Over the years as I feel the nostalgia hitting me I'll grab the game files from the CD and download ScummVM for whatever platform I'm on at the time. I copied the game files to my phone and downloaded ScummVM from the Play store. That's how it happened.


Data is Code

I had been exposed to Lisp, and even written a lot of Lisp before I finally had my enlightenment about macros and metacircular interpreters. I remember vividly reading Structure and Interpretation of Computer Programs and seeing Scheme put to use creating simple yet powerful abstract interpreters. The author's start "simply" with interpreters that add new programming paradigms to Scheme. Then they proceed to simulating a register machine and writing an assembler and compiler for it. This happens in the last chapter, a space of ~100 pages.

It is a Divine joke that Structure and Interpretation of Computer Programs and The Art of Computer Programming had their titles swapped, because---while I don't wish to denigrate TAOCP which is a depth of amazing riches---SICP is about art, and in a metacircular way it is art.

It is too easy as a Lisper to understand the world this way, but data is always code. In Forth, 5 is not a number, it is an instruction to push the value 5 onto the top of the program stack. Your program receives a program as input. It receives files, network packets, key presses, and mouse clicks. It interprets this program and produces output.

A PDF file can cause a buffer overrun in a PDF reader because each byte is literally an instruction to your program-as-interpreter to "write a value at the current location and move to the next location" (or at least it can be if your program-as-interpreter has flawed semantics).

This is not a property of Lisp, it is a property of the stored program computer, Universal Turing Machine, von Neumann architecture. Code and data are made of the same stuff and stored in the same memory.


The Non-Divine Joke

In his talk "The Birth & Death of JavaScript," the 2014 version of Gary Bernhardt extrapolates where JavaScript and asm.js will take the world in 2035 (after an apocalyptic global war, of course). The punch line is that instead of JavaScript running on computers, computers run on JavaScript. This happens through a comical stack of emulators emulating emulators that emulate. Actually I think it's compilers transpiling compilers that transpile transpilers, but...same difference.

But like every joke there's a bit of truth to it.

Paul Graham writes about "Programming Bottom-Up" where you build the language "up" to your program to the point that actually expressing your program becomes somewhat trivial. You're building a domain specific language to solve exactly the problem you have. Again, this is all too natural for Lispers, but everyone does it.

The act of programming is to turn a universal computing machine into a limited computing machine. You build out data types and operations to focus the abilities of the computer into a specific domain. Programmers instinctively understand this, which is why we find it so funny that---in a twist of irony---a universal computing machine emulates a universal computing machine emulating a universal computing machine.


Virtual Machine Oriented Development

I started thinking about Virtual Machine Oriented Development because I was concerned about the transience of my legacy. I noticed that there were software products that were still around 20 years after they were written. I started seeing a VM underneath them.

But having thought about it more, I don't think that Virtual Machine Oriented Development is just about legacy. I think it might clarify the design process to be explicit about the fact that we're designing a limited computing machine that analyzes sales data. What are the data types? What are the operations? If you have power users, maybe they'd even like a scripting language that can describe which data to import and then how to analyze it?

You might find then that you've abstracted your problem into a computation model that will become valuable for years. Maybe you'll end up rewriting the interpreter for this language several times, and all the while users can keep using their existing scripts.



What does a non-universal computing machine look like? It looks like every program you've ever written.

Wednesday, August 7, 2019

Speed Reading

My reading habits are lumpy. I find I'm either not reading anything, or I'm reading seven books at once, and when I am, I wish I could speed read. I have in the past read books on speed reading, and they usually boil down to techniques like increasing your eye span, eliminating regression, eliminating subvocalization, etc. The theory seems to be that your brain can work much faster than your eyes, and you just need to eliminate bad habits, and establish some better ones, so you can get the words into your brain faster.

I do feel like there's something to this. In my experience, my mind tends to wander as I'm reading, and sometimes it's easier to skim since that keeps my mind busier trying to assemble random bits and pieces into a comprehensive whole. That seems to be the idea with this new speed reading book that I picked up called "Speed Reading With The Right Brain." The author claims that by engaging your brain in conceptualizing what you're reading as you're reading, you increase comprehension, and it is through increased speed of comprehension that you achieve increased reading speed. I want to believe, but I'm still skeptical.

What I would love is some reference that approaches speed reading from an empirical approach, you know, with science. What do we know that actually works based on research? may not like the answer.

Speed Reading is Fake

In looking for an empirically backed approach to speed reading, I came across "So Much to Read, So Little Time: How Do We Read, and Can Speed Reading Help?" This article is based on decades of reading research and cognitive psychology. One of the authors—who passed away from cancer a few days after the first draft—proposed the article "because he felt that it was important to share the knowledge we have gained from experimental science with the general public."

While there may be savants who can read impossibly fast without sacrificing comprehension, controlled studies show that for normal people learning to read faster means comprehending less. When you learn to "speed read" you are actually learning to skim. "Taylor notes that [Evelyn] Wood 'repeatedly stated that her people are not skimming, but rather are reading' (Taylor, 1962, p. 65). Based on recordings of their eye movements, however, Taylor concluded that they closely resembled the eye movement patterns produced during skimming (Taylor, 1965; see also Walton, 1957)." Also from the article:
The speed readers did better than skimmers on general comprehension questions about the gist of the passages but not quite as well as people reading at normal speed. … The advantage of trained speed readers over skimmers with respect to general comprehension of the text was ascribed by Just and colleagues to an improvement in what they called extended inferencing. Essentially, the speed readers had increased their ability to construct reasonably accurate inferences about text content on the basis of partial information and their preexisting knowledge. In fact, when the three groups of participants were given more technical texts (taken from Scientific American), for which background knowledge would be very sparse, the speed readers no longer showed an advantage over the skimmers, even on general questions.
According to the article, learning to speed read may improve your ability to skim, but only for familiar subjects. This isn't necessarily bad news for two reasons:
  1. You can improve your reading speed, just not as dramatically as speed reading advocates suggest.
  2. Learning to skim effectively is a useful skill to learn.

Improve Your Reading Speed

The average person reads between 200-400 words per minute. What is the best way to improve your reading speed? Practice. Unsurprising. Perhaps a little disappointing? There are a couple ways that practice increases your reading speed, but they basically break down to improving your language skills:
  • better vocabulary
  • exposure to more writing styles
The broader your vocabulary, the more familiar you are with words and styles, the more quickly you can read. Your eyes fixate less on words with which you are familiar, so they move more briskly across the page. Your familiarity with style allows you to anticipate better how a sentence will end when you've only read part of it. Also, "written language uses some vocabulary and syntactic structures that are not commonly found in speech, and practice with reading can give people practice with these."

The more you do reading, the faster you'll get.[1]

Learn to Skim Effectively

Effective skimming is mostly about trying to extract structure and important ideas from a text. Scan for:
  • headings
  • paragraph structure
  • key words
According to the article, "Research has shown that readers who pay more attention to headings write the most accurate text summaries (Hyönä, Lorch, & Kaakinen, 2002)."[2] You can also do things like:
  • scan the table of contents
  • read the first paragraph of each section
  • read the first sentence of each paragraph
Again from the article:
The eye movements revealed that skimmers tended to spend more time reading earlier paragraphs and earlier pages, suggesting that they used the initial parts of the text to obtain the general topic of passages and provide context for the later parts that they skimmed in a more cursory way. Therefore, effective skimming means making sensible decisions about which parts of a text to select for more careful reading when faced with time pressure. In fact, Wilkinson, Reader, and Payne (2012) found that, when forced to skim, readers tended to select texts that were less demanding, presumably because they would be able to derive more information from such texts when skimming. This kind of information foraging is a useful method of handling large amounts of text in a timely manner.
You know what else helps you skim effectively? Practice. Practice gives you a broader base of knowledge and experience to draw on:
That [knowledge/experience] may be the basis for some anecdotes about the speed-reading abilities of famous people, such as that President Kennedy could pick up a copy of the Washington Post or the New York Times and read it from front to back in a few minutes. However, consider the knowledge and information that someone like Kennedy would bring to the task of reading the newspaper. As president, he was briefed about important world events each day and was involved in generating much of the policy and events reported in the newspaper; thus, he probably had first-hand knowledge of much of what was described. In contrast, the average person would come to such a situation with very few facts at his or her disposal and would probably have to read an article rather carefully in order to completely understand it. To read rapidly, you need to know enough about a topic to fit the new information immediately into what you already know and to make inferences.
Of course, the downside of skimming is that you are skipping over portions of text resulting in lower comprehension. However, if you're looking to get a general overview or find one specific fact, then it can be useful. It may also be good for a first pass at a text before reading in depth.


I do feel as though my mind wanders when I read, and I wonder whether there is a way to better engage my mind when reading. Perhaps conceptualizing or visualizing or some other way of focusing more would help comprehension and speed. If and until I and figure that out, I can improve my reading speed by practicing and getting better at skimming, when skimming makes sense.

[1] I wonder (off-the-cuff, anecdotally, non-scientifically) whether writing more also improves reading, for the same reason: it improves language skills.

[2] Interestingly, this means that as an author you bear some of the burden for helping readers quickly consume your writing. I had started to shy away from listicle style blog posts, thinking I'd try to contribute to a more high minded discourse that rewarded effort in reading and comprehending. This article has more headings and lists...maybe I'll do a little of both. :)