Walid at 12:33, 16 December 2011

2011-12-16T12:33:39Z

← Older revision		Revision as of 14:33, 16 December 2011
Line 2:		Line 2:


	~~<HTML>~~		Sam Kamin and Eelco Visser
	~~<HEAD>~~
	~~<title>~~Sam Kamin and Eelco Visser~~</title>~~
	~~</head>~~

	~~<body bgcolor="white">~~

	Title:		Title:
	Compelling examples of program generation		Compelling examples of program generation
	~~<br>~~Discussion Leader: Sam Kamin and Eelco Visser
	~~<p>~~		Discussion Leader:
			Sam Kamin and Eelco Visser


	==-++ Sam's Perspective: Model Examples for Program Generation==		==-++ Sam's Perspective: Model Examples for Program Generation==
Line 60:		Line 57:

	[WalidTaha]: Eelco, nice discussion topic! For me it depends on how you define program generation. There are concrete aspects (like using "printf" somewhere in your "generator"), and there are much more abstract aspects (like "evaluation under lambda"). MSP, for example, is already a framework were evaluation under lambda is built into the language, and you don't have to leave the language.		[WalidTaha]: Eelco, nice discussion topic! For me it depends on how you define program generation. There are concrete aspects (like using "printf" somewhere in your "generator"), and there are much more abstract aspects (like "evaluation under lambda"). MSP, for example, is already a framework were evaluation under lambda is built into the language, and you don't have to leave the language.


	~~</BODY>~~

	~~</html>~~

Admin: 1 revision

2011-12-12T10:06:25Z

1 revision

New page

[[Category:WG211]]

<HTML>
<HEAD>
<title>Sam Kamin and Eelco Visser</title>
</head>

<body bgcolor="white">

Title:
Compelling examples of program generation
 Discussion Leader: Sam Kamin and Eelco Visser


==-++ Sam's Perspective: Model Examples for Program Generation==

Many techniques to facilitate program generation have been proposed, and many tools developed. Scientific progress in this area requires that we be able to compare these tools and methods concretely.
One way to do this is to apply various methods to the same problem.


The purpose of this discussion group is to begin the process of accumulating model problems and making them available to the community.
Indeed, these are really two purposes: gathering problems, and presenting them in a way that makes them maximally accessible to other researchers.
In particular, the descriptions should permit other researchers to write program generators without learning a specialized area of Computer Science.


In this group, we will discuss model problems and model presentations.
The ultimate goal is the creation of a section of the WG 2.11 wiki hosting both a list of these problems, and, more importantly, a well-grounded discussion of program generation techniques.


Participants are invited to produce a description of their favorite application of program generation. We will begin the discussion with participants presenting their model problem descriptions.

===--+++ Eelco's Perspective: The Future of Program Generation===

Is program generation a fundamental tool for software engineering or is it a crutch to help users of disfunctional programming languages?

Consiser this quote from an [[http://www.codegeneration.net/tiki-read_article.php?articleId=9 interview]] on Code Generation Net with Dave Thomas

<blockquote>
CGN: What do think the future is for code generation?

Dave: I think that in the long term the larger code generation efforts, the "application generators," will become a thing of the past. They are there because the underlying technologies and architectures don't yet support programming at a high level. But I'm betting that languages such as Java and C++ will in the long term be seen as a curious branch in the evolution of computing. I'm hoping that somewhere out there some bright spark is coming up with a way of letting us write applications expressively and dynamically. Once this happens, the need for these kinds of code generators will diminish.

For example, I rarely (if ever) write a code generator that generates Ruby code: there's just no need, as Ruby is dynamic enough to let be do what I want without leaving the language.

In the shorter term, though, I think code generators of all kinds will continue to contribute significantly to the industry. Java and C# are both such stifling languages that you need to be able to use code generators to make them effective.
</blockquote>

So the thesis is: better abstraction mechanisms make program generation obsolete.

In this discussion I would be interested in arguments for or against this thesis.
Preferably such arguments should be illustrated with evidence (examples)

* successful applications of code generation, especially those that are are here to stay
* abstractions that make generation obsolete

A followup question might be: If generation is (temporarily) useful, how important is it to have static guarantees about generators such as syntactic or type correctness of the output programs? Many text-based program generation techniques flourish apparently without suffering from the problem that they do not provide such guarantees.

===-+++ Participant's Comments===

[WalidTaha]: Eelco, nice discussion topic! For me it depends on how you define program generation. There are concrete aspects (like using "printf" somewhere in your "generator"), and there are much more abstract aspects (like "evaluation under lambda"). MSP, for example, is already a framework were evaluation under lambda is built into the language, and you don't have to leave the language.

</BODY>

</html>

WG211/M3KaminDiscussion - Revision history

Walid at 12:33, 16 December 2011

Admin: 1 revision