Lambda the Ultimate

If lambda is the ultimate what is next beyond the death of god?

FPs are not impractical but they are equipped with a particular mindset. Haskell is just a showcase of this mindest like Phil Wadler pointed out in his very beautiful introductory essay about monads where he motivated monads in Haskell by mentioning the cartesian split between res extensa and res cogitans. In Descartes philosophy the inner world is the world of reason and certainty while the outer world is that of matter, chance and deception. The pineal gland was the interface capable to relate one to the other. The Nietzeschean perspective is simply the opposite: there is no such split but the interior world of reason is itself an illusion. More than this it is a perverted attempt to empower the mind over the body the idea over the thing the abstract over the real. A contemporary german philosopher ( F.Kittler ) once provoked his readers alleging that there "is no software" at all. He went thus far recommending programming assembly because it is closest to the real ( just a few of my colleagues would support him but they will hardly accept a language abstracting more far from the machine than C does - they want to read assembly if they need it ).

Thus the real is not a residual a shining glance of a superiour world of eternal forms but the latter is a secondary illusion a simulacrum in the realm of eternal change.

Of course I don't try to answer the question whether the tragic-heroic programmer uses Ruby ;) This labeling transgresses the self-styled body-mind into direction of commodities where he ends up as a farce.

Kay

Were statically typed and supported arbitrary syntax extensions (not requiring the obligatory parens), then I would probably agree that Lisp is more or less the best language out there. I think it truly was ahead of its time (though time is catching up quickly!).

The best programing language is a lisp dialect. ..is probably what many people mean then they say that lisp is the best programing language. And i don't think thats so strange. what features of lisp do you not want in your language? shoulden't the best language be able to do everything?

Obviously Graham isn't thinking that the current dialects of lisp is the best it can be. Why else whould he be developing his own?

...just the claim (where it occurs) that it represents the apogee of computer science--for now and forever into the future.

While there may be an asymtopic limit that we may approach (but never equal or exceed), I've no idea where it is. I highly suspect we have a long way to go.

For one, I don't want the fact that O(1)-access arrays are not implementable in native Lisp.

Talk about brain-dead...

Vectors are part of the standard Scheme.
http://www-swiss.ai.mit.edu/~jaffer/r5rs_8.html#SEC63

There is no way to express O(1)-access arrays in Scheme without dropping down to some other language.

If vectors are part of the standard language they are so "native" as lists.

Would that be 486 machine code? Or maybe hyperthreaded machine code? Or maybe distributed heterogenous cluster machine code?

There's no such thing as simply "machine code". There are, however, different computational models; and it is the job of the compiler to convert between two of these computational models.

If you need a third language to act as an intermediary for doing elementary operations, there are obvious problems in your design.

* Vectors are part of the Common Lisp standard; other Lisp dialects as well. Which makes them part of the language. You seem to have this notion that any data structure which cannot be mapped onto conses is somehow "foreign" to Lisp--Lisp has had data structures other than conses/lists for DECADES.

* Many compilers for Lisp directly translate between Lisp source and the instruction set for whatever architecture you like (whether a physical CPU, a virtual machine instruction set, etc.) without resorting to any intermediate languages.

While lots of compilers for prototype languages will target things like C, C--, LLVM, CLR, or JVM rather than targeting any particular machine instruction set--that doesn't mean that the language is defined in terms of that compiler's target.

If Lisp is really the best we'll ever do (or Smalltalk, or Haskell for that matter), we might as well shut this site down, as we're all spinning our wheels.

Well, no one likes a smug lisp weenie. And you can imagine superior languages to Common Lisp or Scheme. For example, there's something very 2D about using lists in structuring code; maybe you could win something by using a more sophisticated object. (And incidentally for those curious, Lisp code isn't represented ONLY as lists; in any given s-expression, you might find many different kinds of objects.)



Further, being "a Lisp" is not mutually exclusive with being another language too. This notion is no harder than the concept of multiple inheritance. ;) So for example, manipulation of things at read/syntax/compile times can be merged with concepts from other languages.



But while I don't believe in some "best" language, I'd certainly want one informed by Common Lisp, as well as every other relevant idea. As my personal preference.

Agreed. However, the definition of a "Lisp" seems to vary based on the context and the author. One extreme position has it that Common Lisp is the only language that has the right to the name (based on the claim that the ANSI standardization of Common Lisp served to unite the community behind a single flavor of the language), and that other dialects of Lisp (other than legacy applications like elisp in Emacs) are imposters. This accusation is often levelled at Scheme.

