ATEM 2007 Panel Post Rehosted

The SLE conference started essentially at MODELS 2007 with the ATEM workshop.

We had an important panel back then and it was informed by a MSDN blog post which is no longer available under the same URL. So I am rehosting the content, even though there is some backup somewhere else.


More on IT entropy

  • Article

I look forward a panel on "Grand Challenges in Software Language Engineering", which is going to be the closing event at ATEM 2007, which is the 4th International Workshop on (Software) Language Engineering (SLE). I have attended a number of panels over the years, and I find it very difficult to actually moderate a panel (no matter whether it's me or someone else). I contend that one standard problem is that you invite 4+ celebrities in the field and hope they spark off an interesting Q&A-biased panel by means of crisp introductions. What often happens is that the celebrities turn into marketing engines and roll off a longer slide deck or just keep talking about 2-3 slides (because you told them to really be short). Eventually, there is barely time left for the panelists to relate to each other; not enough time is given to the audience who may not even warm up because there's only a few minutes left to ask quick questions; so why get passionate and how to have a deep conversation so quickly? But what can you do, when panelists take more time initially than they should? The moderator shouldn't taser them, I presume.

This time it's going to be different. Promised! On behalf of the ATEM organizers, I am going to moderate the panel on "Grand Challenges in Software Language Engineering". Nothing can possibly go wrong because we have managed to mark off the subject of the panel in such a crisp manner that the panelists would only need to quickly comment on a few straightforward questions. So we should be done with all initial statements within a few minutes, and get the audience involved early on, as it should be.

Please find the questions below.

Hoping to meet some of you in Nashville.

Regards,

Ralf

 

1. "My definition of SLE in elevator speech"

Would you mind attempting a definition of Software Language Engineering (SLE). Please make it short, crisp, personal, even biased and opinionated. Imagine we wanted to engage into a productive definition war. Here are some hints: How many different kinds of software languages can you think of? What does it mean to "engineer" languages? If you dislike attempting a definition, skip this part.

 
2. "SLE finally provides a home for xyz"

When you hear "Software Language Engineering", is there anything (any sort of concept, principle, application domain, technical subspace, or any community) that you appreciate associating with the embracing notion of Software Language Engineering (SLE), while that thing was homeless in the past? Whatever you have in mind, how does it better live up to its full potential -- now that it is cultivated by the SLE community? If you think that this is a weird question, skip it. 

 
 3. "An SLE challenge, readily waiting"

Do you have any gut feeling where you would say that one "technical space" could be definitely capable of inspiring another one because the former is conceptually ahead of the latter in some specific context? Can you dive a bit into the technicalities and the history (very briefly of course) why the tranposition would be useful, why you think it hasn't happened yet, and why it hopefully will, though? Take a risk! Don't mind if someone is telling you later that your challenge isn't one!

4. "Any useless kind of language in sight?"

Rants are appreciated on presumably superficial kinds of languages. Just for the heck of it, can you imagine (do you want to imagine) any technical space (or any subspace) to eventually disappear in say 3-10 years from now? How do we get rid of it? Actively? Patiently? Painfully? Arguably? What sort of complexity reductions may we hope for -- with one space less? Conversely, are we aware of all spaces there are, or should we expect uncharted territory to appear?

5. "A praise on MDA as an SLE target"

Just for the fun of it, if MDA was the answer, can you quickly rant at what was the question, while essentially referring to the aspects of software language engineering in this context? Please try to avoid hyperboles, and as a proper challenge, please make it so that denotational semanticists, attribute grammar researchers, XSLT programmers, and most importantly, Haskell geeks can (and want to) follow your arguments.

 
6. "Clearance sale for programming languages"

You must have those friends, too. One is telling you that Java is something for system programmers and barely more exciting than Cobol; the future is with DSLs. The other guy has been drinking the MDA Kool-Aid for a while, and tells you that you (and your first friend) are outdated because programming is to be replaced by modeling, and you better get some brains to appreciate MDA's power of abstraction, which makes your third friend laugh, but she is not explaining herself (because she is a lazy Haskell programmer). Where are we heading to and what's the role of a committed software language engineer in this DSL/MDA/PL triangle?

7. "Connections of SLE to linguistics et al."

Software Language Engineering clearly relates to software engineering, programming languages, modeling, and information systems, but let's assume that it also relates importantly to usabiliy, sociology, and linguistics. Is that something that interests you? For instance, isn't it sort of disappointing that "grammar engineering" exists in both the linguistics and the software engineering circles, but hardly any cross-fertilization has happened so far? Another blind spot is perhaps software usability: how does come that language engineering plays almost no role in this important area of informatics?

8. "Software language engineers to care for IT entropy"

Can you take an entropy-centered view on the frequent circumstance of languages to emerge, take over a domain, succeed or fail to compose with existing languages, vanish indefinitely? Is there a useful definition of IT entropy in terms of the number of languages that come and go (and stay)? It is quite common to focus on the next cool language (be it a DSL today), on the next standard for SOA, WebServices, etc., but do we sufficiently fill in the "moral" mandate of coping with legacy and competing standards and viable alternatives for any sort of languages in software systems?

9. "If you were a congressman on planet HOPL ..."

... how would you be lobbying? Say, would you just be nearly paralyzed by the scary tower of babel (comprised of languages in informatics such as those on planet HOPL) so that language retirement must be the first duty, or would you think that free speech is doable, and hence focus on methods of language evolution, matching, conversion?  What other operations on languages make it into your party platform?  Language composition?  How do you even talk about your empire? That is, what is a useful cartography of languages in informatics?

10. "Specific engineering challenges for your pet kind of languages"

Finally, please turn back into a technician and specialist, that is, please zoom out and focus on your technical space of interest, and point out the challenges in that area! Please make an effort to abstract (may we say handwave) so that outsiders can still carry away something. What sort of engineering issues are worth focusing on in PhD theses, project proposals, Dagstahl seminars, the conference of Software Language Engineering, and the next special issue on SLE?


Comments

Post a Comment

Popular posts from this blog

SWI-Prolog's Java Interface JPL

I would like to mix Java and Prolog code on a number of occasions. Together with a student of mine (Joachim Pehl), we just convinced ourselves that the JPL library of SWI-Prolog is really cool. Basically JPL allows you to call Prolog from Java and Java from Prolog. But the question is, of course, how easy is it and can you easily go back and forth . For instance, can we call Prolog from Java and call back Java from Prolog and share Java state throughout? Sure it works! PROLOG PORTION FOLLOWS % This library is all we need to call Java from Prolog :- ensure_loaded(library(jpl)). main :- % Create an object jpl_new(class([],['Test']), [], X), % Printing objects is like printing object ids write(X),nl, % Access a field of the object; happens to be static jpl_get(X, state, Y), % Prints whatever the state's value is write(Y),nl. JAVA PORTION FOLLOWS // This jar is all we need to call Prolog from Java import jpl.*; public class Test { public static int state = 0; ...
Read more

Lecture series on advanced (functional) programming concepts

[ Added 10 Aug 2010: Here is the link to the first lecture's video: " The Expression Problem ". ] If you are a programming nerd or something of a similar species, you may know of C9 Lectures at http://channel9.msdn.com/tags/C9+Lectures . Several of the lectures are given by Erik Meijer who has turned many chapters of Graham Hutton 's book " Programming in Haskell " into videos. In my recent, recorded lecture on " Programming Paradigms and Formal Semantics ", I also incorporated Graham's text, but you should really watch Erik's lectures, if you haven't---they are more fun. I am inspired by his ability to present relatively simple content in such a crisp, insightful, and enjoyable manner. In the aforementioned lecture, I covered all kinds of "crazy stuff" though, and in the end, I had to deliver body bags to my Bachelor students---in the form of a radically simple examination. Thanks a lot btw to @grammarware for helping with t...
Read more

Should I declare defeat on the research topic of API migration?

Of course, I won't, but perhaps I should! Then, I could turn to lower-hanging fruits in research, which I first need to spot, which I can't though because I am a bit obsessed with API migration (and admittedly some other stuff such as megamodeling ). Sigh! It was around 2004 that I became interested in API migration and I have talked about it here and there ever since. Perhaps I am thinking that talking about a difficult problem of interest helps in discovering the solution of the problem, or at least a sensible path to go. Wishful thinking so far! In theory , the objective of API migration made a lot of sense while I was on the XML team at Microsoft because there are obviously way too many XML APIs. In practice , nothing happened on this front because I didn't understand automated API migration well enough back then. Add to this that API migration is something that is potentially risky for the API provider and the API migrator . So you need to mash up a rocket scientist ...
Read more