|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 12
Messages: 12
Messages: 12
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
DSLs, frameworks under consideration at TSSJS in Las Vegas
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.
|
|
|
Message #249698
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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
|
|
|
Message #249701
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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.
|
|
|
Message #249708
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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
|
|
|
Message #249738
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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
|
|
|
Message #249742
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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
|
|
|
Message #249749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Operator overloading
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.
|
|
|
Message #249772
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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
|
|
|
Message #249787
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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.
|
|
|
Message #249801
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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?
|
|
|
Message #249811
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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
|
|
|
Message #250011
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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 :-)
|
|
|
Message #250090
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: DSLs, frameworks under consideration at TSSJS in Las Vegas
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.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
