Via Chad Fowler. A two part series describes code generation using java and xsl.

I started this article by saying that code generation was important and it was something that you need to understand. Why is that? It's not just because today's frameworks are code-intensive. It's also because the code that generators build is far more consistent in form and quality than hand code.

I've done a fair bit of code generation for various purposes but I can't help but think that much of the need for using the technique lies with the facilities of the language. Ran across an opinion a while back that took the extreme POV:

Blanchard's law: Systems that require code generation lack sufficient power to tackle the problem at hand.

My opinion probably lies somewhere in between: code generation is a useful programming approach but it many times indicates a fault in the underlying programming language to capture the necessary abstractions. (of course, the lines between compiler, interpreter and code generation are rather blurry).Posted to general by Chris Rathman on 6/13/04; 9:24:54 PM

There never seem to be a lot of discussion about Vector languages here, so I figured I'd point at a new one under development: Glee(warning: awful frame-based navigation on site), found on the Jsoftware forum (not linkable, requires authorisation to view archives!)

Vector languages (or array processing languages) are fun. I really don't know why they never seem to get much attention.

Should languages provide such a feature, and if they do, how should nullable types behave (e.g., does null==null ?).

A DSL I worked on that was used for data analysis had two special values represeting missing and erroneous data. Builtin functions each had to decide how to handle these special values. It was quite useful in practice.

More interesting is a project to add continuations to Java. If my reading of the code is correct, it works by annotating each basic block with code to store the current environment. These continuations are single use only, so probably not that handy for web applications. Interesting none the less!

So if Java has generics, continuations, pattern matching, AOP and open classes what language innovations are left in our supposedly more advanced languages? It used to be the state-of-the-art was at least 20 years ahead of practice. Has this gap narrowed?

In Terminator 3, the SkyNet AI, exploiting the fundamental failure of computer security, distributes itself globally and becomes invulnerable to destruction. It then destroys the world when it gains control of America's nuclear missiles. While this is a considerably more serious disaster than any wrought so far by cyber-crackers, cyber-terrorists, or cyber-warriors, the flaws that make SkyNet unstoppable are the same flaws that make crackers, terrorists, and warriors possible. The same fix that eliminates crackers can terminate the Terminators.

This presentation starts by examining in detail the fundamental flaw in computer security today--the ludicrously excessive authority granted to even silly programs like Barbie Fashion Designer. We go on to see how the Principle of Least Authority (also known as the Principle of Least Privilege), ubiquitously applied by bundling designation with authorization, can end the madness while simultaneously making the user interface to security simpler than it is today.

This talk touches on a very important topic, one which may make the
crucial difference for our personal liberties in a future where almost all
of our society's activities will be happening on a digital substrate.
The thorough use of the Principle of Least Authority, which the talk
explains, can give us security that is both usable and effective.

All editors are, of course, encouraged to provide links from the home page to items from the discussion group, when they think the discussion group messages are worthy of wider attention.Posted to general by Ehud Lamm on 5/5/04; 12:35:25 PM

In the companion blog entry Sean gives the example of a Jython script that he used, instead of an XML configuration file, to parameterize a piece of software. It illustrates, by example, one of the points I tried to make in my recent IT Conversations interview with Doug Kaye. Dynamic languages are a great way to record data when a solution is fluid and requirements are evolving. And, come to think of it, when aren't those things true?

I like Jon's reporting, and I think he is a smart guy, which is why I don't think it's his fault that he constantly uses the rather meaningless term dynamic languages. It's ours.

I don't think this is just a problem with terminology. I think a more careful analysis of technical issues involved can be enligtening.

As part of LtU's mission to educate the world about programming language technologies, can we come up with a better, more meaningful, term for what Jon and others are looking for?

To get us started here are some relevant factors: interpretation vs. compilation, type system expressiveness, run-time environment and VM.

RDFEngine, a reasoning engine for the Semantic Web, was developed as a part of the master's thesis (pdf) of Guido Naudts. It's written in Python. Based on Jos De Roo's Euler proof engine (Java/C#), it appears to cover most of the functionality of Tim Berners-Lee and co's cwm inference/query engine. It uses a variety of formats to represent RDF + logic - Notation 3 (like cwm), as well as a verbose triple-oriented XML format and the novel "SIF", Short Inferencing Format.

The XSLT 2.0 specification defines tunnel parameters as having "the property that they are automatically passed on by the called template to any further templates that it calls, and so on recursively." When working on the big, complex stylesheets described above, if I could have identified the parameters passed to the original template as tunnel parameters, there would have been no need to explicitly pass them to templates that it called.

Reminds me of dynamically scoped (special) variables in Lisp.Posted to general by Patrick Logan on 4/19/04; 9:58:33 PM

I'm fascinated by programming languages. So it was quite exciting to run across Poplog, a venerable workhorse of a language long-popular on the other side of the pond.

Poplog consists of an efficient runtime environment with incremental compiler that supports Common Lisp (CTL2), ML, Prolog, and Pop-11.

The system appears to have many of the strengths of each of these languages, and has the interesting property of allowing a program to be composed of modules built in any combination of the various supported languages.

