Codeviz: Some thoughts

This post to be fleshed out better later, but here's an insight I had today.
The format that codeviz will use must contain the following types of information:

• graphs
• nodes
• edges

... and these pieces of information should be easily intermingled with each other, and must be line oriented, ie the data that a node has about its parent should be expressed in that line itself, not presorted by parent to include this child. This enables easier sequential processing.

Quantum Commuter

This is an idea that I've had for quite a while, and thought I'd blogged about already, but apparently I hadn't.

You ever had the choice of two routes to the same destination and wanted to find out if the "road not taken" was the better one? Well this idea is one that'll help you find out.

Chicago's public transport system - CTA - provides an api to find out bus times and a whole slew of transit related information. The idea is to create an app that allows you to select two (or more) buses/trains that ply between points A and B; and pit them against each other using the API. The display would show a live display of the progress of the buses/trains, and who won.

I've always wanted to "clone myself" quantum mechanics-style to do something like this IRL, so I call it Quantum Commuter. Nice play on words, even if I say so myself :)

Btw, this could be an easter egg in an otherwise normally useful bus tracker app :)

Idea: A URL/URI spec for code

This is one of those early morning ideas that I have to put down before I forget it: How about a URL spec for code? Something like:
code://somecompany.com/someapp/package/structure/goes/here/AClass.java#methodName#if3@rev234

The idea is to be able to refer to any part of the code externally, easily, and transparently. guarantees on the posterity of the resource returned similar to general URLs, so they're more URLs than URIs.

Elements that should be in the url:
- language used (better notation that file extension tbd). alternative the protocol could be the language name instead of "code"
- ownership of the app by company/individual identifier. i think the java package concept of inverting the domain name works fine here
- package structure
- source object reference. could be file name, but doesnt have to be so in this abstract space
- intra source object references to methods and specific lines, eg the 3rd if in a method
- version information in the form of a scm version specifier

Code Canvas

I just discovered a Microsoft research project from 2008 that foreshadows quite a bit of my ideas with Webster. Its called Code Canvas (demo video).

In line with the N+1 concept, the few things I can think of (if I were to think of Webster as a product) are:

