You are quite right that this is not new physics, or even new engineering. The problem is that this engineering now would need to be done within the cost constraints of a $1000 PC or $5000 server, not some multi-million supercomputer architecture.
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.
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.
Hmmm. Funny, this is an article about Apple's new $300 access point, and you mention a product where Intel suggests a $449 retail price for the 802.11a access point, according to this Intel press release (Strangely, the 802.11b one is apparently $649. Can anyone explain?)
Where does that equate to "paying more" for the lower data rate?
(Not that $300 is a necessarily good price for a 802.11b access point, but that's a different comparison.)
I am surprised that they did not apply the 802.11a standard that some other base station makers have recently announced for increased bandwidth over the wireless portion of the LAN. Oh well, I'll just have to wait...
802.11a isn't something you just "apply." It is a different range of spectrum entirely (5 GHz, not 2.5 GHz), requiring a totally new RF design.
I recommend http://www.lisp.org/ for on-line resources regarding Lisp. I think the best introduction, however, is Paul Graham's _ANSI Common Lisp_, which I believe is only available in dead tree form.
I happen to like CMUCL, a relatively robust public-domain implementation available for Intel Linux and a few other UNIXes, operated using GNU Emacs as a front end. Many other implementations are listed on the web page.
Well, strictly speaking it isn't valid, in that there might be reasonable complaints about Lisp's limitations (and, of course, as all things made by humans, it does have some.) However, *most* people who reject Lisp bring up criticisms which don't hold water.
That is, they are typically criticisms based on an inexperienced or outdated perspective. E.g. "I can't read code with all the parentheses." People who have used Lisp for more than a week no longer notice the parentheses, and as they further grow into the language, they begin to appreciate the other language features that the uniform syntax allows.
Another common criticism of Lisp is that "everything has to be a list." This was true back in 1960, but is most emphatically untrue now.
The most commonly voiced criticisms of Lisp would obviously not come from anyone who wrote real code in Lisp on a serious implementation for a couple of weeks with proper assistance.
Paul Graham likens it to ice skating. Sure, everyone is wobbly the first few times they try to ice skate. They fall down, and they are slow. But if they give up and say "ice skates are useless" they are not making a valid criticism. When someone makes the effort to learn to skate, ice skates are pretty much the fastest way to get around on ice. When an experienced ice skater makes this claim, he isn't being elitist, he's being honest. If the novice retorts "all these people who use ice skates are so elitist. Their mode of locomotion is obviously not as good as they say it is. Why, I tried it [for three whole hours,] and I couldn't get anywhere." then he is just betraying his ignorance, and deserves to be criticized for it.
If you concede that ice skates are best on ice, but mention that skis are better on snow, no honest skater can deny that. Then, there can be useful discussion.
You miss my point. Why are you looking at the ")" in the first place? There's nothing to see there.
When you read Lisp, you look at the "(". Then there is a symbol that tells you what the S-expression is. If your text-editor cursor is on the ")" for some reason, use the appropriate navigation key to jump to the beginning of the s-expression, so you can tell what it is. Emacs does it with a single key (C-M-a, I'm guessing)
The ")" per se has no meaning. It takes no effort to understand.
car and cdr are certainly important operators in Lisp, but if that is all you remember, you probably weren't shown much. Did you even use arrays? Hash tables? Structures? Objects? Common Lisp has all of those and more.
It sounds like you, along with many other students, were introduced to Lisp as a way to learn to express and manipulate recursive data structures. While Lisp is an excellent language for expressing those concepts, modern Lisp implementations (all the commercial ones of which compile to native machine code) have a much larger amount of functionality than car and cdr.
As an aside, you don't even have to use "car" and "cdr." You can also use "first" and "rest" if you find those more readable.
The Common Lisp language reference includes large sections on things that a typical C language reference, for instance, leaves out. Like a flexible way to express and manipulate pathnames in a OS- and file-system- independent fashion. A flexible and powerful condition (exception handling) system. A very powerful I/O formatting language (like printf on steroids). A powerful macro system. There is lots to discuss!
The book you are probably referring to, "Common Lisp: the language" also contains extensive discussions on a number of issues, large examples, and much material that is explanatory (like plots of all the transcendental functions over the complex plane, and the Lisp code that automatically generated the plots in PostScript). It is one of the best-written language references that exist for any language.
If you wish, you can summarize Common Lisp in about 50 pages, such as in the appendix to Paul Graham's "ANSI Common Lisp" book. That is useful enough for my day-to-day work. Or, for more detailed issues, I use Kent Pitman's (you know, the guy whose interview this was) web version of the ANSI standard, the Hyperspec.
Lisp's redundancy is more English-like, in that more is done with words (in Lisp terminology, "symbols") than with punctuation. Also, indentation is often used to clarify the grouping relations (just as in C).
In fact, as a Lisp programmer, your choices of interpretation for ")", that is "block", "function argument" or "other syntax element" seem strange to me. ")" doesn't denote any of those things. From your examples, I can't even tell what you mean by "syntax element."
"block" as in a block of execution in Lisp is denoted by symbols like "progn", "let", "defun", "tagbody", or by a number of macros and special forms. All of them group using ( and ), but you tell them apart by reading the first element. You see the grouping not by counting parentheses, but by the indentation under the first term. Poorly indented Lisp code is as hard to read as poorly-indented C code.
"function argument" is no different in Lisp from any other expression. "4" might be a function argument, so might (+ 3 5) and so might (if (>= x 0) x (- x)) [otherwise known as (abs x)].
Note, particularly, that the result of a if-then expression can be used as a value to be passed to a function. C can only express this using "?:" expression, which many C programmers don't even know about. This is *extremely* useful, and I miss it all the time in C.
"+" or "map" or "let" or "defun" look pretty different to me. When you see a parenthesis in C, how do you know whether it is a function call or a cast or a expression grouping? When you see a comma, is it separating function arguments, or is it a sequence operator? Those are actually more difficult problems than understanding ")" in Lisp.
ANSI CL never claimed to be an industrial-strength programming language. (Implementations might be, or claim to be, industrial-strength, but portability and industrial-strength are orthogonal concepts.)
from the Hyperspec:
In April 1981, after a DARPA-sponsored meeting concerning the splintered Lisp community, Symbolics, the SPICE project, the NIL project, and the S-1 Lisp project joined together to define Common Lisp. Initially spearheaded by White and Gabriel, the driving force behind this grassroots effort was provided by Fahlman, Daniel Weinreb, David Moon, Steele, and Gabriel. Common Lisp was designed as a description of a family of languages. The primary influences on Common Lisp were Lisp Machine Lisp, MacLisp, NIL, S-1 Lisp, Spice Lisp, and Scheme. Common Lisp: The Language is a description of that design. Its semantics were intentionally underspecified in places where it was felt that a tight specification would overly constrain Common Lisp [r]esearch and use..... In 1986 X3J13 was formed as a technical working group to produce a draft for an ANSI Common Lisp standard. Because of the acceptance of Common Lisp, the goals of this group differed from those of the original designers. These new goals included stricter standardization for portability, an object-oriented programming system, a condition system, iteration facilities, and a way to handle large character sets. To accommodate those goals, a new language specification, this document, was developed.
and in
1.1.1 Scope and Purpose
The specification set forth in this document is designed to promote the portability of Common Lisp programs among a variety of data processing systems. It is a language specification aimed at an audience of implementors and knowledgeable programmers. It is neither a tutorial nor an implementation guide.
Personally, I think it is a lot more important to have a portable object model than to have a portable networking interface. When porting from implementation to implementation, the networking performance of different platforms is certain to be different, and require re-tuning anyway.
As for the issues you mention on type-checking being non-portable, optimization and portability are nearly opposite directions. Different implementations (and different (optimize...) settings) will make different trade-offs. If you're spending the time to seriously optimize a program, you probably have gone past the point of worrying about your choice of platform.
I don't understand. You hold up Scheme as the best Lisp variant, but complain that ANSI CL didn't standardize enough functionality? Does Scheme even have a standard object system yet?
Also, you fail to prove the case that ANSI CL killed Lisp (even if I somehow grant that Lisp is dead). What is your realistic alternative? A Lisp that somehow got all the features and market acceptance of Java? Would this have come about in the absence of a standardization effort like ANSI CL? Without the resources of Sun?
Standardizing threads, etc., is quite difficult in a language that is meant to run on a wide range of platforms and OS's. Commercial CL implementations manage to include interfaces to all of this functionality anyway. What in this "poorly written standard" prevents different implementations from choosing a standard networking interface, if the market really demanded it?
Lisp machines sure didn't help Lisp in the long term, but all independent workstation vendors have essentially lost to Intel. Their problems weren't unique to Lisp, but rather to independent microprocessor development.
Not that I'm in the Lisp pantheon, but I'll try to answer your question.
CL doesn't support currying (or continuations, or monads, or a bunch of other functional stuff) because Common Lisp isn't a purist language. It is rather a pragmatic language. Purists are welcome to look elsewhere while Lisp programmers still manage to write world-beating applications like Orbitz.
Look. Airlines save millions of dollars in real money by using these kinds of programs, and they're not going to quibble if it is implemented in Java. They pay *real* money for these kinds of programs, and getting serious companies to pay large amounts for solving these kinds of real-world problems is enough to say "I rock" even if one isn't living with Mom anymore. Point me to a documented case where Java handles these kinds of intense logistics problems, and I'll begin to give you some credibility.
Right around the time when you show me the Mona Lisa done in fingerpaint.
Considering your preferred example was a 3D-shooter game, I'm relatively skeptical about your opinion on world-class application development.
If you think anything in Java touches what CLIM has achieved, you obviously haven't even followed the link I gave and read what is there. You also ignored all the positive qualities of Emacs (ever try to program Word?) that I cited. I fully conceded at the outset that Emacs and MS Word are competing in different arenas. Lisp has a history of serious publishing tools (also not word processing). These solved, for example, the serious problems involved in generating large sets of documentation using hypertext. in 1985.
Again, I concede that MS probably didn't use Lisp to develop Word. The fact that there isn't a Lisp-based competitor probably is due to the fact that smart people don't try to compete in the same niche as MS, and Lisp is used by smart people.
Almost everyone thinks and says their favorite language is best. But only the Lisp people are RIGHT.:-)
More seriously, most people whose favorite language is C++ have never used or even seen a Common Lisp implementation. At most, they might have been scarred by a few-week introduction to a limited Lisp dialect, which is "obviously" only useful for toy recursion problems.
Whenever I read Andrew Koenig, for instance, criticizing Lisp, it's obvious he has never seriously used an industrial-strength Lisp implementation to write a large program.
I think the only people I've heard who really understand Lisp, yet favor other languagues are the extreme functional camp, using languages like OCaml.
C'mon. Every C function needs you to declare the type of every argument to the function (except in varargs, which are done infinitely better in Common Lisp) in machine-level detail before it will even compile, much less work.
Have you spent any time at all thinking whether a numeric argument should be "int" or "long" or "float" or "double"??? You're falling behind Lisp. Did you remember to worry about integer overflow? (Lisp integers only overflow when you run out of memory. C programmers think that wrap-around is a problem that won't happen soon enough to care (2038 A.D.?)) Yet more time wasted, or bugs introduced.
Did you need to define a data structure? In Lisp, you can just use lists for quick-and-dirty. If you want to be cleaner, use structures. You don't have to define the type of every slot, unless you want to.
Did you need serious, robust string handling? Watch out for buffer overflow exploits, extraneous NULL characters, and so on. Did you do any memory allocation? Be sure to think very carefully about "who owns what" or you've introduced memory leaks. Well, even very careful probably wasn't enough, so you still have memory leaks, but you can just restart every so often, right?
You did remember to check the return values of all your system calls to make sure they worked, right? Lisp file I/O throws exceptions, so you can handle errors in structured ways.
Lisp has arrays that can automatically expand as you add data to them (retrieval is fast, storage is fast until the size needs to bump up, when it is still very fast, no arbitrary array bounds to cause buffer overflows later).
Sure, you can write C programs fast. If you have time to put in extraneous detail. And can ignore all the pitfalls in the resulting code. Something like doing surgery fast with a chainsaw. Sure, it might be fast, but do you really like the results?
1) The thing that makes Lisp friendly to Emacs is its uniform programmatic structure. The real benefit of this structure is that it is trivial to write programs that write Lisp programs.
2) see answer to (1). Uniform notation means programs can understand (and manipulate) programs.
3) Lisp lets you add declarations to speed up a program that you have written, without changing the behavior. But only if you want to. Premature optimization is the root of all evil. Lisp lets you paint with a broad brush, so you can cover a large area fast. When you need to get the little tiny details painted, (the routines that run many times, and must be made faster) you switch to a smaller brush. Instead of having to paint the whole damn wall with the small brush. Lisp applications have been compiled which run at speeds competitive with Fortran applications.
4) brackets are the glue that holds the uniform notation together. With auto-parent matching and auto-indenting in your editor, you learn to see past the parens. See answer to (1) again.
5) What are you fanatical about? C? Obviously something is making you fanatically opposed to Lisp.
6) Huh?
7) lambda means that functions are just as much data in Lisp as numbers are in Fortran. When you write programs that crunch functions in the same way that Fortran crunches numbers, you can kick some serious ass.
Sure, you can find a Java implementation of a word processor, but will it last as long as Emacs? Is it as flexible? Is it as customizable? Is it as powerful? An Emacs based on Common Lisp (instead of its own crippled Lisp) would be even more of an improvement.
Any Java "word processor" is going to have a hard time beating MS Word at its own game. Emacs, however, thrives by playing another game, the "text editor" game. And it wins.
Lisp has toolkits like Common Lisp Interface Manager (CLIM) which are much more than simple layers to create windows with widgets. I can't even come up with a concise description of how different the Lisp idea is. (Some of this is my lack of practical experience with CLIM. I don't program GUI applications.)
Java is fine for relatively simple, solved problems (like GUI word processors). Lisp is for horrendously complex, hard-to-solve problems like managing logistics for airlines. Or bioinformatics
You'll notice that all of these are created to solve real-world problems, where it might not be obvious how a computer could help you. Word processing and 3D-shooters are all very securely "inside the box" of what computers are known to do, and have been done many times. Lisp is for taking on the world, forging into new territory, and kicking the world's ass. If you want to stay safe and do "yet another" of the same old thing, maybe Java is all you need.
First of all, the *747* is a 30 year-old technology, the DeHavilland Comet is 50 years old. 747s still get sold today and make a profit for their owners.
The reason a DC-8/747/777 got developed is because there was a huge *profitable* market for intercontinental flight. There is no corresponding market for space flight. There is a market; that is, people are willing to pay money to go into space. Unfortunately, it is not a profitable one. Not enough people are willing to pay enough to support the capital necessary to create the infrastructure.
There is a profitable market for satellite launches. By unmanned rockets, not by expensive Shuttle launchers.
The point is that you have to convince people with billions of dollars (for something on the order of a 777) to lend it to you so that you can design and manufacture the thing, with the idea that PROFITS from selling it will be enough to make it worth their while.
If there were an argument to be made for this, then it would likely have been made already, and you would be worried about spaceport security these days. The fact that manned spaceflight is still not a commercial reality probably means it isn't going to be any time soon.
Why spend billions of dollars to make a unprofitable activity slightly less unprofitable?
The 12C is a *much* older model. Also, it's less featureful than the RPN 17BII, for instance.
But a huge number of financial firms have standardized on the 12C. All that experience and training would go out the window if they switched to anything with new features. If it ain't *really* broke, don't fix it.
The large clamshell "Business Analyst" was their next financial calculator after the 12C. 17BII is the natural successor to the 12C. The 10C is an attempt to compete against the lower-end algebraic financial calculators.
The 12C is just kept around because firms keep ordering them.
OK. Totally unrelated story. A Motorola (making radios, not computer chips) guy was telling me, they made these radios for railroads. Motorola made some changes for a new model, including the case, and suddenly field returns started shooting way up. The railroad guys hated the new model.
A factory guy goes to investigate, says "hey, the new ones should perform much better. We've really improved the electronics, should be much higher reliability. What's the deal?" One of the railroad guys takes a radio in his hand. He says "sometimes, these railcar couplings don't always come apart right, so you have to whack em..." Lifts the radio, and ***WHAM!*** slams the bottom end against the hitch. "The new radios keep falling apart."
The advantage of RPN is more than just the raw number of keystrokes.
When I'm solving a real-world problem, usually I have the numbers (or you look them up when you need them), then I need to put them together semi-interactively. You look at the number on the screen, decide what the next step is, then do it.
RPN let's you type the number in, then decide what to do with it as you go. Algebraic/TI notation is only really useful when you've got a long formula on the page, and you want to read it left-to-right, parentheses and all, and just hit = at the end.
That happens a lot when you are a student who is just grinding through textbook problems, but hardly ever happens when you are thinking on your feet.
The levels of precendence used in the algebraic system are based on rules that make it easy to read equations on paper. There is no intrinsic reason why multiplication is higher precendence than addition, it just happens in practice to be most legible to write equations that way. When you're dealing with numbers, trying to get other numbers, the RPN stack let's you do things with the precendence that works best for thinking through the problem. APL has even a screwier behavior than RPN, but people who use it (I don't) swear it makes solving problems easier.
The Palm has serious limitations on screen size that prevent getting a useful number of keys on the touch screen, in addition to having a touch screen instead of the fine feel of the HP 11C/28C/32SII keys. (I haven't touched one of the newer 48/49 series, so I can't respond to someone claiming the 49G had squishy keys.)
I thought about trying to emulate the 11C/12C on the Palm, but the 11 keyboard is too large to fit on the screen, without even thinking about the fact that the keys each have three functions on them.
The holistic experience of using one of these fine calculators is just not easy to achieve on a Palm.
I don't care about graphing or solving equations or matrices or playing Quake on my calculator, I just want something with all the mathematical functions I need, plus RPN, that doesn't make me curse. The mid-range HPs are great for me.
Could it be that HP's calculators are so damn reliable they never sell replacements?
I'm still using my HP11C daily. Bought in 1987.
(I did dally with a 28C, and replaced it with the next rev. 28(?) when it was stolen, but I find the compact 1xC form factor ideal. The clamshell was too wide, the new 48,49 are too darn tall. And my 11C just won't quit.)
I did see a HP32SII die when a can of Coke was spilled on it.
Slashdot Mirror
You are quite right that this is not new physics, or even new engineering. The problem is that this engineering now would need to be done within the cost constraints of a $1000 PC or $5000 server, not some multi-million supercomputer architecture.
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.
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.
Hmmm. Funny, this is an article about Apple's new $300 access point, and you mention a product where Intel suggests a $449 retail price for the 802.11a access point, according to this Intel press release (Strangely, the 802.11b one is apparently $649. Can anyone explain?)
Where does that equate to "paying more" for the lower data rate?
(Not that $300 is a necessarily good price for a 802.11b access point, but that's a different comparison.)
I am surprised that they did not apply the 802.11a standard that some other base station makers have recently announced for increased bandwidth over the wireless portion of the LAN. Oh well, I'll just have to wait...
802.11a isn't something you just "apply." It is a different range of spectrum entirely (5 GHz, not 2.5 GHz), requiring a totally new RF design.
Thanks for your thoughtful response.
I recommend http://www.lisp.org/ for on-line resources regarding Lisp. I think the best introduction, however, is Paul Graham's _ANSI Common Lisp_, which I believe is only available in dead tree form.
I happen to like CMUCL, a relatively robust public-domain implementation available for Intel Linux and a few other UNIXes, operated using GNU Emacs as a front end. Many other implementations are listed on the web page.
Well, strictly speaking it isn't valid, in that there might be reasonable complaints about Lisp's limitations (and, of course, as all things made by humans, it does have some.) However, *most* people who reject Lisp bring up criticisms which don't hold water.
That is, they are typically criticisms based on an inexperienced or outdated perspective. E.g. "I can't read code with all the parentheses." People who have used Lisp for more than a week no longer notice the parentheses, and as they further grow into the language, they begin to appreciate the other language features that the uniform syntax allows.
Another common criticism of Lisp is that "everything has to be a list." This was true back in 1960, but is most emphatically untrue now.
The most commonly voiced criticisms of Lisp would obviously not come from anyone who wrote real code in Lisp on a serious implementation for a couple of weeks with proper assistance.
Paul Graham likens it to ice skating. Sure, everyone is wobbly the first few times they try to ice skate. They fall down, and they are slow. But if they give up and say "ice skates are useless" they are not making a valid criticism. When someone makes the effort to learn to skate, ice skates are pretty much the fastest way to get around on ice. When an experienced ice skater makes this claim, he isn't being elitist, he's being honest. If the novice retorts "all these people who use ice skates are so elitist. Their mode of locomotion is obviously not as good as they say it is. Why, I tried it [for three whole hours,] and I couldn't get anywhere." then he is just betraying his ignorance, and deserves to be criticized for it.
If you concede that ice skates are best on ice, but mention that skis are better on snow, no honest skater can deny that. Then, there can be useful discussion.
You miss my point. Why are you looking at the ")" in the first place? There's nothing to see there.
When you read Lisp, you look at the "(". Then there is a symbol that tells you what the S-expression is. If your text-editor cursor is on the ")" for some reason, use the appropriate navigation key to jump to the beginning of the s-expression, so you can tell what it is. Emacs does it with a single key (C-M-a, I'm guessing)
The ")" per se has no meaning. It takes no effort to understand.
car and cdr are certainly important operators in Lisp, but if that is all you remember, you probably weren't shown much. Did you even use arrays? Hash tables? Structures? Objects? Common Lisp has all of those and more.
It sounds like you, along with many other students, were introduced to Lisp as a way to learn to express and manipulate recursive data structures. While Lisp is an excellent language for expressing those concepts, modern Lisp implementations (all the commercial ones of which compile to native machine code) have a much larger amount of functionality than car and cdr.
As an aside, you don't even have to use "car" and "cdr." You can also use "first" and "rest" if you find those more readable.
The Common Lisp language reference includes large sections on things that a typical C language reference, for instance, leaves out. Like a flexible way to express and manipulate pathnames in a OS- and file-system- independent fashion. A flexible and powerful condition (exception handling) system. A very powerful I/O formatting language (like printf on steroids). A powerful macro system. There is lots to discuss!
The book you are probably referring to, "Common Lisp: the language" also contains extensive discussions on a number of issues, large examples, and much material that is explanatory (like plots of all the transcendental functions over the complex plane, and the Lisp code that automatically generated the plots in PostScript). It is one of the best-written language references that exist for any language.
If you wish, you can summarize Common Lisp in about 50 pages, such as in the appendix to Paul Graham's "ANSI Common Lisp" book. That is useful enough for my day-to-day work. Or, for more detailed issues, I use Kent Pitman's (you know, the guy whose interview this was) web version of the ANSI standard, the Hyperspec.
Lisp's redundancy is more English-like, in that more is done with words (in Lisp terminology, "symbols") than with punctuation. Also, indentation is often used to clarify the grouping relations (just as in C).
:" expression, which many C programmers don't even know about. This is *extremely* useful, and I miss it all the time in C.
In fact, as a Lisp programmer, your choices of interpretation for ")", that is "block", "function argument" or "other syntax element" seem strange to me. ")" doesn't denote any of those things. From your examples, I can't even tell what you mean by "syntax element."
"block" as in a block of execution in Lisp is denoted by symbols like "progn", "let", "defun", "tagbody", or by a number of macros and special forms. All of them group using ( and ), but you tell them apart by reading the first element. You see the grouping not by counting parentheses, but by the indentation under the first term. Poorly indented Lisp code is as hard to read as poorly-indented C code.
"function argument" is no different in Lisp from any other expression. "4" might be a function argument, so might (+ 3 5) and so might (if (>= x 0) x (- x)) [otherwise known as (abs x)].
Note, particularly, that the result of a if-then expression can be used as a value to be passed to a function. C can only express this using "?
"+" or "map" or "let" or "defun" look pretty different to me. When you see a parenthesis in C, how do you know whether it is a function call or a cast or a expression grouping? When you see a comma, is it separating function arguments, or is it a sequence operator? Those are actually more difficult problems than understanding ")" in Lisp.
ANSI CL never claimed to be an industrial-strength programming language. (Implementations might be, or claim to be, industrial-strength, but portability and industrial-strength are orthogonal concepts.)
.... In 1986 X3J13 was formed as a technical working group to produce a draft for an ANSI Common Lisp standard. Because of the acceptance of Common Lisp, the goals of this group differed from those of the original designers. These new goals included stricter standardization for portability, an object-oriented programming system, a condition system, iteration facilities, and a way to handle large character sets. To accommodate those goals, a new language specification, this document, was developed.
...) settings) will make different trade-offs. If you're spending the time to seriously optimize a program, you probably have gone past the point of worrying about your choice of platform.
from the Hyperspec:
In April 1981, after a DARPA-sponsored meeting concerning the splintered Lisp community, Symbolics, the SPICE project, the NIL project, and the S-1 Lisp project joined together to define Common Lisp. Initially spearheaded by White and Gabriel, the driving force behind this grassroots effort was provided by Fahlman, Daniel Weinreb, David Moon, Steele, and Gabriel. Common Lisp was designed as a description of a family of languages. The primary influences on Common Lisp were Lisp Machine Lisp, MacLisp, NIL, S-1 Lisp, Spice Lisp, and Scheme. Common Lisp: The Language is a description of that design. Its semantics were intentionally underspecified in places where it was felt that a tight specification would overly constrain Common Lisp [r]esearch and use.
and in
1.1.1 Scope and Purpose
The specification set forth in this document is designed to promote the portability of Common Lisp programs among a variety of data processing systems. It is a language specification aimed at an audience of implementors and knowledgeable programmers. It is neither a tutorial nor an implementation guide.
Personally, I think it is a lot more important to have a portable object model than to have a portable networking interface. When porting from implementation to implementation, the networking performance of different platforms is certain to be different, and require re-tuning anyway.
As for the issues you mention on type-checking being non-portable, optimization and portability are nearly opposite directions. Different implementations (and different (optimize
Can you be more specific about the "abstraction features" in C++ that you are talking about?
I don't understand. You hold up Scheme as the best Lisp variant, but complain that ANSI CL didn't standardize enough functionality? Does Scheme even have a standard object system yet?
Also, you fail to prove the case that ANSI CL killed Lisp (even if I somehow grant that Lisp is dead). What is your realistic alternative? A Lisp that somehow got all the features and market acceptance of Java? Would this have come about in the absence of a standardization effort like ANSI CL? Without the resources of Sun?
Standardizing threads, etc., is quite difficult in a language that is meant to run on a wide range of platforms and OS's. Commercial CL implementations manage to include interfaces to all of this functionality anyway. What in this "poorly written standard" prevents different implementations from choosing a standard networking interface, if the market really demanded it?
Lisp machines sure didn't help Lisp in the long term, but all independent workstation vendors have essentially lost to Intel. Their problems weren't unique to Lisp, but rather to independent microprocessor development.
Not that I'm in the Lisp pantheon, but I'll try to answer your question.
CL doesn't support currying (or continuations, or monads, or a bunch of other functional stuff) because Common Lisp isn't a purist language. It is rather a pragmatic language. Purists are welcome to look elsewhere while Lisp programmers still manage to write world-beating applications like Orbitz.
That is all.
Look. Airlines save millions of dollars in real money by using these kinds of programs, and they're not going to quibble if it is implemented in Java. They pay *real* money for these kinds of programs, and getting serious companies to pay large amounts for solving these kinds of real-world problems is enough to say "I rock" even if one isn't living with Mom anymore. Point me to a documented case where Java handles these kinds of intense logistics problems, and I'll begin to give you some credibility.
Right around the time when you show me the Mona Lisa done in fingerpaint.
Considering your preferred example was a 3D-shooter game, I'm relatively skeptical about your opinion on world-class application development.
If you think anything in Java touches what CLIM has achieved, you obviously haven't even followed the link I gave and read what is there. You also ignored all the positive qualities of Emacs (ever try to program Word?) that I cited. I fully conceded at the outset that Emacs and MS Word are competing in different arenas. Lisp has a history of serious publishing tools (also not word processing). These solved, for example, the serious problems involved in generating large sets of documentation using hypertext. in 1985.
Again, I concede that MS probably didn't use Lisp to develop Word. The fact that there isn't a Lisp-based competitor probably is due to the fact that smart people don't try to compete in the same niche as MS, and Lisp is used by smart people.
Almost everyone thinks and says their favorite language is best. But only the Lisp people are RIGHT. :-)
More seriously, most people whose favorite language is C++ have never used or even seen a Common Lisp implementation. At most, they might have been scarred by a few-week introduction to a limited Lisp dialect, which is "obviously" only useful for toy recursion problems.
Whenever I read Andrew Koenig, for instance, criticizing Lisp, it's obvious he has never seriously used an industrial-strength Lisp implementation to write a large program.
I think the only people I've heard who really understand Lisp, yet favor other languagues are the extreme functional camp, using languages like OCaml.
C'mon. Every C function needs you to declare the type of every argument to the function (except in varargs, which are done infinitely better in Common Lisp) in machine-level detail before it will even compile, much less work.
Have you spent any time at all thinking whether a numeric argument should be "int" or "long" or "float" or "double"??? You're falling behind Lisp. Did you remember to worry about integer overflow? (Lisp integers only overflow when you run out of memory. C programmers think that wrap-around is a problem that won't happen soon enough to care (2038 A.D.?)) Yet more time wasted, or bugs introduced.
Did you need to define a data structure? In Lisp, you can just use lists for quick-and-dirty. If you want to be cleaner, use structures. You don't have to define the type of every slot, unless you want to.
Did you need serious, robust string handling? Watch out for buffer overflow exploits, extraneous NULL characters, and so on. Did you do any memory allocation? Be sure to think very carefully about "who owns what" or you've introduced memory leaks. Well, even very careful probably wasn't enough, so you still have memory leaks, but you can just restart every so often, right?
You did remember to check the return values of all your system calls to make sure they worked, right? Lisp file I/O throws exceptions, so you can handle errors in structured ways.
Lisp has arrays that can automatically expand as you add data to them (retrieval is fast, storage is fast until the size needs to bump up, when it is still very fast, no arbitrary array bounds to cause buffer overflows later).
Sure, you can write C programs fast. If you have time to put in extraneous detail. And can ignore all the pitfalls in the resulting code. Something like doing surgery fast with a chainsaw. Sure, it might be fast, but do you really like the results?
1) The thing that makes Lisp friendly to Emacs is its uniform programmatic structure. The real benefit of this structure is that it is trivial to write programs that write Lisp programs.
2) see answer to (1). Uniform notation means programs can understand (and manipulate) programs.
3) Lisp lets you add declarations to speed up a program that you have written, without changing the behavior. But only if you want to. Premature optimization is the root of all evil. Lisp lets you paint with a broad brush, so you can cover a large area fast. When you need to get the little tiny details painted, (the routines that run many times, and must be made faster) you switch to a smaller brush. Instead of having to paint the whole damn wall with the small brush. Lisp applications have been compiled which run at speeds competitive with Fortran applications.
4) brackets are the glue that holds the uniform notation together. With auto-parent matching and auto-indenting in your editor, you learn to see past the parens. See answer to (1) again.
5) What are you fanatical about? C? Obviously something is making you fanatically opposed to Lisp.
6) Huh?
7) lambda means that functions are just as much data in Lisp as numbers are in Fortran. When you write programs that crunch functions in the same way that Fortran crunches numbers, you can kick some serious ass.
Sure, you can find a Java implementation of a word processor, but will it last as long as Emacs? Is it as flexible? Is it as customizable? Is it as powerful? An Emacs based on Common Lisp (instead of its own crippled Lisp) would be even more of an improvement.
Any Java "word processor" is going to have a hard time beating MS Word at its own game. Emacs, however, thrives by playing another game, the "text editor" game. And it wins.
Lisp has toolkits like Common Lisp Interface Manager (CLIM) which are much more than simple layers to create windows with widgets. I can't even come up with a concise description of how different the Lisp idea is. (Some of this is my lack of practical experience with CLIM. I don't program GUI applications.)
Java is fine for relatively simple, solved problems (like GUI word processors). Lisp is for horrendously complex, hard-to-solve problems like managing logistics for airlines. Or bioinformatics
Or managing information in complex investigations and audits.
You'll notice that all of these are created to solve real-world problems, where it might not be obvious how a computer could help you. Word processing and 3D-shooters are all very securely "inside the box" of what computers are known to do, and have been done many times. Lisp is for taking on the world, forging into new territory, and kicking the world's ass. If you want to stay safe and do "yet another" of the same old thing, maybe Java is all you need.
First of all, the *747* is a 30 year-old technology, the DeHavilland Comet is 50 years old. 747s still get sold today and make a profit for their owners.
The reason a DC-8/747/777 got developed is because there was a huge *profitable* market for intercontinental flight. There is no corresponding market for space flight. There is a market; that is, people are willing to pay money to go into space. Unfortunately, it is not a profitable one. Not enough people are willing to pay enough to support the capital necessary to create the infrastructure.
There is a profitable market for satellite launches. By unmanned rockets, not by expensive Shuttle launchers.
The point is that you have to convince people with billions of dollars (for something on the order of a 777) to lend it to you so that you can design and manufacture the thing, with the idea that PROFITS from selling it will be enough to make it worth their while.
If there were an argument to be made for this, then it would likely have been made already, and you would be worried about spaceport security these days. The fact that manned spaceflight is still not a commercial reality probably means it isn't going to be any time soon.
Why spend billions of dollars to make a unprofitable activity slightly less unprofitable?
The 12C is a *much* older model. Also, it's less featureful than the RPN 17BII, for instance.
But a huge number of financial firms have standardized on the 12C. All that experience and training would go out the window if they switched to anything with new features. If it ain't *really* broke, don't fix it.
The large clamshell "Business Analyst" was their next financial calculator after the 12C. 17BII is the natural successor to the 12C. The 10C is an attempt to compete against the lower-end algebraic financial calculators.
The 12C is just kept around because firms keep ordering them.
OK. Totally unrelated story. A Motorola (making radios, not computer chips) guy was telling me, they made these radios for railroads. Motorola made some changes for a new model, including the case, and suddenly field returns started shooting way up. The railroad guys hated the new model.
A factory guy goes to investigate, says "hey, the new ones should perform much better. We've really improved the electronics, should be much higher reliability. What's the deal?" One of the railroad guys takes a radio in his hand. He says "sometimes, these railcar couplings don't always come apart right, so you have to whack em..." Lifts the radio, and ***WHAM!*** slams the bottom end against the hitch. "The new radios keep falling apart."
The advantage of RPN is more than just the raw number of keystrokes.
When I'm solving a real-world problem, usually I have the numbers (or you look them up when you need them), then I need to put them together semi-interactively. You look at the number on the screen, decide what the next step is, then do it.
RPN let's you type the number in, then decide what to do with it as you go. Algebraic/TI notation is only really useful when you've got a long formula on the page, and you want to read it left-to-right, parentheses and all, and just hit = at the end.
That happens a lot when you are a student who is just grinding through textbook problems, but hardly ever happens when you are thinking on your feet.
The levels of precendence used in the algebraic system are based on rules that make it easy to read equations on paper. There is no intrinsic reason why multiplication is higher precendence than addition, it just happens in practice to be most legible to write equations that way. When you're dealing with numbers, trying to get other numbers, the RPN stack let's you do things with the precendence that works best for thinking through the problem. APL has even a screwier behavior than RPN, but people who use it (I don't) swear it makes solving problems easier.
The Palm has serious limitations on screen size that prevent getting a useful number of keys on the touch screen, in addition to having a touch screen instead of the fine feel of the HP 11C/28C/32SII keys. (I haven't touched one of the newer 48/49 series, so I can't respond to someone claiming the 49G had squishy keys.)
I thought about trying to emulate the 11C/12C on the Palm, but the 11 keyboard is too large to fit on the screen, without even thinking about the fact that the keys each have three functions on them.
The holistic experience of using one of these fine calculators is just not easy to achieve on a Palm.
I don't care about graphing or solving equations or matrices or playing Quake on my calculator, I just want something with all the mathematical functions I need, plus RPN, that doesn't make me curse. The mid-range HPs are great for me.
Could it be that HP's calculators are so damn reliable they never sell replacements?
I'm still using my HP11C daily. Bought in 1987.
(I did dally with a 28C, and replaced it with the next rev. 28(?) when it was stolen, but I find the compact 1xC form factor ideal. The clamshell was too wide, the new 48,49 are too darn tall. And my 11C just won't quit.)
I did see a HP32SII die when a can of Coke was spilled on it.