Webster: switch modes instead of making it hybrid

I just had a brainwave: I have been mulling about ways to bypass the creation of a hybrid editor, when it seems like there's an easier way: allow fluid change to text mode of the whole document.

When you dont want to treat the code as code, just switch to text, and use text semantics. Simple :)

Of course, change "whole document" to "part of document" and you get a hybrid editor for free.

Which of course, goes back to the "islands of one language floating in a sea of another" idea that I've been mulling about. What if the "document" was actually a disjoint data structure held together by multiple instances of small editors? Each such editor would handle its own language fragment.

More thought required, obviously :)

Idea: Photo to Graphviz diagram: an android app

Take a picture of a whiteboard diagram with your android phone.
This app converts it into a graphviz diagram.

A delicious alternative

Delicious is the one intenet resource I use, and that is now on the verge of being sold or shutdown. Here's my idea of an alternative. As always, I like them to be self-sustained, and preferable controllable by my self.

All we need is a web server, and hits to a particular url in which the link to be saved is contained. The url doesnt even need to be active; it just needs to log to the web server's logs. An offline job runs as frequently as needed, trawls the logs, extracts the links and stores it.

Entry and viewing of the link database is mediated through a browser plugin as now, because that's the most common usage anyway.

Simple, and as long as you have a web server (which you should anyway), you're good. The only custom component is the offline job.

Idea: Photo to Graphviz dot file for android

Finally posting this idea from last year. The idea is that you'd take a picture of your latest-n-greatest app architecture that you just scrawled on the whiteboard (as you usually do nowadays at the fag end of that big architecture meeting), and this app would automagically convert it into a graphviz dot file.

Simple, huh :)

Things that I'm really interested in

This is one of those big picture posts. Here're the "hard problems" I'd really like to solve:

• Code Comprehension: How to understand a new codebase easily. If i wrote an oreilly book it would be called "Understanding Code"
• Code creation and maintenance: A lot of this is manual, repetitive, lossy and tedious. Programmers should use the tools (that they make for users) for their own use. And: less snapshot-based development, more fluid one.
• Applying AI techniques to code itself.

Slots: It's like freemind converted to twitter :)

Pardon the cheeky title.


The idea is to have an app that will allow you to take a piece of text, and define "slots" in it. Essentially something like the "Its like x for y" sentence above. It then stores the template sentence, names for each slot, and the values. Once these are stored, Slots then allows for them to be queried using the template sentences. My previous idea of the app to remember where things were could then be just an application of slots.

Further development of the idea:

• It need not have any specific interface; it should embed itself into other apps or work on clipboard text.Input is therefore any text. This means that it could be an android app, or browser extension and still work the same.
• Storage can be local our cloud.
• Once a match is made, action can be taken in any/many ways to actually do something
• 
  

OT + Grammar = New way of defining languages?

Operational transformation is a way of defining documents via the series of steps required to create the document - among many other things.
Language grammars are usually defined by rules on how to recognize a document once its created.

What if the latter was done in the former's style?

Need to think this through but if the rule set is not prohibitively large this would be a nice way to achieve incremental parsing, not to mention the ability to have "islands of known information" mixed with WIP unknown fragments, methinks

Idea: A language that has DI built in

... in fact how about a language that:

• Has only mixins, no pure interfaces (this is probably there in at least a dozen languages already, albeit without the no pure interfaces restriction)
• Allows objects to interact only through dependency injection?

As always, I'm pretty sure a language expert would poke some serious holes in these ideas :)

Layered model for software components

Another idle thought; obviously having your laptop around when you're half asleep at 5am is good :)

How about  a OSI Layer model for application level software components? Lower layers wouldnt have guaranteed delivery or security, which would be provided by the higher layers.

Concept: Dynamic analysis of code statically

Some idle browsing of the architects' dzone led me to think about how programs can not be completely analyzed statically; which led me to think of how humans understand code by just looking at the source.

We run it in our heads.

If we can do it, can't computers? And I don't mean it in a Godel-limit-breaking way, but surely there should be small enough chunks of code that a computer can "run in its head"?

Related thought bits:

