pcmonk's musings

How to Find Frontiers

Tue, 19 Feb 2019 00:00:00 +0000

The history of anything looks sort of like this image.

Each black line is an idea or direction that depends on one or more earlier ones. The top is the beginning of the known history of the subject, and the gray line represents the present. The green circle is the mainstream thinking on the subject. The red circles are out-of-the-mainstream thoughts, but with current adherents.

The highlighted yellow sections are what we learn as “history” – the “just so” account of how the current set of mainstream ideas falls logically from every previous (yellow) idea. We probably know a little about the red circles, but we don’t learn much of the ancestors of the red circles, so they don’t make much sense to us. Why don’t they follow they follow the nice logical yellow path?

I want to learn about the blue dots. Not because the yellow brick road isn’t important to understand – it surely is. But simply by existing in society, we learn quite a bit about the yellow. Furthermore, since the yellow path is the path to mainstream views, most modern analyses of it are colored by the green circle. It’s difficult to tell what was truly thought at each step of the yellow because the precursors to the green bits stand out to us as obviously true and important, while that may not have been obvious at the time.

Blue dots are often forgotten, deprioritized, or sometimes even outright repressed. There are probably few if any adherents to modern descendants of their ideas. Thus, there are probably few modern analyses of them, and you’ll probably have to read a lot of original sources. But those sources will argue passionately about topics that you didn’t even know could be questioned.

Some worry that the blue dots are dangerous, or at least a waste of time. After all, if they were abandoned, surely that happened because they were inferior? And if they were not abandoned but actively destroyed by some group in the yellow path, then aren’t their ideas a threat to our green circle way of life?

To the first question, I would say that selection is fickle and often dominated by unexpected factors. For example, why were there so many memes that encouraged you to copy-and-paste themselves to re-share them? If you try to analyze memes in terms of how they benefit their creators, you wouldn’t have predicted that. The reason why they propogate is because that encouragement is good for the meme, which is orthogonal to the truth of the meme or the power or desires of the person who created it.

To the second question, while that may have been the case at the time when the splits happened, blue dots are very rarely dangerous. After all, by definition they have no or very few modern adherents. The red circles are the ones to be careful of, because they have communities, while the blue dots just have ideas obscured by time and distance. If you’re really worried, choose the blue dots that don’t even have any modern descenedents.

Thus, if you want to maximize the number of genuine new ideas learned, study the blue dots.

Here’s some exampes in several subjects.

The cultural history of the world follows this pattern quite clearly. The history of western civilization is the yellow path, but there have been many cultures that died out with no modern descendants – or, at least, no modern “mainstream” (= western, for me) descendants.

There’s one large red circle around most Islamic countries, where it’s difficult for westerners to understand what they believe and why, because we don’t know what their ancestor blue dots believed.

There are also red circles around isolated tribes, like those in Brazil and New Guinea. Their way of life looks incredibly foreign to us, because they descend from a very long line of blue dots. If you want to understand other paths that western civilization could have gone, study these blue dots. Debt: The First 5000 Years by David Graeber and Guns, Germs, and Steel by Jared Diamond are not bad places to start.

The linguistic version of this traces the influences very distinctly. If you want to learn about the nature of language, make sure to study dead and dying languages at least as much as you study Indo-European, Sinitic, and Arabic languages.

In politics, there are plenty of eloquent writings arguing for political opinions that are unthinkable now, but give you a much broader picture of the space of political theories. Want to read a 1680 argument for how the natural authority of fathers in a family means kings should have absolute authority? Try Robert Filmer’s Patriarcha. An argument against the US Declaration of Independence? Thomas Hutchinson’s “Strictures upon the Declaration of Independence” is quite readable. A more recent example that borders on red-circle ideas because the author is still alive is the Unabomber Manifesto. I agree with none of these works, but I’m glad to have read them.

In programming, the primordial ooze brought forth a few original principles. Some viewed programming as an extension of electrical engineering, while others viewed it as applied math. These ideas mixed early on, but some areas stayed relatively pure – there’s not much category theory in embedded programming, for example.

The mainstream of programming systems feels fairly broad – there’s dozens of mainstream languages and operating environments on eveything from embedded systems to enterprise development to academia. It’s easy to feel like everything we ever discovered or invented has been swept into the mainstream of programming thought.

Of course, we know that isn’t true. Whatever happened to Plan 9? That was the future, once upon a time, but it appears to have zero direct descendants. How about Prolog? Smalltalk? They’re blue dots.

Zooming user interfaces, a la Jef Raskin’s The Humane Interface, were thought by some to be the natural next step for interfaces. A very limited version exists in Prezi, but the only active project I know in the space that’s trying to make a true computer interface is Eagle Mode, which is a one-man project.

Lisp machines have famously been abandoned as hardware projects, though Lisp is still alive, and some Lisps may even be considered mainstream. If you’ve spent your life in x86, maybe take a peek at a Lisp machine.

Interactive storytelling is historically an off-shoot of mainstream game development, kicked off by Chris Crawford’s Dragon Speech, which is worth watching even if you’re not into game development. Interactive storytelling isn’t an ancestor of any mainstream ideas. The most direct impact has probably been to the modern interactive fiction hobbyist subculture – itself a backwater of computing, descended from Infocom text adventures.

I’ve learned some about these particular blue dots, but there must be so many more that I haven’t even heard of. That’s why I intentionally keep an eye out for these sorts of projects and try to learn about them whenever I can.

Every once in a while, you’ll follow one of them into the mainstream. I watched cryptocurrency go from an obscure backwater idea of cypherpunks to being regularly discussed in the Wall Street Journal. All of a sudden, the history and ideas of cypherpunks is not a blue dot – it’s been marked over with a yellow highlighter because its descendant has moved into the green circle.

People claim to be explorers and to love frontiers, but they complain they can’t find the “next frontier” until it’s already mainstream. In reality, they’re not interested in frontiers, they’re interested in getting in cheap on the ground floor of a new city. That certainly sounds exciting, but it’s not the same thing, and the skills and strategies are not the same.

If you’re looking for where the next big city will pop up, you should monitor the reports of all the explorers and watch for someone who has money to start building something – perhaps a railroad, a mine, or a large agricultural area.

A mountain man, on the other hand, should learn where people have gone before and follow their paths as far as they can, then wander off into the unknown. It’s not the most lucrative profession, but the views are unbeatable. You might discover a new lake, be the first to the south pole, or even find a fertile new land that settlers will one day colonize, based on your reports. If you don’t love the frontier for the frontier’s sake, this is probably not a great way of life. But you know that there are endless frontiers for those that look.

