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 ;)