• Since the godel limit is that representation != understanding, how about we settle for metadata calculus = very weak for of understanding? Semantic web for code, that is.
• Would knowing the type and range of inputs to a particular piece of code help us understand the code better - a la Agitar creating unit tests on the fly?
• Often missed out is the "world" around the code, and its impact on the running of the code. It might be useful to model the world as well, and probably develop a taxonomy of such environments. Eg: when function x() is run in java it will behave in one way vs when run as javascript. This is a loaded statement 

Need to think more about this.

Slashchrome: an idea whose time is long overdue

Its been a while since I considered taking this project up, and decided against it because it seemed like too simple a project. The idea is to enable Google Chrome to be able to search using the forward slash key. Nothing new, spectacular, or revolutionary.

I had, in fact, gone through the bug trackers of both the Chrome and Chromium(issue 150) projects a while ago, but a recent re-reading got me back to the old fervor: Here was a dead simple feature that the core developers refuse to implement, and the only reason that I can see is that some webapps (read GMail) capture the slash for its own purposes and the browser doesnt want to get in the way.

The developers insistence in ignoring users who have been begging for the feature since its inception is reminiscent of the Pidgin vs Carrier saga. Its time to fork Chromium and include slash search, methinks.

Since so many people are asking for it, I thought somebody would have already forked it, but a google search did not turn up any such projects.

I also looked briefly at an extension that was written to overcome this limitation, but comments on the thread seem to indicate that a core implementation is still desired. Hence this idea. However, there are some really nice features in the extension that I'd borrow when implementing this.

Roadmap:

• V0.1: fork Chromium and change the keyboard mapping of search from ctrl-f to /
• V0.2: Make the switch configurable via options so that people can still switch back to ctrl-f behavior if needed
• V0.3: Blacklist support for sites that use slash for their own purposes (this from the typ-ahead extension)

Thoughts:

• I looked at the source briefly assuming that finding the keyboard map should be simple. I've not yet been able to.
• The build setup also seems pretty time consuming. I should probably setup on windows (being the first implementation and all, and probably the most users), but that entails setting up on VS Express - which seems like an excursion down the proverbial rabbit hole in itself.

Idea: A browser plugin that answers the question: "How did I get here"

Sometimes I reach a page through a long and circuitous traversal of the interwebs, and I wonder how I reached there. It would be nice if there was a browser plugin that showed me that path.

And no, the back button is not exactly the answer because of new tabs.

Better: We need a browser that shows the part of the web that has just been browsed as a graph, so other traversals can be considered openly instead of through our memory of where we have been!

Fantom: a new language to learn

Today I discovered Fantom - a surprisingly interesting language that seems to get so many things right. My first thought was to re-implement Joey in it. We'll see.

The language is definitely interesting - especially considering 2 brothers built it in the (mostly) spare time.

Things to learn from/use:

• Fan(tom) is self hosting, ie the compiler is written in fan itself. So building it from source involves using an older release of fan. This is pretty standard in compiler land, I guess, but still novel to me; and probably novel in that the although the final executable is a native binary, it goes through intermediate non-binary output levels
• It compiles to its own intermediate code called fcode, primarily because the original intent was to be able to generate code that worked the same on Java and dotnet.
• Javascript compile - sweet.
• The FWT toolkit - havent started using it yet, but any library that allows declarative UI is good in my book. Especially since the same fan source can be used to generate  web ui a la extJS.
• It also seems to have a fluent api to building html - another nice thing
• Units (a la Frink) and a datetime api with durations built in.

PS: When I saw the link in LtU I half expected it to be inspired by the Phantom, but apparently not. I have decided, however, that if I do develop in fantom, the projects will be Phantom themed :)

Some structural editor links

Saving here as there's no delicious bookmaklet on the iPad.

an interesting study of actual developer usage of text editors, and implications for structural editors

Linked discussion at LtU http://lambda-the-ultimate.org/node/3567

FrankenEditor: an unholy marriage of emacs and vi

As is obvious from my previous post, I have just re-discovered these editors; and obviously think there should be a best-of-both-worlds editor. See the bottom of said post for feature list.