There’s a third type of person. They hears about explorations, maybe even go on a few. But they’re neither satisfied with simply experiencing the frontier nor predicting where the next boom town will be built. They’re looking for a place where they can start building something new. Maybe they’re looking for a place where they can start a mine, a ranch, or a new trade route like the northwest passage, the Panama Canal, or a mountain pass. Maybe they’re just looking for a place where they can worship according to their own creed.

All three people are valuable. I started programming as the second type, just climbing mountains because they were there. But as I crested a mountain pass deep in the wilderness, I came across the most fascinating little project I’d ever seen. Now, I don’t simply want to experience new worlds, I want to build one. I have a vision of the city we can build here, and I want to build that. For me, that manifests itself as working on Urbit, which is a software project that falls squarely in a red circle of programming.

All three types of frontiersman benefit from reading the reports of those that explored before them and maybe going to see these places in person, even the ones that looked like dead ends. Sometimes you just have to go a little farther.

If you’re a city-dweller, then as long as you’re not a cartographer, you’re probably fine focusing on the green circle and the yellow path, with a little of the red circles thrown in for flavor. But if you’re a frontiersman of any kind, study the blue dots!

Personal Logging for Humans

Thu, 13 Oct 2016 00:00:00 +0000

Technology tracks our every move. Much of this happens automatically, as when Google records our web searches, our interests, and our whereabouts. Facebook tracks our friendships, our relationships, our interests, and our location. Many other entities, including most tech companies, track us.

This is pretty much what we wanted, right? We’ve dreamed of personal assistant AIs for a long time, and more generally of technological systems that know everything about us. In Star Trek, the Enterprise knows everything about each of its crewmembers, which is usually quite helpful. Most visions of the future assume that technology will know us a lot better.

The dream is that technology will remind us when we’ve forgotten something, notify us when our diet is deficient, let us know when our commute will be longer than usual, give us context for places we’re visiting or activities we’re doing, congratulate us when we’re doing well, and reprimand us when we’re not meeting our goals.

Between Google, Facebook, Fitbit, and other services, a significant amount of this happens, albeit in limited scope. It seems like it’s just a matter of time before tomorrow becomes today.

I’m starting a project to make it easier and more appealing to log information about ourself. My technical thoughts are in another post, but here I answer the question, “Why am I not satisfied with the current state of affairs?”

Too centralized

Most visions of the future didn’t include cloud computing. It turns out to be really convenient and efficient to store everybody’s data in the same place and use it for them, giving them the results. As we use this for more and more of our data, two issues become more and more acute.

First, corporations get access to huge amounts of your personal information. Most people don’t have to be convinced why this is a bad thing, but if you want some light reading on privacy concerns regarding Google, I recommend the Wikipedia article by the same name. I pick on Google because they’re big, but most others are no better.

It’s worth noting that data, once collected by a corporation, doesn’t tend to stay there. Data leaks happen. Companies sell data, or they sell themselves. Government agencies request data, often in very broad terms, and usually receive it.

Besides the instinctual aversion most have to large, faceless entities knowing everything about them, I recommend Googling “nothing to hide argument” to understand more about the issue. You’ll find reference to Edward Snowden’s statement that, “Arguing that you don’t care about the right to privacy because you have nothing to hide is no different than saying you don’t care about free speech because you have nothing to say.” I have no more to say on the subject than has already been said.

Secondly, when corporations store your data, you rarely have access to it in a useful manner. Even if Facebook knows what my and all my friends’ faces look like, I can’t use this information to, for example, organize photos on my smartphone or desktop. I can’t even use it to organize photos on my Dropbox because that’s a different information silo.

Most other services keep our data similarly difficult to obtain, and even in cases where it can be exported, the tools often don’t exist to use it. This is in part because there isn’t a large number of people who want to leave these services but keep their data, so there’s little demand for such tools.

Thus, an effort to improve our ability to log about ourselves needs to be decentralized in nature. Each person should have control of their own data, and other entities shouldn’t have access to it unless they’re specifically given it.

Doesn’t track the interesting stuff

Everybody wants to track different stuff for themselves. Some care a lot about tracking their diet and fitness, which is why tools and companies have sprung up to do so. Others use tools to track their money. Still others track more non-standard things, like crying episodes, number of people they interacted with each day, or pretty much everything.

The general principle is that if enough other people are interested in tracking what you want to track, then tools exist for you to track it for yourself. If a corporation has a financial interest in tracking something about you (for example, interests, so they can show you targeted ads), they’ll do that, but you’ll generally not have access to this data. If you want to track something that few others wish to track, you’ll have to do it manually, and build any tooling you need.

Since a fairly narrow set of things are commonly-tracked enough to have tooling, most interesting logging requires you to build your own tools and processes. There’s a strong temptation to try to get technology to passively collect information about you, and there’s some merit to that approach. You can collect a lot of data that way, but it’s rarely the actually interesting data. But to flesh this out we need a clearer idea of what data is interesting.

In general, “interesting” stuff to log is what Tarn Adams (Dwarf Fortress) calls the “narratively interesting” parts of the world. These are those things that might be included in a story, if you were to write one about yourself. It can be helpful to think, “what would be in my journal if I were to just write what happened in my day?” What would be in your autobiography, and what wouldn’t?

Things like “number, severity, and causes of crying episodes” or “number of poeple I interact with each day” are interesting things to track. In general, you probably need to track with greater precision than would actually be included in a story because it’s the conclusions that are interesting. In other words, it’s less interesting that you interacted with five people a day for these few months than that you went this many years interacting with the same people each day, then two years interacting with nobody, then a bunch of people, and so on. This is especially interesting if you can correlate it with other data about yourself, like general wellbeing, weight, etc.

Any serious effort to make it easier to log personal data needs to recognize that choosing the narratively interesting data is much more important than just gathering any data that’s available.

Not analyzable

Personal logging can have a couple of purposes, but the primary one is to analyze the data afterwards and look for insights, like “you’re generally happier when you eat three meals a day” or “you tend to get stressed on weekends” or “half your expenses are from eating out”.

As mentioned before, we don’t often have the ability to analyse our own data, unless we manually log it and build our own tools. Analysis can never have a one-click solution because it’s all about drawing the kinds of insights that we want from our data. Still, many tools can be built to help.

If you’re lookihg for a kind of insight that nobody’s looked for before, then you’ll have to write your own tooling. Otherwise, you hopefully won’t have to. Of course, if you don’t have access to your data, or if that data isn’t interesting, then those tools won’t exist, and you can’t build them.

