Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Programming IT Technology

Kent M. Pitman's Second Wind 170

Kent M. Pitman has already given you his first 11 answers to the questions you asked him about Lisp, Scheme, the creation of programming standards, and much more -- below are his answers to another eight (starting with answer #12). Thanks again, Kent.

12) Good texts for learning Scheme?
by drenehtsral

I have recently been working on learning Scheme in my spare time, with the eventual goal of writing a scheme based scripting system to run the guts of a massive adventure game/graphical mud sort of system, everything from environment simulation (predator/prey cycles, etc...) to 3d models (i.e. models will be geometry glued together by scripts so you could have trees that by a random seed and a growth level variable have grown over time and are unique to provide interresting landscape features). Scheme is appealing because it's simple, powerful, and adapts well to the idea of a threaded interpreter.

To further my goal of learning Scheme inside and out, I've been reading "The Little Schemer," as well as "Structure and Interpretation of Computer Programs." Do you have any other recommendations for good Scheme programming texts?

Kent M. Pitman: You can get a list of textbooks from Schemers website. If you can articulate a particular need or preference that you think should help narrow down the many available choices, I'd suggest posting a more specific inquiry to the comp.lang.scheme newsgroup.

13) Overlooked practical aspects of Lisp
by hding

Why do you think that people so often overlook many of the wonderful things in Common Lisp such as unwind-protect, the whole condition system (which you are of course closely associated with), and so on - things that make it very useful for day-to-day programming, and are there any such things that you'd particularly highlight, or conversely that you wish had become part of the standard but did not.

Incidentally, thank you for all of the insight so generously and regularly poured forth in comp.lang.lisp.

KMP: Well, people program with tools that are familiar to them. Unless Common Lisp is someone's first language, it'd be easy for them to overlook the things it contains that are not like the things they're familiar with. There's a certain irony here because often the reason people will leave a language for another language is that they've reached the limits of what they can do with the first language and they need more power. So you'd expect that they'd aggressively look for features of the new language that were different than the things they've used before. And probably some do. But you're right that others cling to the safety and familiarity of the operators they could just as well have found in the old language they left behind, and so in the process they miss out on what the language can offer them.

Fortunately, unwind-protect is finally (pardon the pun) present in Java. And some hints of the Common Lisp condition system made it into Java as well. So probably people who come to Common Lisp from Java will be inclined to seek out those capabilities. But there's a lot of other stuff there and I hope new users will indulge their curiosity and take the time to explore.


As to what we should have in the language, the main omission of note is some sort of system definition tool (the in-Lisp analog of make). It was a shame that we did a feature-freeze on ANSI Common Lisp in 1988 but didn't get the standard out until 1994, and the suggestion of including such a tool didn't come until the after-freeze period. All vendors offer such a facility, but programs would be more portable if there were a uniform solution.

There are also quite a number of things about Common Lisp that are available in the same or similar forms in nearly all implementations. Multi-tasking, sockets, database access, external function call, windowing, and so on. It wouldn't be bad to have included any of these, but the fact is that they weren't ready for standarization in 1988. At this point, though, I think other mechanisms than standards are the right way to proceed.

The Lisp community used to expect the delivery mechanism for new functionality to be a new language spec. But that requires working through consensus standards bodies. The problem is that, by their nature, standards bodies are synchronization mechanisms. The problem with synchronization mechanisms in a massively parallel world is that they slow things down. The world is not going to wait for us to slow down, so I think we need to evolve mechanisms that will keep up better with a degree of pace that is externally dictated.

I think this is an area where Lisp as a community has been slow to respond. There need to be community mechanisms for sharing the many great commercial and private packages people have been creating in Lisp, so that we can properly reap the cross-product benefits of our community's productivity. I see evidence that this is changing. The Common Lisp Open Code Collection (CLOCC) is one such mechanism that addresses open source code. I'd like to see similar mechanisms arise for the exchange of proprietary products as well.

As to my posts on the comp.lang.lisp newsgroup, thank you. I'm glad you enjoy them. Frankly, I always consider it a victory to hear I haven't bored everyone to death. In background I've been working on putting together several books on Lisp, but one never quite knows if one will finish such things. I regard comp.lang.lisp as a kind of insurance policy, assuring that at least some piece of what I have seen and done in my career gets transferred from individual memory to global group memory.

I think preserving individual experiences for history is quite important. In the future, this will happen naturally due to logs kept by online collaboration tools. But I'm especially worried about the records of what happened between about 1960 (the birth of programming languages) and 1994 (the birth of the web). Most of everything in that time range is recorded on paper and will eventually be lost. Looking back from the future, I expect it to be as confusing to figure out how the information society was born as it is to look back in a telescope to see the birth of the Universe. You'll get very close, but then you'll get to a point where you can see nothing. The informational big bang. I've been working on webbing all of my old hardcopy papers, and I hope others of that era will commit to doing the same.

14) Lisp - Scheme - ML
by Tom7

I know a lot of big academic (erstwhile) lisp shops, such as CMU, have transitioned away from lisp to ML [standardml.org] and relatives [inria.fr]. Some of the reasons we might give are:

  • Sophisticated type systems, catching most bugs before your program is run, ensuring safety, etc.
  • Much more efficient (http://www.bagley.org/~doug/shootout/craps.shtml), partly due to compilation strategies using types
  • Increased modularity and abstraction
  • Pattern matching, (subjectively) more natural syntax

In fact, I'm one of those people. I've been scoffed at by lisp fans, but most had never used ML. But I have an open mind, so, in the face of more "modern" languages, what advantages do lisp and scheme offer? Do you think that these advantages are fundamentally impossible to achieve in a typed setting?

KMP: First, I assume by "typed" you mean "statically typed." I think of Lisp as "dynamically typed." I think of most machine languages as "untyped." I've heard statically typed languages sometimes called strongly typed, and I sometimes use this terminology myself out of habit, but I've grown to dislike it because it seems to me that the issue of strength ought to refer to whether you check types, not when you do. The terms "static" and "dynamic" seem to me to better get to the heart of the matter.

To quote Abraham Lincoln, admittedly somewhat out of context, "People who like this sort of thing will find this the sort of thing they like." So to somewhat flippantly re-interpret Lincoln's remarks in a modern context, applying perhaps just a bit of obligatory political spin to the result: The fact that functional languages appeal to people who like functional languages is not a proof that functional languages are of general purpose appeal.

I think the real reason that CMU (or any university with a grant-based funding model) changed its direction is good sources of funding in research depend on saying you're doing something "new and different." Such a shift doesn't imply that the thing left behind wasn't "tried and true," but only that "tried and true" is not what gets research dollars. Research must constantly stir the mix, but that doesn't imply obsolescence to what came before. So don't read too much into that.

Answering each of your points in detail might require a whole article, but I'll touch on each in brief:

  • Sophisticated type systems, catching most bugs before your program is run, ensuring safety, etc. Much more efficient partly due to compilation strategies using types.

    Actually, it's funny that you both mention the CMU project and then make this comment. Before moving away from Common Lisp, the CMU crowd was successful in demonstrating to the Lisp community's satisfaction that there were enormous opportunities offered by the Common Lisp language design in terms of type inferencing that still today go untapped by implementations. This is really a market issue, not a language design issue. The fact is that although other languages do a lot more type inferencing, vendors are not getting huge numbers of bug reports saying that better type inferencing is what stands between programmers and the commercial success of their product. Over time, I think you'll see more and more interesting type analysis done, but such work is always balanced against other needs of users, such as CORBA, COM, RMI, and web interfaces, for example, such as UI toolkits and debugging options. When I observe, as I often do, that languages are political parties, this is what I mean. They are each responsive not to the needs of the world, but to the needs of their constituencies. And the Lisp constituency, while it is not oblivious to the value of type inferencing, does not see that issue as its number one priority.

  • Increased modularity and abstraction.

    This is quite a multidimensional space. I think Lisp provides great opportunities for modularity and abstraction that other languages do not. And yet, there are sometimes things I can't abstract as well as I wish. An example of a minor omission: Common Lisp's CLOS doesn't do protocol abstraction as well as Zetalisp's New Flavors; among other things, one can't declare that certain unimplemented methods are required. But with the use of the macro system and the Meta-Object Protocol (MOP), one can add this kind of thing. Further, the package system is missing certain kinds of inheritance capabilities I've often wished for, but I recently sat down and did the work of writing my own versions of defpackage for my own use, adding the capabilities I wanted in a way that my own tools can use, and I had no difficulty. For the most part, I've found the limitations of Common Lisp's abstraction capabilites to be incidental, and not deep, and I've found its syntactic reorganization capabilities more than capable of making up for it.

  • Pattern matching.

    I think you're right that Lisp doesn't do pattern matching. Whether or not that's a good or bad thing is subjective. I think there are people who like pattern matching and people who don't. In fairness to Lisp, though, on the few occasions in my career where I've felt a strong need for pattern matching, I've been able to implement it easily. And, importantly, Lisp's syntactic adaptability has allowed me to make my personal implementation look as natural in the programs I write as if it were natively provided by the language; most other languages don't give me the syntactic control to be able to add new functionality in a way that feels appropriate to the language. So personally, I don't find this a strong negative; rather, I see it as an opportunity for you to create a layered library that supports the needs of yourself and others like you.

  • (Subjectively) more natural syntax.

    I don't think you can make the case that much of any language has "natural" syntax. COBOL and HyperTalk gave this the fairest shot and there's a big difference even between them and any natural language. I personally find Lisp syntax remarkably natural in that it focuses on symbols that you could say out loud, marking them minimally to indicate grouping. Other languages contain lots of special-purpose markers like commas, semicolons, asterisks, and braces/brackets/parens that are used in quite nitpicky ways. All this to say that you're right on this one: it's subjective. And as such, I hope I can fairly dismiss this as an even draw.

15) Lisp in Mathematics Programming
by An Anonymous Coward