Furthermore, being a Sheltie owner, I was greatly pleased to see this demonstration of herding dog skills. :-) [Warning -- 8 Meg MPG.]

I'm interested to hear what other LtUers know about Poplog, or other "Multi-Paradigm" languages.Posted to general by Brent Fulgham on 4/15/04; 1:12:44 PM

Today's defense of linguistic relativity is brought to you by the color "Grue".

Color lexicons vary, first of all, in sheer size: English has 11 basic terms, Russian and Hungarian have 12, yet the New Guinean language Dani has just two. One of the two encompasses black, green, blue and other "cool" colors; the other encompasses white, red, yellow and other "warm" colors. Those languages with only three terms almost always have "black-cool," "white-light" and "red-yellow-warm." Those having a fourth usually carve out "grue" from the "black-cool" term.

And did I mention that it's a very mild defense:

Here, then, is an example of language categories molding thought and behavior in a striking way. Kay concludes that linguistic relativists may be correct that the languages people speak mold their thoughts. "But it is unlikely that the various languages of the world are so different from one another, in underlying conceptual structure, that the ways their speakers think are incommensurable."

This one-day workshop will address the question what role Lisp-based languages can play in the near future to further the state of art in those and related areas. We want to solicit papers that discuss the opportunities Lisp provides to capture and enhance the possibilities in software engineering. Instead of using Lisp for Artificial Intelligence, as has successfully been done in the past, we rather want to explore the usefulness of Lisp with regard to software technology.