Logging without analysis has no purpose.

Requirements

So, then, a personal logging solution must be decentralized (i.e. owned and operated by the user), it must track only whatever is narratively interesting, and it must be possible, as an individual, to analyze the data and find useful insights.

I haven’t come across a project that checks off all three of those boxes, but I sure hope there is in the future. The best way I know to make that future happen is to start building it and see what happens.

I would appreciate pointers to similar existing projects (current or past, successful or failed), and if anyone has ideas on the subject and is interested in comparing notes or working with me, get in touch.

Addendum on world modeling

One of my secondary goals with this project is to experiment with modeling worlds. This stems from a childhood filled with made-up worlds like those of Brian Jacques, J.R.R. Tolkein, C.S. Lewis, and George MacDonald. Using computers to model worlds is particularly challenging. Good examples I see include Dwarf Fortress (which creates the most compelling and diverse stories of any computer game I know), the Civilization series of games (which takes a different tack on which things to model, but each round has fairly unique storyline), and Chris Crawford’s Interactive Storytelling ideas.

Basically, I’d like to separate the problem of building a world from the problem of modeling it, so I may as well use the real world as my first world to model. Perhaps the concepts can be applied to generating made-up worlds.

The Idea Maze of Personal Logging

Thu, 13 Oct 2016 00:00:00 +0000

In another post, I laid out my reasons for building a personal logging system. Here, I’ll go into the strategy and tactics issues.

Like many projects, personal logging can extend into a very large project. Unless you intentionally limit its scope (at least in the beginning), it’ll spiral into a mess of code that won’t ever be useful. If you can quickly build a small subset of the final product that is either useful or interesting, the project is much more likely to succeed (cf. MVP).

Let’s explore the idea maze of approaches to building a personal logging system.

Logging vs analysis

The two main parts of a personal logging system are the data collection and analysis. Analysis without data is impossible, so it makes sense to start with the collection. On the other hand, blind collection without reference to the later analysis phase is likely to result in collecting the wrong data. As mentioned in my earlier post, a significant work item is to determine exactly which facts are narratively interesting and log those only.

Conclusion: start with collection, but try to quickly get that to a basic level so that you can begin to perform rudimentary analysis on it.

Automatic vs manual logging

As far as collecting data, there’s two main ways to do it: automatic and manual. Automatic collection is convenient, but it has a tendency to gather whatever data is easy to collect instead of what’s narratively interesting. Additionally it’s somewhat harder to implement than a manual system. In particular, it requires integration with either hardware (usually in a phone) or the users’ other services.

Manual collection is easier to implement, because it puts more of the burden on the user. More importantly, with manual collection, we can be very flexible about which things we record. This allows us to experiment and determine which things are interesting and which are not. We’ll avoid much of the temptation to only record those things which are easy to record because most things will be easy to record. The downside is, of course, that the user now has the burden of journaling in a consistent manner and determining which things they want to record. For an MVP-like prototype, though, giving manual work to get flexibility and development speed is a fair trade.

Conclusion: start with manual collection. Eventually some automatic collection will be used, but I doubt we’ll ever be able to eliminate manual collection.

Data structure

If we’re manually collecting data, what structure should it have? You should be able to add to a log by adding a “fact” or “event”. But if the log has too rigid a structure, then it’s awkward to put all the differnet kinds of information in it. If it has too flexible a structure, it’s likely to become an unorganized mess of information that’s hard to input and hard to analyze.

On the “too rigid” side, we have things like “list of records of [agent action time place purpose instrument]”. This is a bad choice because not all facts we learn will have each of those fields (or some of the fields will not be interesting), and also because sometimes other modifiers are relevant that can’t be encoded into that structure.

On the “too flexible” side, we have things like “plain text” or (unrestricted) JSON. These are very general structures that don’t give very many guarantees about the structure of the data. It’s easy to input this sort of data, but it’s very difficult to parse meaningful insights from it.

In the middle ground, an option is to take a cue from linguistics and store a list of facts, where each fact is a sentence of the form [subject verb list-of-modifiers], where each modifier is a pair of a tag (usually a preposition or other adposition) and an object. If the tag is empty, then the object is a direct object. Thus, a fact like “i ate a burrito for breakfast at 8am this morning” would be represented as:

subject   => "i"
verb      => "ate"
modifiers =>
  _    "a burrito"
  for  "breakfast"
  at   "8am this morning"

It’s fairly easy to input this sort of data, and it’s fairly easy to analyze it. If you recorded this sort of sentence every morning (and maybe the program should prompt you to do so), then to get a list of common breakfast items, you could search for the direct objects in all facts with subject “i”, verb “ate”, and a modifier “for breakfast”. You can similarly tell things like when you tend to eat, and so forth.

Are there other possible structures? Sure, but this seems like as good of a structure to start with as any. Possible extensions include prompting the user to fill in common modifiers once they’ve entered the verb, or even (if more structure is desired), requiring certain verbs to have certain modifiers.

Conclusion: List of facts, each of which is a triple of a subject, verb, and list of modifiers, and each modifier is a tag (usually a preposition) and an object.

Platform

Web, mobile, desktop, or all three?

A purely mobile system is bad because if you lose your phone (or it’s destroyed or whatever), then you lose your data. Additionally, analysis on your phone is unlikely to work well, and data input may not be all that convenient compared to quickly typing on a desktop.

A purely desktop system is bad because you want to be able to log on-the-go, and you eventually want to be able to access a phone’s hardware for more automated logging (although we really shouldn’t be thinking about that yet).

A web system seems to give the best of both worlds, since it can be accessed from all your devices, and eventually a native mobile app could be built for further integration. A native desktop app could also be built, for that matter.

On the web, it could either be a cloud service or one you run on your own server. In my other post, I detailed the reasons why a centralized cloud service isn’t acceptable to me. This means that you’ll have to run it on your own server for now.

Running your own server usually paying $5/month to Amazon or Digital Ocean and being the sysadmin for a Linux server. Many developers already have servers, so it’s not a problem. For a broader set of people, though, this would be prohibitively hard.

For an MVP it works, and that’s all we’re looking at now, but it’s worth taking a second to understand that you can also get around the problems with centralization (privacy, security, and not having full control of the data) while gaining its benefits. If you fully encrypt the data client-side and do all processing on the client side (there shouldn’t be that much processing, right?), then the data on the server is unreadable by anyone but authorized clients. This isn’t possible for many services, but here the server really is just a data store. This suggests a future where you pay a few bucks a year to someone to host your data. The scheme of “I pay you for goods and services” has a long and glorious tradition, and it’s much better when not complicated by showing you ads and collecting your personal data for nefarious purposes.