Gregory Chaitin has a book called "The Limits of Mathematics." In it he claims that mathematicians should love Lisp because Lisp is basically set theory, and all mathematicians love set theory. I wholeheartedly agree with this, one only needs to look at Chaitin's Lisp programs to realize how quickly and succinctly one can arrive at astonishing incompleteness results in mathematics. So we know Lisp is great for stuff like this, really researching a mathematical subject. Do you see Lisp continuing in this direction, showing and discovering theorems, or will it move into industry? Or has it moved into industry, and we just don't know it? Do the likes of NASA and JPL use Lisp and Scheme religiously? I would bet so.

KMP: Lisp may have started out as a way of addressing abstract topics like math (logic, calculus, prime numbers, etc.) and artificial intelligence, but it long ago made the transition to commercial applications. Both Scheme and Common Lisp have been and continue to be used in real-world applications that might surprise you. These include (but are certainly not limited to) applications in airline scheduling, commercial database manipulation, computer operating systems, bioengineering, web services, document format translation, and, yes, even space exploration. Franz, Inc. has created quite a nice page of Lisp success stories that I think expand on this much better than I could in the space I've allowed myself to answer this question. And speaking of NASA/JPL, they did a comparative study of Lisp vs Java and C++ that some might find interesting.

16) Scheme in CS
by An Anonymous Coward

It seems many of the more popular CS programs in the world use Scheme as a teaching language. A lot of times, students complain about this, saying they'd prefer to learn about C or another language that is considered "apt for industry." I used to be like this too, but have now discovered the error of my thinking. How have you convinced others that while the latest programs might not be written in Scheme, that it is worth a student's time to learn Scheme. Many seem stuck to the point that if they won't use it outside of school, they shouldn't learn it. How can we convince them otherwise, to become scholarly citizens instead of drones?

KMP: I think the thing to explain to a student is that the world is ever changing and that one cannot put ones eggs all in one basket. Furthermore, modern environments are often quite heterogeneous, with different languages and systems being used together cooperatively. Especially for a CS student, who often has the luxury of time that a person in the job world does not, I think it's worth taking time to learn as many different languages as possible. This not only exposes the students to alternate ways of thinking, but it also prepares the student to quickly change modes of thought or languages of expression later. Once on the job, one often can't afford the ramp-up time to learn a new language at the point it becomes necessary to use. Better to already know it and just have to "brush up".

One is much more likely to consider alternative approaches if one has a sense of what is involved in them; it's very easy to fear the unknown, even when the unknown might be of great help. So get to know as many things as you can while you can. Common Lisp and Scheme, which I regard as two very different languages, by the way, should definitely be among the things every student studies. But they should not be the only things the person studies. Like it or not, there is a lot the professional programmer needs to know to be really successful not just tomorrow, but for a lifetime.

As Oliver Wendell Holmes is often quoted as saying, "A mind stretched to a new idea never returns to its original dimensions." In order to stretch a student's mind, I recommend they make a list of "kinds of languages" and then learn as many different kinds as they can. Here are some that come to mind, though I'm sure others with different experience than me might reasonably contribute still others.

  • A block-structured language, such as Algol or Pascal or Scheme.
  • A line-oriented language, such as Fortran or BASIC.
  • A rule-based logic language, such as Prolog or EMYCIN.
  • An Englishy language such as HyperTalk or Cobol.
  • A "stack" language such as PostScript.
  • A "line noise" language (heavy emphasis on one-letter operators) like APL or Teco.
  • A dynamic object-oriented language, such as Common Lisp or Smalltalk .
  • A strongly-typed, statically analyzed language such as ML or Haskell.
  • A dynamically-typed functional programming language, such as Scheme.
  • A string or macro processing language, such as Perl or m4 or TeX or Teco.
  • A database access language, such as SQL.
  • An abstract high-level, assembly language, such as Java.
  • A concrete high-level, assembly language, such as C.
  • A low-level, traditional assembly language.
  • A scripting language, such as Javascript.
  • An interface-definition language such as Visual Basic, HyperTalk, or Javascript.
  • A document-structuring language such as XSL or TeX.
  • A language with a modern error system, such as Common Lisp or Dylan.
  • A reflective/introspective language such as Common Lisp or Java.
  • A symbolic programming language, such as Common Lisp or Scheme.
  • A security-oriented language, such as Java or MOO.
  • A language where both programs and data are fully persistent, such as MOO or HyperTalk.
I'm confident that if people make a sincere effort to learn each of these kinds of languages on their own terms, the Lisp community will get its share of converts. But further, I would hope that the people who come to the Lisp community bring with them the ideas of other communities so that we can incorporate, rather than hide from, the good ideas that we need in order to continually be moving forward.

17) A question for Kent
by MarkusQ

Do you have a maclisp manual I could borrow?

KMP:For those not familiar with Maclisp, it's a defunct dialect of Lisp that predated and strongly influenced the design of Common Lisp.

I've been working on webbing The Revised Maclisp Manual, which I had published on paper back in the early 1980's. It's not quite ready to go out yet, but should finally be ready sometime in the not terribly distant future. Probably a month or two. Watch the site maclisp.info for more information.

18) Open Implementations
by Martin Pomije

What is your opinion of the idea of Open Implementations from Gregor Kiczales? Do you think that his idea could help Lisp be more widely used?

You can see him giving a lecture about this idea here. [microsoft.com] The video is only available in Windows Media format on this site.

KMP: I hadn't seen Gregor Kiczales's talk on Open Implementations, so I enjoyed watching it. Thanks for the pointer!

