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

Minor nice to haves

1. A File Explorer that allows you to put directories as favorites similar to a browser - saves on all the dir tree navigation. I'm sure some file explorer already has this. But it would be nice if windows explorer did. It has something close - a favorites side bar. But I'd like a toolbar.

2. And then of course, an app suite that uses this favorites list. You know how the office suite's File Open dialog has the side bar with My Docs, Recent Docs, etc? Why cant one of the options be My favorites? Or is this already in Vista, and I'm still barking up the XP tree?

3. Another brain-dead feature of the office suite's file open (or most windows app for that matter) is that they will not do what Textpad has been doing for ages - open up the file open dialog to the same directory as the currently open document. Its highly likely that you'll open up one more document from the same place, or somewhere thereabouts. Why should I go back to My Docs all the time? If I was in My Docs to start with, this behavior would still end up effecting the same result. I dont get it.

Anyway, it'd be nice to see these tiny fixes into windows.

A true code format, and its editor

This is post is influenced by my recent preoccupation with code representation (see post on coding in thought, for instance) and inspirations from Subtext and ediola.

Imagine a code editor that allowed you to edit the actual AST of the language instead of text that will be parsed into the AST of the language. It would obviously make it transparent to you that you're editing a tree instead of free form text, except for taking out the inefficiencies. For instance it would allow you to use the normal navigation keys to scroll up and down through the code, but would skip keywords and language constructs automatically because they're are actually tokens and don't need to be treated as English words. When you navigate to a user entered value such as a variable, it would drop into an in-place editor that allowed you to change it, and it would then automatically change all occurrences of that variable because it knows that its a variable.

For the same reason, it would be easily able to provide auto suggestions /completions as it knows the language's syntax. An add-on feature would collect data about imported and declared classes, methods and variables as you edit, and make those available in the auto suggest as well.

The best part of course would be it would have none of the limitations of text - no need to worry anymore about whitespace as it would become exactly what it should be - white space that is merely a visual thing, not something that's stored in the code.

Sidebar: I realized after I wrote this that such an editor could be at a loss with a language like Python, which essentially mandates whitespace. However, I do think the reason Python went the way it did is reconciling to text being the universal code format, and if so, making the best of it, namely to avoid all visual clutter caused by begin/end tokens, and instead rely on whitespace to denote it for both humans and compiler alike. That being the case, there's no reason this editor can mimic the indentation, and provide the output that the python interpreter expects.

How would such code be stored? Why, as the AST itself. The actual storage format (as long its not back to text) is not important, as any number of those are applicable. What is important, though, is that it is in the exact format that the language allows for human thought to be enshrined as code - nothing more (specifically, text formatting warts), nothing less.

Once we have this, we can think of more improvements. How about treating comments as annotations on code, and extracting them out completely? This way, all the issues related to comment obsolescence and non-locality are resolved. We could just tie a comment to a particular piece of code, and wherever the code goes, the comment follows. If the code chunk is removed, broken or altered, it would be trivial to mark the comment as outdated and to be treated with a pinch of salt.

There's another gem hiding in the previous paragraph - that of tying a comment to a particular piece of code. Well what exactly is "a particular piece of code" unless we're talking about some named chunk such as a method? Nothing defined, yet. However, consider this: what if we had a way of identifying every piece of code uniquely - an id for each atomic piece of code? Notice that I've specifically avoided considering the line number as the id because is not just another of those text formatting appendages, but also an unreliable anchor to any particular piece of code as it can easily change with an unrelated edit of the file. I'm thinking more of :

• a unique id for each statement (or its component) (eg, the 5th statement of the main method - which could well be on the first "line" if it were text)
  