Conclusion: Make it a web app, hosted on your own server for now. Eventually build native apps, but you want the data stored in the cloud (either your own or encrypted on someone else’s).

Conclusion

So, we’re going to start by building a web app to manually collect a list of facts so that we can start analyzing as soon as possible. Cool. Here’s a prototype: philipcmonk / plogging

It may be painfully obvious there that I’m no designer, and am also colorblind. Also, the name needs work. Actually, most all of it needs work. Any and all help is appreciated!

Why Don't We Have a General Purpose Tree Editor?

Tue, 01 Apr 2014 08:49:21 +0000

We have excellent tools to create and edit text (vim, emacs, sublime, etc.). We have pretty good tools to create and edit tabular data (excel, other spreadsheet software). We even have pretty good tools to create and edit diagrams, pictures, and video.

Why don’t we have good tools to create and edit trees and graphs?

Trees and graphs (in the sense of connections between data) are the underpinnings of structured data. Virtually all data can be described in terms of vertices with (possibly directed, labeled, and/or weighted) edges between them. That may not be the best way of presenting it, but it works. For a variety of different types of data, it is indeed best to think in terms of the connections between the data.

Most often this is manifested in trees because our data is often hierarchical in nature. Thus it makes sense to focus on trees. Additionally, many graph structures can be viewed best by analyzing them through the “cross-section” that a tree view provides. This is all fairly abstract, so I think before I go any further I should give an example.

An Example: Constructing Proofs

I write math proofs on a fairly regular basis, and I read them even more often. Naturally, my mind has wandered to thoughts of how a computer could be used to write them more effectively, or at least make them easier to read and understand. The natural first step is first defining exactly what is a proof.

For the purposes of this discussion, a proof is the link between a series of hypotheses and a conclusion, such that if the hypotheses are true then the conclusion is true. I realize that not all proofs are simple implications (if-then), but most (all?) can be reduced to a series of implications. Thus, this is a reasonable characterization. A proof (in the abstract), looks something like this:

Theorem: If A, B, and C, then Z.

Proof: By Theorem T1, A and B implies D. By definition, C and D implies E. By Theorem T2, E and B implies F. Clearly, D and F implies Z.

This looks like a graph structure to me. Here is the structure (in various syntaxes):

Z
- D
-- A
-- B
- F
-- B
-- E
--- C
--- D
---- A
---- B

This is a fairly self-explanatory syntax. Note that there is some duplication since we are trying to project a graph onto a tree.

((A B) (B (C (A B))))

This “lisp-style” representation is compact and emphasizes the fact that the result only depends on A, B, and C, but it obscures some of the intermediate information.

                        A && B
                        ------  (T1)
                   C &&   D
                   -----------  (def)
      A && B  B &&      E
(T1)  ------  ----------------  (T2)
        D   &&       F
      ------------------------
                 Z

This gives more explicit information than the others, and gives it in a more visual way. Thus, it exposes the structure of the data.

There are countless other ways of giving the structure, and we haven’t yet even stepped outside the realm of ASCII. See this site for some more innovative visualizations.

Okay, so if we accept for the moment the hypothesis that proofs are structured data, and that in particular they can be represented well as a tree (or a graph), then it seems like we’re halfway there. After all, computer programs have been manipulating structured data for decades. The question I have is, what program would you use to write out a proof in such a way that it exposes the structure of the proof?

The usual way of writing a proof is in a linear, text-based format. This works well, but it doesn’t expose the structure of the proof, so it can be difficult to understand a proof on first read-through and even harder to get a general feel for the reasoning involved. If we want to write a proof in a tree-based or graph-based format, we need software that can help us. A minute ago I used a text editor to draw several views of a tree. There should be a piece of software that is more suited to drawing trees than a text editor.

Unfortunately, no such software exists. Or at least, not that I can find. If it does exist, please tell me. Seriously, I’d love to find out about it.

I want to be able to construct a proof by starting with “A && B && C” at the top of the screen and “Z” at the bottom. As I start finding things I can prove from A, B, and C, I can start adding nodes. Working backwards from Z, I can start creating different sets of sufficient conditions for Z. Thus, I have a tree growing from the top and a tree growing from the bottom. When they meet, the theorem is proved.

This doesn’t require the software to know anything about proofs or logic. I just need a sufficiently general tree/graph editor.

Another Example: Programming

If proofs aren’t your thing, let’s look at programming. Virtually all programming languages can be reduced to an abstract syntax tree (AST). In the Lisp family, the language is essentially a bare AST. The AST is represented using the parenthesis notation for trees, although it could just as easily be represented in other ways. So, if we had a general tree editor, we could write Lisp code directly in it. If it was a general graph editor then we could make connections between parts of the program that are not syntactically related (for example, connecting all uses of a particular variable or function).

Again, the major functionality here is simply a tree editor. For sure, to actually use this to write a program we would want to have a series of plugins that know that we’re writing Lisp and help us, just like a text editor. But the major functionality is the same as proof-writing – we’re just editing trees.

What I’m Looking For

The software I’m looking for is general purpose software. I’m not looking for a proof editor, nor am I looking for a tree-based programming editor. I’m looking for a platform.

In text processing we have text editors combined with plugins and syntax files and whatnot to create an environment suitable for the task at hand, be that writing a to-do list, writing proofs in LaTeX, writing a blog post, or programming. But the main functionality is that of simply editing text.

Analogously, I envision many plugins and whatnot to help with proof-writing or programming or whatever other tree manipulation we might want to do. But we first need the tree editor. We need a solid, simple program that can simply edit trees.

What would this look like? This is mostly pure speculation at this point, but here’s some ideas I have.

The program consists of a series of frames, each of which displays a (part of a) tree. There are many ways to visualize trees, so each frame may use a different visualization, or they may all use the same one. When a change is made to one frame the others immediately are aware of the change. Navigating through the tree(s) should be easy and quick. A good keyboard-focused mouse-optional interface would be important.

Plugins should be able to define additional visualizations and additional commands. These should include domain-specific ways of interacting with the data, just as commands and syntax highlighting do in text editors.

These ideas come to some extent out of a side project of mine. Phlisped is a graphical programming editor experiment that is on some level just a tree editor with a few extra things slapped on to make it work for programming. Some of my writings on the subject include a brief philosophy post, an announcement (includes screenshots) when I released the code, and a short video demo of a few of its features. In some sense, this would be a re-write, but with a more general purpose.

