Search

Calendar

Options

Langs

Just finished reading a good article which sum-up things pretty well and is rightfully named The Semicolon Wars.

Being myself a programming language creator, I mostly agree with what the author tells here. The (still short) programming language history has seen already numerous wars that were more like red vs blue than right vs wrong.

As you should know already syntax is overrated, in the sense that it's far from being the most important aspect of a programming language. As the author notes, what makes a language different - if not better - than another one, is not how you write it but how the language allows you to express your ideas.

Syntax is just a way to encode these ideas, which - as the colors of a painter - is of course necessary but is a lot less important that the idea and the feelings behind the picture he paints.

However, if someone - such as myself - lacks painting knowledge, he might just see the colors while watching some modern art painting and not even touch the painter idea itself (considering there is actually an idea behind each modern art painting, which I highly doubt, but that's another story).

In a similar way to painting, being able to see behind the syntax of a programming language to really evaluate its ideas and features requires knowledge. Knowledge of the programming language itself is important, but as someone that has only paint landscapes would not (maybe) be able to enjoy Picasso, the most important thing to evaluate a language is to already have good knowledge in several languages, with at least one functional and one object oriented.

Not only the more languages you know, the more easy you can learn more, but the better programmer you become. Someone that know well 5 other programming languages will be much better at writing Ruby in a few months than any programmer that have been only been writing Ruby for the past 10 years.

Syntax is a matter of habit : with time, you can get used to any syntax, including the most innovative or poorly designed ones. Sadly, people get too much used to habits, that they get conservative about them. This also apply to syntax, but in the end what makes the difference is the expressiveness of a language.

Some would say that expressiveness comes THROUGH syntax, quoting examples such as Ruby. But I think that you could get the power of Ruby with another syntax as well. What makes Ruby expressive are its language features, and of course having a syntax that helps supporting these features is better than having a syntax that makes language features annoying to use, thus killing their expressiveness (todo : insert a lot of examples of Java here).

In statically programming languages, which is an area I particularly like, expressive language features are a bit harder to implement. This is because you need to design not only the feature itself - and eventually the additional syntax that supports this feature - but also the type system that will make the compiler able to prove that this particular feature is used in a correct way...

Not simple, and clearly harder than to design the same feature for a dynamically-typed PL. But when you manage to do it right, without again killing the feature expressiveness by adding a lot of additional notations that would just hinder its usage (more Java/AS3 examples in mind here), it's a big win.

That's the path I'm following while designing Haxe. Advanced features such as type inference definitely helps here, since it reduce the amount of type notations necessary to make the "type proof" of a program.

And since I'm not confident at all about the ability of people (including myself) to change their habits about syntax, I'm trying to be very conservative about it, sticking to the core C/Java/etc. family.

It makes in the end a programming language that is easy to read and learn, but hard to master, which should gives every Haxe developer a good curve of learning and the enjoyment that comes with it. Or at least, I hope : I don't want to start just another PL war ;)

8 comments

Mike Austin

Dec 22, 2010 at 08:49

Hi Nicolas,

In response to "syntax is overrated", I have to respectfully disagree. Syntax is the interface to the programmer, the communication for someone who has to read other people's code that was written years ago. I've been reading Programming Scala, I'm amazed at how many ways you can write the same thing: a function with/without braces, using dot notation or using spaces to call functions, etc. I prefer one way to do something - you learn it, and you remember it. Java is hardly the best language, but there are a few things I find interesting, such as requiring braces around all conditionals, and requiring booleans in conditionals (object != null).

I'm also writing a programming language, and because there is no deadline, I tend to put a lot of focus on the syntax. How can I make it clearer? How can I minimize keywords and special forms? For example how can I eliminate special syntax such as list comprehension. Here's an example in Ruby:

(1..3).zip(1..5) { |a, b| a + b }

There are lots of parens and brackets cluttering the code here. Also, why is one list treated as the object and the other a parameter? The same expression in my language, Impulse, looks like this:

[1..3, 1..5] zip: |a, b| a + b

As you can tell, it borrows a bit from Ruby, Dylan and Smalltalk, although parameters are more like Dylan keyword arguments than Smalltalk keyword messages. List comprehension can be accomplished with a few anonymous functions (experimental):

[1..3, ('a + 1)..5] comp: |a, b| a < b ? a + b

I won't get into the details, but ('a + 1) is simply a method (+) called on a symbol, which creates an anonymous function. 'a + 1 == |a| a + 1 The list comprehension would be:

[(a + b) | a <- [1..3], b <- [(a+1)..b], a < b]

I understand this syntax originates from mathematical notation, but it's just another syntax to learn on top of the base language. There are possible limitations to my approach, of course, but that's why I'm experimenting, to see how far I can take it.

Happy Holidays!Mike

Gasche

Dec 22, 2010 at 09:06

I think that one of the reason why syntax is so heavily discussed for popular such as Ruby and Python languages is that precisely, they have so much in common concept-wise that you can't tell apart those language (the modern object-oriented script languages allowing reflection) by the expressivity of the programs.

In a sense, syntax fades away when the semantics is interesting. When the semantics is ok, but with nothing new under the sun, you choose a language based on other things such as the syntax, the libraries and tools available, the "Zen" of the language and the overall spirit of the user community you're involved in.

And that's precisely the point of those languages : present what you already know, in a nice way.

Languages that try to introduce new concepts to their users are evaluated on a different scale -- and often partly neglect the syntax.

Philippe

Dec 22, 2010 at 16:34

A nice/smart/obvious syntax is pleasant, but I believe what makes the difference nowadays is learning material (how to get the job done), libraries (how to not rewrite everything), ease of deployment (how to run it) and tooling (write & debug faster).

Then the reason for (lack of) success of languages becomes more apparent.

@Mike: people don't get/like maths and thus has/will any language based on mathematical notations fail. Sorry.

PS: strangely I still throw bits of PHP to get the job done.

Pjotr

Dec 22, 2010 at 22:07

Let me quote the last sentence of the article you mentioned: "When you get to the bottom of it, however, I write programs in Lisp for the same reason I write prose in English—not because it's the best language, but because it's the language I know best."

Zealots a plenty, democracy works is good but not in programming, language design etc. Take the quote and replace "programming in a language" by "designing a language" and it holds the same truth.

The litmus test ofcourse is if a language gets actually used a lot. I have seen many better languages without a following and the exact opposite also. In the end programs and the pragmatism & productivity in which they are written will always be regarded as more important and always be defended form the perspective of what users are used to. Academic qualities of programming and program language design are interesting to a niche.

From the business point of view, it's not interesting in what language is used, as long as the solution (program) does the job and made and sold for the right price and maybe even can be efficiently maintained. So the swollen ego's of those zealots are tolerated, although all they are all wrong. We let them maintaining their act. This is because they are needed to get something done in the end. It's not the language design etc that is important actually. The bottom line is that the products are needed, and therefore the hands why make these. The rest is just the collateral of inwards looking people with their rituals.

What I like best about Haxe is that it can just end with all this "programming language" war.It has a simple syntax, it's clear, and it's made from the ground up so it can be expressive and output to most of the top PL's / VM's / targets we might need.Because of that I really respect the way Haxe is conducted, and I really am impressed on how versatile has it been.

Mike Austin

Dec 23, 2010 at 20:44

Your article was about how syntax doesn't matter, but Haxe is about clean syntax, so I'm a little confused :) Giving HaXe a second look, I commend you on the syntax and on using type inference. I was jotting down a second language I've been thinking about and it looks pretty much like HaXe - the way variables and return types are declared, literal lists, using <> for generics - the only thing I would do different is:

@Mike Austin: I do not really like that Haxe looks that much like Java, but after one has looked past that (And overcome it's Java-phobia), one quickly realizes that Haxe is a very good language for more reason than you would care of!(Or, I'm not the right person to enumerate those reasons =)

The very best thing about Haxe, is that it is really easy to read.The only thing I would like more and/or better of is documentation.

On the other hand, I've learned much by reading Haxe code that others have written. This is something that is not as easy in other languages. For example I tried something like this as my first thing in python:

x = 0
for i in range(0, 268435456):
x += 1
print x

And it failed after running in several minutes =((The reason to why is leaved out for the unexperienced Python coder to find out of why)

@Philippe: Ouch! =D I'm designing a such language. You're supposed to be able to write stuff like this:

It is mostly just to test some fun ideas, and to actually being able to use some of those extra symbols on my keyboard layout.Don't think that it will become something big; but who knows? =)----Well, back to hacking with Haxe =)

I really liked NekoML as a language - I like ML/Algol syntax. HaXe still has some of that feel (mostly the type declations - particularly of functions). I feel that it hits the sweet spot for popularity.

I appreciate Haxe even more for the multi-targeting implementation. Flash, in particular is an unusual and very useful target for many. In world dominated by C# and Java, the world has forgotten that languages used to be ported to many platforms (not only hardware platforms). Thank you, Nicolas, for making multi-platform the new norm for programming languages.