• expressions for groups of such statements (eg, first 5 statements of method foo),
• reference via scope/namespace (eg: 3rd if in Class a's method foo)

- an XPath for code, if you will. Once we have this, refactoring becomes analytical, even expressible as code. And of course, we'll be able to attach all kinds of metadata to chunks of referencible code, including comments.

Update: This from my wife: "3rd 'if' in method a.foo" is as arbitrary as line number. The better idea is to sequence them in order of creation, ie, the first 'if' created in a.foo gets id #1, the second #2 and so forth - for eternity. That way edits will keep the piece of code still identifiable. Ids could be periodically cleaned up to remove unused ones.

Ok, all of the above has been about editing code, not necessarily the format laid down by a language itself. But the more I think about it, formats have been more a limitation laid down by the tools that surround a language rather than the languages themselves. Compilers require classes to be contained in single files. Compilers require directory paths for package name spaces and so forth. There is really no reason a compiler cannot read a pre-parsed version of code as its primary source. By the same token, there is no reason source code cannot be stored as the AST - in version control or outside. The newer source code tools shouldnt have problems dealing with whatever binary format is chosen to store the AST, and diff against them.

And you know the best(est) part? No more tabs vs spaces wars!

Further Ideas for a new language

Some more random additions to the new language idea:

A name: Jack
This is mostly tongue in cheek but I thought if I ever got around to creating this language, I'd call it Jack. You know, like in Jack of all trades, cos its trying to be one - with its polyglot leanings. I did consider calling it Poly, but the options for source file name extensions would be .pl or .py or .ply. First two are taken, and the third doesn't seem that interesting. OTOH, .jak comes out nice.

Aside, I did also consider calling it V after me, but vetoed it cos it didnt give any indication about the language itself, just self promotion.

Anyway, Jack it is. And I've not yet checked if there's already a language with that name - hope not. But think of the possibilities with such a name:

- You could tell others off by saying "You dont know Jack"
- Like Java Jars and Ruby Gems, there could be Jack (in-the) boxes :)
- I know I'm gonna call the hello world in Jack "Jackrabbit slims" :))

Enough buffoonery, now for some serious stuff:

It has optimisations
You know how you have to "drop down a few layers" to optimize things? Like for eg, you can do 3d graphics using the Java3d APIs or you can use OpenGL or you could just drop into the video card's API? Well, Jack will have the same capability. If a thing can be done in more than one way, and one way is the composition of multiple functions, while the other is a single function that does effectively the same, you will be able to specify that. Instant reuse. Want to use the MFC classes, or OS sys calls to do something? Go right ahead. And supported in the language too. Sandbox to be specified, but definitely much easier than JNI et al - remember I'm still dreaming :).

The key thing I want to point out is the "supported in the language" bit. We as programmers routinely cut across language/API boundaries. However, each language is in its own sandbox held together by scripts, duct-tape and magic. Why not be explicit about it? Obviously there will be need for sandboxes, but making it explicit enables maintainability. It should be clear how different parts of the application ecosystem actually connect.

Ideas for a new language

A number of nebulous ideas have been swirling in my mind of late on what's lacking with today's languages. I woke up today morning with the remnants of a dream where I was coding in a language that magically had closed all those gaps, and even improved things a bit. Here's what my conscious self remembers from that dream.

It was based on conditionals
I have been thinking a lot about conditionals lately, partly due to being impressed by Subtext. But more closer to work, I've been thinking of a large legacy application and how to refactor it so that chunks of logic that are in the wrong layers can be relocated easily, and how other chunks of logic that are interwined with each other even though they logically belong to different paths can be extracted, and then combined via configuration using (for lack of a better term) a micro ESB.

And it struck me that the conditional (represented by the plain vanilla if, or an inheritance hierarchy) is the cleave point of "paths". All conditionals that are based on a particular check (eg: is the object of type foo, or is the value equal to x) are essentially in the same path. Therefore code should be organised (or auto-organised) such that conditionals are matched by their paths, and the largest conditional branch naturally gravitates to the top. This is, of course, exactly what Jonathan Edwards' Subtext does, with the additional advantage that it also ensures that there are no gaps in the conditionals - all possible values(or value ranges) have to be filled in. This would be a great thing for a language to have.

So the language from my dream had this feature. It worked using conditionals, and like subtext it auto arranged them - but all in text. That's the dream part, i guess.

Now when I think about it though, I can envision this conditional cleaving happening incrementally - a module can be conditionally complete within itself, but not so wrt other modules in the application.

It had modules/services/components as a first class language construct
Meaning, the "chunks of code" concept that I mentioned above were directly supported by the language. Think COM/XPCOM, or SOA/Web Services - with more accent on the fact that there's a published API backed by an implementation; and less on how they would be discovered, remoted etc. Code by contract, basically.

I don't remember if it had explicit support for constructs such as classes and interfaces that combine to form the components. It wouldn't matter if it did or not, but the key thing was that the component WAS defined, and was the cornerstone of composition.

It was extractably modular
And by this, I mean that chunks of code could be extracted out into modules by the language itself.Not a preprocessor or optimizer - the language itself had operators to extract code, define the api based on the contents of the code, and place it elsewhere. It therefore had meta programming capabilities, and more importantly, code elements were addressable in a platform- and source file-neutral way. Every unit of execution from the statement to the module was addressable to enable the modularisation operators to work.

It had DRY testing
Defining a module or class implied testing it. The language statically checked for bounds and ranges based on the conditionals. In addition, every run with values can be recorded as a test, adding to the test set.

