Home

Project Dung Beetle

The pages in this wiki represents thoughs collected at various times as the system has formed in my imagination. It’s somwehat “under construction” so to speak.

Project Dung Beetle is an attempt to create a system for your typical business application in a more robust but still more agile way than the approaches used toady.

Ultimatley the driving force behind the infrastructure is to provide the system programmer with more control over the sofware definition. Type checking, syntax, semantics and editing features should all be equally modifiable and extensible as the actual logic as such. The system will allow a system architect to implement, or integrate various DSL’s that is statically verified for correctness, don’t need boilerplate or otherwise contain accidental complexity and keeps referential integrity accross language barriers.

Mostly the system is aimed at achieving two goals:

• Cross language referential integrity. (F.ex. the schema of a SQL database is kept in sync with the Java application running on top of it)
• Programmer control over the editing and representation of the system. (F.ex. adding high level DSLs with full semantic editing support)

To achieve the goal of referential integrity the missmatch between the live parts of a system such as an SQL-database, and the rather dead parts such as the Java-code representing the various versions of the system that can work with that database will probably have to be removed entierly. To this end I think the best solution is to make all parts of the system “live”.

Instead of storing the code in a SCM for diconnected editing and later integration with the live system, store the code in the live system, allways integrated. Implement SCM as an integral part of the living system. To this end even the persisted data, and it’s schema, could support versioning with branching and merging.

An interesting problem with this approach is how to branch and merge data. Concider the following scenario

• To facilitate some limited testing of a new feature a branch of the main system is created where some changes in the data model and functionality is added. The branch is exposed to a select set of users who use this branch to perform their work.
  • The input to the side branch should trigger changes in the output of the main branch.
  • The input to the main branch should trigger changes in the output of the side branch.
  • How do we migrate data from different data models between the two systems?

Random things I should write more about

.h3 High Level design languages

Often I have had the wish to express design at a high enough level to basically just convey business architecture. Often this is called “the documentation”. What stops me is that there is no tooling support to keep lower level implementation expressions in sync with this high level. With a system supporting referential integrity across languages maybe it could become possible to express high level concerns and tie lower level concerns to them in a way supporting tool support for high level refactorings.

As an aside it strikes me that to keep expressions at such a level modularized and maintainable there will probably be a need to edit and view sub-parts devided across various dimensions and aspects. I wonder what demands this will put on the language design.

.h3 Deployment

I imagine that a good business model for developing this system is to market the system as a cloud hosted sollution. If all parts of the system is live anyway I think an IDE could be integrated in the system an runnable in the browser. Thus there would be a zero-overhead to start coding. All you need is a browser and a log-in.

.h3 Rewriting for debugging

I imagine that one interesting way to debug f.ex. SQL in a system within a live system with full support for the language and rewriting is to fold and unfold statements and parts in various ways in a drill-down manner