Conclusion

I haven’t written any code for this. This is really just a statement of a perceived lack. I plan to investigate the issue more, do some design, and see if I can write up a prototype, but I can’t give any guarantees. If only I had more free time…

I am interested, however, in any feedback. In particular, any examples of already-existing programs that fit part or all of this description would be useful. Most tree editing software is domain-specific, but if there are good examples of domain-specific tree editors, I’d love to hear about those as well. Any other feedback is also appreciated.

A Short Demo of Phlisped, the Graphical Programming Editor Experiment

Thu, 20 Mar 2014 00:00:44 +0000

As suggested by mako in the comments to the announcement post (if you haven’t read the announcement post, go ahead and do that), here’s a short demo of what it looks like to use phlisped. Some tips for experimenting: try h,j,k,l,d,i,u,R. They work as in vim. Also, ; is like : in vim, but different. Try also o,c,O,C,V,I. If you’re really adventurous, try v,L,n,N,. The mouse works too, and you can scroll/drag around your view. Oh, and F2 saves. I have no idea why I chose F2. There are other commands (check out the commands/ directory). I hope this is helpful, if you have any questions, just let me know.

(there’s no sound)

Phlisped: An Experiment in Graphical Programming

Wed, 19 Mar 2014 20:03:04 +0000

I know, I know. I promised to release the code to my graphical programming project months ago, and I didn’t. I’m an awful person. At any rate, without further ado, the code is now available on Github: https://github.com/philipcmonk/phlisped

Here’s a few screenshots of it in action. Some of these are from a little while ago. Yes, that’s xkcd.com/1190.

A few notes:

I wanted to get some things working before I released it, but life caught up with me, and I just didn’t. So here’s a (semi-)stable version. If you want help getting it to work, let me know. I’d love to help you.
It depends mainly on Racket and openGL. I believe it also depends on ftgl, but it shouldn’t be hard to remove that dependency. If you have a problem with that, just let me know.
I’m still interested in graphical programming, but I’m not sure my approach is the right way to go forward. I would love to hear any positive or negative feedback on it. This project is not under active development, so I’m mostly throwing it out here to generate discussion.
I don’t really have docs written up, but go ahead and ask me if you have any questions. One hint: try vim-style keys (h,j,k,l,i,…) and to switch visualizations. Go ahead and experiment. There are features for some kinds of intelligent autocompletion, autorenaming, and some other bonus features that don’t have standard names.
See my other blog posts for some ideas of my philosophy in creating this. Also read the comments.

Why Lisp is Right for Graphical Programming

Wed, 04 Dec 2013 13:31:13 +0000

In my graphical programming project (which I’m really hoping to open source by the end of the month), the programmer uses Racket. Using a Lisp for graphical programming makes a lot of sense, and I’ll try to explain why here. To do so, I’ll have to go off on a short tangent about what are the opportunities for improvement that graphical programming offers, and then I’ll show why Lisp is ideal as a language to be edited in this manner.

Separation of Entry and View

A critical aspect of this is the decoupling of the method of editing code from the manner of viewing code. It is useful to add visual structure to code, so we’ve evolved standard indentation patterns. However, it’s frustrating and time-consuming to manually indent code, so we built editors to do it automatically. This separates the act of typing in the code from the way it’s presented, and that’s a good thing.

I contend that this principle can and should be extended much further. We should greatly increase the ratio of information added to number of key strokes. Why do I think this is possible? When I look at code, my understanding of the code is much more in-depth than what I see. There is much more structure to the code than is easily visible. Since there is that much structure, the editor should display as much of that structure as possible. Indentation and syntax highlighting is good, but there’s much more we could do.

The question is, then, what can we we do to improve the experience by programming graphically? Obviously, because of the tree-like structure of Lisp code, we can simply visualize the tree in various ways. Most likely, though, instead of simply displaying a tree with no understanding of the symbols, the program should have an understanding of a function like map and display it in a particular way. But how? What would give a better intuitive understanding of the map function than simply the word map? I propose simply showing more or less what a map actually is: simply show the function applied to several of the elements. Thus, instead of this:

(map f l)

We have something more like this:

(f (list-ref l 1))
(f (list-ref l 2))
(f (list-ref l 3))
...
(f (list-ref l (length l)))

To me, this is significantly more intuitive. I’m very comfortable using map because I’ve used it so often for so long, but I still understand the second faster on first glance. This is the same reason why the ellipses notation is often used in math when first explaining a sequence. Only after you understand the sequence do you write it in sequence notation. Humans are very good at pattern matching, so when looking at the second example, it is very obvious what exactly is happening from one line to the next.

The main problem with the first example is not that it’s hard to understand. It’s easy to understand – the problem is that it requires being understood at all. It requires you to mentally imagine the second example without seeing it. We have these powerful machines right in front of us that are already going to create the second example anyway when it runs the code, so why must we duplicate the computer’s work and imagine it in our mind? Why not just have the computer show you what it’s thinking?

There are two main reasons why we don’t do the second example when we’re writing code textually. First, it’s more verbose so it takes more time to type. Second, it’s hard to maintain and modify – one must edit each line to make a change. Having the computer generate the second example from the first example seems like the best solution. That way, we must only tell the program “apply f to every element in l”, and it creates the second example. If we want to change something in it, we should be able to change it on one line and it will be reflected on every other line.

This may remind you of spreadsheet software. I think that’s a good thing – it’s easy to see what’s happening in a spreadsheet because all the data and patterns are easily recognizable. To change a formula in a spreadsheet, you just need to change it in one cell and then tell it to put an analogous formula in the entire column. This is a very intuitive and easy way to model computation.

I should note that spreadsheet software is only good for particular types of programming, and its model falls apart very quickly for general programming. The last thing I want to do is bring Lisp down to the level of a spreadsheet. That’s why a graphical programming editor should understand map and display it in this way, and it should understand fold and display it in a similar way, but it should understand something like a struct definition or a conditional or a macro in a very different way, and it should display it in a way that’s specifically tailored for that operation.

Incidentally, for fold, I’d imagine it displaying this:

(foldl f i l)

As something like this:

(set! res (f (list-ref l 1) i))
(set! res (f (list-ref l 2) res))
(set! res (f (list-ref l 3) res))
(set! res (f (list-ref l 4) res))
...
(set! res (f (list-ref l (length l)) res))