It supported legacy apps
It had the ability to read old app code; and then show the gaps in logic or discover (if not extract) the true modules. It might have had a compatibility mode or it allowed incomplete (from its perspective) code to run.

It was functional at its core
and used monads for everything - especially the micro esb.
... but it had a lot of dsl-ish sugar to make it seem more general purpose.

And finally, it was (j)vm based.

Aftermath
After I wrote this far, I got to thinking about what goals a feature set such as this would arise from? Here's what I got:

• backwards compatibility
• support multiple programming styles
• direct support for common use cases in development and deployment

Idea: Working Diagrams

This is an idea to represent working systems. Working applications are manifested by the files that they are comprised of. So the idea is to rely on expressing the nature of the application using those very files. This is pretty similar to what anybody usually does when whiteboarding out an application - draw boxes representing pertinent pieces of the application. The boxes could be the whole application, or a part of the application or a line in a file of a part of an application. We then draw lines to represent relations that we're interested in. Specs like UML try to formalize this, but for most purposes, we dont need it to be true to the spec - just understandable enough. And there are representations that UML still doesnt (and probably wont) have in it that we'd like to represent - eg the call chain of our build xml's for example, or how two bash scripts relate to each other.

So the idea is to create an app that given the following input, spits out a graphviz (or eclipse emf/visio/jpg/whatever) diagram of the relationships represented by the input.
* one or more dir paths which are considered the nodes of the graph
* each directory and file is a node
* each directory is a hierarchical node and can be folded/unfolded
* a list of plugins that help to identify relationships expressed in each file that can be parsed using, for eg, regexes. The idea of using regex is to to avoid parsing the whole file. Though there's nothing precluding actually parsing the whole file. Eg, a java file plugin would contain regexes to identify method calls and create relations to external classes used as arguments.

Version 2:
Make an interactive version of the output that can be folded/unfolded at will.

Uses:
* Point the tool at your deployed app and get your whole deployment stack displayed as a diagram.

Note: The notion of a file can be generalized to anything whose representation can be queried for interesting relations. Consider, for example a process tree visualization by traversing the /proc directory in unix, and now think of a tool that translates a windows process list into something similar for processing by this tool

I call it Working Diagrams. Its informal and works for purposes of conversation and discussion.

I wonder if there's antisocial networking, and webapps for that

I'm a reluctant participant in the whole social networking thing. Must be my INTJ personality type. But as I get connected into facebook and its ilk, I wonder: how about antisocial networking?

How about a bad mouthing network? This was an idea that i got separately as well - a venting wall where anybody can enter some person's name, and rant on how that person ruined their life, and how they hope that person went to hell. I'd call it cheethoo.com, which should be obvious to anybody from bangalore.

but as i think about it, the possiilities are endless. How about an anti-facebook? When you login, it'll tell you how many new people are not your friends, and therefore you can safely ignore. It'll have an app called fortress of solitude, where nobody can get you (except maybe lex luthor).

Tongue in cheek post, this; but shows my frustration with the whole social networking thing. Do we really need to know everthing everyone is doing right now?

Update: I googled anti social networking after I wrote this up, and apparently this is a solved problem.

Auto indexer

Over the course of my adult life, I've had 1 desktop, 3 personal laptops, 2 official laptops, and a blackberry. Of these, at least 1 personal laptop, 1 official laptop and 1 pda of some sort are actively used depending on which one i'm closest to at the moment. My data, notes and files, therefore, are splintered across all these repositories.

The idea is to have an auto indexer that allows me to retrieve the location of a piece of information regardless of where it is. Essentially, the moment I create a document, it must be indexed with the central repository so that whenever I'm interested in that document, the repository should be able to point me to the location of the document, and possibly allow me to (pre)view it instantly on whatever machine I happen to have handy.

OS Ideas: Tagging FS

I'm sure this has been thought of, and probably implemented, but here goes anyway:
The idea is for each "file" in a filesystem to be tagged instead of put into a hierarchy, and the tags themselves are used as the organizational structure. Tags will be just one of the attributes allowed to each file, so adding meta data will be easy, and even encouraged.

Add to this the ability to organize tags into hierarchies or graphs and you have all possible organizational models available to the user.

Finally, search will be the default mode of finding a file - either by its contents, or its attributes, with tags getting special status.

Other applications: version could be another special tag understood by the file system framework, allowing files to be versioned intrinsically.

All of this of course, will be horrendously slow; but wonderfully flexible as a result :)

Painless Timesheets

This is an idea I got while listening to a few colleagues griping about filling out their timesheets. Nobody I know likes timesheets. Yet everyone has to fill them out. So is it possible to make them at least tolerable?

I think maybe.

