Excellent info Vadim. Give us more!

To bring the discussion back to the "Software Languages" paper; let's ask the newcomers to the group. This paper should define the field, the goal is to document the existence and goals of the larger community that studies, creates and uses software languages. The document should not be too long, i.e. we can not describe the difference between term rewriting and attribute grammars. What should be in it?

I have the same feeling as vadim. And same concerns although I was on the other side in the case of SL(E)BOK @ SLE 2012. Obviously, things should be prepared in advance, announced, etc, if we want this to scale up a bit. We didn't originally planned to do this for this event. but as some people asked, we tried it. The friend-based approach worked more a less, but this is obviously not the solution. I think that we should distinguish different activities/goals that are under the term remote participation (the term is not the good one). May be this categorization could help in improving further feedback. I've just created a group about "research 2.0 practice" dedicated to organizers, leaders, and followers that want more that just read papers. Please join the group and provide reusable and more feedback there. Feedback specific to what happened in the particular case of SL(E)BOK @ SLE2012 could be put here though. Just use the proper place as you see fit ;-)

Vadim, good point! Let's ask why "computer languages" are not a good term. Ralf? J-M? Mark? Görel? Erik? Tony? At the same time, I can ask the same question again, what kind of concept is "computer languages", a paradigm, or a set?

Hi Vadim, interesting points. They remind me of discussions that I had with Fabio Casati, in the context of LiquidPub. Perhaps you find some of the tools at http://project.liquidpub.org/tools useful? Best regards, Pieter

Hi Jean-Marie, the Vimeo version can be accessed at https://vimeo.com/50014524. Feel free to put a copy on YouTube too. Best, Pieter

That's an interesting remark Jean-Sébastien. I did not think out of the software languages box at all. In any case I do think we are talking about "artificial languages", as opposed to natural languages, right? But the use of those artificial languages is certainly not restricted to interpretation by a machine, indeed. Bridging all those software languages to be able to understand their interrelation, is indeed big general question.

Just like in any healthy scientific discussion, there could be a yes and no. Please join the discussion, because nobody has the truth and that We are more intelligent collectively (aka collective intelligence) :-) YES ---- I agree. *Positioning* SLEBOK 2.0 with respect to SWEBOK is a definitively a must. First because of "community reasons" as mentionned by jurgen: relating to things that are known in a community is the best way to make new proposal intelligible by those people in this community. Second for "scientific reasons". It can be argued that software language **artifacts** (SLA) are pieces of software too. It is thereore important to study in a SYSTEMATIC way which concepts and activities described in the SWEBOK apply to SLA. I would say that SWEBOK should be seen as a framework or an evaluation grid to study Software Language *Engineering*, to see what applies, does not apply, what already exist or not. NO ---- I don't think though that we could take for granted the fact that the SWEBOK structure could be applied as is to the domain of SL(E). (1) First, some software engineering activities referenced in SWEBOK might not apply to the case of SLA (I intentionnaly put the emphasis of the artifact aspect, see below)/ But much more importantly some of the features of SLA may be unique to this kind of artifacts. I would say that we simply don't know yet. We cannot predict the result of before doing the job. Here is an nice topic of collaborative paper... Those interested in collaborating are expected to speak up and participate actively in this thread. (2) Second, I think it is fundamental to study software language engineering (SLE) in its context, that is SL(E). Parentheses are important. I will create an separate discussion for that as this going beyond the question of SL(E)BOK vs. SWEBOK. But just tsimply put SLE is about *producing* SLA (Software Language Artifacts), and SLA are not software languages. Just like the C language is not the C compiler, the UML language is not to be confused with UML editor, nor the UML standard specification. Compilers and editors are pieces of software that have to be engineered. But the C language is not software. Don't we have first understand what (software) languages are? This lead to another discussion. YES, we must relate SWEBOK and SLE. but IMHO this is only part of the job, and doing this cannot be used t measure the complenetness of the study. Engineering and Science are both important. Engineers have also to understand what they do. So a very important is for instance 'What is the C language?" (not the compiler for sure).

At fist glance, I try to "formalize" the way Pieter and his colleges to obtain such a collaborative paper: A shift from MOF (Meta-Object Facility) to MPF (Meta-Paper Facility) ...