Text-Oriented Programming Languages

Grammatical Elements

Programming languages should support grammatical elements. For example, instead of writing:

	string condition;
	if(_byID) 
		condition = "WHERE ID ="+ToString(ID);
	else if(_byName) 
		condition = "WHERE name ="
			+CHAR(32)+name+CHAR(32);
	EXEC("SELECT * FROM customers "+condition);

one should write something as:

	SqlClause condition;
	if(_byID) 
		condition = WHERE ID = {ID};
	else if(_byName) 
		condition = WHERE name = {Name};
	EXEC SELECT * FROM customers {condition};

Note that in the first case we have a main language with some embedded strings, whereas in the second case we use a blended expression in two languages, both of which get parsed from the beginning and can cause compile time errors due to incorrect syntax, both of which get syntax highlighting and context-sensitive help in the IDE, etc. A grammatical element looks like a variable, but it is not necessarily. Some of them are compiled as variable, some of them are replaced at compile time and get no runtime counterpart at all.

Grammatical elements can of course also be used inside a single language, for example the above code would look in a SQL stored procedure like that:

	DECLARE @condition CLAUSE;
	IF @byID = 1
		SELECT @condition = 
			WHERE ID = {@ID};
	ELSE IF @byName = 1 
		SELECT @condition = 
			WHERE name = {@Name};
	SELECT * FROM customers {@condition};

Grammatical elements can be local to a function, but they can be defined at application or organization level, too. That will simplify the code a lot. For example, today in database queries one writes again and again things like that:

FROM customers 
	INNER JOIN orders 
		ON customers.ID = orders.customerID

This happens often not just with two tables, but with many: from customer to orders, from orders to products, to parts and prices, to availability and shipment history, etc. One should write such conditions only once and after that just mention them:

FROM {customer orders}

Not only this is shorter and easier to remember, but you can change the table structure and identifiers at any time.

Cut & Paste

Who has not done it? You are in a hurry, you want to get the job done, you remember you saw once something similar... And then you do it: you copy it and paste it and alter it a little bit. The consequence of this: after some years working, after some personal changes, the whole source code is just a big mess of similar chunks of code, whose differences of course nobody can tell. Text-oriented development offers two complementary approaches. On the one hand, it does not just copy and paste, but it records automatically the source of each code snippet. You can always see where some lines originated and compare both, you can always see all places that derive from a particular one and revise them. On the other hand, you have powerful means to unify them, from the beginning or later on. You can define similarities once and refer to them by name at multiple places. That applies not only to whole functions or classes as today usual, but also to segments of instructions or handling aspects, and does not need to have run time effects at all.