Others seem to define a Lisp is any language significantly influenced by its design. Dylan is certainly a Lisp under this definition (even though the syntax is far more Algol-like), perhaps Cecil as well. A middle definition is any language which uses sexprs for syntax and has conses as a fundamental data structure.

Designers of new languages have a duty to be familiar with a wide variety of existing ones--both good and bad. And CL should certainly be on the list.

My feeling on monads is that they are a desperate tool of the FP community to retain more purity than is really necessary. They may have theoretical value, but the fact that you can't sit down and explain monads to someone in 5 minutes if they don't already have a pretty deep understanding of FP tells me that there is something wrong. There must be a better way.

Also, by saying 'desperate', you are implying that even the people who discovered and/or used them are not happy with them. How do you know that ?

I didn't understand monads in five minutes, but I think every minute I spent trying to learn was well spent. My expectations are the opposite of yours: the better the concept, the longer it takes to master (just by itself or by way of its prerequisites).

I don't know enough about monads, but I think I agree. I have no issue with learning something hard if it is powerful. The only issue I see as unfortunate is that difficult concepts can serve as a barrier to adoption, which means a barrier to rich development around a language that can be nice for its users. It pays to have some mindshare and community support. If there were a killer web framework written in Haskell you can bet I'd be pouring over monads right now. Instead they're on the back-burner. I have to balance my curiousity about languages with my desire to be creative and supported in the languages I use.

I think truly great concepts have both depth and breadth. And by that I mean that you can be introduced to the concept through a simple canonical example, but get returns on it through subtleties of the mechanism. For instance, I happen to think that the Iterator is perhaps the most important concept in imperative programming. It's about as close to a universal concept as map/fold/filter, etc. Any novice programmer can look at a simple instance of an iterator and more or less instantly see how it works, if not fully appreciate its value. And on higher levels of abstraction, iterators can perform a bewildering variety of operations that make their usefulness quite powerful, even though the novice would not think of them all right away.

On the other hand, there is no killer canonical example of a monad that programmers universally recognize as justifying their existence. Everyone has a different starting example, probably because they are not entirely satisfied with the other ones they have encountered.

And perhaps the problem is that *nobody* really understands what a monad is. After all, Richard Feynman reportedly said something to the effect that if you can't explain something to a five year old, you don't know what you're talking about. Granted, you aren't going to be able to explain the subtleties of QM to most five year olds no matter how many Nobel Physics prizes you have won, but there is a grain of truth to the saying, I believe.

As far as the existence of complicated mathematical objects goes, I agree that there are many such things that will never have a simple explanation (like most things involved with the Millenium Problems, for instance). However, I would argue that that is exactly what makes them *impractical*. Only mathematicians know and care about many of them. But monads are purportedly not just for theoreticians and academics. They are supposed to be used by the common programmer.

And when I called them a "desperate" solution, what I mean is that perhaps languages simply don't need to be as pure as Haskell to be efficient and elegant. That's also what I was implying by saying "There must be a better way". The fact is, when it comes to the dirty world of GUIs and databases, state abounds. There is no getting around it. A database is *all about state*. So I doubt very many GUI coders are going to give up simple imperative code to build their GUIs with monads. I just don't see it happening. The cost of abstraction is too high. There's not enough return on investment. Also, the dirty world of GUIs and databases happens to be a pretty good deal of the computing landscape.

Instead of finding a way to improve the interaction of stateful and functional code, theorists have made state itself a function. That's what I mean by "desperate". ;) I see the analogous situation being imperative theorists reducing functions to state tables. ;>>

When I use a monad to write imperative-style code, the result is almost /exactly/ the same as if I'd written it in a rather pleasant and capable imperative language. The almost being that I need to use return or let for pure values. The only reason monads are any harder for a user to understand than "use do, this is assignment, use return or call another computation as the last thing" is that sometimes they let you code in something rather different from yet another imperative language (List and Parser monads being fun examples).

Understanding building new monads can indeed become deep stuff, but so's anything else with that power.