Check out the Papers that have been submitted thus far. (Note: Clicking on the PDF links doesn't work on my browser - but if I save them off locally, they open fine).

So why don't I ever get to go to fun conferences like this. (Perhaps it's because I'm the only software person in our three person entreprenoirship). :-)Posted to general by Chris Rathman on 4/8/04; 8:48:32 PM

If you've never had the pleasure of programming an x86-family processor in assembly language, you don't know pain. The 32-bit x86 chips (including the '386, '486, and Pentium-class parts from Intel and AMD) do an amazing job of dragging one of the world's oldest processor designs into the modern age. They do it while still maintaining binary compatibility with chips that are three generations and 15 years behind. It's impressive, really, but it makes these chips tricky to program with low-level code.

Since the discussion forum has gotten into a question of evolution and popularity, I thought I'd pop in with the parallel universe of assembly language. IMHO, x86 assembly language is far inferior to many of the other alternatives. Yet, the biggest target cpu is the x86.

The only upside, I suppose, is that Intel managed to single handedly destroy the art of hand crafted assembly. The vacuum being filled in by C. The problem with the popular choices is not just restricted to higher level languages (and that's not even getting into the question of Operating Systems).Posted to general by Chris Rathman on 4/1/04; 10:01:26 PM

XC# uses C#'s properties to add metadata to C# code that is later used to modify the assembly (e.g, adding preconditions), influence Visual Studio etc.

XC# support any arbitrary compilation attribute.
Compilation attributes perform a certain task at compilation time. They can
inspect the code and look for errors, or they can influence the way the
compiler works by adding or removing statements, renaming classes and members
or canceling custom attribute generation.

It's easy to get lost in the world of "little languages" -- quite a few have been written to scratch some itch of a company, individual, or project. Rexx is one of these languages, with a long history of use on IBM operating systems, and good current implementations for Linux and other Free Software operating systems. Rexx occupies a useful ecological niche between the relative crudeness of shell scripting and the cumbersome formality of full systems languages.

So, we've written a multithreaded port scanner, nicely bundled up as a library for use in our other programs. In the process we've touched on a lot of my favorite features of Scheme (and PLT Scheme in particular): its clever loop constructs, its higher-order functions, concurrency, macros, modules, and contracts.

Scheme is fresh on my mind, as I'm over the halfway point in the SICP videos (part 6a on Streams is the best one thus far). The author of the K5 article is no Abelson or Sussman, but does try to make the language accessible.Posted to general by Chris Rathman on 3/19/04; 8:03:53 AM

I don't trust Eckel, so don't take this post to mean I endorse his view. I just want to get the item out while the server is up, and I don't have the time to read his argument. From a quick glance, I have a feeling he is incorrect about a couple of observations.

Traditional programming languages are heavily tied to their representation as textual source code, which is unfortunate -- pure text is a very poor notation system for the concepts of a high-level language. An Eidola program, however, exists independent of any representation; its "fundamental" form is as a set of carefully defined mathematical abstractions, opening the possibility of having many different notations. Representations of the language thus exist for the benefit of the programmer instead of the compiler, and freed from the constraints of text files, we can tackle the question of how to notate a program well.

Be warned: Eidola is a very large project its very early phases. It is still mostly theory and vaporware.

The impetus and evolution articles give motivation, while semantics are specified in a short PDF document. The proprietors eagerly solicit feedback. They appear to be Java/C++ people. What I find interesting here is the prospect of a visual implementation.

Seeking to eliminate the need for detailed hardware expertise for FPGA design, a research group at the Los Alamos National Laboratory (LANL) here has developed an open-source C compiler for reconfigurable logic. Called Streams-C, the compiler doesn't generally yield the performance of RTL design but claims to boost productivity by 10 to 100 fold.

"After a few years of looking at the problem, I realized that most of the application space could be described well with a stream-oriented communicating sequential processes model," she said.

The result was Stream-C, which is freely available for research and government purposes, with a commercial licensing process underway. Gokhale said that in addition to LANL, several universities are using the compiler, and EDA companies have expressed interest in commercializing it.
Posted to general by Patrick Logan on 2/27/04; 12:16:57 PM

I was going to post this under fun, because the Slashdot comments suggested it would have some readers here in fits. But there are some interesting things in there - she talks about explicit state in programs, for example, and, near the start, seems to be suggesting that an Erlang-like approach could be useful. Her observations about programmers being average people is worth repeating, too.

Finally, some of the /. comments mentioned functional programming. Is my memory deceiving me, or is that something that wouldn't have happened 5 years ago?Posted to general by andrew cooke on 2/13/04; 4:26:57 PM

If these so-called "exotic" languages die, we'll be left with just one world view. This won't be very interesting, and we'll have lost a vast amount of information about human nature and how people perceive the world.

This interview is about preserving natural languages, of course. Still, the issues mentioned and the examples discussed may be of some help in explaining the rich experience that is language.

I'll let you decide whether, and how much, this applies to programming languages.

via Patrick I came across Brian Marick's discussion of code reading practices based on a session in the recent MFA trail run.

The question at hand was in the context of an accumulator passing tail recursive implementation of factorial. Which is better: to use an optional private parameter in a public function or to use a "named" let, and introduce the accumulator there?

I am with Patrick (I think) who seems to prefer the nested let. It seems to me that this is also what Richard Gabriel prefers.

My reasons? First, by exposing the optional parameter you are implying it is part of the interface available to outside clients. I don't think this is the correct semantic interpretation in this case, so it is misleasing. Essentially, what you want is a helper function (fact-iter), and fusing it with the public function seems like a hack. Sexy but confusing...

Second, scope is one of the most important clues when reading code. Scoping techniques make code more readable, both for humans and for language processing tools. Provided, that is, that you pay attention to them when you are writing as well as when you are reading code.

And yes, Patrick, I think that it is idiomatic Scheme.Posted to general by Ehud Lamm on 1/25/04; 12:30:41 PM

by way of the illustrious (and typecast?) Tom Duff in the discussion group.

Graphical user interfaces are difficult to implement because of the essential concurrency among multiple interaction devices, such as mice, buttons, and keyboards. Squeak is a user interface implementation language that exploits this concurrency rather than hiding it, helping the programmer to express interactions using multiple devices.

A 1985 paper by Rob Pike and Luca Cardelli. Squeak looks interesting in many ways. It's especially faithful to CSP, embeds C within itself (yacc-style), and compiles an entire system of processes into a C procedure to be called with primitive events (e.g. mouse clicks).

I would be interested to see more source code of programs written in Squeak or its successor Newsqueak if anybody has a reference.

Did you know that Plan9 can be downloaded as a premade VMware image? I just downloaded and fired it up in a matter of minutes.Posted to general by Luke Gorrie on 1/24/04; 2:22:21 PM

One of the questions I am asked most often is about testing compilers and other language tools. In fact, I've even saw an exam question once about this, and the answer the instructor expected was wildly off the mark (no pun intended).

This blog post provides some inside information.

[Come to think of it, conformance tests accompanying language standards are an example of TDD...]

When I switched over the C# compiler team, I had hoped that I would be able to give some insight into how the design team works, what decisions we make, etc. Language design is a very esoteric field, and there's not a lot written about it (though "Design and evolution of C++" is a pretty good read). I had hoped that I would be able to do this with concrete examples, as that makes it much easier...

In lieu of such an example, I've decided to write something a bit more abstract about how we look at things.

And you were critical of Stroustrup's design philosophy...

Feel free to rant, but remember that sometimes it is better to try to offer constructive criticism. Maybe this is such a case.

Now if only Erik could comment on this item... (It would seem that he is having such a good time in Venice he never logs on )

Onyx is a powerful stack-based, multi-threaded, interpreted, general purpose programming language similar to PostScript. It can be embedded as an extension language...

Onyx is perhaps the most advanced stack-based general purpose programming language in existence (not that there are many others)...

Stacks are first class objects. This may seem like a basic feature, but neither Forth nor PostScript provide stacks, despite the obvious usefulness in a stack-based language...

access to POSIX system functionality...

Perl-compatible regular expressions...

Onyx's syntax is suitable both for code and data, which means that configuration files and databases can be read, written, and stored as Onyx code.Posted to general by Patrick Logan on 1/3/04; 10:56:40 PM

Polyglot is a Java class library that is easily extended through inheritance to create a compiler for a language that is a modification to Java. Language extensions can be implemented without duplicating code from the framework itself. Polyglot is useful for implementing domain-specific languages, for exploring language design ideas, and for simplifying Java for pedagogical purposes. The framework has been used to implement both major and minor modifications to Java. Experience implementing several languages in this framework suggests that the cost of implementing language extensions scales well with the degree to which the language extends Java.

This is the fifth release of Polyglot, incorporating many bug fixes and
extensions based on user feedback and testing. It is released under
LGPL, which is relatively permissive. Polyglot is currently being
developed and maintained by Nate Nystrom and Stephen Chong.

JMatch which is based on Polyglot was mentioned here in the past. I thought it quite nice.

Notice that these experiments are mainly about perception. When we use the intuition we developed from programming languages to conclude that language influences thought we are, more often than not, thinking about experssion rather then perception.

Empirically measuring how language sturcture (i.e, expressivness) influences language use (e.g, how complex things are described) is quite a lot harder than the classic experiments on language relativity.

As we all know (?) Ada gneric units provide a clean, type-system aware, mechanism for specifying the properties of arguments to generic units (i.e, templates).

The cool thing about Stroustrup's proposal is the idea of adding support for run-time semantics and invariant checking. This would be more powerful than what you have in Ada today, but like the related notion of DbC, many have doubts whether this is really worth the hassle. Notice that most of these properties are up to the programmer, and by using a well-defined interface (or concept, or class or whatever) he assumes the responisbility for maintaining them. Exaclty like saying that something is a Monad.

I have to check but it seems the Ada generics coupled with my DbC proposal for Ada provide almost the rquired support for arugment checking (though, obviously, not for unique C++ features like template specialization and automatic instantiation).

The crucial insight is that since [the] control operators take their values from the stack, it really doesn't matter how the values got there. Usually, as in these examples, they'll have been pushed there just before the operator is called. But they could have been placed there any other way, and the operators will still work.

More importantly, recall our recent discussion on reading code. It is a good idea to stretch your mind from time to time by playing with one of these esotric languages. Reading Postscript can be quite challenging.

But I guess I don't have to tell you guys about esotric languages. Preaching to the choir.

Whether IBM and Cray will agree to collaborate on the effort is unclear. Both companies have their own software plans that include developing new languages and operating systems as part of their competing work on the High Productivity Computing Systems (HPCS) project under the Defense Advanced Research Projects Agency (Darpa).

"Java has made it easy to program using a small number of threads. But in this [technical computing] world you have to handle thousands or hundreds of thousands of threads. We need the right language constructs to do that,"

Ok, it's obvious that Java threads are not scalable, but I don't know that Sun's Hero project is a language project so much as it is an attempt at a VM specification. The Darpa High Productivity Computing Systems concentrates on massively parallel architectures, so hopefully they'll tap into languages like Erlang and Oz for inspiration.Posted to general by Chris Rathman on 12/19/03; 1:05:27 PM

The JWIG programming language is a Java-based high-level language for development of interactive Web services. It contains an advanced session model, a flexible mechanism for dynamic construction of XML documents, in particular XHTML, and a powerful API for simplifying use of the HTTP protocol and many other aspects of Web service programming.

JWIG was mentioned here before, but now there's a TOPLAS paper (Aske Simon Christensen, Anders Moeller, and Michael I. Schwartzbach, Nov. 2003) so I thought I might mention it once more.

I don't think the guys discussing events and continuations are going to be very impressed by this, but the paper reflects the sad state of web programming (the bottom line: most people are still using the CGI model).

the real moral of the story is that natural language isn't really the best formalism for specifying language semantics. If in addition to the English prose, the Java and C# language specifications would have had formal static and operation semantics, I could have studied those to see what is really going on. It would also help we could stick to standard terminology, i.e. why use 'variable' when there's already a perfect term for that concept namely 'lvalue'.

The 16th European Summer School in Logic, Language and Information, organized by LORIA, takes place in Nancy, France, August 9-20, 2004. The ESSLLI Summer Schools are organized under the auspices of FoLLI, the European Association for Logic, Language and Information.

The main focus of ESSLLI is on the interface between linguistics, logic and computation. The school has developed into an important meeting place and forum for discussion for students, researchers and IT professionals interested in the interdisciplinary study of Logic, Language and Information.

It is well know that given a cursor interface to a collection,
we can implement an enumerator (aka for-each or fold). It is less
appreciated that given an enumerator interface, we can always derive a
cursor -- in an automatic way. We demonstrate that generic procedure
for languages with and without first-class continuations.

Now that cursors and enumerators are inter-convertible, an
implementor of a collection has a choice: which of the two interfaces
to implement natively? We argue that he should offer an enumerator
interface as the native one. The paper lists several reasons why
enumerators are superior. We present a design of the overall optimal
collection traversal interface, which is based on a left-fold-like
combinator with premature termination. The design has been implemented
and tested in practice.

The enumerator coll-fold-left described in this presentation has been chosen to be the primary traversal interface in Scheme Collections SRFI [SRFI-44]. A similar interface is being considered for an Oracle RDBMS binding in Haskell.

Under the category of "applying pl theory to linguistics", thought this paper would be of interest to LtU. Along the same lines as Linguistic side effects, Chris Barker applies the programming concept of continuations to the dissection and interpretation of sentences in natural languages:

Programming languages such as Scheme allow expressions to denote functions on their own continuation. It turns out that this one device is capable of reconstructing most common programming control structures, including if-then-else statements, goto statements, for loops, while loops, the throw/catch construction, return, etc. Obviously, there is a strong analogy between such programming control constructions and quantification in natural language; for instance, the truth conditions of the sentence Every boy left can be rendered roughly as ‘Foreach x in boy {if (not (x in left)), then return (false)}’. The main idea of this paper, then, is this: if continuations can provide a unified perspective on quantification-like structures in formal languages, then perhaps they can provide useful insights into quantification in natural language.

Must admit that most of this paper is over my head (especially in regards to references to works by other linguists). Can't say that I ever saw a connection between those sentence diagrams I did back in school and the lambda calculus. Still I did find bits of the paper accessible and think at a minimum it provides a useful analogy of continuations in programming languages.Posted to general by Chris Rathman on 11/13/03; 8:29:05 PM

The work described in this thesis is the result of a research program started in 1981 to find better ways of programming Telecom applications. These applications are large programs which despite careful testing will probably contain many errors when the program is put into service. We assume that such programs do contain errors, and investigate methods for building reliable systems despite such errors.

Joe Armstrong's much-awaited PhD thesis about the development of Erlang!

I'm fixing to be moonlighting on a project that involves data analysis from output produced by an embedded system. Thought a look at the main languages involved in the arena might be of interest to others here abouts.

Although C wins the popularity contest as the language most typically chosen for real-time embedded systems, other languages are worth considering. One of them, Ada, offers advantages over the C family, especially in high-reliability environments. Another, Java (as extended with real-time enhancements), may be especially attractive in highly dynamic systems.

In this article, I'll review the language features you'll need for real-time and embedded applications and look at how C, Ada, and Java's real-time extensions address these requirements. I'll use a typical example to describe and compare the Ada and Java approaches.

This wes held in conjunction with LL3. The site has a PDF and PS of the proceedings. Many of the topics complement those in LL3 and would be interesting to non-Scheme programmers as well.Posted to general by Patrick Logan on 11/10/03; 11:23:59 AM

Isaac's post about the MS PDC got me to reading about the proposed T-SQL Enhancements in SQL Server "Yukon". One change that caught my eye was the Common Table Expression (CTE) and the ability to define recursive queries. Recursive queries could come in handy when the data structure is in the form of a hierarchical Tree. The syntax for a CTE seems to be a lifted LET sort of construction:

I guess the usual rules when any vendor enhances SQL applies: (1). Never make it similar to the enhancements made by the competition (I'm thinking of CONNECT BY in Oracle SQL); and (2). Never make the change consistent with your own syntax constructs (Why didn't they just make Views capable of recursion and then introduce CREATE @var VIEW into the T-SQL construction similar to what they did with CREATE @var TABLE?). That aside, the ability to do Tree operations is something that I can use in SQL. It will be interesting to see how the performance stacks up against Nested Sets.Posted to general by Chris Rathman on 11/7/03; 1:53:40 PM

This document is designed to help you convert code from Common Lisp to Dylan. The first part of the document lists problems to look out for; the second part documents a Common Lisp program called LTD (for Lisp To Dylan) that helps to automate the conversion.

[Historical note: I recently found this 8-year old code hidden in the attic. Some readers might find it useful as an example of (1) 40,000 lines of code in the Dylan language (almost), or (2) the powerful pretty-printing capabilities in Common Lisp. Not many people appreciate that you can produce nicely formatted output so easily -- here I produce Dylan code with nice indentation, to any specified column width, just by converting Lisp to a parse-tree syntax that is equivalent to Dylan, and then writing pretty-print directives for the parse-trees. All the rest is handled automatically.]

I have a soft spot for language translator tools, having written pascal-to-c and rpg-to-vb tools in the distant past. Unlike compilers, translators require that the resulting code be readable, maintainable and in the idiom of the target language - making it much more of a dark art (not to mention that you have to worry about library and OS calls). The downside to translation is that there's still a lot of hand crafting that has to be done when the tool generates the output.

Even though code makes for a description of solutions in a fairly objective language, the bottom line is that it makes for a poor repository of knowledge when that language becomes an endangered species. Language translation efforts seem to rarely succeed. I've had a few successes here and there, but an intense familiarity with both languages as well as the software is required.Posted to general by Chris Rathman on 11/7/03; 8:34:26 AM

I thought I might spend a few days talking about the JScript and JScript .NET type systems, starting with some introductory material.

Eric, a Microsoft JScript and JScript.NET guy, begins a discussion of the ins and outs of the JScript type system.

There is a lot of terminology associated with type systems. What exactly is weak typing? What is a subtype? Just what is a type anyway? These terms are often bandied about and seldom actually defined precisely.

First installment is an introduction of types in the context of JavaScript.

For my final post, I'd like to be a little more provocative.
There are several known programming paradigms that
can be characterized as "nonalgorithmic": to solve a
problem, it's enough to specify the problem. (In some
sense, this is the real vision behind declarative
programming: ask, and the system answers.
The traditional declarative paradigms,
functional and logic, are far away from being declarative
in this sense since in practice you still have to think very closely
about how to solve your problem.)

One example is constraint programming. Specify your
problem as a set of constraints and let the constraint
solver do the rest. The constraint solver will do some
reasoning (using heuristics) but it falls back on brute-force
search when reasoning fails. Constraint programming research has
made lots of progress in making the whole thing smart
(see chapter 12 in CTM for an introduction, or any of
several good books such as Marriott & Stuckey or
Van Hentenryck).
It actually works in many cases: it has even been
observed to run in polynomial time if there is an
underlying polynomial solution (in natural language
processing). It is also causing something
of a revolution in the area of numerical analysis.

Another example is genetic programming, in which a
good solution is "evolved". Again, this uses a brute-force
strategy, with populations of tentative solutions. This
has been observed to give very good nontraditional
solutions in some cases.

A third example (which I know very little about) may be neural
nets, although I am not sure how much more than
simple 'minima finding' can be done by them. Can
modern neural nets be trained to do more than
'minima finding'? If so, this would also be an example
of nonalgorithmic programming.

Other examples can be found in AI, e.g., in the area
of machine learning.

So what is your view? Will programming become more
and more nonalgorithmic as time goes by? Or will
"good old-fashioned programming", i.e.,
building components from subcomponents in layers
until the problem is solved, continue to be the main
way that computers are programmed?Posted to general by Peter Van Roy on 11/1/03; 2:30:24 PM

I have been hearing a lot about macros recently, from
Paul Graham's book onLisp to the discussions here on Lambda.

I want to understand clearly what all the hubbub is about.
What are the respective advantages and disadvantages
of macros (i.e., Lisp style) and higher-order programming?
To me the situation seems to be as follows (caveat: it has
been decades since I actually did real programming with macros).
Higher-order programming is more expressive. Macros
are syntactically more concise and give more efficient code.
(Note that expressiveness and verbosity only have a tenuous
connection!)

What I would like to have in Oz is a mechanism for defining
linguistic abstractions within the language. The major thing
that's needed is a nice way to reify the language syntax into
a data structure and back. For example, a quoting/backquoting
mechanism inside of which the usual language syntax would
be considered as defining a data structure. This would have
to be complemented with other mechanisms like determining
context (a function that takes a fragment in language syntax
and returns its free identifiers).

The main advantage of this mechanism would be convenience.
It would not increase expressiveness since the language is
already higher-order.

Flow Java: Declarative Concurrency for Java. Frej Drejhammar, Christian Schulte, Per Brand and Seif Haridi. To appear in the proceedings of the Nineteenth International Conference on Logic Programming, 2003.

Logic variables pioneered by (concurrent) logic and concurrent constraint programming are powerful mechanisms for automatically synchronizing concurrent computations. They support a declarative model of concurrency that avoids explicitly suspending and resuming computations. This paper presents Flow Java which conservatively
extends Java with single assignment variables and futures as variants
of logic variables.

Related to the discussion going on about easy distributed programming and concurrency.

B. Stroustrup. Serving the C++ Community. Foreword to the published version of the C++ Standard (ISO/IEC 14882:2002). Wiley 2003. ISBN 0 470 84674-7.

A language designer's manifesto, plus some comments on language standardization.

Tasty bits:

In retrospect,the committee's role as an open forum and as a focus of the C++ community was at least as important as the final standard.

A standard is just a heap of paper (or a bag of bits) until someone takes it seriously enough to provide
implementations that approximates it as closely as can be done given real-world constraints.

Library development has always been one of the most vital driving forces of C++. One of my earliest principles for C++ was to prefer facilities that ease or enable library building over facilities that merely solve specific problems.

The most successful additions to C++ were developed outside the committee and appeared as well-developed
ideas combining features and a philosophy of use.

Improve the support for generic programming...

Compatibility with the current
C++standard,improvements in the degree of static type safety,and adherence to the zero-overhead principle
("what you don’t explicitly ask for,you don't pay for")are considered very important.

GENETICA is a computer language integrated in a programming environment that includes an evolutionary computational system. The computational system evolves data generation scenarios occurring during different executions of a GENETICA program, with respect to either optimization or confirmation goals formulated in the program.

This site presents a prototype version of GENETICA's programming environment which can be downloaded, documentation, tutorials as well as applications presented as case studies. A large scale application, included in the presentation, concerns the development in GENETICA of a novel architectural design language named G-CAD. Results of a G-CAD application are also presented.
Posted to general by Patrick Logan on 10/18/03; 8:08:34 AM

Yukihiro Matsumoto, the creator of the Ruby programming language, talks with Bill Venners about Ruby's design philosophy, including design imperfection, the danger of orthogonality, and the importance of the human in computer endeavors.

Rather than discussing Ruby features in particular, Yukihiro Matsumoto explains the principles that guided him in the design of Ruby. Interestingly OO is never mentioned (perhaps it's taken for granted).

An interesting quote:

Yukihiro Matsumoto: Language designers want to design the perfect language. They want to be able to say, "My language is perfect. It can do everything." But it's just plain impossible to design a perfect language, because there are two ways to look at a language. One way is by looking at what can be done with that language. The other is by looking at how we feel using that language-how we feel while programming.

Because of the Turing completeness theory, everything one Turing-complete language can do can theoretically be done by another Turing-complete language, but at a different cost. ...

Instead of emphasizing the what, I want to emphasize the how part: how we feel while programming. That's Ruby's main difference from other language designs. I emphasize the feeling, in particular, how I feel using Ruby. I didn't work hard to make Ruby perfect for everyone, because you feel differently from me. No language can be perfect for everyone. I tried to make Ruby perfect for me, but maybe it's not perfect for you. The perfect language for Guido van Rossum is probably Python.

and also:

Yukihiro Matsumoto: Ruby inherited the Perl philosophy of having more than one way to do the same thing. I inherited that philosophy from Larry Wall, who is my hero actually.Posted to general by Dan Shappir on 10/15/03; 1:52:23 PM

This symposium will feature
Dr. John Hennessy, president of Stanford University and a Kieburtz PhD student, as well as presentations on education and research from other students and colleagues of Professor Kieburtz.

Also Paul Hudak, Simon Peyton-Jones, etc. Maybe some LtU readers who attend would like to meet for a dinner afterwards.Posted to general by Patrick Logan on 10/7/03; 1:27:12 PM

One of the books I read while on vacation is The Salmon of Doubt, a collection of short pieces culled from the archives of the late Douglas Adams. The pieces are of uneven quality, but there are some amusing stories and articles sure to delight Adams fans.

This article may interest LtU readers interested in end-user programming:

I know it's unfashionable to say this, because a lot of people feel that HyperCard simply isn't powerful enough to do useful work in. It is, after all, a first stab at an idea that's in its infancy. The list of things you can't do with it is almost as long as the list of macros in Nisus (what are all those things? The very act of pulling down the macros menu causes lights to dim all over North London) but it's a sensationally good idea, and I would dearly love to see something like it become the whole working environment for the Mac. You want the number crunching power of Excel? paste it in. You want animation? paste in Director. You don't like the way Director works? (you must be mad. It's brilliant) paste in the bits you like of any other animation tools you find lying about.

It has been a while since we last discussed end-user programming, and I still remember the wide variety of views on the subject. It is interesting to read what Adams had to say, seeing as he was an end-user, albeit one addicted to technology.

The underlying technical view presented in this article (If it's properly written in object oriented code it should be as easy as writing HyperTalk) is, of course, simplsitic. However, it is not completely out of sync with the way things did in fact evovle. Just think of scripting Microsoft products using what I like to call "the object-model as API approach."

We should also perhaps go one more step and complete a full circle: Scripting using object-models exposed to Javascript/VBScript requires linguistic insight in the design of the class hierarchies that would otherwise lead to the design of domain or application-specific scripting languages.

Philip Greenspun states his programming language preference, and an interesting one it is:

Common Lisp, CLOS, plus an ML-like type inferencing compiler/error checker (with some things done in a sublanguage with Haskell semantics and Lisp syntax).

There is often seen to be a conflict between "the Lisp way" and ML-like type systems. Does embedding an ML- or Haskell-like language in Lisp reconcile these differences, at least from the Lisp programmer's perspective?

Scheme is the core technology in the back-end of the NMK web site developed by LShift. This case study examines how we integrated Scheme into a commercial web development environment, and how we used unique features of Scheme to simplify and speed development.Posted to general by Patrick Logan on 9/5/03; 9:03:56 AM

Felix is new, high power programming language which provides an ML style type system with a syntax that C++ programmers should find easy to learn. It generates C++ and supports both use of C++ types as primitives, as well as embedding in existing C++ written architectures.

For creating mobile applications, scripting represents Park's secret weapon. "It sounds like an odd thing to do on small wireless devices, but I actually use a simple scripting engine," he says. "An app-specific domain language enables quick iterations on design and eases porting across devices. I worked on the scripted AI (artificial intelligence) engine on the Sims franchise at Electronic Arts, and saw how this technology enabled a profitable business model. There's no way that EA could have cranked out so many expansion packs so quickly and cheaply if it weren't for the scripting tools.Posted to general by Patrick Logan on 9/1/03; 12:39:29 PM

Jon Udell posts some thoughts about the role dynamic languages can have in improving robustness (what else) of distributed computing. Don Box's has a rejoinder.

I think programming language technologies can sure help with the robustness and integrity of distributed (and cross language) processes. Obviously, I don't think "dynamic languages" are an important part of the solution.

Indeed, some implementation technologies are related, in particular preserving type information at run time (see our previous discussions on implementing generics/templates on the CLR).

But much more important are things like proof carrying code (discussed on LtU many times), blame analysis (think behavioral contracts), and run time system abstractions. [And let's not forget TAL, which is quite relevant to the message the prompted this post.]

It's always important to keep in mind that there are things important on the language level that are not needed or are redundant on the implementation layer, and vice versa.

All that said, more capable run time engines (i.e., VMs) enable techniques and design choices that are not supported natively by contemporary hardware.

The simulator relies on a "quantum" version of McCarthy's
nondeterministic "amb" operator.

Our version, called quamb, keeps track of a complex amplitude for each
history in the quamb-tree, enabling the computation to branch into a
"quantum superposition" of computations. There is a macro called
quantum-eval, which performs the quantum mechanical sum over histories.

Quantum computation languages were discussed here several times in the past. This one looks cute.

Language purists like myself may find it unfortunate but IDEs are an important part of the "language experience." And, indeed, IDEs are often at the center of lively debates on the LtU discussion group.

In this demo Ari Bixhorn, Lead Product Manager of Visual Studio, shows some of the new features and language enhancements in Visual Basic "Whidbey," including the long-awaited "edit and continue."

This Exegesis explores the new subroutine semantics described in Apocalypse 6. Those new semantics greatly increase the power and flexibility of subroutine definitions, providing required and optional formal parameters, named and positional arguments, a new and extended operator overloading syntax, a far more sophisticated type system, multiple dispatch, compile-time macros, currying, and subroutine wrappers.

Now while this sort of article isn't about the science of programming languages, it sure is about the craft of programming language design (see our recent discussions).

Since we are a fairly young science, I think there's still good reason to look hard at what people are actually doing, even if large parts of what you find turn out to be less than useful. There are plenty of good ideas that started out by professionals who had valuable intuition.

Of course, the same argument works in the other direction: language designers are mostly amateurs, they should try to follow academic research in order to ground their work in solid theory. It's nice to see Perl discussions about named parameters, constant views of variables, currying and so on. Let's not forget that, differences aside, we are all betting for the same team!

It's gratifying to see that the very first example in this Exegesis is of a high order function...

Thought it worth noting that it's been three years (and one day) since LtU was born. Thanks Ehud for the work you've put into the site. (And they said it wouldn't last). :-)

As an aside, I've been playing with the referral logs on my own website to see how people got there. Just for grins, I ran some of the sed scripts on the LtU referral logs as well to look at what people are googling for - the results for the last 2 days can be found at LtU Search referrals.Posted to general by Chris Rathman on 7/29/03; 10:53:13 AM

Half a year ago a few bloggers made the recomendation of adding Hygienic Macros into Java as an alternative to adding language features piecemeal. We received this response from Gilad Bracha, the resident Computational Theologist at Sun.

Thanks for the suggestion. Yes, we do know what macros are, and we may have even heard of Lisp. Seriously, some formulations of macros are well structured enough to prevent the onerous kinds of abuse that have given macros a dubious reputation in the C culture.Nevertheless, we don't plan on adding a macro facility to Java any time soon. A major objection is that we do not want to encourage the development of a wide variety of user-defined macros as part of the Java culture.

Found this link on the ll list. Since I don't follow that list regularly, it would great if the LtU editors that do, inform us when something relevant comes up.

I'd like to submit one more summary of USENIX2003 talks: a
logical file system. It my opinion, it was the best, the most
innovative USENIX talk. Although the subject matter may seem remote
from programming languages proper, that talk touches on several points
that have been discussed on LtU:

SQL and database access languages in general. The talk shows
how to access what is essentially a relational database using a query
language based on propositional logic. Although the label
'propositional logic' seems intimidating, the query language is
actually quite natural -- even more natural than the familiar
"cd/ls". Of a particular importance is the ability to formulate a
query incrementally, to refine it -- what the paper calls integration
of query and navigation.

The paper demonstrates how to automatically group the
results of a query in meaningful and the most general categories, so
as to avoid overwhelming the user.

the view that a hierarchy is deficient in organizing and
using large collections. OOP programmers come to understand this fact:
thus we have AOP. The logic file system shows a different approach,
which might be suitable in large software projects.

The author of the paper is currently working on "views" of a
file (which the summary mentions at the end). For example, we can view
and edit a sample of sections from a document file as if it were a
separate document. This relates to a recent LtU discussion of "one file per
class". The views provided by the file system show a different
solution to the problem (other than the hidden types).

Finally. The summary states that the system was written in a
special language -- improved Perl -- which is then translated into
regular Perl. I guess that makes the paper directly relevant to LtU.

In general, the notion of scoping is common to both file
systems and programming language's variables. The talk shows that we
might view the variable scoping in a more general way: as a logical
formula.
I must also state that embedding a Prolog interpreter into a
file system and viewing file paths as logical formulas are very
insightful and inspiring. Cheers, Oleg

Yukihiro Matsumoto gave a presentation at OSCON in which he discusses the influence of languages on thought, productivity and stress:

Principle of Human Interface
Languages can be viewed as interface. The important guidelines for good interface are:

Consistency

Flexibility

Succinctness

Stumbled across this one while reading the Slashdot comments on Larry Wall's latest State of the Onion screed. (Can't say that I ever get much out of the Onion addresses but some people seem to believe they are fecund).

Perl 6 has a unique set of influences. It has deep roots in Unix and the children of Unix, which gives it a strong emphasis on utility and practicality. It's grounded in the academic pursuits of computer science and software engineering, which gives it a desire to solve problems the right way, not just the most expedient way. It's heavily steeped in the traditions of linguistics and anthropology, which gives it the goal of comfortable adaptation to human use. These influences and others like them define the shape of Perl and what it will become.

I am sure people here will find a lot things in this piece to be worth arguing about ...

Oracle, Macromedia, Zend and Sun began the effort on May 19 by forming a group within Sun's Java Community Process (JCP) standardization program. On June 9, the JCP's Executive Committee gave the group approval to begin work on an official Java standard, called Java Specification Request 223.

To quote the JSR:

This specification will introduce the basic technical background to bridge the scripting and the Java community. The specification is concerned with how to write and package Java classes that will be accessible from different scripting engines. The Java classes may be part of a Servlet application or may be in a standard Java VM.