• Treats everything as a graph - down to the individual tokens. This is a game changer in the way wave was :(
• This also means using graph operations to edit code.
• Any language, not just CLR
• Any mix of languages eg, one web app uses shell scripts, build scripts, assemblies/jars, html+javascript+css, ui frameworks (jsp/asp/etc), compiled code (c#, java, et al), ORM scripts, so forth

I do like the semantic zoom, and the Quad tree algorithm to enable it.

Idea: The "Switch around the And" plugin

I was watching a colleague editing a document, and was struck by the the number of steps he need to change a phase like "cat and dog" and convert it into "dog and cat". I myself have had this problem quite a few times. How difficult would it be to make a plug in (in whatever editor) to automate this simple task?

So, this then, is my next idea: Create the "Swith around the And" plugin. For specificity let's call it a Word Plugin. But no reason to stop there - how about for most other editors?

In fact, when I think about, this could become like one of those projects that write "hello world" in every possible language. The "And switch" plugin for everything from vim to word to what have you :)

And of course, this is just the tip of the proverbial iceberg. Why stop at just "and" as the matching pattern? Why not add this as a feature to any code editor so swapping arguments of a binary operator is easy and automated?

Todo: Somebody must have done this already. Google it.

Idea: Boxview - a new kind of html editor

This is an idea for a better html editor:

• Expose the box model to the html programmer by visually showing the boxes that elements are contained within
• allow changing of padding, margin and border properties directly instead of through property sheets
• automatically calculate the minimal set of properties required to specify the box model built by the user. Eg, if a child and its parent element have the same property, bubble the property up an dinherit it.
•  Allow abilty to specify "global" overflow and containment of elements directly instead of through interacting css properties.
• Allow views of the model with no content, some content and  a lot of content directly, so that the model can be stress tested.
• 
  

Visual != Graphical

It just struck me that visual programming doesnt necessarily have to mean a graphical programming environment.  It should be possible to denote the visual aspects of the program in text mode as with graphical mode.

It does mean some environment, however. A text editor is not one. And that might be the deal breaker for most visual programming environments.

Now what if we had a visual programming IDE in text mode?

Syntactic Sugar IS UI for programming languages

I'm reading Paul Graham's On Lisp, and this section from the chapter on macros struck me as interesting:

Backquote is usually used for making lists.1 Any list generated by backquote can also be generated by using list and regular quotes. The advantage of backquote is just that it makes expressions easier to read, because a backquoted expression resembles the expression it will produce.

...

The longer the macro definition, however, the more important it is to use backquote

 This may not be original, but I just realized that syntactic sugar is the UI for programmers. It just happens to be stuck in the limitation of text. I couldnt help but think that a Structured Editor would obviate the need for backquotes, or the usual "lisp is full of parens" complaint.

All they were trying to do was to make a UI for the programmer

Idea: Where's my stuff

An app that remembers where you keep your stuff. It could be as simple as a wunderbar-style interface. You fill in the blanks for the following sentence:
"I keep/ have kept in/at "
Input could be text or images.

Nothing revolutionary, but should be really useful, methinks. esp as a phone app
maybe this'll be my android app.

webster: avoiding the editing problem

- "everything is a graph": the problem (as is obvious from various discussions on the web on the topic) with structured editors is to allow seamless editing of code. the standard example being converting a for loop to a while loop. My idea is to treat everything as being part of a graph, with infinite breakdown. The default level will be at the "syntax" level, but if you want to break that further, press a hotkey, and the syntax-based placeholders and user inputs get reduced to text nodes.

Superficially, this is similar to the "hybrid editors" that have a mode to switch to text input which is then parsed back. But the key difference is that the conceptual graph is retained.

Combine this with the leaf based parsing should help keep the experience smooth.

Some more thought:
operations allowed by a text editor

• navigate text
• create, modify and delete text
• copy and paste arbitrary text, either in line mode or block mode

to emulate this, how about a structured editor has a "text grid" view

• at every text grid event, the structure model is notified, and it changes the model accordingly
• if a placeholder value is changed, no model changes are required, just the slot value has to change
• if a keyword is changed, a triage construct consisting of the following is constructed:

the rest of the structure is retained in the anticiaption of rollback,

a new structure is anticipated and candidates are stored, which through multiple events may get realized into an actual new structure

• if a new structure is realized, the old one is discarded
• the engine will aim for the quickest new structure that can be realized, given the language syntax

More thoughts on webster

I've been browsing on the general concept of structured editors hoping to find precedents, and finally hit paydirt recently - they were apparently a rage in the 80s and 90s and quite a bit of research was done on them. Of course, they were called syntax directed editors then.

Google returned a lot of hits on this new term, and one paper in particular caught my attention: http://arxiv.org/PS_cache/arxiv/pdf/0710/0710.2358v1.pdf

It talks about a syntax directed editor called Absynthe which allowed editing of code via the grammar of its language - the editor would provide templates for entry of valid language constructs, complete with placeholders for the free text pieces. Of course, they use the right terminology - syntax elements and terminal symbols, respectively.

The paper also went into some detail as to why such editors have not found much favor:

A first problem within a pure template model is that only terminal symbols can be entered as free text. This characteristic is absolutely intolerable in practice. Suppose you want to enter an arithmetic expression containing three or four operators. Then you should select the appropriate template by means of commands or menus for each operator and argument - which results in many additional commands being triggered.

This is why a pure template model has never been implemented in practice. Both the Cornell Program Synthesizer ([Reps 84], [Teitelbaum]) and Mentor ([Donzeau]) have used an hybrid model of top-down replacement of place holders with template and bottom-up construction of phrases from free text. We have also adopted such a model in Absynte. In a hybrid model, a focus is used to delimit an area of free text editing. In this area the text may be temporary incorrect. In the systems where the internal representations are ASTs, a first drawback is the administration required for parsing and unparsing the new representation.

If a free area is really useful to enter arithmetic expressions it does not solve the most important defect of the template model: how to handle modifications within a tree structure ? The replacement of a while statement by an until or if statement is more difficult than the corresponding change in a traditional text editor (the later is quite simple). In general, the replacement of one construct by another causes all information belonging to the old construct to be deleted. If the user wants to save some pieces, he can sometimes do it in special buffers or windows, but he must perform these operations separately (for each syntactic category and, of course, before the complete removal) because every piece of program to be saved must be inserted in its future template separately.

I don't have any better answers than the one suggested in the paper itself - that of storing deleted node content in a special buffer for use later - but here're some of my thoughts:

• Navigation = change of mode. That is, if you navigate out of one of the free text/terminal symbol areas, you're automatically in "edit node mode" - transparently.
• Allow pre-order creation of child nodes. That is, instead of requiring that the parent be created before the children can be, allow the tree to be created from all possible left (or right, if the language is RTL) terminal symbols, and keep pruning the tree as you go.
• More to come as I think of it
  

Webster: the web-based structural editor

This is an update on my previous post of a web-based MPS editor.

I've actually found some time to work on this, and I have a basic version working - well in 2 pieces.

1. A renderer that takes a language spec and an instance of the language, and spews out an editable html version of it - with keywords non editable etc.
2. An editor that takes this rendered version, and adds behavior to it a la MPS - allows navigation, ctrl-space like popups etc.

I still need to combine these together to realize the real goal, ie that of a web based AST editor, which will effectively be Language Workbench meets bespin with an MPS flavor.

But wait, there's more!

My real intent is to go much farther than that:

• Generalize the standard editor commands so that they are the true graph edit operations that are required to transform one version of code to the next. Eg, to add a new import statement, today we insert a line, type "import java.blah.foo;". This should be transformed into: "insert a new import node, which produces an editor node that allows us to choose java from the ctrl-space drop down, then blah, then foo. And so on and so forth.
• Generalize it further such that editing the structure of an application is no different from editing the structure of a class/program - these are graphs too, inherently. So I'm thinking of a zoom in/out feature. Zoom far enough in, and you see the standard AST editor. Zoom far enough out, you see something similar, but it now shows your packages, applications, deployment graph, what have you. Consider using SVG for this.
  
• Webster meets Subtext: Create capabilities similar to the ones demonstrated by Jon Edwards' Subtext. This might however be part of a language that uses Webster more than
  Webster itself.
• Implement Jack in Webster
• Implement Robot framework in Webster

FEM - like analysis on code

This idea is partly from a section I remember from the "Inmates are running the Asylum". Alan Cooper compares code to a huge stack of cards one on top of the other, with just that single flick threatening to bring the whole thing crashing down.

How about treating code as a structure, and using finite element method-like analysis on it? Of course, the math would be discrete, not continuous. But the possiblities are interesting - we already create software in layers, with upper ones depending on the lower ones. Surely some definitions of structural stabilty can be got from those? Similarly the dynamic nature of programs could possibly be modeled as forces...

food for thought..but that's as far as I've got with this idea.

A Web-based MPS Editor

I have been playing around with IntelliJ's Meta Programming System for a couple of days now, and I find it a very interesting and promising tool - to teach myself its constructs, I'v started writing an IDE for Robot scripts. I've got a basic editor and generator done and it looks pretty good, especially for completely declarative code.

I was wondering, however, at the applicability of the concept to the web - as in how easy it would be to port the concept of a declarative structural editor to the web. The MPS editor language is surprisingly similar to divs and spans - all one would need to move the editor to the web would be to slap on a generator that creates D/HTML/5 widget wizardry!

Another project to start....

Implementation thoughts:
This might not need a full fledged editor like EditArea - since its structural, it might actually be cumbersome if it were. It might be easier to have a simple div/span structure or even a table with variable row and col spans, with a single in-place editor component for the current element being edited. Of course, keypress handlers would have to be written to make it usable for keyboarders (like me), and we'd have to find a way to show a cursor always.

Interesting ideas on continuation-style parsers for javascript editors: http://marijn.haverbeke.nl/codemirror/manual.html

Further implementation idea: use the MPS Editor language to define it, and create a generator for the editor from it that outputs GWT! This way the editor is web-enabled!

Thoughts on Joey

• It will mimic Chandler to a great extent - many things they just got right. Eg, all items show up in one flat space.
• It will not have folders at all - only tags a la Gmail.
• Everything will first show up in the main dashboard which is effectively the inbox. There will be no explicitly named folder called inbox
• similarly there will be no Sent items folder. They will automatically tagged as "reference" or "info" or show up in the dashboard with a sent tag. The idea behind this is that there is really no other use for sent items than as reference material unless we're expecting a response and want to watch it. So the user has the option to tag it as watching before its sent, in which case it will automatically trigger a tickler when the user needs to be reminded if a response came, or a follow up needs to be sent.
  
• Projects and subprojects will be handled via hierarchical tagging, instead of the much more complicated route of have tasks and sub tasks. This comes from the insight I had that a) you cannot execute a project, only its tasks, and b) at the execution level, it need but just a flat todo-list. So taking the hierarchical aspect out of the task list helps, and we still retain that structure in the hierarchical tagging. So my strawman design for hiearchical tags is:

simple tag: home, fun, work
hierarchical tag: Projects. Project A. task1, Projects. Project B. Sub Project B1. task 3

• Bring ubiquity/awesome bar concept to PIMs. This is already there in Chandler, but enhance it to make that a primary use vector.
• Make it generic enough that the PIM can be made behave either like a GTD PIM, or like Outlook, if so required.
• Nice to have: Tasks show up in Calendar view if no date is provided, so that allocation can happen right there.
  

Design thoughts

• The core of Joey will know only about items and display them. The user can then setup a profile that has rule on what to do with the items.
• Items can be automatically got from an Exchange/IMAP/POP server or created by hand; and Joey will not do anything special with them like putting them in a special folder called "Inbox". Instead the rules of what should go where will be created by the user.
• Similarly the actions that can be done on an item would be configurable in the profile, and they're effectively two kinds:
  
• tag it
• change its type
• "act" on it. which depends on the item's type. For a mail its to respond. For an event its to attend and dismiss it, etc.
  
• The profile, therefore, will say the following:
• what to do with an item when its rendered on the dashboard - tag it to a particular type or not
  
• what action to take on it when the user "acts" on it.
  

New ideas

I've had a bunch of ideas lately that are sitting on a post-it on my desk, so thought this would be the better place to dump them:

• Twitterbot to show traveler updates: The idea is that you'd add the bot as a friend, and send it a tweet asking it to track your trip, and it would pull the itinerary and send tweets to your account with the progress of your trip. This way your followers (which i'm hoping are family) can keep up with where you are, and if you reached on time.
• Ruby Route for Tax Software: This is the idea that I use Route to create an open source tax prep software that mimics the manual forms
• AST Editor: already expanded on in previous posts. Look at IntelliJ's MPS as a potential solution that already exists. But not quite - I'm interested in maintainability, they're interested in creating a DSL ecosystem.
• Map reduce for code comprehension and static analysis: This comes from my efforts to get XRadar to work for Novo codebase, which it balked on. So the idea is to use map-reduce to break the problem down into manageable size, and still be able to do static analysis of large codebases.
• PIM based on Chandler: This is the new incarnation of my long-standing PIM idea: I recently went back to see how Chandler is getting along, and it seems like they have some great ideas, which seem even greater in the light of my recently drinking the GTD koolaid. But its slllllooooowww as hell - not good for a productivity tool, and it still doesnt do mail. So my idea is to create a PIM tool that does mail, and has all of Chandler's goodness. Chandler itself is not an option because its slow. So I looked for existing open source java mail clients that I can convert, and found Columba which seems to be really mature, but the source seems really impenetrable. Plus it still didnt do Outlook, which is on the top of my list of required integrations. Why have a GTD PIM, if you still have to import/export from the most used email client in the world? So now I'm investigating writing the thing in Ruby. I'm tentatively calling it Joey, as in we already have Chandler, so why not Joey :)?
  

