MB0 Experimental Language


MB0 is designed for experimental purpose. It has a very simple grammar and syntax following to assembler languages. The current implementation is as an interpreter language.


Each line of code has the following form:

[label:] command [var1 [, var2 [, var3 [, …]]] [; comment]


Each line is interpreted as a procedure call of “command” with var1, … the call parameters. All parameters are called by name. The content is completely determined by the called procedure.

The procedures are taken from some library that is implemented in any programming language – most likely the language of the implementation.

The library is indexed by the command names. The interpreter implementation provides an interface for the passed variables

If the library procedures fail, the execution is aborted.


At runtime, an agent is created. An agent can be seen as a CPU executing the code line by line.

The most simple agent has the following internal states:

IP                  Instruction pointer:
Points to the line of code of the current command. After execution it’s moved to the next line

Active            If true, the agent is active, i.e. executing code

The agent executes the following code (written in some pseudo code):

Start agent
While IP <= last line of code
   Read line at IP
   Lookup command in the library
   If not found abort execution
   Call library procedure with all variables passed by name
   Move IP to next line
End loop


Note: this simple agent has no conditional execution.


First reference implementation is in Excel VBA.


MB0 comes with a basic library with only string support and simple global variable functionality.

The variables are available as long as the agent is running.

Command list

MsbBox             creates a VBA MsgBox with message var1

Let                     Puts par2 into variable par1

Data Types

Only strings are supported. String constant is indicated by surrounding double quotes.

MB0 Experimental Language

Agile Backblog

Agile Champion is a title that most of us are familiar with. These often self-nominated champions of cause seem to be in center of most of the agile transformations. But what really are the characteristics of a true champion and are there some other kind of agile personalities and roles that we often find around us?

I’ve taken a look around and reflected some of my experiences to describe few types of agile personalities or “roles” that I’ve often seen. One thing to note is that most of them would not need to be “agile” but instead can be found running some other causes be they practices, tools, programming languages or something else.

So, just for the sake of it being fun sometimes to put things in boxes, here you go.

Agile Champion
Armed with loads of common sense, the agile manifesto and diamond hard determination, these tireless heroes of…

View original post 954 more words

Collaborative programming

“Collaborative programming is an emerging methodology for team software development, which allows a group of programmers to work together on the same source coed for design, implementation, and integration.” [Shen]

One known method in XP is pair programming, in which two developers sit side-by-side in front of one PC.

One technical core component is collaborative editing: in real-time collaborative editing the entered code by one developer simultaneously changes the code all other developers work with.

Shen describes the challenges as group awareness, access control, and currency control.

In a Copy-modify-merge approach the developer can work independently, however there is additional effort and complexity caused by the required merge. Merging tools can be classified as textual merging, syntactic merging and semantic merging. (Shen explains the algorithms for merging techniques)

A quite interesting emergent approach is a Programmable Website:

Adam Cheyer and Joshua Levy created a prototype of a Wiki like environment inspired by WubHub:

The environment’s main elements are

  • Shared storage for pages holding pieces of content or code
  • An execution environment, with a programming language and type system
  • A user interface, with support for invoking commands and wiki-like editing of pages

A page in the environment is like a function in a programming language.

Developers can work simultaneously on the different pages of the application.

External resources:

Collaborative programming

Domain Specific Programming Language Classification

Wikipedia http://en.wikipedia.org/wiki/Domain-specific_language:

In software development and domain engineering, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain… The opposite is a general-purpose language, such as C, Java or Python…

Related to my post on emergent programming languages, here’s my first proposal for taxonomy for the domain classifications:


  • According to customer requirements
    • Business Domain (E.g. insurance, banking, sales)
    • situated applications
  • Programmers
    • According to age (e.g. languages for kids)
    • According to experience (e.g. beginner’s languages)
    • collaborative programming
  • Programming paradigms
    • Imperative
    • Functional (e.g. Haskell)
    • Meta-Programming (e.g. Rascal)
    • … (see Wikipedia)
  • Classify according to Output
    • For websites (e.g. HTML output)
    • For diagrams
    • For texts (e.g. regular expressions)
    • Code generation (e.g. Compiler generators, metacompilers)
    • Game developing
    • Natural language generation
  • Manipulating Objects / Input
    • Text manipulation (e.g. regular expressions)
    • File manipulation (e.g. shell scripting)
    • Media manipulation (pictures, videos, sound)
    • Natural language processing
    • Relational database querying
    • Mapping Reality
      • Business rules engines
      • Simulation tools
      • Artificial intelligence
  • Support Software Development Process
    • Code checking (e.g. profilers, consistency checker)
    • Documentation
    • Tools for build and deployment
    • Versioning and archiving code
    • Support management processes
    • Rapid software prototyping
    • Support for design patterns
  • Special Hardware Target
    • Microcode
    • Assembler
    • Programmable controller (PLC/SPS)
Domain Specific Programming Language Classification

Taxonomy for emergent programming languages

As explained in Wikipedia (http://en.wikipedia.org/wiki/Programming_language) there are different classification schemes for current programming languages:

  • by inheritance (result in language families, mostly related to syntax)
  • by programming paradigm (How to use?)
  • by domain usage (What’s it for?)
  • by generation (related to the history of languages)
  • by language elements (Syntax, static/dynamic semantics, type system, libraries)
  • by tools (e.g. shipped with Eclipse)

You can find more details in Wikipedia using the following keywords

  • Programming paradigms
  • Programming language
  • Programming language generations

All the presented classification schemes are matching exactly the known existing programming languages.

A prospective taxonomy should already contain some white spots for emergent languages.

Here are some ideas for emergent languages not covered by the above classification schemas:

  • support for situated applications
  • supporting build and deployment processes
  • more generic language elements (e.g. patterns)
  • configuration and versioning
  • collaborative programming
  • stochastic semantics
  • interaction with project management / reporting / controlling
  • support for software design / demand management
  • Supporting versioning and code migration
  • Profiling and refactoring support

I’ll explain in detail what I understand by these topics in later posts.

Taxonomy for emergent programming languages

Planning is not estimation is not analysis

After a fruitful discussion on the last meeting of Limited WIP Society Cologne (http://lwscologne.wordpress.com/), I’d like to summarize some terms: 

Often planning and estimation (and analysis) is used interchangeably, but this yields to confusion and stress:

Estimation is the act of determining values based on uncertain data. Usually, thought as predicting some future result.

Analysis is the act of breaking something into parts to get a better understanding of it. If you ask a software architect to estimate, he’ll most likely start an analysis and provides some complexity measure (e.g. in function/story points). If you force him to convert the result into person days, then he’ll estimate a factor he applies to the result.It’s a good idea to not ask him to convert into person days. Rather let the factor be based on historical data.

Planning is an act of arranging tasks to fulfill a management target. A plan is never wrong, but has some probability to hit the target. To determine the probability you need an estimation.

Planning is not estimation is not analysis

No progress in programming languages

Nearly 30 years without fundamental progress in programming languages shows that we’ve reached a trashold to a completely new domain of programming languages. Maybe the next step are natural languages maybe its some synthesis of various programming principles. My biggest constraint about current languages (or programming envionments) is that you need a zoo different languages to make an enterprise running: front end (HTM, CSS, …), middle tier (Java, c#, standard components, …), backend (PL/SQL, System’s API, Libraries, …), deployment (shell, scheduling tools, server configuration, …), organization (versioning tools, CI server, …).

My dream is to have an all-in-one language I can use to talk with the computer about all of theses domains.

Inspired by post http://tagide.com/blog/2012/03/research-in-programming-languages/#comment-123

Paul Graham wrote an interesting post about how difficult it is to convince a programmer to chnge the language – even if it was a more powerful one:  http://paulgraham.com/avg.html

No progress in programming languages