Home

News: Language-oriented Programming and Language Workbenches

  1. "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.

    Threaded Messages (37)

  2. Great presentation. It's a shame that we can't see the slides. Will the slides be on TSS sometime soon? Paul.
  3. Slides[ Go to top ]

    You can find the slides here: http://www.nealford.com/downloads/conferences/Neal_Ford_Martin_Fowler-Language_Oriented_Programming-keynote.pdf
  4. 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.
  5. 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.
  6. 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).
  7. Sounds like Martin Fowler's found a new way to charge consulting fees. =P
  8. Interesting follow on reading[ Go to top ]

    Perhaps this thread would be a good place to compile information about languages, tools, and experiences in creating DSLs.
    I also found the presentation interesting. You may find this excellent paper from the JMock developers useful as additional reading: Evolving an Embedded Domain-Specific Language in Java
  9. 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 !! Daniel

  10. 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".
  11. 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.
  12. 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".
  13. 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.
  14. 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.
  15. 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.
  16. 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
  17. 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.
  18. 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
  19. 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.
  20. 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.
  21. 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."
  22. 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.
  23. 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.
  24. 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.
  25. 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.
  26. 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.
  27. 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'.
  28. 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.
  29. +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.
  30. +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
  31. 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.
  32. 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?
  33. 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.
  34. Re: Where is my Sanskrit lecturer !![ Go to top ]

    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. :)
  35. I first read about DSLs here. Are we reinventing the past, or just updating it?
  36. 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.
  37. DSL and OO[ Go to top ]

    DSL guys 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. Yuri
  38. DCL and C+[ Go to top ]

    Also I would never use C+ if I new DSL prior to doing my projects on Sarkari Naukri. This DSL and its purpose and design matches most of what a Mantra stands. Nothing else is needed! Yuri