Summary
While syntax extensions may not add new functionality to a language, such extensions, or syntactic sugar, can make a language more suitable for specific problem domains, writes Debasish Ghosh in a recent blog post.
Advertisement
Programming languages are often about culture as much as about language capabilities. One area where the cultures of various languages differ is their attitude toward syntactic sugar, writes Debasish Ghosh in a recent blog post.
Java culture looks upon syntactic sugar with more suspicion than, for example, Lisp or Ruby or Groovy cultures do. This is problematic, because, according to Ghosh,
Syntactic sugars, when properly designed, reduce the semantic distance between the problem domain and the solution domain. Syntactic sugars do not add new features or capabilities to an existing language. Still we value them mainly for social reasons - they can make your abstractions much more explicit, thereby making your intentions much more direct. And syntactic sugars often lead to concise and succinct code much pleasing to your eyes... I am always for [the] intention [of] revealing syntactic sugars - after all .. Programs must be written for people to read, and only incidentally for machines to execute ?
Ghosh points out that syntactic sugar not only makes programs possibly easier to read and understand, but may also render a language more suitable for specific problem domains via internal DSLs. Whereas Java developers often look for a framework to solve domain-specific problems, developers using more syntactic sugar-friendly languages tend to develop internal DSLs instead:
Syntax extensibility is a necessity if you want your language to support evolution of DSLs. Extensible syntax scales much better than the framework based approach so popularized by Java. When you add a new syntactic structure in your language, it meshes so nicely with the rest of the language constructs that you never feel that it has been externally bolted on to you...
Although in reality it is nothing more than syntactic sugars being presented in a form that makes more sense when coding for the particular problem in hand. When we talk about a language, we think in terms of parsers - this is no different when we think about DSLs. Implementing an external DSL is hard, considering the enormous complexity that parser generators make you go through. Scala offers monadic parser combinators where you can directly map your EBNF syntactic structures into implementations. And all this is done through syntactic sugars on top of closures and higher order functions that the language offers...
Ghosh believes that languages supporting higher-order functions are more amenable to syntax extensions. Still, he believes that syntax extensions are equally a cultural and attitude issue:
Remember the explosion in the number of blog posts in celebration of the for-each loop when it came out with Java 5. In other languages, people build new syntax by the day and evolve new vocabulary within the same language that maps into the domain that they model. If you miss those features which you enjoyed in your earlier language, just build it over the new language. And it does not necessarily have to be the process of hooking onto the compilation cycle or plugging in customized modules into your language parsers.
What is your attitude toward syntax extensions, or syntactic sugar?
I would divide this into two parts: first the good. Syntax is hugely important. A good, type-safe language needs type inference, closures, static data-structure initialization syntax, etc. Basically all the stuff that Microsoft is putting in C# 3.x.
The bad: DSLs with syntactic extensions. I don't think they bring much to the table. I've only seen them work (and not particularly well) when you have a pure-declarative domain. Once you have a for loop and an if statement, you might as well go whole hog and write a Plain Old Library In A Decent Language (POGLAIDL, pronounced poge-ladle.) Good library design that "stays within the lines" of a language with excellent syntax support is perfect: you don't have to learn a new syntax and your problem is solved with a minimum of fuss.
We'd be better off focusing on what makes good library and framework design (my opinion: make the simple things *dead* simple and the hard things possible) rather than inventing new DSLs. Unfortunately, the latter is more fun and sexier, so we'll have to fight its allure.
> I would divide this into two parts: first the good. > Syntax is hugely important. A good, type-safe language > e needs type inference, closures, static data-structure > initialization syntax, etc. Basically all the stuff that > Microsoft is putting in C# 3.x. > > The bad: DSLs with syntactic extensions. I don't think > they bring much to the table.
It depends a lot whether you are thinking in terms of big shops and being scared about everything that is not controlled by process and not being standardized or using a language and metalanguages as a medium of expression. Java people are always scared about unlimited expressivity and Lisp people are always scared about limitations thereof [1]. Just because one has won the marketplace and the hearts of the management doesn't mean it is just true.
[1] Actually they don't even think there is a valuable distinction between evolving programs and shaping the language. So the term DSL is already an indication of decline.
> We'd be better off focusing on what makes good library and > framework design (my opinion: make the simple things > *dead* simple and the hard things possible) rather than > inventing new DSLs. Unfortunately, the latter is more fun > and sexier, so we'll have to fight its allure. >
I agree. This has always been one of major goals with C++, i.e. to make the core language flexible enough for creating useful libraries instead of adding new constructs to the language itself (the approach taken with C#). From "programming language" discussions I've seen in the past several months lots of people seem to prefer extending the core language without realizing that it is the wrong path: Do we modify the language and its compiler every time we discover some new construct?
> We'd be better off focusing on what makes good library and > framework design (my opinion: make the simple things > *dead* simple and the hard things possible) rather than > inventing new DSLs. Unfortunately, the latter is more fun > and sexier, so we'll have to fight its allure. > > Cheers, > Carson
Hmmm. Looks like artima ate my first reply. Here's a shorter version:
_shrug_
I'm making general assertions about what direction we as the enterprise software development community should go. So I think "we" is appropriate.
I'm happy to change my opinion if you can give me short, specific examples of how a DSL can give a significant syntactic win over a good library written in a solid general purpose language like C# 3.0. I'd point to the posts that Alan Keefer and I put up in the last closures thread as good examples of, er, examples:
Perl has, what, 12 different syntaxes? The problem is that unless your familiar with all 12, reading a Perl program is like reading a foreign language. You're constantly referring to the dictionary to figure out what this syntax thingie does in this context. I can only imagine the tower of babel that a proliferation of DSL's would create.
I think Python's "only one obvious way to do it" approach is more practical. Sure, Pythong has sugar - any language more advanced than a Turing machine has sugar - but the syntax additions are carefully weighed and crafted. Heck, some of the reason behind Python 3 is to remove previous syntax additions that were deemed a mistake.
I'm not saying Python is the golden language that we should all adhere to. What I am saying, though, is that its approach to new syntax seems to be the best balanced among the different languages that I have used.
> > You speak for you, and not "we". > > Hmmm. Looks like artima ate my first reply. Here's a > shorter version: > > _shrug_ > > I'm making general assertions about what direction we as > the enterprise software development community should go. > So I think "we" is appropriate.
The problem is that you can't make the decision of "better off" for others. Maybe for "your" team, "you" would be better off without Macros or other syntax extensions, but other teams have to make that decision on their own.
> > I'm happy to change my opinion if you can give me short, > specific examples of how a DSL can give a significant > syntactic win over a good library written in a solid > general purpose language like C# 3.0. I'd point to the > posts that Alan Keefer and I put up in the last closures > thread as good examples of, er, examples: > >
I'll agree that C# 3.0 is a step up from the boiler-plate ridden of current Java, but then compare C# 3.0 to say Groovy. Obviously static typing plays a difference, but we're just talking about syntax here.
> The problem is that you can't make the decision of "better > off" for others. Maybe for "your" team, "you" would be > better off without Macros or other syntax extensions, but > other teams have to make that decision on their own.
Sure I can, since I'm not a relativist. The vast majority of people would be better off they, and the code they had to deal with written by other people, didn't have macros, syntax extensions or, the original topic, DSLs. All they need is reasonably powerful syntax in the plain ol' general purpose language they use.
> I'll agree that C# 3.0 is a step up from the boiler-plate > ridden of current Java, but then compare C# 3.0 to say > Groovy. Obviously static typing plays a difference, but > we're just talking about syntax here.
I think, from a LOC perspective, you can get C# 3.0 very close to anything you can write in Groovy, mod some type declarations. With the local type inference, you get very close to characters-per-line as well.
Again, I'm willing to change my opinion if you can show me a good, simple example of DSLs (the original topic) that solves a believable business logic problem in a way that general purpose would stumble over syntactically.
> > The problem is that you can't make the decision of > "better > > off" for others. Maybe for "your" team, "you" would be > > better off without Macros or other syntax extensions, > but > > other teams have to make that decision on their own. > > Sure I can, since I'm not a relativist. The vast majority > of people would be better off they, and the code they had > to deal with written by other people, didn't have macros, > syntax extensions or, the original topic, DSLs. All they > need is reasonably powerful syntax in the plain ol' > general purpose language they use. >
Once again, you don't speak for "we".
> > I'll agree that C# 3.0 is a step up from the > boiler-plate > > ridden of current Java, but then compare C# 3.0 to say > > Groovy. Obviously static typing plays a difference, > but > > we're just talking about syntax here. > > I think, from a LOC perspective, you can get C# 3.0 very > close to anything you can write in Groovy, mod some type > declarations. With the local type inference, you get very > close to characters-per-line as well. > > Again, I'm willing to change my opinion if you can show me > a good, simple example of DSLs (the original topic) that > solves a believable business logic problem in a way that > general purpose would stumble over syntactically. > > Cheers, > Carson
Actually, the topic was syntactic sugar and not DSLs. I'm not interested in changing your mind, I was just pointing out that it's pointless to say "we'd be better off" when you don't speak for "we".
> "We" don't need no stinkin' sugar, "let's" go back to > assembler.:)
Right. Because there is no ground between assembler and DSLs/syntactic extensions.
As I've said in this thread and many, many others: syntax matters a lot. Good closures, good static initializers, type inference, LINQ, etc. all contribute hugely to the readability of C# 3.0 and, my favorite, our internal language GScript.
I still would like a good, simple example showing me how syntactic extensions (which I'm calling DSL support) simplify a common business problem enough to justify the mental overhead they cause. I'm not being sarcastic here: I really do want to see it. If there is a tool out there I'm not using that could save me complexity, I'd like to use it.
Please, show me I'm wrong! It wouldn't be the first time, and, if I am, it certainly won't be the last time.
One thing I will say is that in a language as barren as java, I can see the attraction of DSLs. Take LINQ for example. Is that a DSL? Well, kinda. But I see "finding objects" as a fundamental enough operation to belong directly in a general purpose language, and think it should be baked in in a standard manner, not bolted on in different ways by different DSL designers. Same with a "with" statement that handles Disposal-like functionality. So my bar for the syntax support of a general purpose language is pretty high. But once you have those, plus closures and friends, I think you can come very close to any other syntax you might design simply using good ol' functions and objects.
Again, I might be wrong. I'd be happy to be shown so.
> I still would like a good, simple example showing me how > syntactic extensions (which I'm calling DSL support) > simplify a common business problem enough to justify the > mental overhead they cause.
If you consider SQL a DSL, then I use one. Other than that, I'm simply reading up on Common Lisp and Scala right now. Hopefully I won't misrepresent what people with more expertise in DSL's would say.
The problem is that any common business problem probably already has support in a language/library/pattern/framework/etc. DSL's SEEM to be most helpful with "explorative" programming, i.e. coding when you're not sure of the extent of the problem or the "shape" of the solution. In which case, a developer versed in a language that allows DSL creation more or less creates "jargon" to express repeating ideas.
DSL's seem like a powerful idea but like anything else in our field, there's a time and place they're appropriate for.
Here's a story I read from a CL guy recently. It gives you a little more concrete example.
Something else to consider is that we don't all learn and represent our ideas the same way. Some developers seem to think and learn better through graphical images while some think better in languages. Why some developers may prefer languages that allow the creation of syntactical language extensions may simply be because they think better that way.
> > "We" don't need no stinkin' sugar, "let's" go back to > > assembler.:) > > Right. Because there is no ground between assembler and > DSLs/syntactic extensions. > > As I've said in this thread and many, many others: syntax > matters a lot. Good closures, good static initializers, > type inference, LINQ, etc. all contribute hugely to the > readability of C# 3.0 and, my favorite, our internal > language GScript. > > I still would like a good, simple example showing me how > syntactic extensions (which I'm calling DSL support) > simplify a common business problem enough to justify the > mental overhead they cause. I'm not being sarcastic here: > I really do want to see it. If there is a tool out there > I'm not using that could save me complexity, I'd like to > use it. > > Please, show me I'm wrong! It wouldn't be the first time, > and, if I am, it certainly won't be the last time. > > One thing I will say is that in a language as barren as > java, I can see the attraction of DSLs. Take LINQ for > example. Is that a DSL? Well, kinda. But I see "finding > objects" as a fundamental enough operation to belong > directly in a general purpose language, and think it > should be baked in in a standard manner, not bolted on in > different ways by different DSL designers. Same with a > "with" statement that handles Disposal-like functionality. > So my bar for the syntax support of a general purpose > e language is pretty high. But once you have those, plus > closures and friends, I think you can come very close to > any other syntax you might design simply using good ol' > functions and objects. > > Again, I might be wrong. I'd be happy to be shown so. > > Cheers, > Carson
There's the difference between me and you (there is no "we"). You would rather the language restrict someone from doing their own using (C#) statement and I would rather have something like a Boo macro system in order to be able to do my own.
I'm not trying to and I don't want to convince you of anything. And I'm sure there will be languages on the JVM/CLR that will accommodate us both.
The point I was making is that there is no "we should be trying to....".
Flat View: This topic has 21 replies
on 2 pages
[
12
|
»
]
Previous Topic