The talk made me think back to various related ideas I've seen batted around for a long time, the earliest of which that I can recall is a short paper on something called "Capsules" (an object system where classes were allowed to have multiple implementations) by Richard Zippel back in the late 1970s or early 1980s at MIT. Often, especially in a university environment, people will make up such a concept, bat it around for a bit, and then go on to something else. There are some very interesting ideas there and I'm glad to see that they're being pursued seriously, especially by someone as thoughtful and talented as I know Gregor to be.

As a formalized area of study, this topic of "aspect-oriented programming" is new to me. It reuses some old ideas in new ways, and introduces some new ones along with it. I'm only just barely becoming conversant in the terminology, so I can't really speak to it from a theoretical point of view. But it looks promising. And from a practical point of view, I can note that I'm getting daily on-the-job training in it through my consulting relationship with The Software Smith. They're using Lisp as a vehicle to apply the principles of aspect-oriented programming, and the results they get are quite spectacular.

19) What was up with CLisp's "loop" form?
by Jayson

Did you can have anything to do or know who had anything to do with the "loop" form in Common Lisp? Why does it look and feel just like a FOR loop on C (from the Graham book):

(loop for x = 8 then (/x 2)
until (< x 1)
do (princ x))

This is one of by biggest minor nags about CLisp and I am very curious what was going through the committee's collective head. Didn't anybody balk at this enough to at least get the syntax cleaned up?

KMP: The example you cite is quite simplistic and if this were the only reason for using LOOP, we wouldn't have it. Lisp has a number of other iteration operators for doing simple loops like this. However, the reason for using LOOP is that it can represent much more complicated arrangements of iteration paths and collection techniques. I used to grumble a lot myself about how "un-Lispy" LOOP seemed, but over time I come to the belief that the benefits outweigh the costs. A loop like this:

(loop for x from 0
for y in some-list
when (good-result? y)
collect (list x y))

is easy to write and maintain, and much easier to explain than the equivalent, but more Lispy:

