|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 43
Messages: 43
Messages: 43
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
Language-oriented Programming and Language Workbenches
"Language-oriented Programming and Language Workbenches: Shifting Paradigms" is a presentation given by Neal Ford and Martin Fowler on the growing appeal and application of domain-specific languages, and a little on what they look like.
DSLs, surprisingly, take forms beyond what one might imagine: Rails, for example, is a DSL. So are many libraries for Java, although calling some of them "DSLs" might be a stretch - but thinking of them in that way can help streamline their design.
Altogether, this is a great presentation to watch.
|
|
|
Message #238670
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Great presentation. It's a shame that we can't see the slides. Will the slides be on TSS sometime soon?
Paul.
|
|
|
Message #238672
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Halleluyah! Finally! after 30 years masses started to get the idea of literate programming http://en.wikipedia.org/wiki/Literate_programming
Seriously - it makes a lot of sense: the bigger an application the more it "speaks" in terms of application abstractions and less in terms of basic constructs of generic programming language it uses.
By the way I suggest using term DSLang (pronounced dee-slang ) for the concept because it does not collide with Telecom term DSL and also hints intent and meaning of the concept.
|
|
|
Message #238680
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
DSLs, surprisingly, take forms beyond what one might imagine: Rails, for example, is a DSL. So are many libraries for Java, although calling some of them "DSLs" might be a stretch
This feature of Ruby that accommodates DSL creation is looking more and more like a good enough reason to switch teams from Python to Ruby.
As I understand it, Scala also has this (or a similar) feature.
Perhaps this thread would be a good place to compile information about languages, tools, and experiences in creating DSLs.
I've become very interested in this because I was asked recently 'what language should business logic be written in'. I couldn't really come up with an answer I felt good about. When I started reading the transcript for this, the answer was staring me in the face. I think maybe the right answer is a DSL. If the tools are there to prevent this from becoming a maintenance nightmare it might really be the best answer.
|
|
|
Message #238682
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Why do people create new acronyms for old stuff? "Lisp is an horrific language to code in, with all those parentheses and stuff... confusing...".
Hahahaha. Lisp is pretty logical, Ruby looks more like some Perl bastard child.
I laughed not because of specific remarks, this is entirely subjective and you could find many different opinions about it, but because it was almost an excuse for some very high and unjustifiable hype for Ruby. What does Ruby have that Lisp didn't a long time ago?
The coolest thing from Lisp are macros in my opinion. You can get your code really compact, but these days the hype is "closure". I am sure that some time in the future they will come up with some "Fuby" language that will have "macros" and will create a "Macro Oriented Programming".
|
|
|
Message #238683
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
We have based some of ideas of a "language workbench" (that Martin Fowler wrote about) some time ago in the Drools tooling. (Of course a rule language - by virtue of the fact it revolves around your data objects is kind of a DSL itself). We used a mix of Antlr, Eclipse tools (GEF, its text editing model) and such. There are text based DSLs, graphical (rule flow) and form based (guided editor). None of this is rocket science - but the term "DSL" has suddenly made things much more popular. Part of the idea was to create a "language workbench" http://blog.athico.com/2007/08/drools-features-and-screenshot-page.html
We also made heavy use of Antlr3, which is getting easier and easier to use to create a language: http://blog.athico.com/search/label/ANTLR
I also believe that IntelliJ were working on a Meta Programming system (but they have dropped it, a far as I know).
|
|
|
Message #238691
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
does MF get paid by the buzzword?
Sounds like Martin Fowler's found a new way to charge consulting fees. =P
|
|
|
Message #238698
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Hi Thiago,
I laughed not because of specific remarks, this is entirely subjective and you could find many different opinions about it, but because it was almost an excuse for some very high and unjustifiable hype for Ruby. What does Ruby have that Lisp didn't a long time ago?
Try using Ruby for a while (especially Rails)) and it grows on you. Believe me it's not just hype. Even the inconsistent grammar makes sense once you apply a few coding conventions (standards).
Smalltalk use to be my favourite language, but after using Rails for sometime now, the DSLs in Rails are beginning to make me question whether Ruby is ultimately more productive. Matz has done everything in Ruby for a reason, based on practical feel (not conceptual elegance), and his approach works well once you get it.
Paul.
|
|
|
Message #238702
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Try using Ruby for a while (especially Rails)) and it grows on you. Believe me it's not just hype. Even the inconsistent grammar makes sense once you apply a few coding conventions (standards).
Smalltalk use to be my favourite language, but after using Rails for sometime now, the DSLs in Rails are beginning to make me question whether Ruby is ultimately more productive. Matz has done everything in Ruby for a reason, based on practical feel (not conceptual elegance), and his approach works well once you get it.
This is ridiculous. Once I first learned Lisp I also thought it was strange, and gradually while I was coding in Java I thought "hey, if I only had macros I could make this code much smaller" and so on. The fact is that Ruby adds nothing to that, absolutely nothing new, nothing to what people used to do 30 years ago.
And they came up with some "it is horrible to code in... they needed to come up with DSLs to escape from Lisp's horrible syntax...". What in the name of God is that!? Do they really know what they are talking about?
I am not a hardcore Lisp programmer, but I understand that the very concepts involved in it are different from the Algol descendent languages and that's what makes it different. People do think differently with Lisp, because Lisp works that way, and not because "they were running from something".
|
|
|
Message #238709
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Try using Ruby for a while (especially Rails)) and it grows on you. Believe me it's not just hype. Even the inconsistent grammar makes sense once you apply a few coding conventions (standards).
Smalltalk use to be my favourite language, but after using Rails for sometime now, the DSLs in Rails are beginning to make me question whether Ruby is ultimately more productive. Matz has done everything in Ruby for a reason, based on practical feel (not conceptual elegance), and his approach works well once you get it.
This is ridiculous. Once I first learned Lisp I also thought it was strange, and gradually while I was coding in Java I thought "hey, if I only had macros I could make this code much smaller" and so on. The fact is that Ruby adds nothing to that, absolutely nothing new, nothing to what people used to do 30 years ago.
And they came up with some "it is horrible to code in... they needed to come up with DSLs to escape from Lisp's horrible syntax...". What in the name of God is that!? Do they really know what they are talking about?
I am not a hardcore Lisp programmer, but I understand that the very concepts involved in it are different from the Algol descendent languages and that's what makes it different. People do think differently with Lisp, because Lisp works that way, and not because "they were running from something".
Hi Thiago,
I think we are in violent agreement. If you look at the words I used not what was mentioned in the presentation then you will see that we mostly agree. Lisp does look wierd at first, but over time it gradually reveals its secrets and you come to appreciate it's power. Ruby is the same IMO. Now I'm not saying that ultimately Ruby is as powerful as Lisp. But you do get a lot of the feel of Lisp. Ruby manages to give you the best of Smalltalk and a lot of Lisp, with one and two things thrown in from Perl too.
All I'm saying is that don't let first impressions fool you. To get to know Ruby takes a bit of time. For me, it was only after time, decoding and understanding the DSLs in Rails that I began to appreciate Ruby's strengths. I use to think of it as a lesser Smalltalk. I don't now.
BTW. Here is an interesting link that compares what you can do in Ruby versus Lisp:
http://www.randomhacks.net/articles/2005/12/03/why-ruby-is-an-acceptable-lisp
Paul.
|
|
|
Message #238717
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Perhaps some experienced Lisp developer can correct me if I am wrong, but what struck me about Lisp weren't DSLs or some new acronym.
Once you have such flexibility it's not a matter of having small, big or super-size languages, but instead it's the fact that there's no language, in the sense that only with some basic rules you can shape whatever you need.
This is not the case of "hiding the ugliness of Lisp behind DSLs", but that doing so is part of the modus operandi there. Its syntax seemed logical and not arbitrary as it is with languages like Java, Ruby or C#.
About Ruby, I don't really buy it because it doesn't seem that much powerful in order to justify such hype.
|
|
|
Message #238721
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
About Ruby, I don't really buy it because it doesn't seem that much powerful in order to justify such hype.
I don't think it's very sensible to discount a language because there's hype around it. Hype, by itself, doesn't change a language and it can create a powerful community. Just look at what hype has done for Java. If there were no hype around Ruby and it were still the same language, would you then consider it?
I also don't really understand how some people who apparently like Lisp don't like languages that emulate Lisp. If you like Lisp, you should be happy to have an option more like Lisp. Wouldn't you rather have a more Lisp-like tool than not?
It almost seems like some people want Lisp to remain misunderstood so they can be in a secret club or something. We are creeping towards Lisp. If you like Lisp, this hardly seems like something to complain about.
|
|
|
Message #238727
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Having written my own rule engine, which uses LISP syntax, here's my bias take on it.
Many people struggle with the syntax of lisp. An obvious example is this.
(> ?var1 ?var2)
var1 > var2
Most people prefer the non-lisp syntax. I can understand why. From a young age, people are given math problems in the second format, so having to adjust the brain to think in LISP is challenging. I know many people who hate LISP and some who love it. I like LISP syntax, but it does require a significant effort to use. Often I find myself slipping into Java syntax, so I have to consciously make an effort.
To me, languages that emulate LISP without using s-expression syntax feels odd. Ruby is a nice language, but I have a hard time with the syntax. I doubt there's any conspiracy from the prolog community towards other languages. If anything, the prolog guys I know think it's funny new languages are recycling old ideas.
peter
|
|
|
Message #238730
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Having written my own rule engine, which uses LISP syntax, here's my bias take on it.
Many people struggle with the syntax of lisp. An obvious example is this.
(> ?var1 ?var2)
var1 > var2
Most people prefer the non-lisp syntax. I can understand why. From a young age, people are given math problems in the second format, so having to adjust the brain to think in LISP is challenging. I know many people who hate LISP and some who love it. I like LISP syntax, but it does require a significant effort to use. Often I find myself slipping into Java syntax, so I have to consciously make an effort.
The thing about LISP is that it doesn't really have any structure. It's almost low-level, in a strange way. It's kind of like what I imagine a really lazy compiler writer would come up with.
When I read about the origins of LISP, I realized why. I read somewhere (I think it was Paul Graham) that McCarthy didn't even intend to implement LISP. It was an exercise to create a language that was easier for theoretical work than a Turing machine language. Or something like that. I can't find the page again. Correct me if I'm wrong.
So in a way Lisp is very low level. It's axiomatic. But it's hugely powerful. That's what's amazing about and probably why it's seductive.
Honestly, I think one of the big problems with Lisp is that in reality most programmers have a hard time think that abstractly about programming. More structured languages are just more comfortable. The keep your feet planted firmly on the ground. You almost need to know how a parser /compiler works to work with Lisp. It seems to me that languages are slowly working out how to get the power of Lisp while keeping users from feeling like they are on their own in the wilderness.
|
|
|
Message #238742
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Here's a link to a page supporting your assertion about John McCarthy's intentions. I happened to read it the other day.
http://www-formal.stanford.edu/jmc/history/lisp/node3.html
There's something interesting McCarthy writes at the bottom of that page [bolding mine]:
"Another reason for the initial acceptance of awkwardnesses in the internal form of LISP is that we still expected to switch to writing programs as M-expressions. The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned."
Maybe McCarthy had that right all along. Perhaps the current progression of language paradigms is just a search for a comfortable set of M-expressions. I'm sure I'm not the first person to think of this, of course.
|
|
|
Message #238744
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
There's something interesting McCarthy writes at the bottom of that page [bolding mine]:
"Another reason for the initial acceptance of awkwardnesses in the internal form of LISP is that we still expected to switch to writing programs as M-expressions. The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned."
Maybe McCarthy had that right all along. Perhaps the current progression of language paradigms is just a search for a comfortable set of M-expressions. I'm sure I'm not the first person to think of this, of course.
It makes me kind of interested to see what Paul Graham is going to do with Arc.
|
|
|
Message #238746
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
There's something interesting McCarthy writes at the bottom of that page [bolding mine]:
"Another reason for the initial acceptance of awkwardnesses in the internal form of LISP is that we still expected to switch to writing programs as M-expressions. The project of defining M-expressions precisely and compiling them or at least translating them into S-expressions was neither finalized nor explicitly abandoned."
Maybe McCarthy had that right all along. Perhaps the current progression of language paradigms is just a search for a comfortable set of M-expressions. I'm sure I'm not the first person to think of this, of course.
It makes me kind of interested to see what Paul Graham is going to do with Arc.
I don't know but after reading this:
http://www.paulgraham.com/design.html
It's clear that he never watched MTV.
"Look what happened with the 911. It's so obviously superior to the Cadillac that a child could tell it's better. And so, by the 1980s, even the drug dealers that the Cadillac was designed for wanted 911s instead."
|
|
|
Message #238750
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
It's clear that he never watched MTV.
"Look what happened with the 911. It's so obviously superior to the Cadillac that a child could tell it's better. And so, by the 1980s, even the drug dealers that the Cadillac was designed for wanted 911s instead."
I don't get the impression that popular culture appeals to Paul as anything more than a curiosity. Just my impression.
I think the Cadillac was popular because it looked a lot like a limo. It gave people the feeling of royalty when they rode in it...until they went for a long ride and had to replace the transmission, distributor cap, and fan belt. Languages tend to be like that too.
|
|
|
Message #238757
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
I don't get the impression that popular culture appeals to Paul as anything more than a curiosity. Just my impression.
I think the Cadillac was popular because it looked a lot like a limo. It gave people the feeling of royalty when they rode in it...until they went for a long ride and had to replace the transmission, distributor cap, and fan belt. Languages tend to be like that too.
I got the point. I just thought his example was a little poorly chosen given that cars like that Cadillac are highly prized in a certain segment of the population, way more than a 911.
And actually, this one of the things that works against people like Paul Graham and other Lisp advocates. There's a perceived (possibly real) element of superiority and elitism. A lot of people don't really connect with Porshe driving, wine sniffing, classical music lovers. They may be right, but people don't want to listen.
|
|
|
Message #238789
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Where is my Sanskrit lecturer !!
I mean when my Sanskrit lecturer said that Sanskrit is a better language for computing...we just laughed !! He may be too lazy to learn C or C++..!!
This DSL and its purpose and design matches most of what a Mantra stands...(Please Google to know what a mantra is).
The old Panini maharishi, wrote a grammar book on Sanskrit which cud be a superset to these DSLs and more abstracted languages..!!
I mean, when we go on abstracting and re-inventing or evolving programming languages, I think, we will end up in future with something very similar to a mantra AND we may not even need a physical computer to do computing, bcoz, programming language is at such a high-level abstraction !!
If what I posted here, does not sound relevant for a DSL discussion, I wud like to advice to go through the book: Understanding Mantras by Harvey P. Alper.
|
|
|
Message #238811
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
I don't think it's very sensible to discount a language because there's hype around it. Hype, by itself, doesn't change a language and it can create a powerful community. Just look at what hype has done for Java. If there were no hype around Ruby and it were still the same language, would you then consider it?
I discount it because:
- It's horribly ugly;
- It's slow;
- Doesn't add anything to what we currently have;
I wouldn't consider it without the hype, pretty much because of the same reasons. The feature set is not "revolutionary", as some would like you to believe.
Now Lisp, with its S expressions and all, is something that challenges you into exploring its limits. Initially you can't see them and think "let's see what I can do".
Well, I am not an expert in Lisp. I just play with it in my spare time and like to learn about it.
I also don't really understand how some people who apparently like Lisp don't like languages that emulate Lisp. If you like Lisp, you should be happy to have an option more like Lisp. Wouldn't you rather have a more Lisp-like tool than not?
I don't really think Ruby is Lisp-like. It borrows some features, but in the end it looks like Perl. It's just crappy.
Now if you had said "Scheme" or some other Lisp dialect, then yes, I would rather work with them rather than not.
|
|
|
Message #238820
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Smalltalk use to be my favourite language, but after using Rails for sometime now, the DSLs in Rails are beginning to make me question whether Ruby is ultimately more productive.
Ruby is currently more popular mainly because of Rails, Rails benefits from Ruby being more open, not relying on GUI, and easier to integrate to other systems (such as RDBMS). But in terms of language, Ruby is so ugly; in terms of VM implementation, Ruby is also not so good.
I can understand how Ruby appeals to Perl scripters. But those understand Smalltalk or Lisp/Scheme and are using Ruby, how many of them really like Ruby?
|
|
|
Message #238821
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
+1.
When I was evaluating rule engines, comparing Jess and Drools, I really like CLIPS syntax much better. I cannot bear the thought of writing complex rules in XML.
Worked with Jess a bit more, I realized that without pattern matching, it would be hard for other languages to be a good rule DSLang anyway. From a language point of view, maybe Prolog with its unification, or at least Erlang with pattern matching. Most of the mainstream languages do not have pattern matching.
|
|
|
Message #238836
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Where is my Sanskrit lecturer !!
The old Panini maharishi, wrote a grammar book on Sanskrit which cud be a superset to these DSLs and more abstracted languages..!!
Hmmm. I'll have to "chew" on that one. :)
|
|
|
Message #238837
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
I got the point. I just thought his example was a little poorly chosen given that cars like that Cadillac are highly prized in a certain segment of the population, way more than a 911.
And actually, this one of the things that works against people like Paul Graham and other Lisp advocates. There's a perceived (possibly real) element of superiority and elitism. A lot of people don't really connect with Porshe driving, wine sniffing, classical music lovers. They may be right, but people don't want to listen.
We've posted on topics before, so I was certain you had gotten the point. I didn't mean to imply otherwise. Sorry about that.
Given Paul's background in art he's highly in touch with form. Cars are items that average people walking on the street, in the US anyway, pay more attention to than say building design. I know you're into woodworking, so you'd probably understand a comparison of great pieces of furniture - sideboards perhaps; how many other readers would though? I'm not sure he could have chosen another subject as an example without losing his audience.
|
|
|
Message #238856
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Given Paul's background in art he's highly in touch with form. Cars are items that average people walking on the street, in the US anyway, pay more attention to than say building design. I know you're into woodworking, so you'd probably understand a comparison of great pieces of furniture - sideboards perhaps; how many other readers would though? I'm not sure he could have chosen another subject as an example without losing his audience.
I just think he could have used different automobiles. Say:
http://en.wikipedia.org/wiki/Nissan_240Z
http://en.wikipedia.org/wiki/Plymouth_Superbird
I guess there are a still a lot of people who would prefer the superbird but at least these were both sports-cars and targeted to roughly the same market. A 911 and a Caddy are an apple and an orange.
|
|
|
Message #238860
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Oh, yeah, I also found it weird given that the 911 is a somewhat flawed design. It's prone to spin-out because of engine placement making it difficult to drive (and a bit unsafe.) A lot of the attraction is 'taming' the 911. Maybe that's kind of like what Paul Graham likes about Lisp. But I don't think that is the general understanding of good design i.e. ergonomics.
|
|
|
Message #238861
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Oh, yeah, I also found it weird given that the 911 is a somewhat flawed design. It's prone to spin-out because of engine placement making it difficult to drive (and a bit unsafe.) A lot of the attraction is 'taming' the 911. Maybe that's kind of like what Paul Graham likes about Lisp. But I don't think that is the general understanding of good design i.e. ergonomics.
I guess I should say 'fish-tail' here instead of 'spin-out'.
|
|
|
Message #238862
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
I just think he could have used different automobiles. Say:
http://en.wikipedia.org/wiki/Nissan_240Z
http://en.wikipedia.org/wiki/Plymouth_Superbird
I guess there are a still a lot of people who would prefer the superbird but at least these were both sports-cars and targeted to roughly the same market. A 911 and a Caddy are an apple and an orange.
Although without the Caddy in there, he couldn't have made the drug-dealer knock!
Good point on the apples to oranges though. The cars were designed for different markets. It would be interesting to compare the design changes to each - the Porsche and Caddy - throughout time to see if they changed and how much. I would think that a "timeless" design should see few changes over the decades.
|
|
|
Message #239193
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Doesn't anybody read the classics anymore?
I first read about DSLs here. Are we reinventing the past, or just updating it?
|
|
|
Message #239210
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
+1.
When I was evaluating rule engines, comparing Jess and Drools, I really like CLIPS syntax much better. I cannot bear the thought of writing complex rules in XML.
Worked with Jess a bit more, I realized that without pattern matching, it would be hard for other languages to be a good rule DSLang anyway. From a language point of view, maybe Prolog with its unification, or at least Erlang with pattern matching. Most of the mainstream languages do not have pattern matching.
When was the last time you used Drools? The XML syntax is over 2 years old now, we have our own DSL parsed by ANTLR almost everyone prefers it to Clips, which is Lisp based. For example:
rule "Rule 3: If there is a field with a value in a row, remove all PossibleValues with this value in this row"
salience 15
when
$field2 : Field( $row : row, $value : value != 0 )
$possible : PossibleValue( row == $row, value == $value )
then
retract( $possible );
#System.out.println("Rule 3 fired.");
end
Take a look at the features and screenshot page and you'll see that we have come a long way since Drools 2.x, we probably have the most powerful and orthogonal rule language of any system.
http://labs.jboss.com/drools/featuresandscreenshots.html
Mark
http://blog.athico.com
|
|
|
Message #240091
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
Domain specific language and/or modeling (DSL and DSM), as a very effective paradigm, has been around for decades. Other than a newly coined buzzword "LOP", lengthy discussions on common sense, and non-substantial side issues (such as internal vs external grammars), I fail to see this talk presented useful and significant new concepts.
The talk does throw out a few non-orthodox but unjustified claims (or they don’t bother to justify them?), such as:
“For the past 20 years or so, we have been trying to model the world with trees. That is the way we model the world in object-oriented languages is build hierarchies, trees, trees of how we model things in code and it turns out that that works out pretty well because most of the world is tree shaped. Most of the world is hierarchical. You can fit things into trees pretty easily but that abstraction breaks down sometimes because a lot of times, we try to model the real world. We model it like this with a nice tree abstract picture of trees, and of course this is idealized. This is not the way the world really looks. The world really looks like this, tangled branches and interconnections and all sorts of other things that are really, really hard to model in these kind of idealized pictures. So what we have been trying to do is model the world with hierarchies but hierarchies fall down at some point and so we invent things like aspects.” They didn’t rationalize why they belive OO was merely about “model the world with trees and/or … build hierarchies.” A plain and obvious fact is that OO programming languages such as C++, Java do not enforce trees and hierarchies except for the inheritance based class extending. In general cases, nothing in these OO languages discourages models and structures of non-tree/non-hierarchy and vice versa. Widely observable from microscope level abstractions (such as linked list) to marcoscope level system designs on UML object diagrams, in the past 20 years, people have been modeling with non-trees/non-hierarchies no less than the opposite.
The argument of “hierarchies fall down at some point and so we invent things like aspects” sound like to say “the file directory tree structure model fall down, and so we invent things like directory/file access control, monitoring, event triggering and logging”, or "relation model fall down at some point and so we invent things like transaction" ... lol.
DSL folks never claimed that increasing expressiveness of a language for a specific problem domain was contrary to abstracting by hierarchies and modeling with trees. This argument could be the only "invention" they can safely claim credit, if it could be justified. However, as giving no evidence on their claims of OO discourages modeling with non-trees and non-hierarchies, they did neither bother to justify why designing and using domain specific language grammars was contradictory to modeling with trees and building hierarchies.
It is pretty common that DSL grammars, especially declarative DSL grammars (schemas) are defined by their schema trees. An example is defining DSLs using LISP defmacro. An important concept in LISP is “data is code, and code is data”. Therefore, the new DSL schema defined in by a defmacro is effectively expressed in a s-express (data) tree. Therefore, contrary to their claims, tree expressions is not only applicable in defining DSL grammars but also helpful in DSL abstractions. Here, modeling (data) trees is exactly modeling (code) grammars. This makes LISP one of the most effective DSL environments.
Besides an individual DSL grammar tree, the inheritance and hierarchies are also applicable and significant in DSL grammar abstraction and reuse. A desirable DSL environment should not force all DSLs to be defined from scratch (including copy-paste) but support extending grammars/schemas by inheritance (and therefore grammar hierarchies) and semantic overriding (change the semantics of a syntax in the child grammar). We are going to release an open source DSL/DSM framework that supports this inheritance as well as containment based schema extending and reuse. The product is going to be shipped with dozen or so DSL/DSM examples (also in open sources). These DSLs/DSMs are extended (using inheritance or containment) either from the core (root) schema or from other extended schemas and therefore present a DSL grammar hierarchy tree.
|
|
|
Message #311791
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
The application of domain-specific languages is sure to grow even more as more people use Ruby on Rails and other web-driven applications. Managing a project like this with lean six sigma training techniques is essential.
|
|
|
Message #320075
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
idea
In the current incarnation of the talk, I' writing both an internal (i.e., DSL written using Java language itself) and external (using Antlr to create a lexer and parser). In the next iteration, I'm going to extend the external DSL to use IntelliJ's MPS language workbench. In neither case am I creating a scripting engine (been done already, with both Jython and Groovy). If I were going this route, I'd write Python (more friendly to internal DSL's) and use Jython to generate byte code.
inchirieri masini | bijuterii
|
|
|
Message #327162
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Keeping it real
Not meaning to respond to the above comment, but want to be onboard, new to the subject, and am on the fast track learning wise. Am a Python guy but may go to Ruby based on this.
DSL seems to be the future.
Will be following and checking other forums. Looking to Koozies for a better way of management.
|
|
|
Message #328684
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
An ideal presentation
This will definitely help my team move on with the current trends of technology. In a world growing more and more complex each day, it is hard to live by and have a growing business if there won't be dissemination of information like this.
Great work! DSL seems to really for the future.
web hosting
|
|
|
Message #328941
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Language-oriented Programming and Language Workbenches
You can't blame Obama, it's your fault that you can't pay the bills. If you really need to you can apply for cash advance loans which is just a fast loan. If you do I suggest using a well know cash advance loan lender. There are lots of scams so you do need to be careful. There is also the option of applying for loans for bad credit. Your interest rate will be higher but at least you will qualify.
|
|
|
Message #329382
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Language oriented Apps
Language oriented programming examples are JAVA , C , PHP these are powerful languages for build commercial level software's apps . tons of pdf manual for auto repair, automotive vehicles,personal computers, digital photography, business, technolgoy,education, pdf service, manual repair, manual service, car manual . free pdf manual download
|
|
|
| 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)
|
|
