Skip to content
Browse files

## May 7, 2019

{: toc }

### Essay ideas from early April

I sometimes go through phases of creativity where I start a bunch of essays or talks that I never get around to finishing. This happened early this past August. But I had *so* many ideas that I didn't even have time to finish *outlining* them all. I took an hour today to get those outlines in here *without cleaning them up much so they will mostly be nonsense to anyone but me*. I created separate files for these outlines:

* [Tentative derivation of compositionality as the primary subgoal of PL/HCI design](/drafts/composability)
* [Natural Langauge is not and will never be the future of coding](/drafts/natural-langauge)

The rest of them were just small stub outlines so I'll put them right here in the log:

#### Where is the line between programming vs using a computer?  (stub outline)
<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Programming is setting up computation over time. Unfortunately this means that many important insights about your program aren&#39;t apparent until future times  Live programming is about bringing insights from future times to the time of programming</p>&mdash; Steve Krouse (@stevekrouse) <a href="">April 4, 2019</a></blockquote>

And this thread:

#### What is programming?  (stub outline)
<blockquote class="twitter-tweet" data-conversation="none" data-lang="en"><p lang="en" dir="ltr">For what it&#39;s worth, I really like the &quot;soft&quot; part. My vision for software is that it &quot;feels like clay&quot;, is infinitely customizable, the sky is the limit. It is the stuff of thoughts, not of atoms. Fiction, not nonfiction</p>&mdash; Steve Krouse (@stevekrouse) <a href="">April 7, 2019</a></blockquote>