Obviously, when you’ve “zoomed out” on your code, this should collapse into the more concise version.

Lisp’s Homoiconicity

A Lisp file is essentially a bare AST. Thus, the structure of the program is very clear to the programmer. This is critical for graphical programming since the major advantage of graphical programming is that it can be used to very clearly expose the structure of the program. This allows the programmer to more naturally reason about the logic involved.

Creating a program to graphically display and edit an AST is not particularly hard – it’s simply a question of visualizing and editing a tree. There are many different ways to accomplish that, but a minimal functional program can be created fairly simply. This, however, does not likely give a compelling reason to change away from textual programming – the additional clarity gained by the tree visualization is likely negated by the additional difficulty in editing the tree.

Thus, we add more understanding to the program. This is easy to do with Lisp since there is basically no syntax in the code. Thus, all of the “syntax” is controlled by the editor. Note that for a graphical editor, there is a difference between the syntax of typing code and the syntax of displaying the code. Behind the scenes, though, it should simply be an AST.

I realize that Lisp has more features than merely its homoiconicity. However, the rest of the feature are intimately related to its homoiconicity. For example, macros are awesome because they’re easy to think about – you just need to manipulate a tree. The ease of quickly abstracting and the functional nature of Lisp are both also very natural once you have homoiconicity. A graphical programming editor should be able to support these other features very easily. I haven’t talked about these features simply because there will be very little change in them from textual to graphical programming.

In Conclusion

Eventually, I believe that languages will be created specifically for graphical programming editors. Right now, it’s important for languages to be backwards-compatible with textual editors, at least in a pinch. This allows you to use not only vim but also grep, sed, diff, and so forth. Until we have good enough graphical tools to replace these, the various Lisps are the best candidates for graphical programming.

To Open Source or Not To Open Source

Mon, 21 Oct 2013 20:23:06 +0000

I’ve been trying to wrestle the code for my graphical programming project into some kind of releasable form. This brings up the obvious question: in what form do I want to release this? Do I want to release it open source or closed source? Is there any way I can make money off it? Would it compromise the quality of the program to keep it closed source?

There are two basic strategies, and many permutations of each. On the one hand, I could open source it and try to build a community; on the other hand, I could keep it closed and try to do something like a startup.

To come to any kind of reasonable answer to this question, I need to first determine my priorities in writing this software.

Goals

I have five main goals (in order): to learn, to make something worth using, to make something that people use, to advance my career, and to make money.

I’ve started many projects in the past, and I’ve made significant progress on many, but I’ve never tried to turn them into something releasable. This is because my primary goal has always been to learn to be a better programmer. I’m a student, so this is my time to learn as much as possible before I’m thrown into the world of needing to make money. This is my time to dream, and my time to learn. Thus, my first priority is to learn.

My second priority is to make something worth using. That is, I want to make something that I and others would want to use. Thus, in the context of this project, I want to make a program that makes programmers more productive. I believe that if programmers can be made more productive, then not only can problems be solved faster, but problems that were previously prohibitively hard can be solved. Thus, I don’t want to do anything to compromise the power and usefulness of my program.

My third priority is to make something that people use. This is distinct from the above in that this is not measured by how useful this program would be to people if they used it; rather, it is measured by how useful this program is to people since they use it. Thus, I would like for this program to be available to as many people as possible with as little barrier to adoption as possible.

My fourth priority is to advance my career. This is pretty self-explanatory, and it could be accomplished in several different ways. Indeed, the learning I accomplish will be invaluable here.

My fifth priority is to make money. Aside from all the normal benefits of money, if this could turn into something that actually pays me, then I could devote more time and effort to it. If this doesn’t happen, then this will remain a side project while I either get a day job, an internship, or do a startup. At any rate, this project will suffer if I can’t find a way to monetize it.

Ways to Accomplish Said Goals

Learning

Whichever way I release this, I’ll learn a tremendous amount. Part of the learning will be about software projects in general, and some will be about whatever method I choose to release the project. At any rate, there probably won’t be enough distinction here to make a difference in my choice.

Something Worth Using

For making something worth using, the most important distinction is probably going to be between open and closed source. There are two issues at work here.

The architecture of the program is such that nearly every aspect is extensible without too much difficulty. Thus, users should be able to add and remove visualizations, key commands, and even language backends by just dropping the code into particular folders. Additionally, the actual program itself exposes a Racket interpreter that evals in the environment of the program. Thus, this should be eminently hackable. That makes it much more valuable to users. I’m not sure if this sort of open architecture would be possible in a closed source model. It seems like it would compromise this aspect of the system.

The other issue is that this project is too big to solve myself. I’m going to need other people to work on it with me. In an open source model, this means other open source programmers, and in a closed source money-making model, this means employees (and maybe a cofounder or two…). Both of these approaches carry risks. If the open source project does not gain momentum, then there may not be enough developers complete the project. If the closed source company does not earn enough money, then there will not be enough money to hire developers. At any rate, my focus here will be to create a program that is minimally complete and useful (by which I mean something that is complete enough to be useful) and then start iterating and improving. Then, more developers will mean faster improvement, and a lack of developers will mean slower improvement rather than outright failure.

Something People Use

For people to use a piece of software, it needs to (1) be worth using (above), and (2) have low barriers to adoption. I’ve attempted to design the program in such a way that it will be familiar to at least a certain subset of programmers. It is possible to write pure Racket in it (and I’m in the middle of making the process for this smoother), which will be familiar to Racket programmers (and Lisp programmers in general) and allow the use of the usual text tools. If you need to ssh into somewhere and edit code, vim will work just fine. Speaking of vim, many of the keyboard shortcuts are vim-inspired, such as h,j,k,l,i,d,p,q,@,:. If you prefer emacs-style shortcuts, you’ll be able to change them without too much trouble. Incidentally, I think the environment will be more familiar to people who use text tools than graphical tools.

In releasing the program, though, people will likely use the program significantly more if it is free, or if it at least has a free version. Obviously, being completely free is better than having a “community version”, but even that’s better than a purely proprietary program.

Advance My Career

Obviously, if this turns into a multi-billion dollar company, then I think my career will be fine. Assuming it doesn’t, then, this has a couple of ways that it can advance my career.

If this becomes a startup, then, even if it fails, I’ll have gained a lot of valuable experience, which could help my career in three potential directions: (1) this could be something I could put on my job application to a good company, so maybe I get a better job; (2) the experience might be able to land me a good job at a startup; (3) the experience would be invaluable were I to do another startup.