(do ((x 0 (+ x 1))
(y-list some-list (cdr y-list))
(result '()))
((null y)
(nreverse result))
(let ((y (first y-list)))
(when (good-result? y)
(push (list x y) result))))

The Common Lisp community likes to offer the traditional Lispy notations for places where they enhance readability, but we also offer alternative notations for situations where we've learned there's a call for it. We leave the choice of which style to use up to the individual taste of the programmer. Common Lisp is not a minimalist language offering only one way to do things or rigidly attempting to force people into a single programming paradigm.

By the way, this is a fundamental difference between the ANSI Common Lisp design philosophy and the Scheme design philosophy. The introduction to the Scheme specification states:

Programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary. Scheme demonstrates that a very small number of rules for forming expressions, with no restrictions on how they are composed, suffice to form a practical and efficient programming language that is flexible enough to support most of the major programming paradigms in use today.
By contrast, the charter for X3J13, the group that designed ANSI Common Lisp, stated the following in the X3J13 charter:

It will codify existing practice, provide additional features to facilitate portability of code among diverse implementations, and establish normative Common Lisp programming practice. The committee will begin with the language described in Common Lisp: The Language by Guy L. Steele Jr. (Digital Press, 1984), which is the current de facto standard for Common Lisp. Whenever there is a proposal for the standard to differ from Common Lisp: The Language, the committee shall weigh both future costs of adopting (or not adopting) a change and costs of conversion of existing code. Aesthetic criteria shall be a subordinate consideration.

In other words, the Scheme community is a very conservative community that is highly focused on keeping its language specification as highly aesthetic and minimal in size as possible. By contrast, the Common Lisp community is an industrial standard that is concerned with messier issues of compatibility, portability, and commercial need; while the Common Lisp community cares about aesthetics, it does not allow aesthetics to dominate practicality as a design criterion.

The relevance of this here is that the Lisp family of languages is made up of a number of smaller communities who share a few core ideas, but really have some very divergent points of view. Each is worthy of study in its own right. One should not, having looked at Scheme, assume they have good intuitions about Common Lisp, nor vice versa.

This discussion has been archived. No new comments can be posted.

Kent M. Pitman's Second Wind

Comments Filter:
  • by Anonymous Coward
    One-offs and small utilities are all fine and dandy, but are there really people implementing large systems using Lisp?
  • Thanks Kent! (Score:2, Interesting)

    by justins ( 80659 )
    The quality of the information you've given in your answers here and in your other responses is really fantastic. This is infinitely more effective than most language "advocacy" and it has been really interesting.
  • by 7608 ( 515533 ) on Tuesday November 13, 2001 @03:11PM (#2559992)
    Nobody claimed that this language was superior to another language. What about the flamewar? What about 4000+ comments? For the love of god, this is slashdot!! GIVE ME BACK MY FLAMES YOU BASTARD! :)
    • by Anonymous Coward
      Well, if it makes you feel any better, here are a few things pilfered from comp.lang.lisp that may help:

      > Don't Fear the Penguin!

      Another Anti-Lisp ? Tux the Penguin will be as straw before a furnace when the DAY OF LAMBDA arrives. Do not mock, the Holy Lambda or I shall dispatch the Frightful Mark And Sweep Garbage Collector to get you. -- Yet Another comp.lang.lisp Lunatic

      Greenspun's Tenth Rule of Programming:
      "Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp."

      Vote Lisp Machine in '96!
      Because today is the car of the cdr of your life.
      -- http://www.cs.rice.edu/~shriram/LispM/Campaign/

      And finally, to pay homage to the Tao of Programming...

      A novice was trying to fix a broken Lisp machine by turning the power off and on. Knight, seeing what the student was doing spoke sternly: "You can not fix a machine by just power-cycling it with no understanding of what is going wrong." Knight turned the machine off and on. The machine worked.
    • by victim ( 30647 ) on Tuesday November 13, 2001 @03:34PM (#2560098)
      Comments like the parent should really be written in German. It is far superior for this sort of speech.
      • You asked for it...

        Keiner hat einen Anspruch darauf, daß diese Sprache einer anderen Sprache anspruchsvoller gelegt war! Was ist mit dem Flamewar? Und die 4000+ Kommentaren? Im Namen des Herrn, dieses ist verdammt noch mal Slashdot, oder?! GIB MIR MEINE FLAMMEN (or FLAMES) ZURÜCK, DU DRECKSAU!

        You're right... it does work better in German.

        woof.

        BTW, don't use the Fish [altavista.com] for this. The Fish is good for getting the gist of things, but the translations themselves are unintentionally funny. Like Japanglish [jun-gifts.com] (Mmmmm... tasty Japanglish [engrish.com]). If you don't believe me, try my translation in German->English mode! Bwahahahaha!

        The brackets and parentheses are killing me! Make them stop!!!

        • German->English
          None has a requirement on the fact that this language of another language was more fastidiously put! What is with that was? And the 4000+ comments? In the name of the gentleman, this is condemned still times Slashdot, or?! YOU RETURN MY FLAMES (or FLAMES) to ME DIRT SOW!

          And back again: English->German

          Keines hat eine Anforderung an der Tatsache, daß diese Sprache einer anderen Sprache anspruchsvoller gesetzt wurde! Was ist mit dem war? Und der Kommentar 4000+? Im Namen des Herrn wird dieses noch Zeit festsetzt Slashdot oder? verurteilt! SIE BRINGEN MEINE FLAMMEN (oder FLAMMEN) zu MIR SCHMUTZ SOW zurück!
        • What idiot modded this a Troll?! Someone does a decent translation and it's a troll? A troll would've translated it to French!
  • is it frees up a *ton* of time for doing other things.....

    Like writing thesi^H^H^H^H^Hreplies to /. interviews.
  • by Anonymous Coward
    Yes, we got it the last time, everyone with a brain is using LISP, and people who aren't are stupid.

    You use a programming language for one primary reason: you believe most other people in your domain space are using it. This is why C will be around for at least another fifty years, Java will unfortunately be around for at least twenty, and perl will probably last another fifteen.

    No one cares how useful a programming language is - they care how many competent programmers they can hire who can code with it. This is why Lisp, ML, Haskell, Prolog and the rest have been consigned to the dustbin.

    • You use a programming language for one primary reason: you believe most other people in your domain space are using it.

      No one cares how useful a programming language is - they care how many competent programmers they can hire who can code with it.

      Dude, you need to get on some antidepressants or else find something you love doing. There is more to life and one's job than conformity and groupthink.

      Rather than rag you too much, I'd like to invite some C or Java programmers to expound the joy of their chosen languages.
      • by mrpotato ( 97715 ) on Tuesday November 13, 2001 @04:22PM (#2560291)
        I agree so much.

        I'm familiar with a few languages. I begun with C++, thought it was nice and fun. Then I learned Java: I thought it was great not to have to worry about memory allocation and pointers, etc. I thought Java was fun too. But damn the Java community is dry. Then I learned Perl: I was in love. You can build things quick, and the community around the language is just so alive, diverse and interesting. You can get help anytime, people just _love_ to teach you (and show off ;-).

        And these time, I'm into Scheme. It's very different, very fun and rewarding. You get to see the world from a new angle. You get to stretch your mind.

        And everytime I learn a new language it just helps me to better understand the others. And don't forget the fun-factor: it is what drives me to try new stuff, to learn more. Ah well, just random rambling from a happy CS student ;-)

        • Since you seem to like learning languages (a very good trait), I'd suggest you learn at least some Lisp. Becoming proficient with Lisp macros made me a better Perl programmer than any single other thing I've done. (Though one could get the same benefit by becoming proficient with higher-level messages in SmallTalk).
        • From a personal point of view, I find your comment very interesting, because I think I'm going through the same process:

          I was taught Acorn BASIC (?!) during school. Hated it, so:

          I learned C++, I thought this was pretty damn cool - I could do a lot of stuff you just couldn't do in BASIC, the STL was powerful, and objects were damn good.

          Then I learnt Java - and no more memory leaks or GPFs (at least, none that were my fault!). But I miss my generic programming and the ability to use pointers more flexibly when I too... so now I'm looking at Lisp and going "hmmmmm".
          • I have seen memory leaks with Java. Just make a long-running thread which has a reference to something which should really be tossed. The most common of all is to forget removing a listener.

            Just a warning if you ever debug someone else's code. The JProbe memory analyzer is the best I've found for locating the error quickly. Weakreferences are useful at creating quick fixes, until you can correct the design in the next version.
          • You hated BBC BASIC?!?! But it's the best BASIC dialect *ever*! Seriously!

            At least it's nowhere near as bad as MS BASIC and its variations... ...
        • You're right, the Java community is really dry. I guess it's because they're so damn busy all the time.

          They're busy learning all the new APIs that Sun is constantly cramming into Java (and cursing because the sample programs cause the JVM to crash).

          They're busy pulling their hair out because Java is mainly used in business and on large projects (a recipe for ulcers if not actual failure.)

          The Perl guys already got all their work done, so they have time to goof around. :)

          Seriously, the super-friendly community Perl has is its biggest asset. That kind of spirit has to come from the top. I believe Larry Wall, not Perl, is the reason Perl is so successful. (On the other hand, Perl is a lot more fun than most of the languages people learn in school.)

    • Lisp may not be the most useful language in and of itself, but if you learn it, it will make you a better programmer.

      Most people who first learn languages like C, C++ or Java throw around functional side effects like they were going out of style. Lisp makes you very aware of good, disciplined functional programming (it almost forces you to write neat, concise code!).

      Also, I learned many powerful programming concepts such as lambdas and closures while teaching myself Common Lisp. I doubt I would understand the concepts as they are applied in Python and Perl nearly as well, if I didn't first learn Lisp.

      So go and get a copy of The Little Lisper [isbn.nu] and have at it. It's good clean fun!
    • This sentiment is true for industry (except in the rare cases where you can make a real strong economic argument in favor of one language and are lucky enough to have a manager who "gets" it).

      But there's no reason this kind of marketplace idea should apply to the "open source" or "free software" world. Personally, I feel free to hack my software in whatever language I like (typically SML, my favorite underdog). I hope that other hobbyists do take the time to build up an environment where their favorite (whatever that may be) can flourish, too. It is in our spirit to embrace things because of their technical merits, rather than their popularity!
    • You use a programming language for one primary reason: you believe most other people in your domain space are using it.
      I can think of a few other reasons to consider, the biggest one being:
      You believe it will help you solve your problems.
      If your problem is "there is no known efficient algorithm to solve this", you choose a language where you can rapidly experiment and profile different solutions, then tune the hell out of the best ones and deploy them. That's why Orbitz [orbitz.com] chose Lisp for their core fare search engine.

      If your problem is "we need 50 coders to maintain our external Web site", you choose a language where lots of people are available and there are lots of libraries to do the standard stuff. That's why Orbitz's Web site code is in Java.
  • Pitman's answered 19 questions so far, and I can't help but wonder if this second 'leg' is the final. Does anybody know how many more is he going to answer?

    This is the best interview I remember reading here, and I definitely want more of the same (and thanks to whoever decided to post in in sections - it's been easier to digest it this way).
    • agreed, this is one of the few wonderful /. interviews. it pleases my programming heart.
    • I gave timothy all answers at once, but there was a fixed data limit on the size of an article, so he had to post it in two parts. I had no idea this wasn't a typical length; I just wanted to make sure that everyone's question was answered fairly. My thanks to those interested enough to stop back and read along on this second set.
      • I have to say 'thank you' for the reference to the work of Gregory Chaitin. Having been in the trenches way too long and being highly subject to the programming languages network effect, it seems I hardly ever drink of the nectar which fuels deep thinking on topics important to CS. I guess there's a significant difference between CS and IT in general and I appreciate the peeks behind the conceptual curtain more now.

        Anyway, I'll find some way to let my wife order those books. ;)

        Thanks again.
  • Thanks Kent (Score:5, Informative)

    by dlakelan ( 43245 ) <dlakelan@s[ ]et- ... g ['tre' in gap]> on Tuesday November 13, 2001 @03:53PM (#2560154) Homepage
    Thanks again for your two part series. As someone who took to scheme immediately as soon as I saw it, and moved into Common Lisp with enthusiasm when I found it, I am familiar with these types of questions.

    I especially think your description of a list of language types to learn is valuable to those who haven't had the experience of learning multiple languages.

    I want to address a few questions I've heard frequently myself.

    1) Why learn XYZ it won't help me get a job or won't be used on the job.

    The fact of the matter is that the more you know about how computations CAN be described, the more you will know about what the right way to describe a *particular* computation is. This means when someone comes to you with 150 pages of code in straight C that implements a simple data format parser, or a preferences file reader, or a layout engine for a diagram editor or whatever, if you have seen 5 or 6 different styles of languages and techniques for programming, you will be able to decide how best to attack the problem that needs solving.

    Often with the right point of view, a problem becomes an order of magnitude simpler. The beautiful thing about LISP is that it gives you the ability to take so many different points of view within a single language.

    I still use flex/YACC, and M4, and sed, shell scripts, and will occasionally write some C/C++ (usually to link into lisp at a hotspot :-)) but when I approach a problem I always think to myself "what is the best way to look at this problem to make it simpler to solve". Often LISP lets me express that solution better than other systems.

    This approach is basically the same approach a mathematician takes to proofs and problem solutions. Make the problem smaller, make it more like something we know how to solve...

    Here's the other one I hear often:

    2) We can't use XYZ there aren't enough people who know XYZ to support it. Go back to (or stick with) C/C++/Java/Perl!

    This simply is a way to dodge having to rationally consider a different language or system. The fact of the matter is:

    a) Just because you can hire someone who claims to know C/C++ or whatever, doesn't mean you can hire someone who can solve your problem! Programming involves a lot more than just knowing the syntax of a given langauge, and some of the features the library offers.

    b) If by switching to something else you can make your problem several times easier, then the cost of training every good candidate vs. sticking to your old ways is essentially negative!

    Most of the time, spending a few weeks of training your new candidate in how your system works will pay off big-time when it comes to debugging, quality assurance, adding new features, and even implementing the feature you initially hired them for. Why? Because understanding the PROBLEM and the solution method is much harder than understanding the language syntax, or even most language semantics.

    I run my own business, it's just me. My ability to understand a problem, work with people to figure out good implementation strategies, and write code in LISP to rapidly create the products and services I want to provide are all advantages that I got by learning many languages, and especially LISP family languages.

    thanks again Kent!
    • Most of the time, spending a few weeks of training your new candidate in how your system works will pay off big-time when it comes to debugging, quality assurance, adding new features, and even implementing the feature you initially hired them for. Why? Because understanding the PROBLEM and the solution method is much harder than understanding the language syntax, or even most language semantics.


      Few programmers want to learn a new language, especially one that is not C or C++. Working with a niche language is tar pit. You become a specialist who can't find your next job because your experience is creating a resume that won't make it past headhunters' keyword filters.

      • Re:Thanks Kent (Score:2, Insightful)

        by dlakelan ( 43245 )
        Hiring programmers not willing to learn a new language is probably not a good idea, certainly not if you are a small(ish) company that needs every advantage you can get.

        If you're a contract programmer looking to move from job to job at Fortune 500 companies every 6 months, then by all means stick with C++/Java.

        Much of choosing a language (or a project, or even an industry) comes down to being willing to bet the farm on your success. Big companies rarely bet the farm on anything. Small companies have already done it just by starting up. It's not surprising that more and more start ups are choosing Python or Lisp. See Paul Graham's article on "beating the averages" for his take on this issue. Google will find it for you. There were even some slashdot articles about him.
      • Few programmers want to learn a new language, especially one that is not C or C++. Working with a niche language is tar pit. You become a specialist who can't find your next job because your experience is creating a resume that won't make it past headhunters' keyword filters.

        Do you say this from experience, or are you pulling this out of your ass? I've found that the fact that I know Lisp, Scheme, SmallTalk, and PostScript, along with the C++ or Java I'm being hired to do, is a good thing. All things being equal, wouldn't you rather hire the programmer with more diverse experiences? Well, even if you wouldn't, there are plenty of employers who see that as a positive thing.

      • Screw dumb headhunters. All I have to do is get my resume on a manager's desk. Of course I have a lot of C,C++,Java and other languages to boot.

        How is learning Lisp if you also have C,C++ going to hurt you exactly? I have over 10 languages that I've used commercially. I don't see a problem.
    • Do your customers know that you are saddling them with code that will be much more expensive for them to maintain than a "majority" language?

      Seriously, should you pass on and they need to hire someone else to maintain your LISP, they will certainly pay 2x or 3x the cost of a C programmer, as good LISP programmers are far more rare.

      This isn't a joke - I know of companies that have acquired LISP code that has become a complete albatross as they struggle to hire or train people to maintain it - here's a hint - not many programmers want to bother with LISP as they see it as career-limiting.

      All in all, I think offering LISP solutions to your customers is a lousy value proposition in the long term.

      • If by switching to something else you can make your problem several times easier, then the cost of training every good candidate vs. sticking to your old ways is essentially negative!
        • Oh that's great. Mod down a valid comment. I'm pointing out that the poster didn't read the whole comment or, if he or she did, they choose to ignore the part of the post they decided to reply too. Why? I dunno... Don't confuse my sig with the post. Stupid moderators.
      • Do your customers know that you are saddling them with code that will be much more expensive for them to maintain than a "majority" language?

        Seriously, should you pass on and they need to hire someone else to maintain your LISP, they will certainly pay 2x or 3x the cost of a C programmer, as good LISP programmers are far more rare.

        While I agree with your sentiment in principle, some customers agree with the usage of Lisp, even though they know that maintainance will be much more expensive. It depends on the returned value of that usage.

        For example, in one of our projects we substituted a yacc/flex/C++ programm with a Lisp program, the latter running 15x [sic!] faster: The C++ program needed around 17 hours for a job, the Lisp program does it in roughly 1 hour. The job was about data analysis and statistics - and we got statistics just an hour away from the data collection, and not one day away. This advantage is more than worth the raised maintainance costs.

        OK, for our customer (a large European bank) it will be hard to maintain the system himself. So what? They're used to this; they can't maintain SAP or MS Office either, but rely on it nevertheless. In addition, I doubt that they would have been able to maintain the yacc/C++ program - they're a Cobol shop, after all. The Real World(tm) runs on Cobol, don't forget this... :-)

      • Would your customers prefer a solution written in C that was 10x as large, had half the features, twice the bugs, and took 5x as long to deliver?

        You act as though the implementation language is the only thing that customers care about. What about time to market?

        If you pay 2x or 3x the cost, but the Lisp programmer is 4x or 5x as effective as a C programmer working on the monstrous C implementation, your customer wins anyway. Sometimes, in programmers as in other things, you get what you pay for.

        I don't think my multiples, even if optimistic, are fantasies, either. Lisp is a language that can give you tremendous leverage. Small teams or single people can deliver programs that would swamp a team trying to write the same thing in C.

        If you insist on a product that can be maintained by average programmers, you get an average product.
        • Just as another data point, my customers are low-end customers who can't afford technology at all. If replacing me meant paying a programmer a commercial wage, they'd be sunk. It doesn't matter if it was C or Lisp. What will make them win is getting a cheap enough price that they can get any solution at all in their price range. And that requires very smart software, of the kind I am confident I can write in Lisp and not confident I can write in any other language, because I can afford to write that software but I cannot afford to both employ consultants for them and charge them the almost-pennies a month they're willing to pay.

          I happen to also do some consulting on the side for people who want to use Lisp for their own reasons, and that keeps the bills paid while I develop the software for the market area I've picked off (that I'm being deliberately vague about because I have not formally entered it yet, except for some limited testing). But my reasons for using Lisp are simply that it enables me to do what I need to do, and it enables my customers to get something they can't get at all in any form because no one cares about them.
  • by jonabbey ( 2498 ) <jonabbey@ganymeta.org> on Tuesday November 13, 2001 @04:02PM (#2560185) Homepage

    I'm not that impressed with the NASA study linked. Anyone who has done any Lisp programming in school will know that Lisp is a great language for algorithmic problem solving, and the problem used in the study really plays to that strength in Lisp. Perl would also likely kick C++ and Java's ass in this task. That doesn't mean that Perl or Lisp would necessarily be as good a choice as C++ or Java in a wide range of problem domains.

    Lisp is a great language, but it traditionally has not interfaced as well with the Real World as a number of other languages that were more practically oriented.

    I know that people absolutely rave about the pleasures of programming on all-Lisp machines, but most of us don't have those, and without either having a Java-style complete set of API's for doing GUI and system interfacing, or having C's ability to directly call system API's, one is left without the tools to directly influence the environment. And, yes, I'm sure there are implementations that have those things there, but without them being absolutely standardized, you can wind up locked in a ghetto of your own making.

    As a side note, Kent, don't you think it a little churlish to denigrate Java as merely 'an abstract, high level assembly language'? ;-)

    • by frank_adrian314159 ( 469671 ) on Tuesday November 13, 2001 @04:25PM (#2560315) Homepage
      I'm not that impressed with the NASA study... Perl would also likely kick C++ and Java's ass in this task.

      If you took the time to read the paper, you'd notice that the study was based on an earlier one that did include Perl. They both did, indeed, kick C++'s ass.

      However, Lisp still did somewhat better than Perl in terms of time spent coding the task, had less variability in the time it took to code the task, and used significantly fewer runtime resources than Perl, IIRC.

      don't you think it a little churlish to denigrate Java as 'an abstract, high level assembly language'?

      It's not?

    • by NetSettler ( 460623 ) <kent-slashdot@nhplace.com> on Tuesday November 13, 2001 @08:49PM (#2561307) Homepage Journal
      Re: As a side note, Kent, don't you think it a little churlish to denigrate Java as merely 'an abstract, high level assembly language'? ;-)

      Depends on what you think of as an assembly language. It was a somewhat provocative statement, but I didn't mean it to anger people, just to make them think.

      Java is missing certain kinds of syntactic abstraction that force me to forever spell out things that I'd rather abbreviate. That's characteristic of assembly languages. Some of them anyway. Some of them actually have better syntactic abstraction than Java does. Perhaps I was unfair in reverse. ;-)

      Further, when I hear people rave about Java, it is more for the libraries it offers than for the syntax. The syntax is regular enough, but I don't find it particularly "empowering" when compared against other object systems. Compared to nothing, it is certainly empowering. But as an object system, it's fairly vanilla.

      So if libraries are its strength, I model that as a kind of modern day assembly language (I did say it was abstract, after all) with a large instruction set of interesting instructions.. But anything you want to do with those has to be laboriously spelled out, and if you change something, the language's static phase really forces you to do a lot of work to make things self-consistent, providing really very little help.

      I'd say an assembly language is one I'm happy to have present at a substrate level but that I'd rather not program in on a day-in and day-out basis. C, Java, and TeX all fill the bill in that regard. They each provide a fine layer of support, but I'm happier with them in tools that use them as a backend than in tools that use them as a front end.

      It's just my opinion, though. Offered only for the sake of getting you to stop and re-examine your presuppositions for a few minutes. Others are entitled to hold differing opinions without thinking I've accused them of being idiots.
      • Further, when I hear people rave about Java, it is more for the libraries it offers than for the syntax.

        The language is clearly not what makes Java interesting--it's a conservative, somewhat tedious language. The libraries are quite good. But the runtime and its specification what makes Java really interesting from a systems point of view because it offers

        • a well-specified, complete reflection interface.
        • a well-specified, complete interface for dynamic code generation.
        • a well-specified set of interfaces to the garbage collector.
        • complete specification of what operations must throw what exceptions under what conditions.
        • complete specifications of both statically typed and dynamically typed operations (in particular, numbers behave with predictable efficiency).
        • implementations that actually reliably perform cross-compilation-unit inlining and other dynamic optimizations.
        This makes it straightforward to implement bullet-proof and portable code walkers, debuggers, inspectors, novel efficient object systems, code instrumentation systems, transparent persistence and transparent remote objects, and lots more.
    • Lisp is a great language, but it traditionally has not interfaced as well with the Real World as a number of other languages that were more practically oriented.

      It's not Lisp in general. Lisp integrates just fine with lots of environments. Lisp can integrate very well with UNIX if you let it (Elk Scheme and Bigloo are an excellent examples). And traditional Lisp implementations had everything from the assembler on up built-in and written in Lisp.

      I think many of the people who developed CommonLisp and the Lisp machine just had a deep disdain for anything UNIX-related and therefore couldn't care less whether CommonLisp integrated well with UNIX or the kinds of things people were doing on UNIX. Just read the UNIX Hater's Handbook [catalog.com], contributed to by many vocal Lisp users in the the 1980's. As a result, CommonLisp has endless provisions allowing for pathname syntax on TENEX or oddball byte sizes, but few of the things that make systems like Perl, Python, or even Java so useful on UNIX and Windows. Other essential facilities didn't make it into the standard probably because many CL vendors thought they could use essential proprietary functionality as a way of binding users to their product.

      I hope future Lisp implementations will learn from these past mistakes. CMU CommonLisp, in my opinion one of the best implementations around right now, might do well to just forget going for ANSI CL compatibility and instead come up with a more useful, more complete, and more streamlined feature set.

      • Re: Lisp can integrate very well with UNIX if you let it.

        You should have stopped here. Most of what follows is, in my opinion, a hodgepodge of misconceptions and very odd reasoning. Ordinarily, I would let this go and just not respond to such, but a lot of people are reading along and might assume that silence indicates agreement.

        Re: I think many of the people who developed CommonLisp and the Lisp machine just had a deep disdain for anything UNIX

        Inferring something bad about Lisp from such a source is ridiculous. That book had some legitimate gripes and picked he vehicle of humor to present them. The CL design tried to be enduring by not presupposing any operating system. We didn't know whether certain OS's would win out, and even now we don't know that the dominant OS's will not be overturned by others. CL is OS-neutral, but designed in a way that allows vendors to flexibly cater to their own chosen host operating systems. Some CL implementation are heavily Unix-centric and the language causes them no impediment in that regard.

        If you're going to critique Lisp in this way, be specific. Vague and general insults without substance are not appropriate in this venue.

        Re: I hope future Lisp implementations will learn from these past mistakes.

        First, present implementations already cater to Unix and other modern operating systems.

        Second, something funny about the wording here. Languages make design decisions. Implementations just implement them. Implementations do have some discretion, but in that sense, they already do implement that discretion and have for a while.

        I used Lisp to implement my Linux-based web server. I actually did all the development on Windows and it deploys seamlessly on Linux with basically no changes. C is often touted for being highly portable, but every C program I've seen has infinite little conditionals that have to be very different between nearly every platform. I commonly write cross-platform tools for Lisp that don't require any conditionals at all. Xanalys [xanalys.com] even offers a windowing substrate that uses the same operations for windowing under Windows and Linux/Unix, so that one can do GUIs in a natural way on both systems using the same program interface.

        There are many good ideas in CMU CL, but it hardly as a corner on the market for Linux-savvy systems.
        • The CL design tried to be enduring by not presupposing any operating system.

          Very true. And we'll just have to disagree on whether that was actually a good design decision. I think history will tell on this one ;-)

          If you're going to critique Lisp in this way, be specific.

          I'm not sure what you are responding to but it isn't anything I wrote. I do believe that CL has many problems, but CL is not the same as Lisp.

          Vague and general insults without substance are not appropriate in this venue.

          Are you kidding? This is Slashdot. I'll have to remember to add some next time.

          • I don't know why - but to me you sound like a insulted little child.

            It is amazingly astonishing how you - proclaiming of multiple years of Lisp experience - shows up here with nowing so little on the details. To me it is much more likely that you are simply a moron that has read some articles and now plays the role of an insider to create some nice little flamewars.

            I urge you to get a live - so you can finally stop your ridiculous existence of having fun through insulting and attacking other people.

          • Re: The CL design tried to be enduring by not presupposing any operating system.
            Very true. And we'll just have to disagree on whether that was actually a good design decision.

            Already it shows itself to be of value to our community, so I'm not sure what you mean here. This robustness of design allows people to target multiple operating systems with the same code without conditionals. In Common Lisp, you say what you want data to do, but you don't get overly caught up in how you want it done.

            The alternative approach, taken by languages like C, is to focus on what needs to get done in the micro. Certainly this is needed. Not everyone can be an executive director of a major multi-national corporation--some people still have to flip the burgers, and the details of burger flipping do matter. (That probably sounds more pejorative than I mean it to. My point is really that the abstraction tower requires some support from below, at the assembly level. Substitute "fabricate microchips" for "flip burgers" if you like and it will sound jazzier but amount to the same. I'm not trying to address the amount of intelligence/skill it takes to perform a task, but rather the stuctural position of the person doing the task within the hierarchy of a company or the usually-hieararchical decomposition of a large program) But you don't get to be president of a huge conglomerate by micromanaging every burger flip, and it's likewise no accident that Lisp goes after very large, very complex problems because it is able to free itself of detail concern of the small-fry issues like how bytes are laid out in memory or how unused memory gets reclaimed. It has a staff to manage that.

            And like any corporate staff, it's irrational to assume that the system can operate with no slack anywhere. Having a little flexibility and abstraction here and there is the price of not having to retool your products every time the wind blows, but it has saved CL programmers from many a structural redesign as things have changed over time. Lisp is about change and embraces it well.

            It's fine for other languages to take a different approach, but Lisp should not be eschewed for having a different point of view. What's the point of having different languags if they don't take different points of view and are only different in miniscule details of personal preference about syntax?

            I am still awaiting a concrete example of a design decision that Lisp made in the name of its desire to endure that seems unwise and indefensible to you. I'd feel more comfortable defending specific criticisms than general handwaving ones. Too much room for either of us to dodge around there. I'm not saying every decision of Lisp's is perfect, btw, but I do think it makes no more bad decisions than the next language. And I personally feel it's done pretty well in supporting the community it seeks to support.
            • Already [operating system independence] shows itself to be of value to our community, so I'm not sure what you mean here.

              Of course, whatever CommonLisp does works well for the people who are using it, otherwise they wouldn't be using it. Given that the CommonLisp user community is small compared to the C/C++, Java, Perl, and Python communities, however, that is not a validation for that approach--it may just be that the needs of current CommonLisp users are modest. People write cross-platform programs in those other languages regularly, which, for the most part, take very different approaches to operating system integration.

              I am still awaiting a concrete example of a design decision that [the CommonLisp standards body] made in the name of its desire to endure that seems unwise and indefensible to you.

              There are two questions. The first is whether the CommonLisp standards body should have done things differently given what they knew at the time. I don't want to debate that.

              The second is whether the CommonLisp standard is a good standard for software development for most people in 2001. To me, the answer is "no". There are many issues that went into the design of the CommonLisp standard that are simply not relevant anymore, even if they were arguably issues in the 1980s, and there are many other issues that are not being addressed by the CommonLisp standard.

              Just take character sets, for example. The CommonLisp standard allows for things like TENEX and the Lisp machine, but it fails to define many of the functions we expect for dealing with modern character sets. A modern Lisp standard should most likely simply specify Unicode. No Lisp standards body could hope to do a better job on character sets, portability to a few remaining oddball systems with different native character sets can still be achieved via canonicalization at the system boundaries, and if 20 years from now, another character set comes along, experience from other languages shows that changing over is not a big deal.

              The alternative approach, taken by languages like C, is to focus on what needs to get done in the micro.

              I'm not sure what your beef is with the ANSI C standard. Let's look at character sets again. Until Unicode, 8bit ASCII (and later ISO) was the de-facto standard for many, but not all, C programmers. If you wanted to write character set independent code, ANSI C provided a set of abstract functions. And C was designed in such a way that you could define your own character set and operations that were in every regard as efficient and functional as the built-in ones. ANSI C got this right: it gave developers the choice between system independence and simplicity, and as you yourself observed, most developers didn't give a damn about system independence.

              CommonLisp, on the other hand, only covers one of those three approaches: it only has a set of abstract operations, but it never really got a de-facto character set standard and it lacks value types, keeping users from defining their own efficient character datatypes.

              It's fine for other languages to take a different approach, but Lisp should not be eschewed for having a different point of view.

              Why you continue to use the term "Lisp" to refer to one particular dialect baffles me. Do you really consider CommonLisp synonymous with Lisp? I am a regular user of several dialects of Lisp, but I largely stopped using CommonLisp. To me, Scheme is as different from CommonLisp as, say, ML is from C++.

  • Good Point! (Score:2, Redundant)

    by programic ( 139404 )
    I really liked the idea of learning a plethora of languages while in school. Some schools do a good job, but others are rather pathetic.

    I remember when I was in school, taking a databases class where one of the requirements for the last project of the semester was to program it in a language/system we had never used before. It was actually kind of fun (I chose PHP).

    I have seen way too many recent college grads who are proficient in little more than VB. I'm sure they were exposed to C/Java/What-have-you, but man, to say all they needed to do was "brush up" would have been a long stretch.

    So to any professors out there, encourage your students to get some breadth when it comes to languages. The experience will prove invaluable.
    • Recent college graduates... proficient in VB?!? That's scary. I don't go to what would be thought of as a particularly good compsci school, but I've worked in Java, C++, Obj. CAML, and Prolog so far in required classes. What kind of school teaches CS courses in VB, for cripe's sake? And to think I was disappointed that the intro class was taught in Java...
  • by Ars-Fartsica ( 166957 ) on Tuesday November 13, 2001 @04:14PM (#2560247)
    You Work in a Fashion Industry

    I've spent the last several years trying to explain to colleagues why
    they should start using another obscure-but-good language, Eiffel, to no avail.
    Here is what I have learned. Note that this is not about the pros and cons of
    particular languages or paradigms, its about the way the programming language
    industry actually works.

    The language industry is dominated by network effects. There are major
    costs with using a minority language, and for an individual project these
    completely outweigh the benefits, even when the benefits are very large. Hence
    it is generally far better to stay with a majority language. The costs of a
    minority language include:

    Support. Sure, you can get a GPL compiler for most languages, but on a project
    you don't want to have your coders digging into the code trying to
    fix a bug, you want them writing code. Support is something you outsource.

    Performance. Every minority language claims to be faster than C, but often
    isn't in practice. Whatever the truth, C and C++ are at least known
    quantities. Maybe the minority language will be faster, maybe slower. If its
    faster, well gee so what. If its slower then you have a major problem.

    Tool support. These days even small projects start by drawing UML diagrams and
    then converting these automatically into class templates. CASE
    tool vendors don't support minority languages. Ditto for testing and
    documentation tools. Little things like tying your compiler to your
    configuration control manager might potentially be major headaches. Again, its
    more risk that the PM can do without.

    Nobody ever got fired for buying C/C++/Java. If you are a PM this is a major
    issue. Every language is going to bring some headaches, but if you have chosen
    a minority language then these headaches can be turned into an excuse for
    project failure, and hence for hanging you out to dry.

    Trained staff in a minority language are going to be rare. This does not
    necessarily make them more expensive (nobody else wants them), but it
    does make recruitment much harder and more uncertain. Alternatively you have to
    train all your existing people in the new language. And for Functional
    Languages its not just another syntax, its a whole new way of thinking. The
    industry went through this with OO languages, and many PMs have vivid memories
    of reams of non-OO obfuscated C++ written by a bunch of C hackers who had been
    sent on a one week C++ course. Getting your head around a new paradigm can take
    months, and this is time that the project just does not have.

    So, overall the PMs want to go with popular languages, not for PHM
    reasons, but for entirely rational local reasons. But rational local decisions
    turn into globally arbitrary decisions, as the entire herd gallops off in a
    random direction chosen only because most of the herd thought that most of the
    herd were headed that way.

    The lesson of this is that if you want to introduce a language, you don't
    concentrate on making it a good language, you try to persuade the herd of
    programmers, PMs and tool vendors that your language is the Next Big Thing. The
    important point here is not how much the language will do for productivity,
    quality and cost, it is to create the perception that everyone else thinks that
    this language will be the next big thing.

    There are two ways to do this. One way is to tackle the whole industry at once.
    For an object lesson in how to do this, see Java. For an object lesson
    in how not to do it, see Eiffel. Believe me, I know all about this. I have
    spent a long time giving presentations extolling the technical virtues of
    Eiffel, only to have my audience say "Yes, but in the Real World....". In the
    Real World what counts is the network effects. And you know what? My audiences
    were right. It has taken me a long time to realise this.

    The other more interesting and more promising way to introduce a new
    language is to identify a niche market and attack that. Once you have taken
    over your niche you can expand to nearby niches and start to build momentum.
    Python is doing exactly this in web serving, for example. Web serving is a good
    niche because lots of people do it, and productivity and quality generally
    count for more than raw performance. Projects also tend to be small, so
    experiments are not the Career Limiting Moves they are for large projects.
    Education can also be a useful niche if you can afford to take the long view,
    which is how Pascal, Basic and Unix got started.
    • See my reply [slashdot.org] to your posting of this same essay 4 minutes previous.
    • The message seems to be that in the real world (whoops, that should be Real World) being as stupid as the next guy is far more important than any sort of competetive advantage. The nail that sticks up gets hammered down, and all that.

      Since little companies seem to manage to upset big ones' applecarts from time to time, I'm sure that's true at the big companies, where bureaucracy is more important than profits. This same effect might be connected to HP's decision to dump their calculator division?

  • how funny is this?
    I dislike Lisp for many reasons,BUT this is a worth while nerd interview that belongs on /.
    I like Bruce Cambell, but his interview in no way a nerd matter.
  • by Animats ( 122034 ) on Tuesday November 13, 2001 @09:03PM (#2561338) Homepage
    Most of his arguments boil down to "if you learned LISP, you'd like it." But that's bogus. There are some (many?) of us who used LISP and discarded it. Most people who went through a good computer science school in the days before Java used LISP.

    The argument for efficiency via type inferencing is made for many languages, including BASIC. Seldom is it implemented. Smalltalk implementations probably got further in that direction than LISP did.

    The object system in Common LISP was an afterthought, and it shows. It's really a macro package kind of thing. LISP has a strong history of overly elaborate macros; ever see the MIT LOOP macro? These have the usual problem; what you're looking at in the source isn't what's running, and debugging macros (especially those written by others) is hell. Most other high-level languages have banished macros, or discourage their use.

    If you really want dynamism at run time, Smalltalk has most of what you want, and it's cleaner. But Smalltalk is dying, if not dead. Even the ParcPlace people gave up. Java ate their market.

    • Look, nothing against Smalltalk, but the argument that CLOS is "a macro package kind of thing" is beside the point. Lisp macros are so damn powerful that they have OOP as a subset. (One can create a working single-dispatch object system in about 100 lines of not-particuarly-nasty Lisp macrology.) So what?

      Nothing prevents a Lisp compiler from recognizing CLOS "defmethod" or "defclass" just as easily as it recognizes "defun" or "deftype." Most industrial-strength Lisp compilers spend a lot of effort to make CLOS efficient.

      Methods should be just as easy to debug as functions. They are really the same thing. The Lisp environments I've used (mostly Macintosh Common Lisp) allow you to set traps on methods just like on function calls. I never spend any time debugging the MCL internals, any more than I spend signficant time debugging my C compiler.

      Sure, a buggy CLOS implementation based on macros would be a pain. But any buggy CLOS implementation would be a pain. You haven't demonstrated that CLOS is buggy in any implementation, much less inherently so.
      • The poor dude's got macrophobia, the fear of thinking in the large.

        There is only one hell worse than debugging Lisp macros, and that's not having any Lisp macros to debug.

        Debugging macros in any language is hard. Instead of Lisp macros, would you rather be debugging C++ templates like STL?

        Seriously, have you ever tried to port any large code bases using STL from one platform to another? It totally sucks! The fountain of error messages that the compiler vomits gives no clue to the cause to the problem. Debugging STL is much more difficult than debugging Lisp macros, because of the nonsensical jibberish it expands into that the compiler won't even show, instead of simple Lisp s-expressions.

        That's a hell of lot worse than writing clean, simple, reliable, portable macros in Lisp, that you don't have to spend ages debugging, because they often work the first time. Lisp macros are well defined and easy to understand compared to C++ templates mish-mashed with C preprocessor macros.

        Forget all the prejudices against macros you ever learned from other languages like the C preprocessor and C++ templates. They're fundamentally flawed, and qualitatively inferior to Lisp macros.

        -Don

    • Most of his arguments boil down to "if you learned LISP, you'd like it." But that's bogus. There are some (many?) of us who used LISP and discarded it. Most people who went through a good computer science school in the days before Java used LISP.

      Most people who learned Lisp at some school seem to dislike it first. Learning something and getting something learnt is sometimes something completely different. The Lisp that you can learn on most schools is insanely crippled down to months of hacking low-level, useless list-fiddling programs.

      Another problem is that most of these people did not see any need for many of the high-level features offered by lisp and therefore see no urge to use/learn/understand it.

      The object system in Common LISP was an afterthought, and it shows. It's really a macro package kind of thing. LISP has a strong history of overly elaborate macros; ever see the MIT LOOP macro? These have the usual problem; what you're looking at in the source isn't what's running, and debugging macros (especially those written by others) is hell.

      Many people have a bad taste in mind if a notion like "macro" is mentioned. It remembers them on crippled things like C Preprocessor macros , stupid little script languages or embedded pseudo-languages like VBA. But in Lisp a macro is in fact some kind of generalisation over functions. The reasoning is rather simple: 1) Programs are written to solve problems. 2) Writing a program is a problem 3) Solving 2 with 1 means simply to write a program that writes a program. 4) If still too complex goto 2

      Most other high-level languages have banished macros, or discourage their use.

      I don't think that that is really true. Most other high-level languages never had macros. Often enough the designers of other high-level languages do not even know what macros (in the Lisp way of sense) are...

    • Most of his arguments boil down to "if you learned LISP, you'd like it." But that's bogus.
      I guess what Kent should have said more explicitly here was "most people's idea of Lisp comes from bad teaching by people who don't know and use the langauge. If you got to know Lisp properly, you'd like it more."

      I was first exposed to Lisp as an undergrad, in probably the worst possible way. It was as part of the canonical language survey course, taught by someone who didn't really know Lisp, using an atrocious little monograph titled "Lisp for Fortran Programmers". List processing using only PROG, SETQ,and GO *shudder*. No macros, no arrays, no structures. And the implementation we used was essentially a batch interpreter - no emacs, no debugger, just a raw command-line read-eval-print loop.

      When I saw Lisp again, in my second year of graduate school, it was taught by someone who used it to get real work done, with an implementation that had most of the features I have come to know and love.

      A large fraction of current Lisp users (judging from comments in comp.lang.lisp) are people who started out knowing other languages, became frustrated with their instability or limitations, and went out looking for alternatives. Their choice of Lisp was not made in ignorance.

      Lisp is not perfect, but it is an excellent balance of features in progrmming space. Lisp allows you to do imperative code, functional code, and OO code, without forcing you exclusively down one road or another. It is still one of the languages of choice when you want to do something truly new, and it will likely remain so.
      • Re: I guess what Kent should have said more explicitly here was "most people's idea of Lisp comes from bad teaching by people who don't know and use the langauge.

        Indeed I should have thought to express it this way. My point is not "we're a secret society and if you only understand the magic handshake, wisdom will befall you". My point is exactly as noted here: Widespread misinformation, probably mostly well-meaning, injures Lisp.

        I've from time to time observed that perhaps part of the problem is that the misinformation is transferred by people with a static language background. My hypothesis is that they are more inclined than average to assume that things don't change, because the value of static knowledge is given such a premium in their world. But Lisp is a dynamic language, and that attracts people who expect things to change, including the language itself, which means that statically known facts about the language get invalidated over time.

        So there's a problem at the meta/sociological level which mirrors the problem at the technical level. Or such is my guess.
  • Good questions, and answers overflowing with goodwill and scholarship. Excellent work, all round.
  • I stumbled on a thoughtful discussion about lisp
    The Rise of ``Worse is Better'' [jwz.org].

    Even though I don't care about lisp it made me come to the conclusion that XSLT is not a good idea. They have set a goal (no side-effects) with one hand and try the hardest to work around it with the other, making it practically impossible.
    When different approaches to comparing two objects can come up with both true and false there's something wrong, a commite's work that's going to give implementors headaches forever.

In a five year period we can get one superb programming language. Only we can't control when the five year period will begin.

Working...