DSLs, frameworks under consideration at TSSJS in Las Vegas

Home

News: DSLs, frameworks under consideration at TSSJS in Las Vegas

  1. By Jack Vaughan In recent years, much Java development has centered on use of application frameworks. A next evolutionary step may see greater use of domain-specific languages (DSLs), software architect and author Neal Ford told an audience at the first day of TheServerSide Java Symposium in Las Vegas. Popular frameworks such as Hibernate, Struts, and Spring have reduced complexity in programming, but “complexity can creep into the frameworks,” Ford warned. He indicated that DSLs could be a logical next step to reduce such complexity. In fact, while he sees continued use of Java as a stable base platform, Ford also sees a shift in the patterns of language-oriented programming to include far more languages. DSLs are computer languages specially tailored to handle a specific set of problems. In instances, DSLs are used atop more general, stable languages to more quickly achieve programming goals. “Objects, aspects and generics become the building blocks for your DSLs,” said Ford, who serves as a senior application architect at ThoughtWorks. In his words, DSLs are a form of jargon. As such they can more readily communicate intentions in specialized domains than can general purpose object languages like Java. JUnit and JMock are examples of increasingly popular DSLs. “All nontrivial behavior has [its own] jargon,” Ford said. “It takes too long to communicate if you don’t have any short hand.” For samples of jargon he drew from a spectrum of domains, ranging from that of the jazz musician to that of the short-order cook. A valuable aspect of DSLs is that they can be created to more closely resemble the way end users speak, he said. XML has served as a descriptive language that has often become a partner with Java, used especially for holding configurations info and allowing late binding of those configurations. This partnership may not be the best thing, going forward, in Ford’s opinion. “We are using XML as an external DSL but it’s terrible at that,” he said. He noted that XML config files are beginning to comprise thousands of lines of code, highlighting a configuration file from Struts that the audience recognized even though the text was too small to read. Ford mentioned a variety of language workbenches from Intentional Software (still in semi-stealth mode), Microsoft (via its work on Software Factories) and Jetbrains (soon to release a new style of IDE), as examples of tools that might enable effective DSL-based development in the future. “The goal of the DSL is an improved abstraction,” he said. “If we can get closer to the way our users talk about problems, we can solve them more easily.” Ford’s message about DSLs comes at the same time that dynamic languages such as Ruby and Groovy are becoming a greater part of a world that was once somewhat exclusively Java-speaking. As in other recent editions, this Java Symposium considers a good many other languages now coexisting with Java. TheServerSide.com Site Editor Joe Ottinger has indicated that this is a point of view likely to become more commonly found on TheServerSide.com itself as a reflection of the site’s community’s evolving interests.
  2. If we can get closer to the way our users talk about problems, we can solve them more easily.
    I think this sentiment is inherently over generalized when talking about DSL (in a pure sense of DSL that is *new* programming language). Most of it can be solved with proper abstractions existing in most languages (let alone Java or C#). People were screaming that it is impossible to develop a good math library in Java because… it doesn’t support operator overloading (one of the oldest forms of DSL-ish) like C++. By now we all know how “true” is was. I like DSL approach when it ends in good domain model and/or good set of annotations (JPA is a good example for me) – but DOES NOT end up producing a new language no matter how seemingly simple it may look in the beginning. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple

  3. If we can get closer to the way our users talk about problems, we can solve them more easily.

    I think this sentiment is inherently over generalized when talking about DSL (in a pure sense of DSL that is *new* programming language). Most of it can be solved with proper abstractions existing in most languages (let alone Java or C#).
    Not in current Java.
    People were screaming that it is impossible to develop a good math library in Java because… it doesn’t support operator overloading (one of the oldest forms of DSL-ish) like C++. By now we all know how “true” is was.
    It was true then, and true now.


    I like DSL approach when it ends in good domain model and/or good set of annotations (JPA is a good example for me) – but DOES NOT end up producing a new language no matter how seemingly simple it may look in the beginning.

    Best,
    Nikita Ivanov.
    GridGain - Grid Computing Made Simple
    The idea behind the intentional software language workbench is to make it simple in the beginning and the end, but we'll see how that turns out in practice. I'd give 50/50 on Intentional Software making a big mark.
  4. Frank,
    The idea behind the intentional software language workbench is to make it simple in the beginning and the end
    do you even understand what this sentence means or how it relates to the discussion? I think I don't :) Anyways, have fun with this stuff. Best, Nikita Ivanov. GridGain - Grid Computing Made Simple
  5. By now we all know how “true” is was.


    It was true then, and true now.

    Care to elaborate? I haven't seen any evidence that it's true. Because Java doesn't allow operator overloading, the syntax might look a bit cumbersome, but that's not how you define a "good" mathematic library. If anything, Java has proved over and over again that its simple syntax and extraordinarily rich ecosystem has allowed it to outlast many technologies and other languages that were claimed to spell its doom. To me, the continuing success of Java is good evidence that DSL's are just not delivering their promise and that the correct way to approach complexity is to extend a simple foundation with solid libraries, not to invent new languages. -- Cedric http://testng.org
  6. Operator overloading[ Go to top ]

    It could even be argued that the C++ operator overloading is 1) Dangerous, because not just the mathematical operators are overloadable, but also new, delete, assignment, casting etc. so very much ends up done "under the hood" where the programmer won't necessarily look. For instance, should assignment of an matrix to a primitive variable be flagged as an error, or should the library "helpfully" compute some value associated with the matrix in a cast operator? (This is also a problem with DSLs sometimes, because you need to know what actual operations the DSL's instructions perform, e.g. for debugging purposes.) 2) Incomplete, because math has a plethora of operators that aren't in the language. How do I define operators for Sigma? "For all"? Dot product? C++ falls back to using functions where it cannot use its very limited set of operators anyway, so for purposes of a mathematical library C++ is in effect just as limited as Java - with the exception of those few operators it graciously lets you define. 3) Static, in the sense that the compiler has hardwired precedence rules you need to know about (or else be liberal in your use of parenthesis for grouping. Does the compiler's precedence rules fit your particular domain's "borrowing" of the operators which are intended for scalars? So: Java is better off without it, and if you want them use a better language than C++ (like Smalltalk) for their implementation.

  7. By now we all know how “true” is was.


    It was true then, and true now.




    Care to elaborate?

    I haven't seen any evidence that it's true.

    Because Java doesn't allow operator overloading, the syntax might look a bit cumbersome, but that's not how you define a "good" mathematic library.

    If anything, Java has proved over and over again that its simple syntax and extraordinarily rich ecosystem has allowed it to outlast many technologies and other languages that were claimed to spell its doom.

    To me, the continuing success of Java is good evidence that DSL's are just not delivering their promise and that the correct way to approach complexity is to extend a simple foundation with solid libraries, not to invent new languages.

    --
    Cedric
    http://testng.org I hear you & agree that Java the language has been crucial in building a large and powerful ecosystem around the Java platform. Though I dunno about you but I use loads of different languages each day even when developing on the Java platform... * HTML / CSS * confluence markup * XPath / XQuery /XSLT * XML / Spring XML * JSP & JSP EL * Velocity * ${foo.bar} in Maven/Spring XML (which is kinda a cut down JSP EL) * JPA QL * SQL * Camel * regex * groovy / jruby I don't see the number of languages we use every day going down any time soon; if anything it'll just keep increasing as different languages help us to solve problems in easier ways. I certainly hope for better tooling so we can more easily create higher level languages to help express ourselves in more natural ways. Though I agree that most of the library code is probably gonna be written in Java code :) James Iona Open Source Integration
  8. To me, the continuing success of Java is good evidence that DSL's are just not delivering their promise and that the correct way to approach complexity is to extend a simple foundation with solid libraries, not to invent new languages.
    +1 Could not have said it better. Sane voices and common sense engineering can still be heard and found. Thank you, Nikita Ivanov. GridGain - Grid Computing Made Simple.
  9. Because Java doesn't allow operator overloading, the syntax might look a bit cumbersome, but that's not how you define a "good" mathematic library.
    What does make a good mathematical library? Operator overloading certainly would not make a poorly designed mathematical library better, but I think a well designed library with operator overloading would be better than an equally well designed one without it.
    If anything, Java has proved over and over again that its simple syntax and extraordinarily rich ecosystem has allowed it to outlast many technologies and other languages that were claimed to spell its doom.
    Are you implying a causal relationship, as in the simple syntax caused or significantly contributed to the emergence of an extraordinarily rich ecosystem?
  10. What does make a good mathematical library? Operator overloading certainly would not make a poorly designed mathematical library better, but I think a well designed library with operator overloading would be better than an equally well designed one without it.
    Sure.
    If anything, Java has proved over and over again that its simple syntax and extraordinarily rich ecosystem has allowed it to outlast many technologies and other languages that were claimed to spell its doom.
    Are you implying a causal relationship, as in the simple syntax caused or significantly contributed to the emergence of an extraordinarily rich ecosystem?
    The syntax is certainly a big part of Java's success: it builds on C++' strength while removing a lot of the complexity that had been forced upon it for backward compatibility reasons. I remember how liberating it felt in my first few months programming Java: suddenly, I had access to most of C++' power without the compiler getting in the way all the time... Did you have a similar experience? -- Cedric
  11. I remember how liberating it felt in my first few months programming Java: suddenly, I had access to most of C++' power without the compiler getting in the way all the time... Did you have a similar experience?
    Not so much. I really missed operator overloading and templates, although now I find generics to be a powerful substitute for templates, and much less error prone. But...not spending hours tracking down problems with operator overloading and templates probably increased my productivity. I don't think the problem is that the compiler gets in the way. I think the problem is that specifying what you want to the compiler to do is often far more complex than you think it should be. I think in more general terms the problem is that the more complicated the compiler is, the more intimate of an understanding of the compiler is required to effectively use it. The Java compiler is dead simple. That can be a significant advantage.
  12. To me, the continuing success of Java is good evidence that DSL's are just not delivering their promise and that the correct way to approach complexity is to extend a simple foundation with solid libraries, not to invent new languages.

    --
    Cedric
    http://testng.org
    Cedric, I agree with you completely that Java is a fantastic language and eco-system to be in. It is why I believe so strongly in Groovy and Grails. However, to claim DSLs haven't delivered on their promise is a little silly. They haven't had time to deliver on any promise! DSLs have only really started being mentioned and talked about seriously in the last 2 years. Java has had 13 years to get where it is now. Really there currently does not exist any killer framework for creating external DSLs easily although there have been efforts (MPS from Jetbrains etc.). ANTLR and Javacc are just too hard for Joe normal. As for internal DSLs, we're seeing only now the power of alternative languages like Groovy and JRuby come to the fore in this space and there are some really nice examples of their usage. I think personally the real danger is in people thinking that Java is the only game in town and that you must build everything in Java. It results in some horrendously complicated code. That is not to dismiss Java and say its bad, it is as I said fantastic and I am a Java developer first and foremost. However, it is not fantastic for everything. For me this is the fundamental change that is happening and will continue to happen. The realization that you use the best tool for the job and there is not "one ring" to rule them all. However, the big danger when you start to use multiple languages and DSLs is the tooling. You want to retain the maintainability of Java that you get with refactoring and code analysis tools. You see this problem with HTML/Javascript + Java web applications and I believe it is why GWT exists. For me this problem has completely been eliminated by IntelliJ's JetGroovy plugin with its roundtrip refactoring between Groovy & Java. Now all that needs to be done is Eclipse support at the same level :-)

  13. If we can get closer to the way our users talk about problems, we can solve them more easily.

    One thing I guess is important about DSL is the language part. Languages are to describe things, using a grammar and a vocabulary. For my purposes, a language may not actually need to be compiled or executed. It should be fine just to describe something. So, Human-interpreted languages are perfectly fine.
    In this post ( Talk about DSL ) I discuss about them, and my actual conclusion is that we do DSL every time the coding lang does not fulfill our needs. They will work for small problem solving up to architecture description. It is not to reinvent the wheel or write new Java cousin, but to allow a better way to solve a problem.
    William Martinez Pomares.
    Architect's Thoughts