There are a few programs out there that monitor you while work. PTM is one - it looks exactly like the windows task manager, but it tracks what you're doing automatically, and you can then map it to a set hierarchy of tasks that you set up and it will generate summarized and detailed reports based on the hierarchy.

What if we used a program similar to this to capture how time is spent, use inputs both from live monitoring and scheduled information. Further we make the mapping simpler by providing the ability to tag any timeslice with multiple keywords, and a means to map keys to a hierarchy or graph - whatever makes sense to the official timesheet system. Finally we provide a browser plugin or expect/mechanize type mechanism that auto fills the fields so that the user doesnt have to ever enter time. To top it off, we make the whole system pluggable so multiple timesheet systems can be supported - and extended by anybody.

Advantages:

• User entry is automated, and never requires remembering what was done in the past
• We use the best evidence in hand - calendar info, and actual tracked time on pc
• Its still not big brother as there's no reporting to anyone but the individual
• Data entry is also automated.

Learning Haskell -1

I started learning Haskell as part of "learning a new programming language every year". Here's the frist post:
Am using Real World Haskell, first ed, as that's whats available on Safari books.

Notes:

• Installed Hugs, then ghci cos the book uses that, and there're sufficient differences in the output of the interpreters for me to not bother about it.
• Have started reading about types.
• They are strong, static and inferred.
• Type names are Capitalized
  
• ints are signed, fixed width integers dependent on the machine word size.
• Integers are signed integers of unbound size
• Add :: TypeName after a declaration to set the type. Mostly not required
• function args are written after the name without ()'s or ,'s. Eg fn arg1 arg2
• lists are written as [item,item,..]
• head and tail work similar to lisp car cdr.
  
• Strings are character lists. So tail "abcd" returns "bcd"
• Tuple is a collection of items of different types. Witten as (itemofType1, itemofType2, ..)
• () is the type and value of a tuple of zero elements, called unit.
• take, drop work on lists
• fst, snd work on tuples. due to strict typing, we cannot define a fst fn for all kinds of tuples, only pairs.
  
• Side effect explained: If a function is dependent on a global variable, each run of the function will differ based on the current value of that variable, which alters the way it executes. And therefore, even if it doesnt ever change a value, it has a side effect.
• Pure functions dont have side effects. That is, they're idempotent - every execution of such functions return the same value. Kinda like GET.
• Impure functions have side effects. They are identified by the Monad tag before their type. Eg:Prelude> :type readFile
  readFile :: FilePath -> IO String

Next week:

2.9. Haskell Source Files, and Writing Simple Functions

A pc my 2 year old can use

My kid already can use a pc - minimally. She knows how to start a pc. With the right settings she manages to get it to hibernate. She figured out all by herself that hitting the space bar will pause and resume video on youtube and windows media player.

The key to her ability IMO is following simple rules: She presses the biggest buttons, and recognizes simple patterns. I was wondering if it were possible to create a controlled environment where everything is consistent with what she knows, and therefore she's able to use it better. Some of my ideas:

Direct manipulation: these are based on my observation that she sometimes doesnt make the connection between hitting a key/clicking a mouse and the action it triggers on screen. No fault of hers, imo, its akin to Pickard talking into a mouse.

• Use concepts from Johnny Lee's wiimote project to create a direct manipulation display for her
• Combine this with creating a projection tv using projector panel + OHP to make a viewing + playing + learning environment for her

Sandboxed input: These are based on the earlier mentioned observation - she tends to hit the larger keys, or the ones at the edges. So the idea is to put a fixture around the keyboard that allows access to only those keys. Or put on a template such that all the usable keys are highlighted in red, and the others aren't. And the usable keys would have simple one-to-one mappings to actions -eg, start, shutdown, run video, pause/resume, play (gcompris) game, nav keys. Similarly, the mouse too would be in controlled mode - no right click, click=double click, etc.

The good part about sandboxing is that it allows her to learn, and as her understanding expands, I should be able to scale up towards full keyboard and mouse functionality and this enables her to be productive with existing hardware sooner.Need to research laptop templates for this.

Easy Interface: The OLPC's Sugar UI comes to mind. But methinks an even simpler UI is in order to get her to understand how to use things - with a lot of association thrown in. Eg, really large buttons on the screen, that are the same shape, color and location as the keyboard. Icons that are the same on the keyboard as well.

Scheduled Programs: This is an idea I got from noticing that my kid seems to gravitate towards one of the screens we have at home (no tv, but 4 laptops and 1 dvd player) automatically, and turns it on - invariably to her favorite dvd or cartoon. What if the laptop came up, and the only option allowed at that time was to play an educational game? Or maybe if she's already done one ed game, it shows a cartoon as a reward?