3 ms·
Even that isn't smooth enough for me. Why is the 'var as' still there? it's superfluous, ofcourse we're declaring a variable, there's nothing else that makes s
by chton 12y ago
Even that isn't smooth enough for me. Why is the 'var as' still there? it's superfluous, ofcourse we're declaring a variable, there's nothing else that makes sense at that point. Why not:
def hello(String name) as String:
String greeting
greeting = 'Hello '+name
return greeting
which is how a lot of other languages are doing it. On the other hand, maybe I just don't like writing syntax that doesn't add any meaning :p
- mborch 12y agoWhile definitely superfluous, it arguably makes it easier to read and scan.
- chton 12y agoI think that's a matter of habit. I've gotten far more used to the more condensed syntax, so for me that's faster to read and scan. I tend to prefer languages where there is little syntax wasted as a consequence.
- seanmcdirmid 12y agoC style type annotations that put type before name were never as elegant as pascal style annotations that put name before type. They are also more consistent.
- chton 12y agoelegance is debatable, and consistency is a matter of how the rest of the language is built. But you can still eliminate the superfluousness (is that a word?) by using greeting as String or even greeting :: String Either is fine, though my preference would then go to the latter option, since it'll be faster when scanning.
- scott_s 12y agoHaving a language keyword which means "we are now defining a new variable" makes parsing easier, and you run into less ambiguity. See: http://en.wikipedia.org/wiki/Most_vexing_parse http://en.wikipedia.org/wiki/Most_vexing_parse
- chton 12y agoAmbiguity in the language is a whole problem of its own. Ambiguity in parsing is also ambiguity in writing, so a language should avoid it all cost. It's true that forcing actions to come with extra words is a way to do that, but it's by no means the only one. It's possible to strive for non-ambiguity without extra syntax. A good example of this case would be Java (like it or not): String Hello(String name) { String greeting; greeting = "hello " + name; return greeting; } Say of the braces and the semicolons what you will, but the core syntax is unambiguous and doesn't have a single word that doesn't have semantic meaning.
- scott_s 12y agoI was exclusively talking about parsing ambiguity. Using a keyword to introduce entity definitions (variables, functions, packages, etc.) gives the language more space to grow in syntax without worrying about such ambiguities later. You can construct a grammar without any ambiguities that does not use such keywords - such as with your example of Java - but you're going to have to keep this pitfall in mind anytime you change the grammar.
- chton 12y agoThat's true, it does make it easier to evolve the syntax. The negative side of demanding a terse syntax is clear enough in the C# 6 changes (http://msdn.microsoft.com/en-us/magazine/dn683793.aspx http://msdn.microsoft.com/en-us/magazine/dn683793.aspx), which are really showing a lot of bloat. It's possible to debate the positive side too, but I do agree that constructing a language with a verboser non-semantic grammar is easier.
- 12y ago
- pdabbadabba 12y agoArnoldC or go home. LISTEN TO ME VERY CAREFULLY hello I NEED YOUR CLOTHES YOUR BOOTS AND YOUR MOTORCYCLE name GET TO THE CHOPPER greeting . . . ENOUGH TALK GIVE THESE PEOPLE AIR I'LL BE BACK greeting HASTA LA VISTA, BABY (I have a truly marvelous ArnoldC string library (with string concatenation), which this margin is too narrow to contain.) Of course, the comparison may not be very illuminating given that all ArnoldC variables are Int16s.
- chton 12y agoI'll counter your ArnoldC with http://shakespearelang.org/ http://shakespearelang.org/ But only because You are as brave as the sum of a fat little stuffed misused dusty old rotten codpiece and a beautiful fair warm peaceful sunny summer's day is pure art.