Lambda the Ultimate

And _everytime_ someone tries to proove how useful and powerful Lisp is, they quote this Orbitz example. I start to think that there are no others ;-)

bye -funzel

Can you be more specific as to where you think Python (for example) has surpassed Lisp? Aside from OOP, of course.

bye

-funzel

Bedide OOP ? I would say OOP is useful in some circumstances. To my point of view, modelling business entities and dealing with gui etc. is easier in OO (as is building frameworks). Expressing algorithms and business logik is easier in functional languages. This is imho the foundation of object-functional languages. The author thinks functional is the only thing you need.

Where did Java (for example) surpass Lisp ? I think beside the business logik you have to do a lot of other stuff like persistence, GUI, fulltext search, etc. And Java has a lot of great libraries and - not as a language but an enviroment - Java surpassed lisp (although I must admit that I'm no expert and this is as I see it).

You state a high level opinion. You do not provide any concretes to support your claim. And at the end you say that you are not an expert. It will be much harded for you and interesting for me if you learn more about a subject, become an expert, do research and state your opinions based on concrete evidence and not on negation of other person work.

Regards, Dimitry

There were some problems, but they were related more to the design of J2EE than the language - a design error, imho, but one that's understandable within the culture of Java, which doesn't rate dynamic code very highly. In other words, it is more a cultural than a language issue.

Having said that, my code is a long way from accepting generic snippets of Java code. But to be honest, I prefer it that way - I'd be terrified of the client breaking things...

Believe me - in a market like that, with that level of programmer ability, you want static typing and interfaces, just so that you can sleep at night (and this is to build a team of two people with Java - how is the difficulty of finding 10 Lisp programmers a red herring?!)

This connects back to my previous comment about not wanting to give the client the ability to break things. Graham was dealing with exceptional code and exception people in an exceptional market. Formula 1 racing cars are pretty damn spiffy, but I hate to think what it would be like trying to drive aroud Santiago if everyone owned one...

Maybe you can be more productive with Lisp (I don't have enough experience with Lisp, but I am certainly more productive in ML than Java), but I suspect the libraries more than compensate. J2EE must do 90% of what Yahoo Store does (how many Lisp implementations support distributed code? It's in J2EE). I only have to add 10%. And those libraries didn't appear for free - they're the direct result of all that campaigning and marketing and all the rest of the necessary crap that Graham so disdains.

If this is a bit of a rant then it's because Graham seems so naieve. It's like reading a left wing rant (one commodity that is widely available here) about how the world could be a nicer place if only people understood that noone is really greedy.

(And why on earth does he think Python is closer to Lisp than Perl? If anything, Python is Scheme to Perl's Common Lisp.)

you seem to be an expert. Could you please tell me how to become one ? I studied CS, I studied philosophy and medicine, I programmed for 20 years and do a lot of zen - but have not reached your deep level of understanding. I fear, if only real experts talk, there would only be silence.

To come back to a discussion, I did not make any claims but expressed my opinions, which were that object-functional programming is useful and that support infrastructure is more easily written in OO and business logik and algorithmic parts are better written in a functional style.

An simple example might be:

tax | income>30 = 10

tax | income>50 = 20

is more readable to me than

int tax = 0;

if (income>30) {

tax = 10;

} else if (income>50) {

tax = 20;

}

(which is, I know, not OO but the way most people do business rules in OO languages, when they don't use rule engines. I write my java rules in jython or jruby).

I also rewrote a IP traffic billing solution for a big ISP from OO to func which was much shorter and easier to understand afterwards.

This is based on my experience and it's hard to support this with hard facts. The last time I worked with lisp, it was quite diffcult to talk to a database or write GUIs that users like.

I did some research in the Lisp community and could only find this Yahoo and the Orbitz example. So if you have others, some with user interaction prefered, you could tell me about them. I'm always open to change to a better language that suits my problems better.

And I find it interesting that people claim 10x productivity gains from C to Java (the Java people) and 10x from C to Lisp (the Lisp people) and 10x from Java to Lisp (the Lisp people). This could not be true, I think.

I couldn't find any arguments in your post beside "shut up" and so I would like to hear some concrete evidence that (whatever-your-argument-might-be) is true.

Yours, sincerly,

-stephan

A second issue is the choice of paradigm. For sure, OOP is a popular paradigm for business apps. But CLOS was the first standardized OOP language - beating C++ standardization efforts by a dozen years. In many ways (reflection, multimethods, etc), CLOS outshines Java and C++ in terms of Object Oriented programming. The author may feel that the functional paradigm is superior, for any number of issues, but the beauty of Lisp is it's adaptibility. Lisp can be used for practically any paradigm: past, present or future. It's why many academics prefer the language - it will never become outdated; it is excellent for exploring new computing concepts, the syntax can be learned in a matter of hours, etc...

As for myself, I'd probably be a Lisp bigot myself if Moore's law would have been a bit more steep. I looked into using Lisp for embedded systems back in the mid-80's and although I liked the language and environment, the hardware just couldn't be coaxed into responsive behavior. Funny thing is, though, that the modern day virtual machines (JVM and CLI) are much less efficient than those Lisp machines of the '80s. But then the vast majority of embedded apps are still using C or C++.

The aesthic value and power of lisp ist not to be critizied. I think the same. But I object to your

"It's why many academics prefer the language - it will never become outdated; it is excellent for exploring new computing concepts, the syntax can be learned in a matter of hours, etc..."

I think academics use Lisp because they have not to deal with real users, with real legacy systems and real performance issues. They have all the time they want, they have no deadlines. If this constraints come into play, pureness and power of a language is not all that makes a language balanced and useful. Libraries and tools are also needed.

I have done quite a lot of J2EE stuff and mostly don't like it. There are better GUI libs and there are better persistence tools, but the power of J2EE is that it's a standard. There are more than 10 usable J2EE products with different characteristics. And that's useful, at least to me. I can easily switch to another vendor, if my current vendor doesn't keep pace with others. And if you don't like J2EE, then just use Webobjects or Struts or Bebop or Tapestry or Velocity for the Web GUI and JDO or Castor or .... for the persistence.

I took a fast look at sourceforge. There are 5 pages of Lisp projects and I stopped counting after 50 pages of Java projects.

The Nice author seems to be a nice guy and I hope he adds more functional functionality (continuations, abbrevations for list handling , macros etc.) to Nice. Then I have a powerful language (I also think a good way in the future are DSLs) and the libraries and support from Java.

This practice is not only common, but institutionalized. For example, in the OO world you hear a good deal about "patterns". I wonder if these patterns are not sometimes evidence of case (c), the human compiler, at work. When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I'm using abstractions that aren't powerful enough-- often that I'm generating by hand the expansions of some macro that I need to write.

I think there is some truth in this.

I'm also worried about the hype (well, the hype is maybe a little bit over) surrounding design-patterns. In fact you find yourself implementing the same pattern over and over again. If you decide the Singleton pattern can be implemented in a better way, you have to change all your Singleton pattern uses. There must be a better solution...

there is a better solition. Or partly better. In Ruby you can include a observer or singeleton mixin into your class (you still have to code against the singleton api, but you can change the singleton mixin later).

And the paragraph tells me, that the author misses a crucial point about the purpose of patterns. What I always liked about patterns was their name. Yes, you can add :after to something to avoid an OO pattern. But you have to tell people what you did. With a pattern you just have to say: I used obeserver there and singleton over here, and everyone understands your design at once.

I quite like the idea of mining patterns for lanaguage features, and cited a few papers that discuss this approach.

I think no one wants to dispute the importance of libraries. The real debate concerns two issues: (1) what's the right balance between library and language size (e.g., I think it was Frank that argued here that everything lacking in Scheme can easily be provided by libraries) (2) how language features influence library design.

I think the second issue is quite important, and many tend not to realize just how fundamental it is.

Notice that this is a question of language expressiveness: some languages make some libraries hard to write.

A simple example is memory management. Language that don't proivde destructors, nor garbage collection, make it hard to write libraries that protect the programmer from memory leaks.

Now, it turns out that many language have problems like this (most of them, of course, much more subtle). The real objection I have to OOP is that I think it doesn't solve many important problems with library design. Mixins help, but are not enough.

Recent discussions here about AOP (aspect oriented programming) and multi-methods give good examples. Not to mention the discussion of lazy evlauation and DSLs.

I think the best way to learn about these issues is to try to design a good library, for a domain you are interested in. Simply measure the level of frustration you feel.

Are those writing about academics checking the academic journals?

Seriously, though, the academic world is as varied as the business world. Everything from teaching programming as a trade skill, to teaching the philosophy of computer science in an almost liberal arts sense (and all points in between). I'd speculate that Java is popular in the academic community for the same reason that it's popular in the business world - it's where the money and action are (at least at this point in time).

Still, I can't help but think that the pliability of Lisp makes it an excellent teaching language. Whether it will ever become as popular (in the sense of $$$), I don't know. Popularity is not always a function of technical merit. But one can hope that lessons learned can be applied to future development. After all, Java, Python, and Ruby were not built in isolation - containing the seeds of such dead languages as Algol and Simula.

I don't really want to go into that debate all over again, let me just say that the more I look at Java textbooks the more I prefer starting with Scheme (perhaps even Haskell). But this is really another debate.

On the usage of Java in academic papers: I read quite a lot of them and really a lot of papers that use code examples in an OO language, are using Java. Partly this might be because of the hype, but I think academics also appreciate the clearness of the language and the relative small number of constructions compared to for example C++ or C#. Besides this, academics also appreciate the platform independence of the Java Platform because of the greater diversity of processor architectures and operating systems at universities (at least in my country).

There is - macros. Paul Graham is right about the power of Lisp. He's not so clued up about why it is and isn't a success.

Why wouldn't I use some sort of Counter object, or even just a plain variable?

As an aside: And the use of these special, reserved field names, especially __call__, seems a bit of a hack.

I suppose that coming from a language that has a single nice way to represent functions with no need for special (infix) operators, any sort of operator-overloading thing seems like a hack.

the design of a language influences the libraries heavily. On a recent discussion on the ruby mailing list about which on is more OO, python or ruby (which is a mood point), some people argued python has now the same features as ruby, so they are the same. Some others argued, that although pyhton now has continuations etc., this is not reflected in the libraries. Whereas in Ruby libraries tend to use code blocks and continuations etc. a lot.

The discussion then went into why a common VM for perl, python and ruby (parrot) may be nice, but the libraries may be of limited use, because they reflect their language. Using Python libraries from Ruby may feel akward. Alhough I like the idea of a common VM, I have the same objections about .NET. Using e.g. .NET from Eiffel may feel strange, because the .NET libs don't reflect the power and style of Eiffel (Dbc, etc.).

Things are subtle enough when working in a single language..

There are certain types of applications that are `solved' and for these applications the mainstream methods often have an advantage due to their large libraries. The old `front-end to a database' web sites is such an application. For the rest (i.e. the interesting applications :-) there are big wins to be made using unconventional technology.

Getting back to the recruitment problem, a believe in Andrew had been advertising for a Lisp hacker he would have had different results. He might only have had one response but I bet it would have been a good one!

I would like to think of me as a good programmer. But how to decide? Just holding the strong opinion doesn't cut it.

Are you in academia? When I moved from academia to industry I was amazed at the increased range (downwards) of abilities. This is just my limited experience, and I don't want to embarass myself by trying to explain it, but from what I've seen industry is much more tolerant of people who are "just good enough". Just reading this group ups the odds significantly on you being a decent programmer by (my) industry standards.

There's also the trade-off between ability and experience, which is kind-of related to advertising for a Lisp programmer. I did, in fact, turn down someone who was smart but knew no Java. This is the first time I've had to choose an employee and it's likely I screwed up. On the other hand, the person we now have, who I've done something of a dis-service to in the name of rhetoric, is improving rapidly. And they have to contend with someone who's learning how to be a "boss" in a new culture and a new language...

(I wondered about posting all this, but I think it is relevant when we're looking at people like Paul Graham making claims about industry that just don't fit with what I, at least, have seen).

PS Re "held back". Held back how? From making more money for my employer? When I work for myself, I use whatever language I choose. When I work for someone else, they call the shots, but they also pay the bills. If they choose the language then the results are their responsibility.

Now if I needed something to be done ASAP (which means my project was mismanaged up until now) I'd hire someone with as many of the specific skills I need.

If I have a bit more flexibility I'd go for the better programmer, and let him pick up the skill needed (and try to learn from him all the things he knows and I don't).

The are two types of management: task oriented and people oriented.

My experience with software projects is that managing people is more important. In the (relatively small) projects I managed I tried to think of myself as coach/leader/educator and not a project manager. The projects were ready on time, and worked well.

I've seen more task oriented managers produce late software, that simply didn't meet requirements (didn't scale, wasn't robust enough etc.)

But this really isn't a language issue: most of these software was done in ASM/370.

This was the case. But (and I suspect this might be a general point) I underestimated the amount of learning necessary to get up to speed on the project. Compared to understanding the design and J2EE, learning Java itself - given a knowledge of other languages - is pretty insignificant.

Thanks for the general advice. I´ve tried to avoid the mistakes of people who've managed me, but it's harder to emulate their good points, because I never consciously thought about them....

On a more general language point - to what extent do Lisp projects have detailed designs? In Java interfaces are a useful half-way house between code and design (DbC would be even better). I can say to someone "implement this interface" and they don´t have to understand the rest of the code (that much). If I was working with Lisp, what would the equivalent be?

As to Java, one of the things I complained about in my little Goo/Eclipse write-up was how difficult it was to add new features into the existing framework without having to "reuse via copy-and-paste" large amounts of boilerplate code.

Now, you could argue that this just indicates a flaw in the design of the APIs. But I think a more fundamental problem with the object-oriented design paradigm is that in many cases the protection levels for object access may become so fine-grained and convoluted that extension becomes nearly impossible.

The best analogy I can come up with is that we end up with a system in which little object fiefdoms (that are highly protective of their internal data) don't work together effectively because they are too busy conflicting over who owns which resources. Someone either has to come in and modify the protection levels, or break up the objects into finer pieces that can be used more effectively (refactoring). This is an effective solution when you have control over the base code, but does not work at all if you are using a closed vendor library.

As I become more educated in functional programming, and Lisp-ish languages, I find myself become more conviced that OO design does not effectively deal with large categories of problems. One nice thing about Lisp is that you can mix-and-match your development efforts using OO concepts where useful, functional where useful, etc.

Nice seems like a useful extension to Java that supports this "paradigm-agnostic" approach. But you still don't have macros...

I couldn't resist. After all the words here is a bit of code. First the accumulator code in JavaScript:

function foo(n) {
    return function(i) { return n += i; }
};

So you do have a return statement but otherwise pretty close.

Here the C++ implementation I came up with:

template<class T>
class bar {
    T n_;
    bar(T n) : n_(n) {}
public:
    T operator()(T i) {
        return n_ += i;
    }
    friend bar foo(T n) {
        return n;
    }
};

Certainly not as short (man I miss closures when programming in C++), but at least not limited to integers.

Usage example:

bar<int> x = foo(1);
std::cout << x(2) << x(3) << std::endl;

I couldn't resist. After all the words here is a bit of code. First the accumulator code in JavaScript:

foo: n

^[:i | n+i].

Why is it so important that a function that adds 1 to another value work for cabbages as well as integers? That sounds like a recipe for having code that, with some obscure combination of inputs, tries to treat a vegetable as a number. Isn't it better to have explicit control of what can be added to, and what not?

This isn´t an argument for OO, but for some formal system of types - something that really wasn't understood when Lisp was developed. In fact, we still don't have a perfect solution to the problem, so the big question, it seems to me, is at what point do you acknowledge that an imperfect but advanced tool is better than no advance at all?

The only place I can see where Paul Graham addresses this is when he bashes C++/Java, but those are hardly languages with the best support for this kind of thing. If he wants to make the point that Lisp is better than the best languages that exist today, shouldn´t he be looking at other languages with a strong theoretical basis, like Haskell (or maybe ML)?

Instead, he chooses Python and Perl which are both dynamically typed. That makes for a flattering comparison with Lisp, but the vast majority of big programs are not written in these languages precisely because everyone recognises the engineering problems associated with such a typing system...

(I know, all old points, but someone has to say them)

Not many (any?) programming startups have been efficient as Viaweb. Can anyone name another company with 3 programmers and a bunch of people answering the phone that created $50 million worth of value? I can't. Why is that? Is it just luck (indeed that is a part) or is there something more?

To put it briefly: why is a top lawyer's hourly fee (in excess of £300ph here in the UK) so much higher than a top programmer's (about £125ph here)? Is it because law is intrinsically worth more than software (in which case explain Microsoft) or is it because lawyers are more efficient producers of value?

Does this seem like it would be useful, or am I going to meet too many cases where I can't say anything useful because the feature is part of a more general language based idea that's difficult to separate from Lisp "as a whole".

It would be nice to end up, for example, with statements like "about 10% of the functionality in Lisp requires dynamic typing; this (includes important|is mainly little used) functions like...". But I'm worried that the whole approach is so naieve that it's pointless.

[I think lawyers are paid more because they produce more; high value programs are normally the work of many programmers over the long term, but lawyers are more clearly visible as separate enteties - they can be assessed individually more easily and work on more projects. The obvious counterexample to Viaweb is Microsoft - it got where it is today using C or assembler (I presume) and also, in my limited experience of startups, being lucky is hugely important.]

21 employees. Sold to Yahoo for $49 million ($2.3 million per head). Yahoo later bought eGroups (python users) for $432 million (about $3 million per head, iirc). Microsoft bought Cooper & Peters (smalltalk, java) for about $20 million ($10 million per head). Verisign bought Thawte (python) for $575 million ($11 million per head). And so on.

I can't

Where were you hiding during the dot-com era? ;-)

It acutely analyses the balancing act that is the on-going evolution of Python as an object-functional language with a remarkably wide set of users.