Block delimiters – a syntaxic evolution

Recently, I have been playing with Boo and the Mono framework. Even if it suffers a lot from its lack of auto-completion in Monodevelop 2, the python-like syntax is really nice to use. I am really looking forward the new Monodevelop plugin version to be ready and (why not), a VS 2008 plugin version for it.

I realised that what I like the most about the python-like languages is not their instrinsic capabilities. Let’s face it, you do not code the same playing with Boo or IronPython than you would do with python. Having a framework (.Net or Mono) as a basement does change a lot of things and in many case the whole way of approaching a problem.
Of course, the language possibilities do matter. And it matters a lot. I am just saying that this is not the main reason why I like python-like languages.

Anyway, if what the language does is not the big point, what is it? I just realized that what I really liked with it was that we were finally freed from block delimiters.
That, and the fact that the compiler/interpreter won’t play dumb and will finally be able to guess what type I am using.
Why the hell would I have to type

T var = new T();

Can’t the compiler know from the right side of the equal side that I want a T instance? I know, C# 3 does, but it took ages to come if you ask me.

But the nicest thing ever is definitely not to have to type any curly brace while coding.
If, like me, you are using an AZERTY keyboard, you need to press AltRight + 4 and AltrRight + “+” to make them.

For sure, the guy who designed the AZERTY keyboard was not a C coder…

Of course, by the time, you learn to twist your thumb and extend your ring finger to reach it without thinking about it at all, but this is a real additional pain for the programming newbies.

But this was even worse before. I remember a time where we had to type entire words(!) to delimit programming blocks!.

I came to computer programming in the late 80s. At that time, I was experimenting my first pains with GFA basic on Atari ST. The same mostly applies to the VB6 coders community.
In Basic, once it became mature enough to integrate decent flow control instructions and not only GOTO and GOSUB, some new words were introduced to delimit these blocks of instructions.
For each loop or conditional block, we would then get a starting delimiter and a closing one.

In order not to confuse the BASIC programmers, it was decided to define specific per block delimiter.

If IWantAnIf Then
	'... DoSomeStuff
EndIf
 
Do
	'... Whatever
Until done
 
Do
	'.. Loop
Loop
 
For i = 0 To 1
	'...
Next

Etc.

Note that this syntax is still in use in VB.Net and VBA for instance.

After BASIC, the first other language I learned was Pascal, at school.
Pascal introduced to me the concept of universal block delimiter syntax. Once the type of the block and its parameters were expressed, the code to run was always enlosed by a begin and and end:

program WHILE_DEMO (output);
	const   PI = 3.14;
	var     XL, Frequency, Inductance : real
	begin
	        Inductance := 1.0;
	        Frequency  := 100.00;
	        while  Frequency < 1000.00 do
	        begin
	            XL := 2 * PI * Frequency * Inductance;
	            writeln('XL at ',Frequency:4:0,' hertz = ', XL:8:2 );
	            Frequency := Frequency + 100.00
	        end
	 end

That was already a little simpler but still, we had to type 8 chars just to say to the compiler where the block starts and where it ends.
We still encounter this kid of syntax from time to time, for instance in PL/SQL and T-SQL.

Then I was introduced to C…
At that time, switching from beginend to { } was a big relief to me. It then became the obious way to do it. Almost all that very popular languages I was seeing from there: C++, Java, Javascript, PHP, Perl, C# etc were using the same curly braces to delimit blocks.

Soon, I started believing the curly braces were an universal paradigm.

Till I saw some python and ruby code… First I could not accept it. My first impression was that it was “dirty” and probably error prone. I had been using curly braces with every language I was using for more than 10 years and there had to be a good reason for this. This was the way to do it. Period.

Except that I had to change my mind. Looking at some cool applications developped upon the Django framework, or seeing that Google was internally using python, I took a closer look. And it rocks.

The thing is that there is something true: At the end, coding is just typing. And the more you have to type, the less you can think to your code.
The simpler the syntax is, the more you can focus on what the code should do and not on how to write it. It also makes it more readable and then easier to debug.

Just compare the two following bits of code.
C#

class MyClass
{
	private string _name;
 
	public string Name
	{
		get	{	return this._name;	}
		set	{	this._name = value;	}
	}
}

Now, in BOO

class MyClass:
	[Property(Name)]
	_name as string

They both do the exact same thing.
Which one is quicker to write?
Which one is easier to read?

But even if there is quite a lot of fuzz around ruby and python for quite a long time now, I do not believe the languages based on this kind of syntax have reached their maturity state yet.
The first symptom is the poverty of good IDE integration.

For Python:

  • BOO lost its auto-completion in MonoDevelop with the 2.0 version.
  • PyDev for Eclipse mostly only supports native methods completion and still has a lot of progress to perform. It is very far from CDT, PDT or JDT integration.*
  • Cobra is only on the state of syntax highlighting, not of integrating an IDE.
  • Only IronPython is quite well integrated into Visual Studio but then, you need to stick on Windows.

I am far being an expert in Ruby but my understanding is that it is a bit the opposite (quite good integration in Eclipse, very early state of development for IronRuby).

Second, especially regarding python, there are still too many dialects and no one is totally beaten yet. Native python takes the lead due to its age but the community is complaining about performance issues. The lack of portability is also a problem in many cases.
IronPython is quite mature on .Net but is not officially supported in the Mono ecosystem. BOO is nice and offers additional features such as the duck typing but is still very young.

Interestingly, we have a bit the same evolution with data exchange format specifications for the web.

Since the early 90s, the king is XML. It lead to an almost infinite number of specifications, formats or standards that we use or should use every day (XHTML, SOAP & WSDL, XSL(T), XSD, RDF, OWL, XAML, XUL, SVG, OpenDocument and all other Oasis standards…)
XML was so strongly accepted that some could not even imagine using something else to exchange data.

I was watching a conference by Douglas Crockford, the father of JSON. The fact that some of customers we refusing to use JSON because “they had a policy to stick to XML” struck me.

If you look at some XML messaging, it is bloaty, giving more space to meta information than to information. All block delimiters are specific per block and use words.
In a way, XML is to data exchange formats what BASIC is to programming languages.

JSon uses curly braces. It is by far easier to read and often leads to much smaller messages, which can quickly be very important on a network.

And finally we have YAML, as the python|ruby for data.

And here again, the last two ones appear to be quite immature compared to XML. I have to say there are good reasons to this.

All decent programming platform do offer at least one, often more, XML parsing library. This is becoming true for JSON, not for YAML yet.
Only XML offers the ability to be validated against a schema or a DTD.
And of course, I believe the install base of XML-dependent application is by far larger than any other format.

And you, are you ready for indent-base syntax?

*[EDIT:] I just reinstalled Pydev and I must say it has made a lot of progress. It is now able to detect what import is needed or not, and to drill through your imports to give you some completion on your custom types.

  1. No comments yet.

  1. No trackbacks yet.