Visual Programming: how it should really look

A meandering walk through the net that started at LtU and ended in Source code in Database led me to thinking (again) about how the real visual programming environment should be. And here's what I came up with:

• It should reflect the fact that code is essentially a graph. It should therefore be basically a graph editor.
  
• At the single program level, however, this graph is essentially left to right, top to bottom, so a standard representation (as shown by current editors) will be natural
• Folds and hyperlinks are still useful to have around, though; and this represents the 2.5D solution to what is essentially an n-dimensional graph
• It should have the ability to move in at least 3 dimensions - zoom in and out being the 3rd axis. This should behave according to usability principles - zooming way out from a single program should show its package within the other packages' context, but highlighted; while zooming just a little should show more of the program, but not fold or summarize it in anyway (font zooming goes away completely- we are looking at code, not text)
• Multiple views should always be available - eg, package view must be vieweable as a tree, or a treemap, or a graph, or a list of packages
• editing must be keyboard based to allow for a completely console based implementation if required. The focus is on exposing the true structure of the program, not to sugar coat its display
• Constructing programs must be a structural editing task, not a text editing task.
  
• language constructs such as keywords, classes, packages etc must act as single "characters" and be deletable atomically.
  
• since the AST is being represented visually, the editor must provide auto-complete and hints as to expected parts of the current statement being constructed. Eg, typing an "if" or choosing a command to insert an if statement should allow autocomplete to finish choosing if, and provide VB/eclipse style popup hints as to the other components expected.

