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.