All haskell apps deal with states, and people who wrote them seem to keep on going, so I'd assume that for them it's practical to do so. I am not sure where you get the impression that They [monads] are supposed to be used by the common programmer, though (and I don't mean to sound elitist).

If you're writing in haskell, you've gotta use them sooner or later. It's that or you can't write useful code because you've no IO. That said, monadic IO is pretty easy to work with once people stop scaring you.

Feynman wasn't quite that harsh it was a college freshman not a five year old. The story was that he had listened to a lecture and after leaving ran into some students and told them that he had heard something cool and started explaining it to them. He then realized he couldn't and later told a colleague that the state of I think it was QCD wasn't where it needed to be since it couldn't be explained to freshman.

Yeah, I get what you're saying about the vacuum cleaner. Writing Java for my research job, I live in eternal fear of having to refactor stateful code. Overuse of type declarations don't help to lessen the pain. Is there an inherent contradiction in the idea of an object oriented functional language? By this I mean a language that emphasises recursion and functional algorithms but passes around little stateful collections rather than values? What about a scheme whose closure property was not that everything was a procedure, but instead that everything was a collection of procedures with shared state? I guess that's what an object is in the non-CLOS-like OO languages.

There's no contradiction between object orientation and functional. Alan Kay wrote:

"Doing encapsulation right is a commitment not just to abstraction of state, but to eliminate state oriented metaphors from programming." — Alan Kay, Early History of Smaltalk.

My interpretation of that statement is that it doesn't necessarily mean that you program without state, but that manipulation of state is hidden within higher level abstractions that are manipulated in a declarative manner.

• External representation. (Syntax.)
• Internal representation. ("Parse tree".)
• Typing system.
• Computational model. ("Semantics".)

The "typing system" usually gets merged into the second or fourth layer, depending on whether you do static typing or not.

...but I just emphasized syntax because I had sort of grown to dismiss it after going from languages like Java and C++ to Scheme, because they seemed to use their syntax on ineffective approaches to problems. Why have special for loop syntax... just make the language support recursion. But with Ruby, I realized, wow, when the language doesn't rely on syntax to support non-intuitive assumptions, it can really assist my productivity. I have come to appreciate the aesthetics of programming languages more than I ever had. The regular, uniform nesting of S-expressions is almost unbeatably beautiful, but if it takes four or five lines of nesting to perform regular expression matches that I can bust out in one line in Ruby, then the pure approach begins to lose its appeal. So while I agree that syntax isn't everything, I think that syntax and its unity with deeper features can do a lot to determine one's experience. Syntax is the linguistic interface with the computer... feeling comfortable and supported by that interface is definitely a plus.

The regular, uniform nesting of S-expressions is almost unbeatably beautiful, but if it takes four or five lines of nesting to perform regular expression matches that I can bust out in one line in Ruby, then the pure approach begins to lose its appeal.

This is a syntax issue, so I guess the "purity" you mean is syntactical purity? You probably know that it's possible to define a regular expression syntax for scheme, using macros, that would allow you to write code very similar to your Ruby one-liners. I'm sure there are already Scheme libraries that do exactly that. So, is the advantage of Ruby that regex syntax comes with the core language? Maybe so, but that's a function of the objectives for what the language was designed. Ruby was designed as a scripting language, to be an alternative to both Perl and Python; so it would had to support regular expressions natively, by design. Scheme, on the other hand, was designed to be more a general-purpose language. Which one is better? Well, it depends on you goals, doesn't it?

Different languages occupy different points in the design space, as already noted. What will be better for you will depend on where you are in this space.

Is purity important? Experience seems to show that state should be minimized. I guess this is an indication that functional programming must be doing something right. Practical concerns may limit the amount of "purity" you are willing to maintain.

Actually, Bash can perform numerical operations. So some strings can be "typecast" to numeric types, if you will.

There are multiple instructors for the course, each with a really different approach. The first instructor is a statistical guy... he's having us massive amounts of newspaper text that has been "dependency parsed", meaning that all the words are linked to their syntactic governors with information regarding the relationship. So, for "John likes Mary", "John" and "Mary" would both be linked to "likes", in the subject and object relationship respectively. (Actually, they are linked to "like", which is the lemmatized form).

Using millions of words from parse trees like this, we are to build a database of features describing each word. A word's features are all the relationships it has with other words in the entire corpus of text. Using this knowledge and some statistical techniques like mutual information and clustering, we will derive sets of similar words and then eventually break words apart into word senses by relating those words that appear in similar context. It's an approach centered around Wittgenstein's idea that a word's meaning is based on its usage, on "the company it keeps".

Our instructor isn't forcing us to use any particular language, but he basically told us flat out to write it in Perl. I don't think he knows too much about less popular languages, since when I mentioned Scheme he didn't recognize it until I told him it was a dialect of Lisp, which he had only vaguely encountered. So he was more recommending Perl versus C++ or Java, mainly, I think, because he thought it would make completing the assignment easier.

In my previous free choice natural language course last spring I used Common Lisp once and then Scheme for the remainder, and I think they may have been part of the reason why I excelled. But because I want to get started with the Rails framework, I decided to use Ruby and get familiar with it... especially since learning Perl is very low on my list of priorities. If not for wanting to use Rails, I'd probably be using this as the occasion to learn O'Caml instead, because I could use the efficiency in the massive statistical processing that's required.

After reading some of the responses, I think that it's perhaps not an issue with functional languages that I have, but with overly "pure" ones. Ruby just felt so much more convenient to use than Scheme did last semester, and I think a lot of that is it's willingness to be a language for "right now" rather than a minimalist, beautiful language for the ages in which you are constantly forced to either reinvent the wheel, or adapt yourself to a particular implementation's reinvention of it. By comparison, Ruby is loaded (or cluttered) with features, but it organizes them well and manages to avoid flaws that make Java and company so obnoxious.

So maybe a good question is... what's a feature-rich functional language for which those features are well documented? Things like syntactic regular expression support are the sort I am talking about, features that make common tasks simpler. Maybe O'Caml is the answer... but I think that, so far, Ruby is much more convenient for the task at hand than Scheme would have been. It's the source of a lament I posted in another thread about yearning for a practical Scheme. For things like Essentials of Programming Languages and learning to write interpreters, for pure, perhaps academic tasks, Scheme seems unbeatable because it doesn't clutter the problem. But when I need something done, it has frustrated me, and I don't think it's because I'm not familiar enough with the language. I think it's because the language is not familiar enough with the things I need to do. That's not a knock... Scheme was never meant to be that language, and if it were, it wouldn't be Scheme and that would be sad. I guess what I want is a functional scripting language with an indulgent feature set.

I find it very hard to read this post without paragraph breaks.

Then again, if you like the long paragraph style, there's no reason to pander to lazy readers like me.

Yeah... you're right. I start off with a mind to keeping it short but run my mouth longer than I thought all too often. I edited the comment and broke it into paragraphs.

It would seem as Common Lisp is the obvious choice. It has tons of features and is as close to scheme as any established language. Is there any particular reason why you don't like it?

Amusingly enough, one of the biggest reasons I ditched it for Scheme after seeing how much cleaner it felt to use one namespace for variables and procedures. So the very reasons I now have gripes with Scheme originally brought me to it. I was also really interested in explicit continuations, which CL doesn't support. But you might be right. I learned for the first few months on Common Lisp... maybe it's time to look at it again.

Yeah, those are really nice features of Scheme. I have thought about how dificult it would be to make Common Lisp behave in the same way. I think single namespace wouldn't be so hard. Just overload defun, setf and simillar to write to both namespaces.

Continuations is more difficullt, but I wonder why nobody has made a Common Lisp implementation with them.

For one because it is impossible to say how they ought to work in the presence of unwind-protect and condition signalling.

I'm sorry but I can't see what the problem is. Especialy since I recently implimented a system with exactly those featrures. Would you care to explain? I wouldn't like my system to have any hidden inconsistencys as I supose thats wath you are talking about.

Take this piece of code for example:

(let ((r (acquire-resource)))
  (unwind-protect
    (progn
      (foo)
      (use-resource r))
    (release-resource r)))

Without continuations, FOO will either return, followed by (USE-RESOURCE R), or the stack will be unwound. Either way, the resource will be released.

With full continuations, as in Scheme, it's more complicated: FOO may return zero or more times. If FOO never returns, the resource is never released. On the other hand, if it returns more than once, (USE-RESOURCE R) will be called after (RELEASE-RESOURCE R) has been called.

Here's an example of a problematic FOO:

(define foo-continuation #f)
(define (foo)
  (call/cc (lambda (k)
             (set! foo-continuation k))))

The only way to prevent this is to ensure code inside UNWIND-PROTECT doesn't use CALL/CC, but with higher-order functions, this can be impossible.

Can't you just add a before clause (to unwind-protect) to be evaluated before you enter the protected area, and then evaluate the after clause thenever a continuation call makes the controlflow leave the protected area and evaluate the before clause, every time it jumps in to the area again?

That would at least garantee that the after clause is evaluated exactly one time after each time the before clause is evaluated and that the before clause never run twice without the after clause runnig inbetween.

That's what dynamic-wind does. It's not hard to imagine a situation where it would be worse than unwind-protect, though. (For example, iterating over the output of a Python-style generator would needlessly invoke the before and after clauses if the generator was called outside the dynamic-wind.)

Other solutions seem to put light restrictions on call/cc.

Here's a link describing the problem.