Ted Neward's Languages talk

Ted Neward gave a talk at my office, and spoke about Languages, and how we're seeing a renaissance of languages currently. I spoke to him afterwards about visual programming, and his comment was:

"You know, every time I do this talk, someone comes to me afterwards and asks about visual programming. The thing is: text is currently the most succinct way to represent code"

I had to agree with him. But I thought some more about it later, and felt that while that that's true for presentation of code, it need not be for its persistence. Why should text also be the storage mechanism?

define: roomba football

Roomba Football (room-bah fut-bol): The practice roomba owners have of kicking crud towards the path of a running roomba so that it gets a second (or third, or fourth...) chance at picking it up.

Its quite an interesting sport, especially because the device is prone to make crazy changes in course, as any player of the sport will attest.

Tax season and opensource

For various reasons, I cannot use e-filing. So I have to fill out the IRS forms manually. And while I'm doing them, I cant help but think that those forms are a workflow implementation waiting to happen.

The forms themselves are pretty easy to follow, so it shouldnt be hard to automate them. But in between there are deviations you've to take to determine if you're eligible to take an earned credit, or (in my case) if you're a resident or non-resident. And a lot of these deviations are presented as worksheets embedded in the instructions!

Wouldnt it be better to have it in the form itself? And while the pdfs that allow data to be input (and saved, which the federal forms do but some state forms dont - thank you New York), it would be nice if they were in spreadsheets. Or better still - as a workflow implementation. So here's my idea for the week:

An opensource workflow implementation for creating your tax return.

Nothing original, of course, as tons of websites make this idea (sans the opensource requirement) their means of existence. But I thought it would be challenging as an exercise. Here're my high level requirements:

• Workflow based: Each step in the process of filing a return is expressed as a workflow step, and execution proceeds as the user works through each step
• Modular: Deviations and side steps are expressed as sub-processes, which allow them to be optional or ignored if required
• Useful: Allows user to verify results, or actually generate manual pdf output that can be sent to IRS
• Extensible: The basic implementation should cover the common case, but it should allow addition of special cases, or conversion of values to calculations that are output from sub-processes and so forth; so that eventually it covers the span of the IRS forms.

Implementation Ideas:

• Use ruby and Route
• Use Route's web implementation as the basic UI