
Show HN: Whilelse – a programming platform that represents code as a web - leente
http://whilelse.com/
======
allanderek
The screen cast videos did not work for me. Pressing play just made the video
load, but would play for only a fraction of a second.

Anyway, I think I about understand the concept. Basically, rather than
organise software into files, you store your source code as a database.

This has several advantages. Firstly you can easily attach metadata to your
source code components (be they, modules, methods, functions, datatypes,
classes, etc.). You can then selectively choose to view/edit the metadata
attached to source code components. The traditional way of attaching metadata
is to have semantic comments, which quickly tend to get a bit ugly.

Once you have such metadata you can choose which parts of your source code to
view on screen. Rather than open a _file_ which may also represent a module or
class, you can open a filter, which filters code objects. A bit like labels in
email organisation are better than directories, since an email can belong to
more than one. To put this another way, deciding how to modularise your
program is tough, using a database to store your code objects you could make
it a bit less tough by making it more flexible.

In general when you change the format that source code is stored in, you face
the the problem that you're mostly stuck with re-implementing all of the
software tools that support a language. Okay, so maybe you don't quite have to
re-implement all of these tools so much as re-target them, but still, it's a
chore. A particularly challenging tool is source code control.

In addition, you have the problem that typically, a project will have to
either choose to store its source code in traditional text-based format, or
whatever the newly proposed format is. Usually the proposal to get around this
is to translate between the two, so that code is _actually_ stored in the
original text-based format, but when you open it up with your fancy new
format-aware IDE, it does an on-the-fly translation and you get all the
benefits thereof.

This might work to an extent to allow users to use existing tools, although
you still need to do a bit of touch up, for example, coverage analysis will
report on the translated text-based format rather than your database format.
So you have to translate the results of coverage analysis, but you can at
least get to a point where it is usable in this fashion.

It does not work so well for collaborating with others that are still using
the text-based format. Mostly because your database format when output as a
traditional text-based format, either loses all the metadata, or stores it as
comments, or in a separate meta-data file. These all have the obvious problems
when collaborating with someone who either ignores it, or wants to.

Source code control is a problem in both kinds of scenarios. Even if all
developers are using your database format, what happens if there is a merge-
conflict? Either they have to modify directly the translated text-based
format, or you have to implement merge-conflict resolution in your IDE.

None of these problems are insurmountable. They are just challenging.

In summary, I think the reason source-code-as-database has not already been a
success, is mostly because it is difficult to introduce incrementally. But I
hope you succeed.

