DanWeinreb

I totally agree about the families. That's way, way over the line. IANAL so I don't know whether there are actually laws being broken here, but there might be; freedom of speech in US law has exceptions for threats and putting people into harm and so on. The problem is that it may be hard to find out whom to prosecute; the name "Anonymous" is there for a reason. A lot of very bad things can be done behind a mask of anonymity, just as good things can be (c.f. Tor servers to help dissidents).

There isn't any one "self-taught programmer" who can be characterized, so a lot of these comments are claiming to be more general than I think is fair.

I have close friends who are utterly top-notch software engineers who didn't learn any of their skills in a formal educational setting. Often they have been able to learn-as-they-go. After all, these days the field is so large that nobody can be an expert at everything. And we often change jobs enough that what we need to know changes over time. So we all need the ability to learn-on-demand.

I was fortunate to get a computer science undergrad degree from M.I.T., but at the time, they didn't have any courses whatsoever on database systems. I ended up in a position where I needed to write a DBMS, so I found the textbooks and papers and learned how. A lot of my career has been based on that. It's not necessarily all that hard to learn things yourself.

About your last paragraph, I agree 100% All of that is more important than choice of language.

Peter, you imply that Python is better for, or more like, pseudo-code, but why is it better? In my opinion, it is better for most people because they were taught syntaxes more like that of Python than that of Lisp. An important factor in easy-of-understanding is to be similar to something you are already familiar with. To the extent that this is the reason, it's not implicit in Lisp vs. Python, but rather more a question of which style of syntax is better-known.

A function definition is, in general, far away from the function call. If you think this problem is more severe for macros than for functions, then you should articulate why. You may well have a very valid point in your mind but I think it needs to be expressed somewhat more specifically.

At the International Lisp Conference last year, I put in an evening event called the "Great Macro Debate", in which these issues were discussed. (We encouraged humor, and flaming as long as it was witty, so it was a lot of fun.) What you say is true to an extent. Macros, like most things, can be abused. If you have a group of Lisp programmers, one thing you can do is have the junior ones request advice from the senior ones about what constitutes "tasteful and idiomatic" use of macros, and vet particular macros, since it is rather hard to crisply "pin down" just what those things mean.

Hello, my co-worker, whoever you are. Yes, Common Lisp should have dictionary literals. I don't know why there hasn't been a commonly-used reader macro for this. (Emacs Lisp mode and other tools would have to know about it, so it needs to be a widely-accepted convention.)

Common Lisp does have strong typing. What it does not have is static typing.

