Lambda the Ultimate

Without wishing to cause a flame war, ..., well actually I do wish to start a discussion ...:)

For the last 25 years I have been working on programming languages roughly in the logic programming/functional programming paradigms.

About 10 years ago I embarked on a research trajectory involving moving from Prolog's 'meta-order' approach to a higher-order approach.

The reasons were technical: meta-order sucks from a software engineering POV.

However, recently, I have changed my mind. Or rather, changed direction.

While robust, HO does not deal with OO programming all that well. (Start flame wars here)

The reason is that OO involves combinations that are difficult for HO styles of programming.

On the other hand, OO does nearly everything that HO can do. I would argue, that at a slight loss of elegance, OO does *everything* that a good software engineer wants to do.

My reasoning is based on the fact that an object can act as a kind of closure but a closure cannot capture the multiple uses of an object - together with the interface contract.

BTW, as far as I am concerned, OO is *not* equivalent to inheritance+subtypes+methods+classes+instances. Those are techniques useful in some situations.

For me, OO is fundamentally about encapsulation and interfaces. The rest is noise (in my opinion of course)

So, in my most recent work, I am throwing out my HO implementations and replacing them with an Object Order implementation....

Comments?

Nonsense generates random (and sometimes humorous) text from datafiles and templates using a very simple, recursive grammar. It's like having a million monkeys sitting in front of a million typewriters, without having to feed or clean up after them.

The demo pages are quite nice. I liked the randomly generated laws. The Slashdot imitation is sure to please.

ZigZag has been mentioned on LtU only in passing. I think it merits a story, although no personal opinion is implied.

I have always tended to disagree, but there is more and more to disagree with as the computer field gets worse and worse.

The world is unanimous about "computer basics" and "computer literacy". They tell beginners: computers are built around hierarchical directories, word processing, the Desktop, databases, the one-way links of World Wide Web.

Lies. All lies.

These things are, of course, the present reality. But they are no more true and natural than hamburger being the true and natural form of cows, or Central Park being the true and natural form of uptown Manhattan.

The ZigZag tutorial descibes the idea this way:

The ZigZag system is very hard to explain, especially since it resembles nothing else in the computer field that we know of, except perhaps a spreadsheet cut into strips and glued into loops.

It is a PRINCIPLED SYSTEM OF INTERCONNECTION.

Lists and Spreadsheets are rational ways of connecting things, but they have shortcomings. Hierarchical directories are a standard way of connecting things, but they have extreme shortcomings.

The ZigZag structure...is extremely simple but has remarkable properties.

The ever-enticing search for the ideal programming language produced this 1997 article from Sergey Polak. Although somewhat dated, I liked the article's comments about strings:

The discussion of arrays also brings to mind the subject of strings. No matter what anyone says, it is my firm belief that any language, regardless of its purpose, must have a powerful and flexible string-handling facility built-in. A program is very rare if it has no need for string handling, and I myself have had to write a great deal of programs, both at work and for my own uses, that depended heavily on strings. Some languages put strings in as an afterthought, and others put in some very basic features and leave the rest to library routines. That just can not be. The text string is a fundamentally important data type and can not be ignored, nor can it be relegated to blatant impersonation by some other type, such as array of characters. A string data type is required in a good language.

The very popular language C, and C++ as well, have horrendous string-handling facilities. Not only is the programmer required to declare his strings as character arrays, but there simply is no way to deal with strings as entities in the language.

Ouch. So true. That is not to endorse the specific string implementation recommendation from the article. (I have previously commented about implementation ideas, including communication buffers.)

Do the man a favor and save the article to disk for offline reading so as to minimize his bandwidth hits.

P.S. You're welcome, Ehud. I'll now be Internet-disabled for a week.

Yet another example of language design in action. The specific issues Guido is concerned about are perhaps of less importance than this concluding remark,

A warning: some people have shown examples of extreme uses of decorators. I've seen decorators proposed for argument and return type annotations, and even one that used a decorator to create an object that did a regular expression substitution. Those uses are cute, but I recommend being conservative when deciding between using a decorator or some other approach, especially in code that will see a large audience (like 3rd party library packages). Using decorators for type annotations in particular looks tedious, and this particular application is so important that I expect Python 3000 will have optional type declarations integrated into the argument list.

The Schematics Scheme Cookbook is a collaborative effort to produce practical documentation for using the Scheme language, particularly in commercial environments. It is focused on PLT Scheme, although other Scheme dialects are supported as far as possible.

A nice attempt by several of lambda's friends to provide practical help for people trying to solve real problems using Scheme.

I think the community around any non-mainstream language must encourage and support such efforts for the language to have any chance of gaining momentum.

This is somewhat related to our discussion of real life programming using Haskell, and about the success of so-called scripting languages.

I must admit that I use Python for my scripting work. Tried to use Scheme but it was too much of a bother. Guess it's time to try again.