Discussions

News: Superlanguages: A Revolutionary Approach to Development

  1. Superlanguages offer a new approach to application development. They empower developers, de-skill aspects of the development process, can include all stakeholders and can increase the quality of the process and product. Ceteva has published an online book (free for download, no registration required) discussing the concept as well as the application in XMF, recently released under the EPL as mentioned on TSS. Here is an excerpt:
    We are drowning in implementation technology. Software language engineers have been very busy over the last 10 years inventing languages that control the new frontiers of technology. In particular there are a huge number of languages that provide control over distributed applications, databases and web-content. Basic technology issues are very well provided for. This can be seen in the rise of open-source technologies and the standardisation of architectures for information processing applications. And yet there are still problems. Little attention has been paid to closing the gap between the languages and the applications that they implement: the representation chasm. The chasm is bridged by highly skilled developers who take designs and produce the application. But what if your developers are not as highly skilled as you would like? This leads to errors and delays arising from misunderstandings. Iterative development is compromised by the representation chasm since various project stakeholders become disenfranchised depending on which side of the chasm they live. Maintenance become difficult: the customers, architects and designers shout new requirements from one side of the chasm only for the development team to mis-hear them on the other. How do we bridge the representation chasm? The answer is in moving towards a new breed of language technology: superlanguages. A superlanguage provides a number of technical features that are specifically designed to close the gap between the concepts in the application domain and the technologies that are used to implement the application. Superlanguages can be used to empower development teams by increasing the sophistication of the tools they use to implement the application. Superlanguages can be used to de-skill various aspects of the implementation by offering restricted languages suitable for the application. Superlanguages can be made accessible to project stakeholders that would usually be unable to engage with implementation technologies. Superlanguages can radically increase the efficiency of the development team and can radically increase the quality of the delivered products, derisk the development process, and increase the ability of the supplier to maintain the products.
    [Editor's note: got to totally dig the use of the words "de-skill" and "derisk." :)]

    Threaded Messages (30)

  2. Interesting... it's like a runtime MOF.
  3. The wheel turns[ Go to top ]

    And the wheel turns once more and we start thinking the numpties in marketing should be programming in VisualBasic and Excel macros. Programming is an engineering art that cannot be de-skilled. Nor should it be.
  4. Re: The wheel turns[ Go to top ]

    And the wheel turns once more and we start thinking the numpties in marketing should be programming in VisualBasic and Excel macros.

    Programming is an engineering art that cannot be de-skilled. Nor should it be.
    Why is a marketing guy who has very little understanding of programming writing a program in VB to solve a marketing problem worse than a professional programmer who has no understanding of marketing writing a program in Java to solve a marketing problem? In both cases the person developing the software is ignorant concerning about half of the knowledge required. So you stick them together so that they can do a mind-meld and hopefully the whole is almost equal to the sum of its parts. Unfortunately if the problem is complex, they probably talk past one another. So you add in a business analyst who hopefully knows enough about marketing and enough about programming to bridge the gap. Now you have three people so you need a project manager. Now you have a lot more overhead. If the BA turns out to be ignorant of both marketing and programming than he just makes the situation worse as opposed to the programmer and marketing guy slugging through it. And if the programmer is inept, then even if the requirements are right the resulting program won't be much better than if the marketing guy wrote it - just two or three times as expensive.
  5. Re: The wheel turns[ Go to top ]

    Why is a marketing guy who has very little understanding of programming writing a program in VB to solve a marketing problem worse than a professional programmer who has no understanding of marketing writing a program in Java to solve a marketing problem? In both cases the person developing the software is ignorant concerning about half of the knowledge required.

    So you stick them together so that they can do a mind-meld and hopefully the whole is almost equal to the sum of its parts. Unfortunately if the problem is complex, they probably talk past one another. So you add in a business analyst who hopefully knows enough about marketing and enough about programming to bridge the gap. Now you have three people so you need a project manager.

    Now you have a lot more overhead. If the BA turns out to be ignorant of both marketing and programming than he just makes the situation worse as opposed to the programmer and marketing guy slugging through it. And if the programmer is inept, then even if the requirements are right the resulting program won't be much better than if the marketing guy wrote it - just two or three times as expensive.
    Simple solution: don't hire a programmer who can't figure out a marketing problem after talking with the marketer. People want so badly to commoditize programming. There is no solution for hiring smart people, whatever the position. You can get more done with less people if they are smarter, even though they cost more. But too many companies are penny wise and pound foolish to do so.
  6. Re: The wheel turns[ Go to top ]

    Simple solution: don't hire a programmer who can't figure out a marketing problem after talking with the marketer.
    This doesn't scale to complex problems. What happens when understanding the problem requires a PhD in mathematics or some hard science? Then the solution effectively becomes "hire a domain expert who is good at programming."
    People want so badly to commoditize programming.
    They do, but there are other more interesting motivations for bringing the software closer to the problem domain. In my opinion this is more about enabling interdisciplinary teams to work together without highly ambiguous methods of communication causing too much confusion.
    There is no solution for hiring smart people, whatever the position. You can get more done with less people if they are smarter, even though they cost more. But too many companies are penny wise and pound foolish to do so.
    Absolutely, but the question remains: Smarter at what?
  7. Re: The wheel turns[ Go to top ]

    his doesn't scale to complex problems. What happens when understanding the problem requires a PhD in mathematics or some hard science? Then the solution effectively becomes "hire a domain expert who is good at programming."
    If the problem is so specialized and abstract then I think that is a fine solution, if you can find that person with both skills. I don't think it is ever so black and white. I'd be willing to bet that with many complex domain systems you can encapsulate the expert domain problem into small units that, yes, the PhD could help write. An example would be my current project which is an online stream-based statistical analysis tool. We created an API where our PhD could write the more statistical plugins without having to know anything about the rest of the system, which is more of your meat-and-potatoes web UI, REST services, etc. The point is that the PhD couldn't build the system properly but a smart team of developers should know how to not only build a system but put domain-experts to good use. I'd also guess many rules-engine based systems are the same. 90% plain old web programming with a small part that handles the rules loading, processing, etc.
  8. Re: The wheel turns[ Go to top ]

    his doesn't scale to complex problems. What happens when understanding the problem requires a PhD in mathematics or some hard science? Then the solution effectively becomes "hire a domain expert who is good at programming."


    If the problem is so specialized and abstract then I think that is a fine solution, if you can find that person with both skills.

    I don't think it is ever so black and white. I'd be willing to bet that with many complex domain systems you can encapsulate the expert domain problem into small units that, yes, the PhD could help write.

    An example would be my current project which is an online stream-based statistical analysis tool. We created an API where our PhD could write the more statistical plugins without having to know anything about the rest of the system, which is more of your meat-and-potatoes web UI, REST services, etc. The point is that the PhD couldn't build the system properly but a smart team of developers should know how to not only build a system but put domain-experts to good use.

    I'd also guess many rules-engine based systems are the same. 90% plain old web programming with a small part that handles the rules loading, processing, etc.
    This is an excellent example of how software development of this nature should (and, I think, often is) done. The goal is to avoid having to make the statistician into an enterprise developer, or to make the enterprise developer into a statistician.
  9. Re: The wheel turns[ Go to top ]

    I agree with many of the points here. Many thanks to all the people who have grabbed the original post and run with it - and sorry to the person who flounced off by removing the RSS feed! There have been some misconceptions in earlier posts so I thought I would try to make the points clearer. We are saying two separate things: (1) Programming is about controlling the machine. Superlanguages empower the programmer and lets them build abstractions for representation and control. These abstractions are not limited in any way and can be wrapped up and handed on so that the authors and others can benefit. Of course these can be misused, but so can lots of other things. With good practice, this approach represents a significant step forward in programming language technology which has arguably reached a local minimum. (2) Superlanguages open up the possibility of new development approaches whereby projects are organised differently and where all stakeholders get to be more integrated. The approach will require some radical changes to the way a project is organised. In particular there would have to be a group of language engineers who work with both developers, customers, designers etc to produce language technologies appropriate to the domain. The language engineers benefit from (1) above. The artifacts that are produced become accessible to many more stakeholders and there are many quality related benefits. No-one is suggesting that project stakeholders with no technology background suddenly become programmers. Also, the new approaches will undoubtedly require more effort up front. BTW you can achieve DSLs without code generation. In many cases a better way to implement a DSL is by producing an execution engine for the DSL. This is mostly way-better because of the degree of control it affords.
  10. Re: The wheel turns[ Go to top ]

    There have been some misconceptions in earlier posts so I thought I would try to make the points clearer. We are saying two separate things:
    It's extremely unclear what you are really saying. The marketing statements such as "de-risk" and "de-skill" send up all sorts of red flags. It seems like CASE tools (and their child, MDA) all over again, with an unhealthy mixing of DSLs and metaprogramming. The first chapter of the book seems to alternate between stating that "superlanguages" are revolutionary and that "superlanguages" are already a proven technology. It seems like "superlangauges" are trying to be everything and the kitchen sink. As a result, the overall concept seems to lack any sort of conceptual integrity. Perhaps if I carefully read the 431 page book instead of skimming sections of the introduction I would feel differently. But I won't invest that kind of time, or even the time for 40 pages, without reading a concise (~10 pages) paper on the topic that is not saturated with marketing statements. So I'd like to suggest that you write a short paper, with a really solid abstract, and re-post it here.
  11. Re: The wheel turns[ Go to top ]

    Superlanguages are an overall aim for programming technology that, if realised, would support a number of new approaches to development. Lots of things approximate a superlanguage and as such provide a useful basis for moving forward. Fully realised superlanguages would be revolutionary. Many aspects of superlanguages are already proven. Not sure where the lack of integrity comes in. The book is focussed on technology and, I completely agree, a helicopter view is missing. Thanks for the suggestion about the short paper. There is one in the works and hopefully it will be out soon.
  12. Re: The wheel turns[ Go to top ]

    Simple solution: don't hire a programmer who can't figure out a marketing problem after talking with the marketer. People want so badly to commoditize programming. There is no solution for hiring smart people, whatever the position. You can get more done with less people if they are smarter, even though they cost more. But too many companies are penny wise and pound foolish to do so.
    I suspect the same was said by assembler programs during the 1960s. There is a shortage of smart people that can bridge domains in the way you describe and those people are expensive. What is being proposed here is that the smart people are used to create the bridge as DSLs (or DSLs extensions), and the not so smart people can utilise the bridge many times over. It is not so much as deskilling programming as using those that can to the benefit of those that cannot. This is nothing new it has been happening since the beginning of computer languages and will continue to happen. DSLs are been produced and used in this way, for example: - GUIs (see XAML) - Data represntation and transactions (SQL) - Scenarios scripting (e.g. level design in games) - business logic rules - expert system rules
  13. Re: The wheel turns[ Go to top ]

    I suspect the same was said by assembler programs during the 1960s. There is a shortage of smart people that can bridge domains in the way you describe and those people are expensive. What is being proposed here is that the smart people are used to create the bridge as DSLs (or DSLs extensions), and the not so smart people can utilise the bridge many times over. It is not so much as deskilling programming as using those that can to the benefit of those that cannot. This is nothing new it has been happening since the beginning of computer languages and will continue to happen.
    I think you have several major problems here: 1. You're assuming a hierachical skill relationship as opposed to an interdisciplinary relationship 2. You're assuming reuse of the developed abstractions (the DSLs), which in turn assumes that the problem domain has wide applications and that the abstractions can be defined in a stable manner 3. You're assuming tiered abstractions 4. By focusing on external DSLs you are entangling yourself in code generation
  14. Re: The wheel turns[ Go to top ]

    I think you have several major problems here:
    1. You're assuming a hierachical skill relationship as opposed to an interdisciplinary relationship
    I don't think I am. I talk about people that can bridge domains and are therefore interdisciplinary. For instance, programmers who are HCI experts can create GUI languages that capture good practice for those that no nothing about HCI.
    2. You're assuming reuse of the developed abstractions (the DSLs), which in turn assumes that the problem domain has wide applications and that the abstractions can be defined in a stable manner
    Yes and the challenge (as with all languages) is getting the balance right between specificity to the domain and generality. In one extreme the language can describe a single application, in the other every possible application.
    3. You're assuming tiered abstractions
    I'm not sure why? Is this a reference to the DSL extensions?
    4. By focusing on external DSLs you are entangling yourself in code generation
    Absolutely not. I'm not sure where that came from?
  15. Re: The wheel turns[ Go to top ]

    I don't think I am. I talk about people that can bridge domains and are therefore interdisciplinary. For instance, programmers who are HCI experts can create GUI languages that capture good practice for those that no nothing about HCI.
    Those people are known as "Product Manager" and their job is to translate whatever the domain is to programmers in a wonderful language known as English. Good luck getting them to start writing codes. For the rest, don't worry about programming skills being commoditized. I'm sure the marketing skills will be commoditized first if enough of you stay in this forum long enough.
  16. Re: The wheel turns[ Go to top ]

    I'm sure the marketing skills will be commoditized first if enough of you stay in this forum long enough.
    Are you suggesting I'm a marketing person or technical lightweight? I suggest you look very careful at my background before leveling such comments. Did you actually read the book that triggered the thread and which I co-authored?
  17. Re: The wheel turns[ Go to top ]

    I suggest you look very careful at my background before leveling such comments. Did you actually read the book that triggered the thread and which I co-authored?
    No, I did not suggest that. Many authors are great marketers though - they have to sell books. (Again, no suggestion.) Besides, I have nothing against marketing people. In fact, I admire them. I believe most technologies will turn useless without great marketing people. Just that turning marketing people -- or for that matter professionals in any other disciplines -- into programmers (or vice versa) are not necessary and contrary to the principle of specialization that defines the modern economy. And good luck finding a domain professional who can design a ``domain language'' -- or even writing a formal spec in English.
  18. Re: The wheel turns[ Go to top ]


    I think you have several major problems here:
    1. You're assuming a hierachical skill relationship as opposed to an interdisciplinary relationship


    I don't think I am. I talk about people that can bridge domains and are therefore interdisciplinary. For instance, programmers who are HCI experts can create GUI languages that capture good practice for those that no nothing about HCI.
    You're place the HCI expert who decides "what the rules for making a good GUI" should be above the people who actually create the GUIs. The application programmer must work within the bounds defined by the HCI expert. That's establishing a shallow hierarchical relationship.
    3. You're assuming tiered abstractions


    I'm not sure why? Is this a reference to the DSL extensions?

    Perhaps "boxed" would be a more appropriate word than "tiered." In the HCI example, the application programmer is boxed into the abstractions defined by the HCI expert. The application programmer is constrained by the rules set by the HCI expert. This creates a very strict separation of concerns. IMHO, the biggest problem with this is that if the abstractions defined by the HCI expert happen to be leaky, then the application programmer is stuck. With a more traditional GUI toolkit or an embedded DSL, he could drop down to a lower level API.

    4. By focusing on external DSLs you are entangling yourself in code generation

    Absolutely not. I'm not sure where that came from? How do you implement an external DSL without implementing a code generator? Keep in mind that a compiler is a code generator.
    Yes and the challenge (as with all languages) is getting the balance right between specificity to the domain and generality. In one extreme the language can describe a single application, in the other every possible application.
    The challenge is significantly greater in your approach because the application programmer is being bounded by what the experts have created. For example, Hibernate works pretty well for a very large portion of common use cases. But it both provides an API for extending it and lets you drop down to good old fashioned JDBC if you need to. They assume that they can't possible get all the use cases right for all of the applications. If a API or framework can keep you high level 80-90% of the time, that's great and it has succeeded. However, if you take away the escape hatch, even 99% of the time can represent a failure. So there is a much, much higher burden on the external DSL designer in the method you describe than the library or framework designer who may use an embedded DSL.
  19. Re: The wheel turns[ Go to top ]

    This is nothing new it has been happening since the beginning of computer languages and will continue to happen. DSLs are been produced and used in this way, for example:

    - GUIs (see XAML)
    - Data represntation and transactions (SQL)
    - Scenarios scripting (e.g. level design in games)
    - business logic rules
    - expert system rules
    The interesting thing is that, maybe with the exception of expert systems, none of this technologies have got rid of the need to have a good developer or programmer to implement the actual code. I have yet to see the bank or telco "business people" to actually write business rules, SQL statements and the like.
  20. Re: The wheel turns[ Go to top ]

    Why is a marketing guy who has very little understanding of programming writing a program in VB to solve a marketing problem worse than a professional programmer who has no understanding of marketing writing a program in Java to solve a marketing problem? In both cases the person developing the software is ignorant concerning about half of the knowledge required.

    So you stick them together so that they can do a mind-meld and hopefully the whole is almost equal to the sum of its parts. Unfortunately if the problem is complex, they probably talk past one another. So you add in a business analyst who hopefully knows enough about marketing and enough about programming to bridge the gap. Now you have three people so you need a project manager.

    Now you have a lot more overhead. If the BA turns out to be ignorant of both marketing and programming than he just makes the situation worse as opposed to the programmer and marketing guy slugging through it. And if the programmer is inept, then even if the requirements are right the resulting program won't be much better than if the marketing guy wrote it - just two or three times as expensive.
    Your argument seems to be "if you make a lot of bad decisions and hire the wrong people you'll get a bad result". File that under "S" for surprise. Part of a professional developer's job is to be able to be an analyst and sift out requirements from the sponsor and others related to the project. There isn't a software process I know of where that isn't an important component. The problem with do-it-yourself programmers is the same with do-it-yourself electricians, mechanics, plumbers, rocket engineers, etc. There is a point where the project will go beyond the novice's abilities and they'll either continue and dig themselves a big expensive hole or hire professional help.
  21. Re: The wheel turns[ Go to top ]

    Your argument seems to be "if you make a lot of bad decisions and hire the wrong people you'll get a bad result". File that under "S" for surprise.
    That was really tangential to my point, but perhaps I was unclear. My point was the sometimes a portion of the problem domain is too complex for someone who is a professional developer to grok without being a professional X as well.
    Part of a professional developer's job is to be able to be an analyst and sift out requirements from the sponsor and others related to the project. There isn't a software process I know of where that isn't an important component.
    I agree with that 100%. But again, this assumes that the entire problem domain is within the professional developer's grasp.
  22. Numpties?[ Go to top ]

    LOL. That's the first time I've read that term. But I figured it out from the context, and once again, my vocabulary is enriched. Thank you, sir! :-) Are you in Edinburgh or something?
  23. Re: Numpties?[ Go to top ]

    LOL. That's the first time I've read that term. But I figured it out from the context, and once again, my vocabulary is enriched. Thank you, sir! :-)

    Are you in Edinburgh or something?
    Just Google it ;) And no, I'm not in Edinburgh, nor anywhere else in Scotland.
  24. Did TSS Editors really review this? It just seems like a bunch of nonsense. I don't think there is really any sort movement behind "superlanguages" or XMF. A quick search in Google and Wikipedia shows that no one is using these terms like this other than a few people from this company posting things in various forums, etc.
  25. Did TSS Editors really review this? It just seems like a bunch of nonsense. I don't think there is really any sort movement behind "superlanguages" or XMF. A quick search in Google and Wikipedia shows that no one is using these terms like this other than a few people from this company posting things in various forums, etc.
    Yes, the TSS editors reviewed this. You can tell because I was amused by the "de-risk" statement... and honestly, I'm a little tired of protecting people from themselves. Part of the problem here is that people post nonsense, and don't realise it because nobody but me tells them so.
  26. Yes, the TSS editors reviewed this. You can tell because I was amused by the "de-risk" statement... and honestly, I'm a little tired of protecting people from themselves.
    I saw the editorial comment, but my expectation was that if something was published under "news" on this site, then it would be more than just marketing material from an obscure company trying to make up a new category of language in order to sell their product. However, now that I review the contents of this RSS feed, it appears it consists only of corporate press releases. I guess I mistakingly subscribed thinking I was getting tech news. Sorry for the misunderstanding--I will just go ahead and remove this feed from my reader.
  27. Yes, the TSS editors reviewed this. You can tell because I was amused by the "de-risk" statement... and honestly, I'm a little tired of protecting people from themselves.

    I saw the editorial comment, but my expectation was that if something was published under "news" on this site, then it would be more than just marketing material from an obscure company trying to make up a new category of language in order to sell their product.

    However, now that I review the contents of this RSS feed, it appears it consists only of corporate press releases. I guess I mistakingly subscribed thinking I was getting tech news. Sorry for the misunderstanding--I will just go ahead and remove this feed from my reader.
    Which product is been sold here exactly? Did you have a look at the book? The material refers to an open source technology. How does that differ from all the other OS announcements and discussion that constitutes news on TSS?
  28. I saw the editorial comment, but my expectation was that if something was published under "news" on this site, then it would be more than just marketing material from an obscure company trying to make up a new category of language in order to sell their product.

    However, now that I review the contents of this RSS feed, it appears it consists only of corporate press releases. I guess I mistakingly subscribed thinking I was getting tech news. Sorry for the misunderstanding--I will just go ahead and remove this feed from my reader.
    Do you REALLY want me to respond to this, by walking through the last few days' worth of news posts, showing you which ones are "corporate press releases," comparing them to the ACTUAL corporate press releases I get, just to explain to you the process that goes into this stuff? I mean, God forbid you could actually participate in "YOUR Enterprise Java Community" such that you defined content appropriate for your interests...
  29. However, now that I review the contents of this RSS feed, it appears it consists only of corporate press releases. I guess I mistakingly subscribed thinking I was getting tech news. Sorry for the misunderstanding--I will just go ahead and remove this feed from my reader.
    Bye-bye!
  30. ...Domain Specific Languages, Language-oriented programming, model driven development, meta-linguistic abstraction...and a million other buzz-words for basically the same ideas. There's nothing new here except some very good business-speak.
  31. please present us a success story[ Go to top ]

    If it is such a great idea and it's fondly embraced by business people there must a success story! Could you please indulge us by reporting one?! Quality software is not produced like this. It takes hours of designing, programming, testing, debugging. Dou you think business people are eager to get dirty and get involved in development as you say:"Superlanguages can be made accessible to project stakeholders that would usually be unable to engage with implementation technologies" ? Furthermore, to write code to respond to every possible action stupid users may take on the system is not impossible, but harded to develop, takes more time to get to market and actually takes people vith skills above average to implement. My question is: is it worth it? Working like this is like sculpting a chair instead of leting a carpenter build it. The holy grail of business is getting software that requires 0 maintainance cost and they would wish we, programmers, die...we should let them brake their neck in ventures like this, they will end up to our doorstep to help them clean their mess. "Superlanguages can be used to empower development teams by increasing the sophistication of the tools they use to implement the application"?! I thought these languages were about simplifying development. Sophisticated tools are not for dummies, but you want dummies to use it: "Superlanguages can be used to de-skill various aspects of the implementation". Testing such software will also be a challenge....