I am at the SPLASH conference, and the Dynamic Language Symposium is happening right now. There is controversy over whether we can find a way to have the benefits of both static and dynamic typing in the same language. The great advances in type inference make me hopeful. The keynote speaker, Allan Wirfs-Brock, replied to my question about this with more pessimism. It is not a simple question; for one thing, not everybody even agree about which factors are "pro" or "con" for either static or dynamic. I am not doing programming languages these days (I'm doing databases) but I continue to be hopeful.

Oh, it's so ugly, and it hasn't been checked for mistakes, etc. I'd be embarrassed to have my name associated with it.

I agree. But if you find yourself with an employer who requires that everything be written one of a few languages, and Lisp isn't on the menu, I'd take Python over C++ in a heartbeat.

I tried writing an extensive Common Lisp vs. Python paper (yes, I have seen all of the existing ones), but it got too big and out of hand. One of interesting developments in Python recently are decorators, which allow some interesting metaprogramming. This can do some things that Lisp macros are used for. It's still not Lisp macros, but it;s picking off the low-hanging fruit, which helps Python coders a lot.

I guess so, but actually I don't think that Java and CLOS have such a different idea of what OOP means. They just have different specific features. CLOS has multimethods and multiple inheritance; Java has explicit interfaces.

Frankly, multiple inheritance, and multimethods, are nice tools when you need them, but I'd say that most of the time, you don't. (Let me clarify that. Doing what Java does with multiple inheritance of interfaces IS very important, and it would be very bad to leave that out. What Java cannot do, namely multiple inheritance of implementation, is much less crucial. And you can very often get around it by using delegation. See "The Treaty of Orlando" which asserts that multiple inheritance and delegation have the same inherent power. (This was formulated at an OOPSLA conference in the 80's; Henry Lieberman was one of the main authors.)

Anyway, my point is that Java does indeed have limitations, but the fundamental concepts are very similar to those in CLOS.

It's true that when people learn object-oriented programming, and they learn about inheritance, they tend to think that inheritance is something you should be using heavily all over the place. It takes some experience to learn where inheritance is proper and where there are better ways of doing things, such as delegation.

I don't think OOP is that hard to learn, but I do agree that learning to use it very effectively in the best and most tasteful way takes time and experience. But that's true of so many aspects of software design; I don't think OOP is all that different in this regard.

Yes. That's why you want a multi-paradigm language, in which all of those methods of writing code are available. The trick is to figure out how to provide all of them in a way that is well-integrated. I feel that Common Lisp does this very well. For example, when you want a method to get called, you don't use a special "send message" operator; you use a generic function. It looks just like a function call, to the caller; the fact that this call is doing a method dispatch is part of its internal implementation, rather than part of its externally-visible contract.

One reason Lisp has survived so long because it is capable of absorbing so many of the good new programming ideas as they come along. (No, it's not perfect this way, but it's pretty darned good.)

Exactly. If your IDE can just generate it, then why is it needed at all? And, as I said, it makes the code harder to read. You have to look over all the boilerplate and see if it's all exactly the usual boilerplate, or whether one or two methods in there were manually improved. If the IDE has to generate it, it means that the programming language is expressing your wishes at too low a level of abstraction, rather than more-directly reflecting what you were trying to say in the first place. So you have hit the nail precisely on the head.

I was one of the designers at BEA for four years. (BEA made WebLogic, a leading J2EE server.) Indeed, J2EE requires a lot of annoying boilerplate. Yes, you have to let the IDE handle it for you, which is fine for writing code but not so great for reading (someone else's, or even your own) code.

I will assert, though I can't demonstrate it, that had this been done in Lisp, the boilerplate problem could have been substantially alleviated by using Lisp macros. One piece of evidence: J2EE has improved this problem substantially by using Java's relatively-new "annotation" feature, which, broadly speaking, has some of the same mojo as Lisp macros, when used properly.

On the other hand, you can do a lot better even in Java. Look at Spring and the other new post-J2EE frameworks. The experience with J2EE has led to learning and improvement in these new "dependency-injection" frameworks, which is definitely a good thing for the Java world.

C succeeded because it was the language of Unix, and it rode to success on Unix's success. C++ did indeed succeed because so many people knew C. Java has very little to do with C, except for the surface syntax, which makes it look as if it is similar to C, but its semantics are not like C at all.

You do not need to throw away everything you know to use Lisp. 90% of what you have spent your time on when you learn programming applies to Lisp just as well as any other language: variables, procedures, iteration, and on and on. At ITA, when we hire new hackers who don't know Lisp, we just give them a copy of Peter Seibel's excellent book "Practical Common Lisp", and they quickly pick it up.

Common Lisp, as it is used in real-world practice, isn't nearly as strange as many people think. (Yes, we have a job to do to explain that to the world.) It's not a new paradigm the way Prolog or Haskell are. You can get started, doing the kinds of things you do in Java, very quickly. Now, learning all the more-powerful stuff, like Lisp macros and how to effectively and tastefully use them, and more advanced object-oriented features of CLOS, does take some time to learn. But, then, learning all the useful stuff in the Java libraries takes time to learn, too, even if you're the best C programmer in the world.

That's an amusing idea, but it is not the case. I used Lisp extensively at the MIT AI Lab, at Symbolics (I was a founder), and now at ITA Software. The people worked together as teams very well in all places. The fact that you're using Lisp does not change the need to work together on design, conventions, architecture, etc, not to mention code reviews. The only top-grade hacker I ever worked with who could not work with others was using C++ (not that I think it matters).