I wonder, though, how much an open source project might help with those same three things. On a job application to either a big company or a startup, I could point potential employers to this project, and they could look through the code, and, hopefully, they could see how I worked with other developers. This would highlight my love for programming even without a direct path to monetization. The experience would also be useful in doing a startup since I would be working on a project with actual users and whatnot. It would not be as useful as actually doing a startup would, but it also wouldn’t be as much of a risk and time investment.

Make Money

This one is pretty heavily weighted to one side. I don’t know of any good way to make money off of an open source project of this type. I could ask for donations, but unless this becomes huge that’s not likely to be a sustainable source of income. Some have suggested Kickstarter, and that might be a good idea, but I’m not sure how I would make a Kickstarter campaign work for this. Maybe I’m just not familiar with the Kickstarter model.

If anyone has any ideas on how to monetize this, particularly in an open source manner, I’d love to hear them.

In Which the Author Does Not Come To a Conclusion

So, that’s where I’m at. I’m leaning toward open sourcing, but I’m still not completely convinced. The crux of the issue seems to be that closed source would compromise the quality of the program, and I don’t think I’m willing to do that.

Clarification Regarding Graphical Programming's Potential

Tue, 15 Oct 2013 19:13:57 +0000

After posting my previous post , I submitted it to Hacker News, and, while I slept, it hit the front page. As is to be expected after about 10,000 views, there was a lot of feedback, mostly constructive. A couple of points recurred, and I’d like to address them here.

Show Me the Code

This is the easiest: I’m working on it. I’ve got a few thousand lines of Racket to show that I’m serious about this. I plan to release this, but I’ll warn you, it’ll probably be a few months before that happens. I plan to continue blogging and laying out my philosophy, and I may post some screenshots, but I’m going to spend most of my time wrestling the code into something useful.

<Insert Graphical Programming System> Is Awful, Ergo Graphical Programming Is Awful

I acknowledge that graphical programming, in its present state, is not good. In particular, it’s significantly worse than textual programming. That’s exactly my point. I think there’s a lot of improvement that can be made here. Graphical programming has (with a few exceptions) failed. My goal is to change that.

The argument that “textual programming is better than graphical programming in their present forms” is not an argument that textual programming is better than graphical programming. When deciding to work on something like this, you don’t ask whether TP is better than GP right now, you ask whether GP has the potential to be better than TP. My hypothesis is that it does.

The Mouse Is Awful, Ergo Graphical Programming Is Awful

I agree that the mouse is used way too much in user-oriented software. But graphical programming does not have to mean using the mouse. It’s true that those have been used together for much of their combined history, but it’s not because the one inherently depends on the other. In my system, the mouse is purely optional; indeed, most of the important interactions can only be accessed by the keyboard.

On the flip side, some may argue that this makes it not very user-friendly. I’m not trying to make it easier to learn programming, and I’m not trying to get non-programmers to start programming. I’m trying to make the everyday life of the developer easier. If a system is such that many of the interactions will be brief, it may be important to make it intuitive and obvious. If a system is such that many users will spend hours every day working with it, the “activation energy” is not terribly important, since it will be dwarfed by the later productivity. Think asymptotic complexity. When n is small, the constants are important; when n is large, the constants don’t make that much of a difference. That’s why vim is not “user-friendly”, but is still commonly by programmers. For people for whom editing text is a significant part of their life, it’s a lot more important that the text editor be powerful and efficient than that it be easy to learn.

I Want a Neural Interface (Or at Least Natural Language)

I hope we move beyond both textual and graphical programming. But it’s going to take a while. I think graphical programming is within the limits of our technology, so I’m going to try to make that. Waiting for the technology to get good enough for a neural interface is not productive. If I had the scientific and background required to help with the research required to implement a neural interface, I would. But I don’t, so I figure I’ll do the best I can with what we’ve got.

Incidentally, regarding natural language, I disagree with (what appears to be) the general consensus that this is a better way to interact with the computer than what we have presently. There are certainly some cases where it would be useful (typing this blog post, for example). But English is not a technical or precise language. English has been optimized for interpersonal communication and relations, and it does a pretty decent job at that. English is not good for describing stuff on a technical level. If I were able to speak to a computer, I would want to be able to use a language specifically designed for being able to speak technically. It might take some time for me to learn, but I think it’d be better than the machine trying to assign meaning to my English statements. Most of what we say in English is not just hard to assign a technical meaning to – it may not have a technical meaning. When telling a computer what to do, I want to actually be able to communicate exactly what I want.

Conclusion

Thank you guys for the constructive criticism and the links to other projects. I do want to be able to give a well-reasoned response to possible issues with my hypothesis, so any criticism is welcome. If I missed an important point, let me know.

For the near future, I’ll continue blogging about my ideas and working on the code. Eventually, I’ll release, and then it’ll probably make a lot more sense.

Graphical Programming: I Really Hope This Is the Future

Mon, 14 Oct 2013 23:48:19 +0000

Since March 2013, your author has been working on a software project with a fervor not previously experienced by said author. This work has not been a never-ending drive in a certain direction with a clear vision; rather, I’ve been engaging in copious exploratory programming. Over spring break, I got a working pre-alpha, and I thought the basic architecture was fairly solid and wouldn’t change much. Since then, every aspect of the stack has been swapped out for something new at least once. All the data structures are different, the important program logic is solving a completely different problem than it was, and the interface has gone through iteration after iteration of paradigm shift.

One thing, however, has remained.

Purpose

The purpose of this project is to assist the coder in developing more complex code faster and easier by clearly exposing the structure of the code.

To explain the solution I propose, I will first explain the particular problem I see.

ASCII Is Awesome, Just Not That Awesome

In the Good Old Days(tm), people wrote programs in binary, and the great masters of the era were those who achieved the greatest oneness with the computer. By which I mean, the interface between humans and computers followed a very simple rule: make something the computers can understand, and then teach the humans to speak the language. This system worked rather well because humans have an amazing ability to learn even the most abstract skills remarkably well.

In time, though, with advent of assemblers, and later compilers and interpreters, we moved the frontier between humans and computers. Now, the computer does much more work to try to understand what we mean; likewise, humans do much less work to try to explain what we mean. As abstraction is layered on abstraction, humans can use simpler statements to describe more complex programs than ever before.

However, and this is the meat of my criticism of the state of programming today, our interface for programming is still based on text.