Programming is the study of precision like math is the study of long chains of close reasoning without paradoxes and history is the study of past humans through text.  
#### Learning to Code Isn't a Thing  (stub outline)
* just like learning to speak a language (or use a computer) isn't a thing  
* personalization and intrinsic motivation is key, then env feedback loop, easy setup, googleability, unstuckability
<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">When helping someone learn to code, I ask them what they want to be able to code. Then I help them find an environment (coding notebook, online IDE, desktop IDE, Zapier, spreadsheet, etc) with the best feedback loops, easiest setup. The language is not part of the equation <a href=""></a></p>&mdash; Steve Krouse (@stevekrouse) <a href="">April 6, 2019</a></blockquote>
#### Immutable Code Editing (stub outline)
editor = f(node, editState) so f can be a recursive polymorphic func... cyrus and hazel... cursor is key<  
Recursiveness of the state = lift validatorfunction allModifyerFunctionstreams initial state  
But then of course each piece of this defition is a behavior with it's own validator function that's a behavior with it's own validator function...  
Ultimately this Programming Language is one single fucking immutable expression! It is Behavior [Expressions] (aside: I want Behavior length list where each item is Behavior) defined as (fold processEdit (fold concat newExpression []) Behavior [self]  

[This SVG is hard to read but shows a bit of the thinking here.](
#### How many language features can be replaced with editor ones? (stub outline)

* lets, closures, imports (Cyrus Omar of Hazel talks about this)
* it seems like most things can be editor features, especially if the editor is recognizing patterns and making syntactic sugar out of them (a la lamdu)
* it's the things you want in the AST (stored as metadata) that maybe should be in the language semantics?

### Week of May 5th, 2019 (and beyond)

Yesterday I cleaned up my email, todo lists, random errands, and went on a run. I also had dinner with Sam John of Hopscotch, which was fun.

Today I did more errands, a bit of consulting work for TCS, and adding things to the website I've been meaning to for a while. I also cleaned up my workflowy which feels great.

My meeting with Dark was pushed to next week, which frees me up to work on my research proposal draft 2 this week, which is due on Friday and then I'll speak with JE afterwards about next steps.

Next week the focus will be Zapier for Dark as well as the draft of the piece framing the research we will be publishing on my site. So it'll be Dark-heavy next week. I'll also be traveling back to London Weds, so won't get much work done then or later in the week as I readjust, so let's just say Dark and random errands is all next week.

The following week I might try and (finally) publish the Cyrus Omar episode and edit a few others. I'll also want to get back to research, as well as doing the work for TCS on curriculum research I promised.

So many balls in the air! It's key to keep my organizational systems clean to manage it all. I really feel like I need the malleable software medium to really build what I need here to make my brain powerful enough to handle it.
  • Loading branch information...
Steve Krouse
Steve Krouse committed May 7, 2019
1 parent dc49041 commit a5782067c75125211bc1bb49c99d84b5436a3dd7
Showing with 102 additions and 0 deletions.
  1. +27 −0 drafts/
  2. +75 −0 drafts/
@@ -0,0 +1,27 @@
title: Tentative derivation of compositionality as the primary subgoal of PL/HCI design

# Tentative derivation of compositionality as the primary subgoal of PL/HCI design

The ultimate vision of many PL/HCI idealists is a lang/env that maximizes human expressivity/creativity over computation. Why can't more people have their computers do more of what they want?

Most (interesting) computations are very complex (in the essential complexity sense). So complex, in fact, that the bottleneck is the working memory of the human brain. Creativity creeps along at the pace determined by how many of ideas can fit in the human brain at one time

Operation management teaches us to maximize said bottleneck. We can maximize the capacity of the human brain by utilizing compression. I mean compression in the classic lossless CS sense: reduce space by eliminating statistical redundancy

This is the proper foundation for DRY: replacing occurrences of repetition with a single element, so more details can fit in a human brain. In this way abstraction is compression.

But instead of the classic CS compression of bytes, here the right level is bigger units. Our brains have already compressed letter sequences into words, which point to even larger complex ideas. For example the letters s i n e in sequence isn't 4 letters in my brain but the one idea sine trig concept.

In other words, we want to compress at the level of concepts, because we can then leverage all existing concepts in the brain

In order to abstract out a repetition, we must be able to make some sort of meaningful _equivalence_ between occurrences, so languages that augment equational reasoning allow for decomposability.

For example, width+1 and height+1 are equivalent in the +1 sense, so we can abstract out the +1 to a function inc(), leaving us with inc(width) and inc(height): three things where we had four

Notice this is much harder than determining the repetitions in hello (the l's). Luckily, the kind folks of category theory have developed tools for recognizing and capturing the similarities of abstract structures. This justifies what might seem overly obscure topics like functors and monads.

(find the paul chiusano retweet that sparked this as well)

Math and science aren't more true perspectives. They are more build on toppable ones. Shoulderable ones in the giant's sense. Which is why math is a good foundation for programming where collaborative construction is key, but not --- The unreasonable effectiveness of mathematics in the natural sciences (1960) [pdf] (
@@ -0,0 +1,75 @@
title: Natural Langauge is not and will never be the future of coding

# Natural Langauge is not and will never be the future of coding

<blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">I have an outline for an hour-long rant about how &quot;plain English&quot; is not and never will be the future of programming. Any suggestions on the right venue for such a talk?</p>&mdash; Steve Krouse (@stevekrouse) <a href="">March 30, 2019</a></blockquote>

As the future of coding guy, I get some strange ideas my way: ex ex ex

But the craziest is also one of the most common: isnt the future of coding just talking to the computer and telling it what you want?

At first blush, this might not seem so crazy. And if you're someone who doesn't think this is crazy yet, don't worry. You're in the majority. I used to think this too...

AI seems to keep improving so if we extrapolate... Show Google ai booking appointment.

But let's remember that we're still here (audio of obvious misundstanding audio clip) so voice programming would be a lot of "no, a button!", "a picture of a mutton?"

Ok, ok voice is a ways off, so a few years ago it was all about chatbots. Chatbots are the future of programming. "Make me an app where the...." long wait. like this? Again no.

The whole point of formal languages is that they are precise, concise, and suited to their domain. Math in English vs formula. Music in English vs notation. Sowing notation. Baseball notation. Accounting notation. Even letter and reading!

One of the key principles us PL designers try to achieve is liveness which is quick feedback. Plain English is way to slow for that compared with a formal language or GUI interface. Latency.

A conversation is makerd by taking turns and waiting for responses. Long running queierws and dialogue boxes are conversation. Actually an antipattern.

Using voice to control a computer is a disability accessibly case. Mouse or fingers are better.

Also bandwidth, which is about the compression. How much we can get across precisely with few words.

Why does nobody say the future of painting will be coveersational? As Bret Victor lies to say, clearly, van goughs ideal interface would've been, ok so add some stars in the sky. Ok now add some swirls and make it impressionistic. SOURCE

Clearly your human hand and a physical paint brush and paints is a much lower latency, higher bandwidth device for visual communication than your voice. That's why the future of visual art tools look like this: drawing pad, ipad and not like this: girl talking to robot.

All pro artist tools map very closely to their domain: vlad's image.

That is except programming. Which is still this formal language thing. So maybe that's where people's misunderstanding comes from. We go from binary to assembly to Fortran to C to Python. English must be next!

Of course This jump is a whole lot bigger than it seems. Python is still a formal language, but just with friendly syntax. You can't write Y and have it still work.

Maybe the misunderstanding comes from non programmer's interface to programming. Some comic, maybe Dilbert, of a boss giving orders to an engineer.

Maybe you work with a dev team in Russia and you just send them mockups and emails and they send you back code, and you interate with them. Isn't that conversational?

Ok, here you got me. That truly is one realistic model of how the future of programming could be conversational.... Strong AI.

The abroad dev team Turing test. Once a computer can maqurade as your dev team in Russia without you noticing it's a computer, I guess that's programming by conversation.

Even if you do that now, it's approximating it in the same way Uber approximates self driving cars. Modulo the small talk. Every designer and PM currently programs via conversation. With Is.

But of course we don't actually call this programming. If you hire a painter and ask him to make it impressionistic, you're not a modern day van gough.

That's not to say that AI has no place in the craft person's tool belt. The feild of intelligence augmentation... Grab stuff from that essay.

In fact the reverse has happened conversation is so low bandwidth that computers have mastered conversation, not conversation mastering computers. Google inbox.

Recap, while programming in plain English may seem like a good idea. It's actually very low latency, low bandwidth, computers are nowhere near advanced enough for it, but ultimately it's not the right medium of expression for programming.

A little to the left. To the left again. A little more. Ok change lane to the right. Hard right, hard right!! Clearly no. We want a steering wheel for all these micro interactions.

What about voice controlled cars like this "take me home, Elon." That's not a voice controlled car. That's a self driving car with a miserable interface. "taking you to Elon's home." Not again. Which is why we don't even use voice with our human Ubers. We use the app's map interface. Because it's the right medium for specifying location.

So what is plain English good for? Small talk with all the people that will eventually be replaced with proper interfaces. Oh and mealtimes conversations with friends and family. Not for programming. Not now. Not ever.

If you have crazy ideas for the future of programming, I organize this online community, meetups around the world, and have this podcast. Please join in with all your whacky ideas. Except this one.

## Todo

* Check out @Glench’s Tweet:

* Higher level. Like English. But formal languages are used in many places and are very powerful. Concise, precision, leverage spatial metaphors.
Other people point to AI and say one say just tell it how you want the parts of your app to interact and it'll code it code it for you. Imagine Monet painting a painting with a voice based interface. Give me a some lillies and make em impressionistic. A paintbrush is the right tool to convey visual information.
This talk continues to poke fun of this idea from a number of perspectives: HCI, notation, programming language design, matical thinking people use with thinking of ai.

* reply to Bakz T. Future because he had some representative thoughts here of the opposing case

0 comments on commit a578206

Please sign in to comment.
You can’t perform that action at this time.