|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 19
Messages: 19
Messages: 19
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Opinion: Domain Specific Languages picking up steam?
Sergey Dmitriev, the CEO of JetBrains, was interviewed at JavaOne. He discussed IntelliJ IDEA, Visual Fabrique, and also got into the new Meta Programming System (MPS) that JetBrains uses. This system seems similar to the DSL meta system that Microsoft is working on. Is this the new MDA/UML?"With this system you can quickly develop the syntax structure, an editor and a code generator for custom domain specific languages." Sergey explains that this ISN'T UML. This is the same stance that Microsoft has:CGN: Is this in UML? What is the visual language?
Sergey: The visual language is not one language. It's not an MDA-like program. We have two main parts that are public. One describes the business model, similar to an entity relationship diagram. But it's not about this, it's about business objects. It's a diagram editor because that's a convenient way to represent such models. And we also have editors for queries to the database, but again, not in UML.
We also can discover a database, and talk to web services or to session beans. However, we describe these things on a more abstract level. We don't push the user to use a concrete run-time platform, like J2EE, .NET, Web services, and so forth. You don't need to choose this at an early stage.
This is a domain specific language for this domain, which is data access plus a web user-interface. So for the moment it's just for web applications. But in the future we will also do client side applications. For each domain we will have a special language. Then we generate for a particular computer language. Right now that means we generate Java and J2EE. In the future we will add .NET and others.
When you use a more high-level description, you have less dependence on the target platform.
Our domain specific language for web pages is based on XHTML, and we have a set of web controls that are expressed in our own language. Read the full interview.
|
|
|
Message #129610
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Doesn't XML allow for Domain Specific Languages?
I've made a few domain specific languages using XML mixed with XSL and Java for code generation. It works great.
Getting companies to buy into a Domain Specific Language is pretty difficult though. Most would rather cut and paste ad infintum.
+1 for being able to refactor from the Domain Specific Language out to the Java code.
-1 for putting a GUI on the Domain Specific Language. VB anyone?
|
|
|
Message #129613
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Domain Specific Languages picking up steam?
Formal languages can solve strictly computable problems - they are both equivalent to a Turing machine.
Reality is non-computable; however, it can be reduced locally to a computable problem by accepting a finite set of axioms in the system. But such a system is either incomplete or inconsistent.
This type of solution is perfectly acceptable iif we have a framework managing both the incompletness and inconsistencies in our system.
IMO though, just the langugage/editor do not provide are not sufficient for providing a manageable solution. A tool to manage the domain statements out of which the language/editor are generated is also required.
Great idea and very interesting research! And I'm not surprised this comes from a innovative company like JetBrains.
Cheers,
Dino
|
|
|
Message #129639
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Domain Specific Languages picking up steam?
And I'm not surprised this comes from a innovative company like JetBrains. When perhaps the best Java IDE vendor focuses on users avoiding Java, it's an obvious sign that procedural hand coding has peaked.
|
|
|
Message #129645
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Domain Specific Languages picking up steam?
And I'm not surprised this comes from a innovative company like JetBrains. When perhaps the best Java IDE vendor focuses on users avoiding Java, it's an obvious sign that procedural hand coding has peaked.
Yes, old good things never die.
|
|
|
Message #129672
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"Domain specific languages"
I very much doubt that this idea can work in "the real world". There are a couple of reasons for it, for example
- The domain is only understood during the construction process. This is a very common problem in a lot of projects. "Analysts" don't know enough about what the system formally requires and are not able to communicate requirements in a concise way. I would assume this is a prerequisite for developing a domain specific language.
- Domains are too broad. A lot of projects deal with a domain like "the business of United Airlines". This is essentially not a single domain but at least a dozen formal business domains and even more technical domains. One ends up with dozens of languages, potentially with different syntax and editing tools.
- Domain is insufficient. You can see this with fabrique at the moment. Nice to quickly put together simple web apps. But as soon as you work with multiple databases and a message queue and a couple of flat files at the same time as your data source and sinks, you need more flexible, more mature tools
- Graphical editors break down early. This is even true for database modelling, where only very sophisticated (and expensive) tools give good graphic representation for the entire development circle. And this is only data modelling.
- Redundant learning. Learning a new domain language is only justified if it gives you very significant advantage about the generic language. With languages like Java and .NET this is not easy.
|
|
|
Message #129749
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Domain Specific Languages picking up steam?
I suspect it's more of an issue of the IDE market being commoditized at the low end. This means tools vendors must provide something over and above simple IDE functionality that may be had for free. Perhaps something like an MDA tool maybe (grin).
|
|
|
Message #129783
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Domain Specific Languages picking up steam?
Formal languages can solve strictly computable problems - they are both equivalent to a Turing machine. Reality is non-computable; however, it can be reduced locally to a computable problem by accepting a finite set of axioms in the system. But such a system is either incomplete or inconsistent.This type of solution is perfectly acceptable iif we have a framework managing both the incompletness and inconsistencies in our system. According to Goedel (to whom you are referring here I presume) you have either inconsistency OR incompleteness. I'd rather settle for the lack of completeness because I as a developer can fill this void personally. In fact, that's how we all earn our money ;-)
|
|
|
Message #129791
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Opinion: Domain Specific Languages picking up steam?
Yes, I am referring to Goedel's theorem. From this perspective, development seems to cycle between incomplete and inconsistent states. Deliverables seem to belong to the first category though.
|
|
|
Message #129816
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Domain Specific Languages
I very much doubt that this idea can work in "the real world". There are a couple of reasons for it, DSLs have been used with great success for over a decade by the Functional Programming community. If you look into this a bit, bear in mind that they often use the term "combinator library" when referring to DSLs. The FP community's favourite use of Monads is for DSLs (a successor to Monads is proposed - Arrows). Also note the arguments in favour of Domain Specific Embedded Languages (DSELs) over DSLs.
The Logical Programming community gets DSLs, too. See this paper:
"A Horn Logic Denotational Framework for Specification, Implementation, and Verification of Domain Specific Languages" by Gopal Gupta and Enrico Pontelli
(www.cs.nmsu.edu/~gupta/logden/dsl.ps)
Imperative programming language practice has lagged badly, and it is time to enjoy the benefits of DSLs/DSELs. The domain is only understood during the construction process. This is a very common problem in a lot of projects. "Analysts" don't know enough about what the system formally requires and are not able to communicate requirements in a concise way. I would assume this is a prerequisite for developing a domain specific language. You are confusing waterfall process with DSLs. There is no connection. Development of DSLs is highly iterative.Domains are too broad. A lot of projects deal with a domain like "the business of United Airlines". This is essentially not a single domain but at least a dozen formal business domains and even more technical domains. One ends up with dozens of languages, potentially with different syntax and editing tools. For a look at an approach for linking domain semantics for very complex endeavours, see the work for the Rosetta System Level Design Language (www.sldl.org). Domain is insufficient. You can see this with fabrique at the moment. Nice to quickly put together simple web apps. But as soon as you work with multiple databases and a message queue and a couple of flat files at the same time as your data source and sinks, you need more flexible, more mature tools It would be wrong to judge DSLs by where fabrique is at right at this moment in the development of their product. There is plenty of other experience with DSLs. Graphical editors break down early. This is even true for database modelling, where only very sophisticated (and expensive) tools give good graphic representation for the entire development circle. And this is only data modelling. Agreed, but there is no particular connection between graphical editors and DSLs. Historically, DSLs have been developed non-graphically.Redundant learning. Learning a new domain language is only justified if it gives you very significant advantage about the generic language. With languages like Java and .NET this is not easy. You are thinking about domain languages in terms of large general purpose languages, and this is leading to you to a wrong conclusion. Instead, try equating a DSL with an API. Do you avoid APIs because there is something to learn about using them? I hope not.
Also, there is no avoiding acquiring the necessary domain knowledge under any approach, and hence no possibility of avoiding learning. A DSL makes standard (normalises, if you like) the domain knowledge.
|
|
|
Message #129858
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Domain Specific Languages
You are confusing waterfall process with DSLs. There is no connection. Development of DSLs is highly iterative. No I don't think I am. But I do know that you require more than a single programmer for a project and I know that the quality of most "software engineers" is not good enough to sustain a single comprehensive language, let alone a lot of languages that are "evolving" and "iterative". Also I know that even if some domain languages will be available, people will be reluctant to use them but rather "roll their own", much like with APIs. And finally, waterfall process is back big time with the current trend to offshoring anyway :-)>ou are thinking about domain languages in terms of large general purpose languages, and this is leading to you to a wrong conclusion. Instead, try equating a DSL with an API. Do you avoid APIs because there is something to learn about using them? I hope not.Also, there is no avoiding acquiring the necessary domain knowledge under any approach, and hence no possibility of avoiding learning. A DSL makes standard (normalises, if you like) the domain knowledge. Yes, but what if you have to deal with different domains and different languages using different syntax at the same time. Sure you can integrate them and there are standard ways of doing so. But still this is overhead and essentially may create more problems than it solves. In particular when you are confronted with large systems with high developer fluctuation and long application lifetime, keeping complexity low and integration easy is a prime concern. If I see people struggling using SQL, JavaScript, Java, JSP, Ant and whatnot at the same time, I think it is not because they are "general purpose" but because they are different. So I'd like to keep people/teams working with as little different languages as possible. This makes me a bit wary about lowering the threshold for the creation of a domain language as a general approach in the first place, no more, no less.
|
|
|
Message #129865
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Domain Specific Languages
You are confusing waterfall process with DSLs. There is no connection. Development of DSLs is highly iterative. No I don't think I am. But I do know that you require more than a single programmer for a project and I know that the quality of most "software engineers" is not good enough to sustain a single comprehensive language, let alone a lot of languages that are "evolving" and "iterative". Also I know that even if some domain languages will be available, people will be reluctant to use them but rather "roll their own", much like with APIs.
In that last sentence, you were so close to understanding what DSLs are. Stop thinking of DSLs as something only "supplied", and do think of them as something that people build for themselves, much like APIs. And finally, waterfall process is back big time with the current trend to offshoring anyway :-) It is still in your thinking though.you are thinking about domain languages in terms of large general purpose languages, and this is leading to you to a wrong conclusion. Instead, try equating a DSL with an API. Do you avoid APIs because there is something to learn about using them? I hope not.Also, there is no avoiding acquiring the necessary domain knowledge under any approach, and hence no possibility of avoiding learning. A DSL makes standard (normalises, if you like) the domain knowledge. Yes, but what if you have to deal with different domains and different languages using different syntax at the same time.
If you are using someone else's DSL but you don't like the syntax, just change the syntax. As for having to deal with different domains, you have to deal with different APIs today. Sure you can integrate them and there are standard ways of doing so. But still this is overhead and essentially may create more problems than it solves. Do you find introducing an API to be an overhead that creates more problems than it solves? In particular when you are confronted with large systems with high developer fluctuation and long application lifetime, keeping complexity low and integration easy is a prime concern. Yep, and DSL is the best approach so far for reducing complexity.If I see people struggling using SQL, JavaScript, Java, JSP, Ant and whatnot at the same time, I think it is not because they are "general purpose" but because they are different. So I'd like to keep people/teams working with as little different languages as possible. This makes me a bit wary about lowering the threshold for the creation of a domain language as a general approach in the first place, no more, no less. The things you are thinking of as domain specific languages don't really qualify as such. Java and JavaScript are very far from DSLs, unless of course the domain is general-purpose computation. JSP and Ant don't address the complexity at the heart of an application domain. As for SQL, while relational data manipulation is a smaller domain than general purpose computation, it is still very large.
There is a second reason why those things aren't good DSLs, that being that you can't look at their syntax and semantics and readily customise them. The DSL approach and supporting tools are all about vastly lowering the cost of introducing a custom-built language.
If other people's taste in syntax offends you, you can define your own syntax for the same semantics. Multiple syntaxes can be in use for the same semantics at the same time.
Do have a glance at the paper I cited, unless learning something is just not on the agenda.
|
|
|
Message #130025
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Domain Specific Languages
DSLs have been used with great success for over a decade by the Functional Programming community. If you look into this a bit, bear in mind that they often use the term "combinator library" when referring to DSLs. The FP community's favourite use of Monads is for DSLs (a successor to Monads is proposed - Arrows). Also note the arguments in favour of Domain Specific Embedded Languages (DSELs) over DSLs. Hi G Hermitage,
Your comments on DSLs in FP interest me. Do you have any pointers (URLS?) to resources on DSLs, or combinator libraries, in FP?
Thanks.
--
John
|
|
|
Message #130048
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DSL and DSEL in FP
Thanks! I'll start with the first paper on DSEL. Cool.Thinking out loud: All these are in FP (or logical prog). I'm wondering if DSEL can be done in OOP...--John It is a good question to keep in mind when reading that paper.
I am curious to see what the vendors (e.g. Microsoft) will deliver in 2005 in support of DSLs.
The second paper is "especially targeted for the software reuse community, which is not likely to be familiar with many of these ideas".
|
|
|
Message #130070
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DSL and DSEL in FP
The second paper is "especially targeted for the software reuse community, which is not likely to be familiar with many of these ideas". Are you referring to the paper at
http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/Papers/dsel-hudak.ps? It has the same content as in the first pdf file...
Btw, I had a quick read of the first paper. Given my rusty Haskell, I don't follow all the details (e.g. The Haskell syntax. And this concept of "monads" seems unique to Haskell. Don't recall seeing it in LISP or LML etc.) But the general paradigm is fascinating!
--
John
|
|
|
Message #130080
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DSL and DSEL in FP
The second paper is "especially targeted for the software reuse community, which is not likely to be familiar with many of these ideas". Are you referring to the paper at http://www.cs.chalmers.se/Cs/Grundutb/Kurser/afp/Papers/dsel-hudak.ps? It has the same content as in the first pdf file...
Oops, so it does. Unify my remarks about the "first" and "second" papers.Btw, I had a quick read of the first paper. Given my rusty Haskell, I don't follow all the details (e.g. The Haskell syntax. And this concept of "monads" seems unique to Haskell. Don't recall seeing it in LISP or LML etc.) Arrows is a recent successor of Monads, and using Arrows is the thing to do. However, following what is written about combinator libraries requires understanding Monads.But the general paradigm is fascinating! --John Aye!
|
|
|
Message #130907
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
smagu sutikti lietuvi
sveiki kaip tiktai zvalgiausi kokio nors pigesnio web serverio, nes noriu patalpinti savo home page. Gal kokiu patarimu?
Aciu
|
|
|
Message #203469
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
DSM in parctice
I very much doubt that this idea can work in "the real world"
I am very certain this idea works in the real world, so are companies like Nokia, Lucent, St. Jude Medical, NASA, SiemensVDO, Audi, EADS, USAF, Vertu and many more. A rich number of case descriptions can be found from the website of the DSM Forum at www.dsmforum.org
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
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)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
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)
|
|