Another thought: recast Webster into a vim/emacs mode. That will go a long way in adoption.

Doh! Vi and emacs ARE structured editors

In hindsight this was to be expected. I have been reading up the vi and emacs documentation and finally realize that they are both structural editors - not like Alice and Concrete and Webster (when/if its made) is, but definitely they're smart editors, and in some parts, they're structural editors too.

Vim got it right with "command mode is normal, you drop into edit briefly", while emacs got it right with its major modes.

Thoughts in no particular order:

• They seem to have a fixed concept of the "constructs" that comprise structured text, although that could well be my superficial reading of the docs. ESP considering the file explorer mode, for eg. That seems to be a full-fledged structural editor
• emacs already has the concept of skip words ie structural elements that should be skipped over in navigation which is exactly what Webster/concrete does. Dunno if vi does.
• vi's idea of normal mode seems to be more efficient than emacs's "type normally, use ctrl/escape sequences to insert commands" as a user interaction strategy. Should use this for webster.
• this explanation of why the command sequences need to be as weird as they are is useful in understanding emacs, as was Tim ottinger's explanation of the vi command syntax
• they both separate function from it's keystroke - an important detail.
• The good things, therefore are:
• structured text
• structured navigation
• undo/redo/buffers
• command syntax, ESP of vi
• normal mode is navigation, not text entry
• emacs mnemonic navigation seems better than vi's home row based one, although using modifiers for the levels of objects (char,wore,line,para) doesn't.

It seems like there's opportunity to take a modern stab at an editor that's in the spirit of these two behemoths, and yet goes beyond their limitations.I would not be the first to think this :)

I propose, others implement...And a vim hater recants

Predictably, some of the ideas ive been writing about are being implemented by others, notably webster.
I recently found concrete on github, and it's a pretty close approximation of Webster. It doesn't have all the niceties I meant to implement ESP cos it's viewpoint is MDA, but it's there for the most part, and does the modeling in a neat and lightweight way by reusing html, CSS and standard dom - something I intended to do, but didn't succeed with.

The real reason for this post tho? I just realized that vim could just be half way down the syntax editing route!

Coming from someone who doesn't think much of vim's weird modes and keystrokes that's as about face as it could get. Tim ottinger's vim tutorial was what made me change my mind. This is by far the most approachable vim tutorial iv'e read and finally had me grok the vim way. Now the need for command and edit modes seem almost required, especially considering all syntax driven editing is in such a mode! Vim could be thought of as a syntax driven editor that supports the "text language"!

Maybe I'll implement Webster as a vim mode someday!

Doc Dep: A tool to handle the dependency of code and its corresponding documentation

As I work on Abu, I realize that documenting a project is a separate side project in and of itself. I started with a simple Idea.txt, and that has burgeoned into the following:

• A readme.md (for markdown) for github's main page
• A contents.md showing the contents of the codebase
• A design.md for the design "discussion"
• A user guide - WIP
• A developer guide - to be created
• A roadmap.md
• A log.txt for my personal use - as a tickler for when i stop working and have to pick back up later.
• A news.md (yet to be created) letting people know of recent changes

And what's interesting is the interplay between changes I make to the code (or design) and these documents. Each change in code/design obviously impacts one or more of these documents, but there's no easy way for me to keep track. Eg, change in design impacts the user and developer guides, the news file, and sometimes the readme and roadmap files. Any new top level directory added  changes the contents file and so forth.

Now, what if I had a way to say "this code file impacts these document files", so that when the code file changes, I have to change the corresponding document? That then, is the idea - DocDep - which will have:

• A means to list all the documents in a codebase - some kind of config file should do, or probably a /doc directory could be assumed if we want to go CoC.
• A means to represent the dependency between a file and these documents - easily done by creating a tag - embedded within a comment - in the files
• A means to alert the developer when a change has occurred on a file, which therefore needs a change in the document file linked to it.
• This could be as simple as generating a todo list by commit, Eg: todo: change guide.md to handle change in commit# xxx; Or...
• We could go anal and prevent checkin of the code changes without the documentation.

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.