Syntax Matters...?
smallcultfollowing.com
Syntax Matters...?
1–10 of 44 posts
Re: Syntax Matters...?
#2It is important, however, to distinguish between syntax and expressiveness. I don’t care (too much) whether you write function(x) { ... }, \x -> ... or { |x| ... } to denote a closure, but there had better be a way to write a closure somehow! (Java, I’m looking at you here)
Java is the refutation, IMO: it does have a way to express a closure, it's just that the syntax (anonymous class) is laborious. You need to wrap up any mutable variables to be captured in final single-element arrays, and your closure type will be a single-method interface, but the expressiveness is there. The syntax just sucks.
The laborious syntax is what stops you from writing what may be expressed in C# as 'foo.Where(x => x.Name.Length > 10).OrderBy(x => x.Name)' in Java. The equivalent, even using the smaller Javascript syntax of 'function(x) { return x.name.length > 10; }', is tedious. The (current) Java syntax is just silly.
The syntax "weight" of a feature matters. Syntax that's light and unobtrusive invites use. Syntax that's large and clumsy dissuades use, to the point that whole libraries may not come into existence, not because of a lack of expressiveness in the language, but because of aesthetic ugliness.
Lisp has an out here because of macros; almost everything is equally ugly. Many people appear to consider this base level of ugliness unacceptable; others may see it as a flaw of Lisp, because the very malleability of the syntax makes it harder to encode implementation costs in the form of the program.
Re: Syntax Matters...?
#3It is important, however, to distinguish between syntax and expressiveness. I don’t care (too much) whether you write function(x) { ... }, \x -> ... or { |x| ... } to denote a closure, but there had better be a way to write a closure somehow! (Java, I’m looking at you here) Java is the refutation, IMO: it does have a way to express a closure, it's just that the syntax (anonymous class) is laborious. You need to wrap…
I think you're abusing the word "syntax." I think there is a difference between being able to implement the same functionality of an abstraction, and having direct language support for that abstraction.
I don't think it's accurate to say that Java has clunky syntax for closures. Rather, I think it's more accurate to say that Java has no concept of closures. If you want that functionality, you need to roll your own support using existing concepts. C++ before C++11 is the same.
Re: Syntax Matters...?
#4It is important, however, to distinguish between syntax and expressiveness. I don’t care (too much) whether you write function(x) { ... }, \x -> ... or { |x| ... } to denote a closure, but there had better be a way to write a closure somehow! (Java, I’m looking at you here) Java is the refutation, IMO: it does have a way to express a closure, it's just that the syntax (anonymous class) is laborious. You need to wrap…
You make a very good point. However, I think he addresses your concern over "syntactic weight" in this line:
Basically, there are some languages whose syntax is so distinctive that it makes a qualitative difference to the experience of programming.
I believe his argument then is that of the following three syntaxes (syntaxen?) to describe closures:
function(x) { ... }
\x -> ...
{ |x| ... }
Re: Syntax Matters...?
#5It is important, however, to distinguish between syntax and expressiveness. I don’t care (too much) whether you write function(x) { ... }, \x -> ... or { |x| ... } to denote a closure, but there had better be a way to write a closure somehow! (Java, I’m looking at you here) Java is the refutation, IMO: it does have a way to express a closure, it's just that the syntax (anonymous class) is laborious. You need to wrap…
I think you're abusing the word "syntax." I think there is a difference between being able to implement the same functionality of an abstraction, and having direct language support for that abstraction. I don't think it's accurate to say that Java has clunky syntax for closures. Rather, I think it's more accurate to say that Java has no concept of closures. If you want that functionality, you need to roll your own su…
But isn't that abuse of the word "concept"? The same logic would argue that C has no concept of a string, or that lisp has no concept of an object (despite lots of text handling and OO code being written in both languages). Not every "closure" works the same, even between languages that support things called "closures" and use them in roughtly the same way. Anonymous Java classes are clearly a related concept, and in fact as the grandparent points out there's a straightforward mapping between them.
Re: Syntax Matters...?
#6It is important, however, to distinguish between syntax and expressiveness. I don’t care (too much) whether you write function(x) { ... }, \x -> ... or { |x| ... } to denote a closure, but there had better be a way to write a closure somehow! (Java, I’m looking at you here) Java is the refutation, IMO: it does have a way to express a closure, it's just that the syntax (anonymous class) is laborious. You need to wrap…
I agree with all you said, except that writing the equivalent of "function(x) { return x.name.length > 10; }" on java is a syntax problem. There is a lot implicit when you declare this function on javascript, for example, it's visibility. There's also the typing which is resolved on runtime. So maybe I don't have the concept very clear but, is this really a syntax difference or a language features difference?
Re: Syntax Matters...?
#7Frankly, I've stopped using languages, or lost interest in learning languages, entire over "small" syntax issues. Syntax is a bigger potential deal-breaker to me than functionality in many cases - I spent many times more time reading code than molding my mental model of what I want to do into something I can write down as code in a particular language. If I can't read and scan code quickly, the language is dead to me.
Re: Syntax Matters...?
#8Earlier quoted context omitted.
I think you're abusing the word "syntax." I think there is a difference between being able to implement the same functionality of an abstraction, and having direct language support for that abstraction. I don't think it's accurate to say that Java has clunky syntax for closures. Rather, I think it's more accurate to say that Java has no concept of closures. If you want that functionality, you need to roll your own su…
But isn't that abuse of the word "concept"? The same logic would argue that C has no concept of a string, or that lisp has no concept of an object (despite lots of text handling and OO code being written in both languages). Not every "closure" works the same, even between languages that support things called "closures" and use them in roughtly the same way. Anonymous Java classes are clearly a related concept, and in…
I would argue that C has no concept of a string: there is no direct support in C (or C++, for that matter) for concepts related to strings. They are just arrays that happen to contain characters. All of the strigyness of those arrays exists solely in the mind of the programmer. C itself does not help you any. That is, I think, the hallmark of a language level abstraction: does the language allow you to think of the entity only as its abstraction, or do you need to handle that yourself? This fact is also, I think, a major reason why there are so many string-related bugs in C code.
Having never used Common Lisp, I can't say if that's also accurate for your other example.
Edit: ARGH. I forgot string literals in C. So C clearly does have the concept of strings. The problem is that's the only support in the language for that concept. Aside from being able to define string literals, C does not help you with strings at all.
Re: Syntax Matters...?
#9Well, there are two things here: syntax, and lexical form or lexical syntax -- the underlying structure and the textual representation. The term 'lexical form/syntax' ought to be more popularly used, and hence make it clearer to talk about exactly what we like or do not.
Re: Syntax Matters...?
#10It is important, however, to distinguish between syntax and expressiveness. I don’t care (too much) whether you write function(x) { ... }, \x -> ... or { |x| ... } to denote a closure, but there had better be a way to write a closure somehow! (Java, I’m looking at you here) Java is the refutation, IMO: it does have a way to express a closure, it's just that the syntax (anonymous class) is laborious. You need to wrap…
You make a very good point. However, I think he addresses your concern over "syntactic weight" in this line: Basically, there are some languages whose syntax is so distinctive that it makes a qualitative difference to the experience of programming. I believe his argument then is that of the following three syntaxes (syntaxen?) to describe closures: function(x) { ... } \x -> ... { |x| ... } The differences are so slig…
Part of my comment is arguing that there is actually a significant difference in aesthetics between "\x -> y" and "function(x) { return y; }"; and that query library like LINQ is natural to use with the former syntax, but so awkward to use with the latter that it's unlikely to be written in that way because of how ugly it would be in use.