Show HN: Whilelse – a programming platform that represents code as a web

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.