William Cook, University of Texas at Austin Jonathon Cooper, Oxford Andy Gill, University of Kansas Oege de Moor, Oxford University Bernard Sufrin, Oxford University Doaitse Swierstra, Universiteit Utrecht
Introductions:
Oege has been interested in DSLs on and off over the years; he has worked with animations with Conal Elliot and is now working with databases.
Jonathan has been using DSLs for biological models. He has been using them for transforming models and is interested in using them describe the glue connecting different models.
Andy has been involved in many EDSLs. He currently has two projects at the University of Kansas on EDSLs.
Doaitse's goal at the beginning of his career was to make programming a less painful and more rewarding experience.
Bernard has been interested in DSLs because every program he has developed has a DSL embedded in it.
Doaitse: Doaitse described his views on the role of computer science in society. He describes some general stages of knowledge and expertise. The first stage is when people work as amateurs; following this stage is the stage of the craftsman -he may not know why things work, but he develops some techniques. The next stage is the mathematical stage, where formal models of the craft are edeveloped. Note that at this mathematics is acting as a service science here. However, these formal models don't tell people how to build things, and so the next stage is engineering, where there are methods to build objects according to the principles of the science. The next stage is computerization stage, where the engineering principles are automated. And computer science is the service science for this stage, just as maths was the service science for computerization. This is why DSLs are the cornerstone of computer science.
What is computer science? It is the use computer science techniques to help others use computers. At this conference, he expected papers on design principles of DSLs or implementation techniques. Examples of some work in this are the Helium compiler, where the designer of the library can give specialized type rules for a library which allows the compiler to give library-specific error messages. This is the kind of paper that was missing in this conference: generic techniques for developing and designing DSLs.
Walid & Doaitse: We can call this evolution "technology maturity process".
Andy: Andy is interested in pushing the science of DSLs. Would like to see the underlying principles understood. An example principle that needs to be explored is the difference b/t deep and shallow embeddings. Andy sees DSLs as a route to writing clear programs without sacrificing speed. And we may need implementation techniques, for example compilation techniques to make this practical.
Jonathan: This issue of making DSLs more useful should be aimed also outside the computer science community, because others outside the community could use these techniques. A challenge for the field will be whether it can move technology out to users.
Walid: Do biologists know about modelica or other tools?
Jonathon: People are hacking systems. They typically start with Matlab and then move to Fortran or C if they need more speed. People are also developing XML models of domains. Another important area is in developing ways to componentize mathematical models. But there aren't any good techniques for doing this now. People are using DSLs like Matlab and Mathematica that really are general purpose.
Walid: One major issue in developing DSLs as programming language researchers is that it a huge amount of work to find out about the domain and learning about the DSLs that are available for a given domain.
Oege: We've got to work with users. I am surprised that there weren't more papers on DSLs addressing business concerns, for example DSLs on some of things that software like SAP is doing.
Because DSLs are user-oriented, we should evaluate DSLs based on users. Productivity studies are difficult, but we could take the Helium project as a model; they log user activity and analyze the errors that users make.
He takes issue with Walid saying that DSLs are not about optimization, because if this is going to be user-oriented then there certainly will need to be optimizations to make these programs run efficiently.
William: Different communities within computer science are using different terminology for similar aspects of DSLs. We need to connect the terms used by different communities.
Jeremy: Is there a feeling among users that there is a dire need for programming language researchers to address these issues, or do they feel "this is easy, let's just do it ourselves."
Jonathon: There is a recognition that something is wrong, or that things are difficult.
Doaitse: Compiler construction is core CS, and unfortunately students aren't required to take such a course.
Jeremy: Do people feel that they need PL researchers for language design.
Doaitse: It's worse; they are unaware that they are developing a language.
Oege: Disagrees; he knows scientists who know and want help implementing compilers for their languages.
Bernard: Hedge fund comment. They recognized they had a problem with scale and that their current approach, which consists of hiring lots of physicists, won't work in the future.
Martin: He has worked with both bioinformatics folks and oceanographers, and has had two very different experiences; the bioinformaticians did not recognize the need - they basically build their own tools. The oceanographers were different. They were suffering under two code bases. Theory: scientists need to suffer, before they recognize the need.
Bernard: He had an experience working with animal behavior experimenters working with birds. Their primary program was a Basic program that consisted of 100,000 lines of code. Experimenters spent 2 years learning how to operate and tweak the program. Most of the code concerned administrative things so that things didn't fail catastrophically. Only a small amount of the code was for the experiments themselves.
Ken: Can we develop a one page brochure describing the kinds of pain and suffering that DSL can alleviate? What would the brochure look like?
Tony Sloane: regarding the people writing metamodels and uml diagrams. there are people within computer science and software engineering that could use DSLs but are not using them.
Jeremy: He is skeptical; they are people who feel like they are working to a solution, and so may not be open to the DSL approach.
Doaitse: One problem is that many computer scientists feel like programming languages research is completely uninteresting, whereas I feel that it is a core subject. The problem with this is that we educate students and stamp them as computer scientists, rather than "game specialists".
Bernard: Regarding characterizing embedding vs. the language itself: to avoid being vacuous about a DSL we need some laws about the language. 1) What are the appropriate characteristics of an embedding? One thesis: the laws of the DSL, then it should be true in the embedding. 2) What are the characteristics of a language to support embeddding e.g. the Helium compiler, and 3) What are the characteristics of the embedding of a specific language?
Votes were taken on the questions collected by Walid (which appear in the panel slides) 1 vote for #7 1 vote for #[8,9,10] 1 vote for #3 several votes for #1
Start with 7: "What is a domain, anyway?!" Martin: "Domain" is an overloaded term - one meaning is technical in terms of a mathematical model of computations, and the other refers to a problem area.
Walid: In designing a DSL, one has to identify the domain, and an issue here is the size of the domain.
Jason: Maybe we should develop a taxonomy of domains rather than a definition.
Ken: What are the symptoms of the domain? This relates to what we can do for users.
Bernard: We should continue to communicate about the problem areas in which we are all working on after the conference.
Jeremy, Tony: The next conference should be sometime, but after 2010.
Bernard: No to summer school, because we are not ready, we can't even define DSLs very well.
Oege: Disagrees; Some topics you could teach at a summer school are embedding, rewriting, attribute grammars, i.e. enabling technologies for building DSLs.
Bernard: We should invite people other than those here to the summer school, for example potential users.
Doaitse. We should aim the school at either at computer scientists and enabling technologies for implementing DSLs, or at users and things relevant to them, rather than both.
Martin: The summer school could help us raise awareness.
Bernard: Keep the blog going; the "Afterblog".
Walid: People should feel welcome to post pointers to our blog on other blogs. And all presenters are encouraged to post their slides.
This comment has been removed by the author.
ReplyDelete[Panel Notes, Part 1]
ReplyDeletePanelists:
William Cook, University of Texas at Austin
Jonathon Cooper, Oxford
Andy Gill, University of Kansas
Oege de Moor, Oxford University
Bernard Sufrin, Oxford University
Doaitse Swierstra, Universiteit Utrecht
Introductions:
Oege has been interested in DSLs on and off over the years; he has worked with animations with Conal Elliot and is now working with databases.
Jonathan has been using DSLs for biological models. He has been using them for transforming models and is interested in using them describe the glue connecting different models.
Andy has been involved in many EDSLs. He currently has two projects at the University of Kansas on EDSLs.
Doaitse's goal at the beginning of his career was to make programming a less painful and more rewarding experience.
Bernard has been interested in DSLs because every program he has developed has a DSL embedded in it.
[Panel Notes, Part 2]
ReplyDelete-- Statements --
Doaitse:
Doaitse described his views on the role of computer science in society. He describes some general stages of knowledge and expertise. The first stage is when people work as amateurs; following this stage is the stage of the craftsman -he may not know why things work, but he develops some techniques. The next stage is the mathematical stage, where formal models of the craft are edeveloped. Note that at this mathematics is acting as a service science here. However, these formal models don't tell people how to build things, and so the next stage is engineering, where there are methods to build objects according to the principles of the science. The next stage is computerization stage, where the engineering principles are automated. And computer science is the service science for this stage, just as maths was the service science for computerization. This is why DSLs are the cornerstone of computer science.
What is computer science? It is the use computer science techniques to help others use computers. At this conference, he expected papers on design principles of DSLs or implementation techniques. Examples of some work in this are the Helium compiler, where the designer of the library can give specialized type rules for a library which allows the compiler to give library-specific error messages. This is the kind of paper that was missing in this conference: generic techniques for developing and designing DSLs.
Walid & Doaitse: We can call this evolution "technology maturity process".
Andy:
Andy is interested in pushing the science of DSLs. Would like to see the underlying principles understood. An example principle that needs to be explored is the difference b/t deep and shallow embeddings. Andy sees DSLs as a route to writing clear programs without sacrificing speed. And we may need implementation techniques, for example compilation techniques to make this practical.
Jonathan:
This issue of making DSLs more useful should be aimed also outside the computer science community, because others outside the community could use these techniques. A challenge for the field will be whether it can move technology out to users.
Walid: Do biologists know about modelica or other tools?
Jonathon: People are hacking systems. They typically start with Matlab and then move to Fortran or C if they need more speed. People are also developing XML models of domains. Another important area is in developing ways to componentize mathematical models. But there aren't any good techniques for doing this now. People are using DSLs like Matlab and Mathematica that really are general purpose.
Walid: One major issue in developing DSLs as programming language researchers is that it a huge amount of work to find out about the domain and learning about the DSLs that are available for a given domain.
Oege:
We've got to work with users. I am surprised that there weren't more papers on DSLs addressing business concerns, for example DSLs on some of things that software like SAP is doing.
Because DSLs are user-oriented, we should evaluate DSLs based on users. Productivity studies are difficult, but we could take the Helium project as a model; they log user activity and analyze the errors that users make.
He takes issue with Walid saying that DSLs are not about optimization, because if this is going to be user-oriented then there certainly will need to be optimizations to make these programs run efficiently.
William:
Different communities within computer science are using different terminology for similar aspects of DSLs. We need to connect the terms used by different communities.
[Panel Notes, Part 3]
ReplyDelete-- Questions Segment --
Jeremy: Is there a feeling among users that there is a dire need for programming language researchers to address these issues, or do they feel "this is easy, let's just do it ourselves."
Jonathon: There is a recognition that something is wrong, or that things are difficult.
Doaitse: Compiler construction is core CS, and unfortunately students aren't required to take such a course.
Jeremy: Do people feel that they need PL researchers for language design.
Doaitse: It's worse; they are unaware that they are developing a language.
Oege: Disagrees; he knows scientists who know and want help implementing compilers for their languages.
Bernard: Hedge fund comment. They recognized they had a problem with scale and that their current approach, which consists of hiring lots of physicists, won't work in the future.
Martin: He has worked with both bioinformatics folks and oceanographers, and has had two very different experiences; the bioinformaticians did not recognize the need - they basically build their own tools. The oceanographers were different. They were suffering under two code bases. Theory: scientists need to suffer, before they recognize the need.
Bernard: He had an experience working with animal behavior experimenters working with birds. Their primary program was a Basic program that consisted of 100,000 lines of code. Experimenters spent 2 years learning how to operate and tweak the program. Most of the code concerned administrative things so that things didn't fail catastrophically. Only a small amount of the code was for the experiments themselves.
Ken: Can we develop a one page brochure describing the kinds of pain and suffering that DSL can alleviate? What would the brochure look
like?
Tony Sloane: regarding the people writing metamodels and uml diagrams. there are people within computer science and software engineering that could use DSLs but are not using them.
Jeremy: He is skeptical; they are people who feel like they are working to a solution, and so may not be open to the DSL approach.
Doaitse: One problem is that many computer scientists feel like programming languages research is completely uninteresting, whereas I feel that it is a core subject. The problem with this is that we educate students and stamp them as computer scientists, rather than "game specialists".
[Panel notes, part 4]
ReplyDeleteBernard: Regarding characterizing embedding vs. the language itself: to avoid being vacuous about a DSL we need some laws about the language.
1) What are the appropriate characteristics of an embedding? One thesis: the laws of the DSL, then it should be true in the embedding.
2) What are the characteristics of a language to support embeddding e.g. the Helium compiler, and
3) What are the characteristics of the embedding of a specific language?
Votes were taken on the questions collected by Walid (which appear in the panel slides)
1 vote for #7
1 vote for #[8,9,10]
1 vote for #3
several votes for #1
Start with 7: "What is a domain, anyway?!"
Martin: "Domain" is an overloaded term - one meaning is technical in terms of a mathematical model of computations, and the other refers to a problem area.
Walid: In designing a DSL, one has to identify the domain, and an issue here is the size of the domain.
Jason: Maybe we should develop a taxonomy of domains rather than a definition.
Ken: What are the symptoms of the domain? This relates to what we can do for users.
Bernard: We should continue to communicate about the problem areas in which we are all working on after the conference.
Jeremy, Tony: The next conference should be sometime, but after 2010.
Bernard: No to summer school, because we are not ready, we can't even define DSLs very well.
Oege: Disagrees; Some topics you could teach at a summer school are embedding, rewriting, attribute grammars, i.e. enabling technologies for building DSLs.
Bernard: We should invite people other than those here to the summer school, for example potential users.
Doaitse. We should aim the school at either at computer scientists and enabling technologies for implementing DSLs, or at users and things relevant to them, rather than both.
Martin: The summer school could help us raise awareness.
Bernard: Keep the blog going; the "Afterblog".
Walid: People should feel welcome to post pointers to our blog on other blogs. And all presenters are encouraged to post their slides.