Text is awesome. I much prefer the terminal over GUIs. I write documents in LaTeX using vim and avoid Microsoft Word and LibreOffice Writer like the plague because they’re just such a pain to work with. Nearly without exception, if I’m given the option to write something in plain text rather than “visually” or in “formatted” or “rich” text, then I’ll write in plain text, even if that means throwing in a little code. For a combinatorics problem I’ve been working on recently I needed to draw a series of graphs, so what did I use? Tikz in LaTeX. I find that almost without exception, GUIs (1) do not allow the kind of manipulation I want, (2) hide important information, and/or (3) are simply frustrating to use.

Is this a problem inherent in graphical user interfaces, though? Is text really the best interface possible to interact and communicate with computers?

I submit that it is not.

GUIs have been misused.

A Defense of Graphical User Interfaces

Why do I use text programs rather than graphical programs? As outlined above, there are essentially three reasons.

Programmability

This is the most important isssue. The terminal is awesome because of its composability. Basically, the Unix pipe and backticks allow any command to be used as the input to any other command, and this allows the user to take relatively simple commands and mold them together into a one-liner that solves exactly his or her problem. When a new command is added, it integrates perfectly with the other commands, so it immediately gains all the power contained in the other commands. This allows the user to learn one set of commands and everything else just plugs right in.

I use vim for everything from configuring programs to note taking to todo lists to writing math papers to programming. I even use vim macros as a sort of scripting language if I’m trying to do something that’s a little too complicated for sed. Regular expressions make manipulating many different kinds of data – anything from file lists to code to csv files – surprisingly easy.

I like LaTeX better than Word not because I can use a plain text interface. I like it better because I can program in it (either directly or by writing a program that spits out LaTeX code). And being able to program in it gives the interface more expressive power. It is easier to tell the computer what I want it to do.

Text interfaces in general usually exhibit this kind of programmability. GUIs, as a rule, do not.

This problem, however, is solvable. Inherently, I don’t think it’s any easier to make a text interface programmable than it is to make a graphical interface programmable. However, since the text tools are already available, it is easier in practice to create a programmable text program. The solution for GUIs, then, is to create the tools necessary to program them. That’s a really vague description, but that’s because this is the hardest problem. I will describe my solution in detail in another post.

Show Me Everything

WYSIWYG editors are basically evil. I don’t want you to hide all the complicated formatting stuff in the background. I don’t trust you that much. One of the most frustrating experiences is, in Microsoft Word, to try to put a picture exactly where you want it. There usually is a way to make it work, but it is so needlessly complicated that I get insanely frustrated. When I drag this picture right here, why do you put it over there? The problem is not so much the putting it over there as it is the not telling me why. Please, if I’m doing something that doesn’t work in your framework, then let me know.

In LaTeX, every little bit of formatting is eminently visible. If there’s a problem, then at least I know exactly what the inputs are that give me the incorrect results, so I can know what to try to change to fix it.

However, this is clearly just a misuse of GUIs. Is there any inherent reason why GUIs must show less information than text interfaces? No. In fact, I would argue that they ought to be able to show more. This is a problem with current GUIs, but this is very solvable.

Physical Interface

GUIs generally depend on the mouse for interaction, and that’s generally a bad thing. What is the difference between the mouse and the keyboard? Basically, the mouse gives you pseudo-analog interaction, and the keyboard gives you a lot more buttons. Thus, the mouse should be used in cases where you want analog interaction, and the keyboard should be used for making discrete choices. That’s why manipulating menus with a mouse grates on me so much: it’s absolutely the wrong choice of utensil. It’s like eating soup with a fork.

There are good uses for mice. For example, viewing 3D models should definitely be done with a mouse since the interaction is fundamentally analog (although there should be discrete buttons to, for example, snap to an axis). Flight simulators are a lot more fun with a joystick than just using the arrow keys, and that’s because flying a plane is an analog interaction.

GUIs don’t need to be based on the mouse, though. It’s perfectly possible to create a GUI that is primarily controlled by the keyboard, and in many cases that would be a good thing. Again, this is a solvable problem.

Graphical Programming

So, yeah, text is great, and modern GUIs are, if not completely awful, at least significantly worse than text interfaces. I’m trying to make a GUI for programming that is an actual improvement over a text interface.

How could programming be helped by seeing the code graphically? Basically, in text, there are a lot of connections behind the scenes that the programmer must keep in his or her head. For example, an identifier is not merely a string of characters; it is connected with every other instance of that identifier, and in particular with its definition. It may also be connected in some ways to other identifiers – it may have been included from some module, it may have various functions that apply to it, or it may be the inverse of some other identifier. All these connections must be kept track of by the programmer in his or her mind (assisted by documentation).

However, the computer knows all these connections as well. Why can’t the computer just show me these connections? In a text interface, this is difficult (although automatic indentation and syntax highlighting is helpful).

Thus, this isn’t really about graphical programming. The point is not that stuff is arranged nonlinearly. The point is that we show more of the structure of the code. We show several different aspects of the code at once, and we can have different graphical views of the same code. Maybe one view emphasizes the data flow; another view emphasizes the control flow, and another view emphasizes the human-meaningful divisions in the code (between, for example, view logic, controller logic, and model logic).

This applies especially well to Lisps. A Lisp program is just a tree, and every expression in the program is just a subtree of the program. Text, however, being line-oriented, is good for displaying linear processes, as in assembly or C or Python. It is difficult to naturally represent a tree in text. The most common solutions are indentation, which is too vertically verbose for Lisp’s needs, and parentheses.

Using parentheses to display a tree is a decent system. It is unambiguous, simple, and easy to type. However, it is clear to me that it is not the best system. When we draw a tree on a blackboard or on paper, we don’t use the linear parenthesis system. No, we draw them graphically. Why? Because it’s easier for humans to understand something drawn out visually. Why don’t we use that when programming Lisp, then? Because it has historically been hard to draw that kind of thing quickly and easily with a computer. Basically, it’s just easier to use parentheses.

However, I believe this can change. Thus, I propose that graphical programming should be the future. I haven’t seen a graphical programming system that I thought was better (or even close to as good) as a text system, but that’s just because people are going at it the wrong way.

In time, I’ll write about what my solution is to the problem of graphical programming. My solution is still in pre-alpha, although I think I’m tantalizingly close to an alpha version. So, until then, I’d love to hear anyone’s opinions on the subject.

References

After working on my project for a couple of months, I found Bret Victor’s work, and I’ve since incorporated some of his ideas into my view of programming (as you may notice above). I particularly recommend Learnable Programming and The Future of Programming.

For an overview of many of the studied tree visualization techniques, see treevis.net. I’ve implemented several of these visualizations in my project, and I plan to implement many more.