Lambda the Ultimate

I have posted a document explaining how Heron implements metaprogramming online at http://www.heron-language.com/metaprogramming.html. Heron is a C++ style imperative language, and the metaprogramming functionality leverages the type system more logically than C++ template metaprogramming does. I would be interested in hearing any comments, suggestions or criticisms of the design decisions. Thank you very much!

n/a

Video lectures featuring presentations by Alan Kay, Butler Lampson, Dan Ingalls, and other computer scientists are available at the Internet Archive via this page
The currently available films are all from the late 80's, but may still be interesting to some of the LTU readers. Some highlights:

Alan Kay: Doing with Images Makes Symbols

John Backus: Function Level Programming and the FL Language

Daniel G Bobrow: Common LISP Object Standard

http://www.aisto.com/roeder/paper/

Three PowerPoint* presentations on "interactive source code", i.e. source code beyond ASCII. Röder worked with Charles Simonyi.

* there's a PP viewer for Macs.

Okay, I'm doing a self study in techniques for defining the semantics of programming languages. I have found this book( Syntax and Semantics of Programming Languages ) which seems pretty comprehensive. In particular, I was interested if there were any formalisms besides those in the book(Operational, Denotational, Domain Theory, Axiomatic, Algebraic, etc.). I was also interested in people's opinions about the strengths and weaknesses of these formalisms, and if any of them are more popular, or considered "obsolete".

Also, since I'm interested in parsing as well, I was wondering how the use of grammar formalisms to define semantics(such as Attribute Grammars, Affix Grammars, Wijngaarden grammars) is seen in comparison to these formalisms. I guess, this paper(ACM Digital Library membership required) is a good example of one way of using a grammar to define semantics. Is it considered antiquated to use grammar formalisms to do this, or is it simply not popular?

In connection with the recent discussion concerning how people think about programming, I thought it might be worthwhile to revisit some of E. Dijkstra's writings on the subject.

From EWD854: The fruits of misunderstanding:

I think anthropomorphism is worst of all. I have now seen programs "trying to do things", "wanting to do things", "believing things to be true", "knowing things" etc. Don't be so naive as to believe that this use of language is harmless. It invites the programmer to identify himself with the execution of the program and almost forces upon him the use of operational semantics.

and:

And now we have the fad of making all sorts of systems and their components "intelligent" or "smart". It often boils down to designing a woolly man-machine interface that makes the machine as unlike a computer as possible: the computer's greatest strength—the efficient embodiment of a formal system—has disguised at great cost.

and:

Another analogy that did not work was pushed when the term "software engineering" was invented. The competent programmer's output can be viewed as that of an engineer: a non-trivial reliable mechanism but there the analogy stops...

From EWD1036: On the cruelty of really teaching computing science (html):

It is the most common way of trying to cope with novelty: by means of metaphors and analogies we try to link the new to the old, the novel to the familiar... Coping with radical novelty requires an orthogonal method... one has to approach the radical novelty with a blank mind, consciously refusing to try to link it with what is already familiar, because the familiar is hopelessly inadequate... Coming to grips with a radical novelty amounts ot creating and learning a new foreign tongue that can not be translated into one's mother tongue. (Any one who has learned quantum mechanics knows what I am talking about.)

and:

A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash [sic]: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot".

and:

We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation... My next linguistical suggestion is mor rigorous. It is to fight the "if-this-guy-wants-to-talk-to-that-guy" syndrome: never refer to parts of programs or pieces of equipment in anthropomorphic terminology...

and finally there is the now-classic example (a domino-tiling problem) of why "operational reasoning is a tremendous waste of mental effort."

In debates over merits of programming paradigms, languages, and tools, often the way ordinary humans think is cited. For example, some opinions dismiss non-imperative programming "because people think in terms of states", or non-object-oriented programming "because people think in terms of manipulating objects".

I think this is all very well. Ordinary people also fear blood and gore. Can you imagine an "opinion leader" in medical science saying "never cut open the body of appendicitis patients because it would be tough to doctors"? Medical treatments are assessed based on benefit and harm to patients, not comfort of doctors. Medical students are required to learn to face blood and gore, or quit.

The "natural" or "common" argument is never brought up in professions such as medicine and surgery, law, accounting, and engineering whenever there are debates over methodologies and training. It is not ordinary people's nature to be rigorous, analytic, quantitative, formal, rational, calm, objective, impartial, ... The professions do not give in to human nature; quite on the contrary, apprentices are trained for years against human nature, and those who fail to change are weeded out.

There are professions and professional training because the way of common people is deficient.

If common people can think of nothing other than states and objects, perhaps programmers should grow out of it.

(Also posted as
http://slashdot.org/~Albert%20Y.C.%20Lai/journal/83868
and in comp.lang.functional under the same title.)

Following on the heels of this year's ICFP Programming Contest, Ant Wars is a competitive programming web game where competitors code finite state machine ant brains to guide colonies of ants. Two species compete for food in a simulation; the ant with the most food at the end winning.

The programming is currently done in an s-expression based high level language, compiled to a simple bytecode using SISC. Many intriguing behaviors have already arisen, including a running arms race between two competitors.

Phil Greenspun has an amusing anecdote of his troubles with MIT Scheme, from, I guess, around 1990, and including an unwise declaration from Gerald Sussmann. Not terribly conclusive, but I'd like to collect similar anecdotes, if anyone has some. Via lemonodor.

[edit: CL <-- CLisp following Pascal's comment in thread]

Here's a spectacular paper by Oleg Kiselyov and Chung-chieh Shan which describes a method of faking dependent types in Haskell using type classes.

McBride mentions that, with all the tricks, the programmer still must decide if data belong in compile-time or run-time terms. "The barrier represented by :: has not been broken, nor is it likely to be in the near future." If our reflect and especially reify functions have not broken the barrier, they at least dug a tunnel underneath.

(Mentioned yesterday by Dave Menendez in the Apple Flunks... thread, but I thought the paper merited a discussion of its own)