My experience was a lot different. I found some of the doors clumsy if you approached them running, which was doubly annoying since the only time I ran in that game was when I was being chased by a gang of machine-gun wielding guards. I liked the challenge of the no-save gameplay. The saves in Hitman II definitely changed my playing style. The only time I found it annoying was when I had to replay the Rotterdam docks mission twice (nailed it on the 2nd time). I did the Honk Kong boss assasination mission the plain old poison way, and had no problems, so I can't really comment. I thought Hitman II was worse in terms of illogical and just plain linear mission situations than Hitman. The Malaysian twin towers missions were particularly frustrating and disappointing. Now as far as eyes in the back of the head, I thought Hitman II was far worse in that respect. Whereas in Hitman, the garotte was my most used weapon, in Hitman II I abandoned it's use entirely after fumbling around with the thing on the first level. Knives were useless as well (but the katana was pretty entertaining for a while). That was pretty disappointing. I haven't played Hitman Contracts yet, but I'm looking forward to it.
He did great stuff in the 1970s inventing SmallTalk, developing graphics GUIs, a formulating the "Dynabook", the early PDA.
Yeah, and he did this all single-handedly in his spare time. Please give credit where credit is due, as Xerox PARC was at the time one of the best R&D labs in the world, and employed several hundred people.
This stimulated Jobs and Gates to commercialize graphical computing and OOP-based OS's.
Since when are Windows and MacOS OO-based?
Kay... missed "industrial-strength" OOP
Here's what Kay said when someone showed him Oberon:
"So, it doesn't seem to me like it's object-oriented".
To which the presenter huffily responded,
"Well, who's to say what's object-oriented and what's not?"
At this point the person replied,
"I am. I'm AlanKay and I invented the term."
Here's what Alan says about C++:
"I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."
Here's what Alan says about Java (he really has a lot to say about Java).
It seems to me that "industrial-strength" OOP missed the whole point of the OO.
Kay... missed the significance of the Web
For a man who was involved in the Arpanet effort in the 1960s and Ethernet in the 1970s, I say he didn't miss too much about the web.
Kay... missed the significance of... PDAs
Two sentences before, you just claimed he invented the things! Well, not only that, but if you actually read Kay's PhD Thesis, you'd know that the invention was motivated by actual applications! Today's PDAs are fancy toys for adults with too much money, rather than the powerful exploratory tools that Kay imagined them to be.
Kay... missed... cellphones
Alan Kay is a computer science researcher. There's nothing particularly interesting or revolutionary about circuit-based analog phone networks.
The Gore-Gates initative to make the Web available in every school and library by year 2000 did far more for children computing access than SmallTalk and eQuariums.
But you just claimed that Gates ripped off Alan Kay! How would he have made his fortune otherwise? Where would the web be without the bitmap display? And what the fuck does Kay have to do with eQuariums??
Lets see if the moderators can distinguish a contrarian opinion from troll-bait.
Moderators, you have failed again.
Oh, and if you're actually interested in what Kay has been up to, watch the video linked as Kay's Java comments. The man's been damn busy, and I hear that later this year there will be a public release of his current project, Croquet.
LISP tried to replace flow control with function calls, yet this didn't become the dominant programming model. People who swear by it end up using functions like apply that implement flow control statements like foreach.
It really should be noted that McCarthy first invented flow control statements in Lisp. The main difference between foreach and map (apply is used to apply a function to some arguments) is the scope of the variable to which each is bound, modularity concerns aside. Pretty much any Lisp aside from Scheme and derivatives has imperative, block-scoped iteration constructs as primitives.
Generally, error messages and debugging in Lisp are a lot better than in most other languages because it has a well specified way to print out (and read back in) many built-in data structures, and any combination thereof. In a typical Common Lisp implementation, all syntax errors are caught by the compiler (unless the function being referenced has not been defined yet). Variables not lexically bound give a warning (since they may be present when the code runs). While type checking is done at run-time, most Lisp compilers do type inference and will warn about some type errors. Since errors don't unwind the stack, you can examine the whole calling history if an error occurs (complete with printed argument lists). Many system errors are continuable - that is, you can change whatever was causing the problem in the source code, recompile the erring function, then change the data in the current invocation of the function, and the debugger will back off to the last point before the error and continue running the program with the changes. All program-generated errors can be specified to be continuable. Because macros are expanded at compile time, the regular run-time exception mechanism can be used by them to cause customized compile-time error behavior.
The misanthropes that took over comp.lang.lisp are pathetic. I've never seen a techical discussion group that hostile and defensive.
Ah, I see. You probably made the mistake of phrasing a question as an assertion that something is broken in Common Lisp. Not only do the denizens of c.l.l. look unfavorably on that, but many of them have been involved in the design of Common Lisp, and may take such inflammatory statements as reflections on the quality of their work. I see you're still upset by the experience. Grow a thicker skin, and next time read some messages in a newsgroup before posting to it.
Common Lisp fossilized sometime back in the Reagan Administration and has since lost almost all ability to improve.
As a result, the vast majority of former users have abandoned it and those who remain almost have to take a position that there is no further NEED for improvement except in trivial ways (more libraries, more "complete" implementations, etc.) that, if you think about it, are merely restatements of the "nothing needs to be improved" notion.
Have you ever worked with an ANSI standards committee? Do you want to pay $700 per year (travel expenses not included) to sit around while someone doesn't show up or vetoes your decision? Neither does anyone else involved with Common Lisp (that's why almost all of those involved dropped out by 1990).
Arc is announcementware. It has shown no signs of life since its first few weeks.
You link to Paul Graham's website, but obviously you don't realise that Arc is still in planning. The ICFP committee doesn't agree with you either, as this year Paul is one of the invited speakers.
There are several dozen different Schemes, all incompatible, with an average of maybe 1.1 implementers each.
You know, I'm starting to hear more and more people complain about the lack of the "one true" implementation of Lisp. This is where I think Scheme comes in. Pick one implementation and stick with it. Personally, I'm rooting for DrScheme, but the GNU people seem to be doing a mighty fine job with Guile.
Of course, if you really want a one-implementation, brand-spanking-new (no compatibilities here, sir!) Lisp, then by all means check out newLISP.
Your argument is fine and dandy for many languages with syntactic hair in the drain, but unfortunately it does not apply to Lisp, because S-expressions impose a rigid grammar on the syntax. It's all (operator operands). Furthermore, the standard prohibits the redefinition of Common Lisp symbols, so any package (namespace) that wants to do so must explicitly declare those symbols it is shadowing, a list of which is also available at runtime (this applies to any other user-created packages that package is using as well). In this respect C++ is just poorly thought out. In any case, your argument is a straw man when it comes to Lisp.
PS - If you think C++ operator overloading is confusing, wait until AOP takes off in Java-land.
O'Reilly's and Levenez's original charts include a number of errors and omissions. Many have already been pointed out by other posters, but I'll nonetheless compile my own list, in the order of what I think is decreasing importance. Guide to the symbols used: $ Error in both charts. * Error in O'Reilly's chart.
$ - CLOS is listed as a separate language. The Common Lisp Object System, as it's name implies, is an object-oriented extension to Common Lisp. Why they thought it was a separate programming language is beyond me.
$ - No ANS Forth. The ANSI Forth specification was ratified in 1994, and is known as ANSI X3.215-1994.
$ - No Lisp dialects between 1.6 and Common Lisp. This is an incredibly glaring omission. There were a number of widely used, divergent dialects of Lisp after 1.6, the chief two being MIT's MACLISP and BBN/Xerox Interlisp, both of which were used well into the 80s and had a major influence on Common Lisp, among other languages. This is not to mention the other dialects of Lisp left out (the principal ones I can think of are Portable Standard Lisp, EU_LISP, Le Lisp, Lisp Machine Lisp).
$ - No ISLISP or XLISP. ISLISP became an ISO standard in 1997, and is a subset of Common Lisp with additions from several European Lisp dialects. XLISP, on which AutoLisp is based, became available for PCs in the late 80s, and due to the popularity of AutoCad was for a time the most widely used dialect of Lisp.
$ - No StarLogo. StarLogo is a parallel version of Logo which was developed at MIT in the late 90s. It's used in a lot of grade-school computer courses.
* - Haskell has an arrow pointing to CLOS. Not only is CLOS it's own language, apparently it is also a purely functional one. Again, where this was pulled out of remains a mystery.
$ - No R^3, R^4 Scheme revisions. PHP has a box for every 0.0.x revision. They could have at least acknowledged the major revisions of other languages (and of course Scheme is not the only language this applies to!).
$ - No Squeak. Squeak is a derivative of Smalltalk started by Alan Kay and Dan Ingalls (among others) in 1994. Today it is the most popular Open Source Smalltalk.
There are also a lot of languages that can be included, like Carl Hewitt's PLANNER (MIT's precursor to Prolog) and ACTORS (a purely message-passing object-oriented formalism that predated Smalltalk, and had several implementations and a lot of influence on other object-oriented languages).
All in all, I think both charts are pretty lame. O'Reilly should have at least solicited public comments before producing such a factually erroneous telling of history. This is altogether more surprising considering that O'Reilly is not a general publisher but instead specializes (in what they claim are) accurate technical manuscripts.
... better alternatives exist such as ML and Haskell... functional programming... since Haskell is pure via Monads and has a more powerful type system.
There seems to be some confusion. Many people think that Lisp is a functional language, for some inexplicable reason. But in Lisp, when you need goto, you've got goto. Functional purity is mighty fine if someday someone will figure out how to actually apply it to anything resembling automatic programming verification, but until that day comes, a multi-paradigm language will always be more convenient. As for having a more powerful type system, I'm sure that Haskell programmers never ever miss the ability to find the type-of an object.
AutoLisp is based on an early version of XLISP (which isn't on the chart either). Given that AutoLisp was probably the most widely used dialect of Lisp, it really should get it's own little box and arrow.
I know Lisp is not the ideal language - its ugly, illegible, and slower than compiled languages
Well, Lisp aesthetics are a personal opinion (but you really shouldn't knock it until you've tried it), but your implication that Lisp is slow and not compiled is wrong.
The vast majority of Common Lisp implementations have either a native code or through-C compiler, and at least two (Corman Lisp and SBCL) of them only come with a native code compiler.
Scheme seems like it has lost the intelligent simplicity of Python in favour of clumsy "special character" based syntax,
Yes, the Scheme standard certainly has a lot of "special character." But if you don't like to write '(bar baz), you can do (quote (bar baz)). Does that make it any better?
while Common Lisp has many detractors that don't complain much of details. Is your complaint about Common Lisp based on all Lisp variants? Or is CL especially bad?
I've looked at a lot of pro- and anti- Common Lisp propaganda, and it seems that the latter is almost entirely written by those who have no experience with the language. Many is of the type, "Oh, look, the CL spec is 1500 pages, so the language must be complex," which is of course rubbish, because for one thing it was based off of Guy L. Steele Jr.'s Common Lisp the Language book, and Harbison and Steele's C: A Reference Manual is 500 pages, while the actual C specification (not written by Guy Steele) is something like 250 pages. The ANSI Common Lisp specification also includes detailed examples for many functions. What this means is that while the C specification (only available from somewhere in ANSI/ISO for at least $20) is only useful to compiler writers, the Common Lisp specification (available in TeX and hypertext form for free over the Internet as the Hyperspec) is the definitive reference for all language users (all the Emacs-based CL IDEs have keybindings to look up terms in the Hyperspec).
Of course, your own assertion that Lisp is ugly and slow is stated authoritatively, even while you admit that you've "not coded a line yet," certainly could give someone the wrong impression.
Currying didn't come from Lisp, but from ML or maybe Haskell (certainly the Haskell proponents seem to emphasize the wonders of currying a lot more than their ML counterparts). I'm familiar with a number of Lisp dialects, and none feature currying as a built-in feature, as it's mostly regarded as infrequently used syntactic sugar (between macros and good old fashioned sequential assignment, there's not a whole lot that can be done nearly as efficiently or succinctly with currying, and of course the currying operator itself is easy enough to implement using the former).
One thing that really should be noted (and hasn't been, as far as my browsing cutoff of 1 tells me) is how different the 1958 Lisp is from ANSI Common Lisp. Lexical scoping for functions, an extensible type tower, and object-oriented exception handling are really big concepts, none of which were possible in 1958 Lisp. What today are known as macros did not appear until the late 60s, and then in a very different form.
Someone mentioned Fortran, and the situation is exactly the same. The original Fortran was limited to 6 character variable names (the first one of which was used for manifest typing) and had no real conditionals!
What both have in common is evolutionary growth through the support and input of their user communities. What differs between them is the relatively linear progression of Fortran, and the wild branching out and subsequent collision of Lisp (which unfortunately is completely absent from either Levenez's or O'Reilly's charts). It'll be interesting to see what will happen to the overabundant weedy garden of today's scripting languages in the same span into the future.
Although i have never programming, my first college leve CSCI class used SCHEME (a direct descendant of Lisp if i remember correctly) as the language.
Scheme is not an acronym, and it's not a descendant of Lisp. It's a Lisp-like language that borrowed and extended the idea of lexical scoping from Algol, and kept some of the good ideas of Lisp (such as the syntax and source code representation).
This language is structed very difficult for a new computer science student to easily understand.
I disagree. I first learned Scheme (and computer programming) in the introductory CS class at Stuy, and I don't recall that anybody in the class had any problems (I certainly had a lot of fun!). I abandoned computer programming for two years after taking the class, until I read about Abelson and Sussmans' Structure and Interpretation of Computer Programs somewhere. Within a week of picking up that book, I not only had a firm grasp of the language, but a much better understanding of programming and recursion as well.
The endless parenthesis does not help either.
Scheme was invented in 1975, well after glass teletypes first became available. I suggest to anyone using or learning Scheme that they avail themselves of a full-screen display editor with such advanced capabilities as character blinking (to help match parenthesis, among other things).
And, on top of this, the language is completely dead!
I much rather would have learned an assembly language. This would have given students a better feel for the hardware and would have had useful applications.
You obviously didn't have SICP as your course textbook. In chapter 5, you first write a simulator for a simplified register machine, and then write a simplified Scheme compiler targeting it.
Smalltalk was an interesting experiment, but every single feature smalltalk touts as being great inventions has been around for ages in Lisp (with CLOS obviously).
Except that by the time the CLOS effort began, Smalltalk-80 was already over six years old. The first precursor to CLOS, Flavors, was explicitly influenced by Smalltalk and it's ideas of inheritance and message-passing (this is acknowledged by the system designers in published literature). What is significant about CLOS is the ways in which it advanced over Smalltalk. First, there was Flavors, with the concepts of multiple inheritance to enhance reuse and modularization, and method combination (which is now one of the central tools of Aspect-Oriented Programming). Then, Xerox's LOOPS introduced the idea of multimethods, which showed that not only was message-passing not needed for Kay's definition of OO, but there was a better way to use the type system for object behavior.
If sucess is measured by longevity, COBOL & Fortran are the most sucessful programming systems in history.
The problem here is in the definition of system. FORTRAN and COBOL are programming languages - the systems for programming in them have changed drastically over the years, from punched cards to teletypes to full-screen glass teletypes. The Unix command line, on the other hand, has pretty much stayed the same since it was introduced. You can only type in the current prompt, editing the prompt is awkward, and previous input and output scrolls up off the screen. The three biggest changes have been job control (so you can edit your command line with vi), pipes, and editing-friendly shells (tcsh has nice key-bindings borrowed from Emacs for moving point, deleting, etc.). I think they were introduced in that chronological order, although I could be mistaken.
Smalltalk-80 and Lisp didn't fail because there was some grand conspiracy against them, they failed because people voted with their feet... general-purpose macros are out--language designers made deliberate decisions not to include them in Java, C#, and similar languages.
This is why I still regularly hear people complain about the lack of even a simple, C-like preprocessor in Java.
Terry Winograd wrote a paper, called Breaking the complexity barrier (again), in 1973 (it is reprinted as the first paper in Barstow, Shrobe, and Sandewall's excellent compilation, Interactive Programming Environments, 1984). In it he described the integrated programming environment of the future, speculated on the role AI would play in it, described the importance of extendable syntax and the need for data-code representation, and noted that all this would need to be deeply and intimately interconnected, all the while taking a technology agnostic view.
Where Wilson goes wrong is in assuming that this kind of environment will be built based on plug-ins. The interrelationships needed between the components to get the required level of functionality are too great. What many people have already noted is that the current Unix environment is in fact based on plug-in development. Editors, debuggers and compilers are modularized as programs, with clean lines of communication between them in the forms of files and streams (which Unix again abstracts to one concept). The limitation of this system lies in the fact that the modules all use their own separate address spaces, and hence each one has to have a private representation of the program. This can't be mitigated by having the separate tools communicate to a central database (this is the most that Wilson's proposal of using XML as the underlying format can accomplish), because then the method of communication would be the limiting factor. Of course, you can use the neutral code-data representation to make the communications between the modules and the database be in terms of sending closures (from reading the paper, I don't think Wilson even considers this), but then you've just designed a single distributed address space, and in the process removed all the encapsulation and modularity advantages of the communication links (not to mention introducing a whole slew of concurrency issues)!
One such integrated system has been built in the past, called Interlisp. Barstow, Shrobe, and Sandewall's book (mentioned above) has a few papers that describe the system, but briefly a few lessons can be distilled from it. First of all, the system itself was an integrated development environment for a dialect of Lisp, where everything was done in one in-core address space: source code (including comments) was represented by data structures in memory, upon which the structure editor (residing in the same address space) operated directly. Code could either be interpreted from the data structure or compiled by the (yes, in-core) compiler. There were several extended packages (besides a Lisp macro-like facility), notably the structure editor and "Conversational LISP," a pseudo-natural language command-prompt parsing system. Although source code (and data) could be serialized to files (there was a sophisticated change-tracking facility that took care of this), the usual way of working was by saving the core image to disk and loading it next session, so the whole environment was persistent. There were hooks for everything from the parser to the compiler to error handling down to the most basic frame-handling code of the stack-based VM, and in order to implement the facilities mentioned above (and some other ones I left out, like the ever-present DWIM automatic error-correction facility) the code took full advantage of them. This caused some trouble when it came to portability of the components and the Interlisp itself (the heavy interdependence caused many problems in bootstrapping the system). Some of these incidents are documented in Barstow et al.'s book, but the Interlisp bootstrapping difficulty has been mentioned in all of the Interlisp porting papers I've read. Unfortunately, I don't think a system with those capabilities can be built with the rescrictions of modularization, since all of the things it did are applicable to programming in any language, and to do them required precisely the
Cray was the prototype of the Real Programmer.
on
Hardcore Java
·
· Score: 1
The operating system (the proper terminology would probably be "monitor") for the CDC 6x00 computers was manually disassembled into symbolic assembler from the octal code Cray and his team wrote for it. According to folklore, they had a strong dislike of anything to do with programming. Another thing I've recently learned about Cray is that he designed the Cray 1 and several subsequent models as a semicircle of cabinets because he liked to meditate in the alcove they formed. If nothing else, Seymour Cray was the prototypical eccentric genius.
In case you didn't notice by his frequent mentioning of it, or by watching Roger and Me, Michael Moore was born and raised in Flint, Michigan, which last time I checked was in the US of A. Now what's all this about Greek gods?
If anybody wants to try out Xerox's Unistroke alphabet, a simple text editor that's trained to recognize Unistrokes is part of the demos that come with Garnet (source comes under a public domain license). Personally, I'm not too impressed, but then again, I find the whole notion of pen computing more of an annoying throwback to the 60s than anything else.
Tell that to people who live above 9,000 feet -- in the dead of winter.
I emailed John and Mary about this very same thing in January, but haven't heard anything back yet. I hope they didn't freeze to death.
To be serious, what the other poster said about electrical plug-ins is perfectly correct, and they work quite well at -40 degrees Celsius (ok, this is the same as it is in Fahrenheit, but the fact is almost everyone here in Calgary has one on their car, and it does get that cold on occasions). Put your car in an enclosed garage (it doesn't have to be heated, just keep the wind and snow out) and you won't have any problems at all.
There are probably better books written on the subject, but I've read Jamie Kassler's Music, Science, Philosophy: Models in the Universe of Thought, which deals extensively with automatic music generation in the past several hundred years. There have indeed been dice-based, rule-based and wind-up based music generation systems going all the way back to the 16th century, and the basic ideas stem all the way from Plato.
Re:There are many better alternatives to PHP
on
Hardened PHP
·
· Score: 1
I'm sorry, but I think you're nuts.
Thank you.:)
Not to specifically knock the other choices you mention, but I think plenty of people feel that PHP has a far less annoying and convoluted syntax than say Perl or Lisp, which you seem to be advocating instead of PHP.
Well, that is why I said "annoying," instead of "bad" or "stupid" or something absolute like that.
And you say you have a "superficial familiarity" with PHP, yet knock PHP for a lack of Speed... Try it, you might be surprised (especially if you use a compilation cache like Turck MMCache). Why do you think every other random interpreted language is going to be way faster than PHP?
When I don't know any better, I go by the Computer Language Shootout for data (unfortunately, it is the best I've yet to find). Turck MMCache sounds neat. My opinion of PHP's speed has a lot to do with my opinion of it's syntax and semantics - I think they would make compilation and optimizations unnecessarily difficult. Most other recent lightweight languages are more uniform in these respects, and I think it shows with the (relatively) good speed of their bytecode output.
The only point I won't argue strongly is the security aspect. I don't think PHP is as bad as everyone is claiming if it is set up properly, but it isn't perfect - in particular too many ease-of-use features have been added that can chuck any semblance of security right out the window...
This is the only point I didn't really raise, because I think that the security shortcomings of PHP can be fixed with better design and implementation without compromising any of it's other qualities or backwards compatibility (indeed, good design will only improve most of the other aspects of the language implementation).
Slashdot Mirror
My experience was a lot different. I found some of the doors clumsy if you approached them running, which was doubly annoying since the only time I ran in that game was when I was being chased by a gang of machine-gun wielding guards. I liked the challenge of the no-save gameplay. The saves in Hitman II definitely changed my playing style. The only time I found it annoying was when I had to replay the Rotterdam docks mission twice (nailed it on the 2nd time). I did the Honk Kong boss assasination mission the plain old poison way, and had no problems, so I can't really comment. I thought Hitman II was worse in terms of illogical and just plain linear mission situations than Hitman. The Malaysian twin towers missions were particularly frustrating and disappointing. Now as far as eyes in the back of the head, I thought Hitman II was far worse in that respect. Whereas in Hitman, the garotte was my most used weapon, in Hitman II I abandoned it's use entirely after fumbling around with the thing on the first level. Knives were useless as well (but the katana was pretty entertaining for a while). That was pretty disappointing. I haven't played Hitman Contracts yet, but I'm looking forward to it.
From 1984 to 1996 Alan Kay was an Apple Fellow. Following that, he was a fellow at Walt Disney Imagineering. I think he became an HP Fellow in 2001.
"So, it doesn't seem to me like it's object-oriented".
To which the presenter huffily responded,
"Well, who's to say what's object-oriented and what's not?"
At this point the person replied,
"I am. I'm AlanKay and I invented the term."
Here's what Alan says about C++: "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind."
Here's what Alan says about Java (he really has a lot to say about Java).
It seems to me that "industrial-strength" OOP missed the whole point of the OO.
For a man who was involved in the Arpanet effort in the 1960s and Ethernet in the 1970s, I say he didn't miss too much about the web. Two sentences before, you just claimed he invented the things! Well, not only that, but if you actually read Kay's PhD Thesis, you'd know that the invention was motivated by actual applications! Today's PDAs are fancy toys for adults with too much money, rather than the powerful exploratory tools that Kay imagined them to be. Alan Kay is a computer science researcher. There's nothing particularly interesting or revolutionary about circuit-based analog phone networks. But you just claimed that Gates ripped off Alan Kay! How would he have made his fortune otherwise? Where would the web be without the bitmap display? And what the fuck does Kay have to do with eQuariums?? Moderators, you have failed again.Oh, and if you're actually interested in what Kay has been up to, watch the video linked as Kay's Java comments. The man's been damn busy, and I hear that later this year there will be a public release of his current project, Croquet.
Generally, error messages and debugging in Lisp are a lot better than in most other languages because it has a well specified way to print out (and read back in) many built-in data structures, and any combination thereof. In a typical Common Lisp implementation, all syntax errors are caught by the compiler (unless the function being referenced has not been defined yet). Variables not lexically bound give a warning (since they may be present when the code runs). While type checking is done at run-time, most Lisp compilers do type inference and will warn about some type errors. Since errors don't unwind the stack, you can examine the whole calling history if an error occurs (complete with printed argument lists). Many system errors are continuable - that is, you can change whatever was causing the problem in the source code, recompile the erring function, then change the data in the current invocation of the function, and the debugger will back off to the last point before the error and continue running the program with the changes. All program-generated errors can be specified to be continuable. Because macros are expanded at compile time, the regular run-time exception mechanism can be used by them to cause customized compile-time error behavior.
Of course, if you really want a one-implementation, brand-spanking-new (no compatibilities here, sir!) Lisp, then by all means check out newLISP.
PS - If you think C++ operator overloading is confusing, wait until AOP takes off in Java-land.
There are also a lot of languages that can be included, like Carl Hewitt's PLANNER (MIT's precursor to Prolog) and ACTORS (a purely message-passing object-oriented formalism that predated Smalltalk, and had several implementations and a lot of influence on other object-oriented languages).
All in all, I think both charts are pretty lame. O'Reilly should have at least solicited public comments before producing such a factually erroneous telling of history. This is altogether more surprising considering that O'Reilly is not a general publisher but instead specializes (in what they claim are) accurate technical manuscripts.
AutoLisp is based on an early version of XLISP (which isn't on the chart either). Given that AutoLisp was probably the most widely used dialect of Lisp, it really should get it's own little box and arrow.
The vast majority of Common Lisp implementations have either a native code or through-C compiler, and at least two (Corman Lisp and SBCL) of them only come with a native code compiler.
Objectively, CMUCL can produce flotaing point code at least 5% faster than GCC on a non-trivial (the "Coyote Gulch" ephemeris calculator) benchmark. Of course, bechmarks are objective and misleading, and your assertion was subjective and misleading, and there's plenty of testimony (from real users writing non-trivial applications, not just some random bums paid off by the Scheme Underground) that Lisp is faster than C++.
Yes, the Scheme standard certainly has a lot of "special character." But if you don't like to write '(bar baz), you can do (quote (bar baz)). Does that make it any better? I've looked at a lot of pro- and anti- Common Lisp propaganda, and it seems that the latter is almost entirely written by those who have no experience with the language. Many is of the type, "Oh, look, the CL spec is 1500 pages, so the language must be complex," which is of course rubbish, because for one thing it was based off of Guy L. Steele Jr.'s Common Lisp the Language book, and Harbison and Steele's C: A Reference Manual is 500 pages, while the actual C specification (not written by Guy Steele) is something like 250 pages. The ANSI Common Lisp specification also includes detailed examples for many functions. What this means is that while the C specification (only available from somewhere in ANSI/ISO for at least $20) is only useful to compiler writers, the Common Lisp specification (available in TeX and hypertext form for free over the Internet as the Hyperspec) is the definitive reference for all language users (all the Emacs-based CL IDEs have keybindings to look up terms in the Hyperspec).Of course, your own assertion that Lisp is ugly and slow is stated authoritatively, even while you admit that you've "not coded a line yet," certainly could give someone the wrong impression.
Currying didn't come from Lisp, but from ML or maybe Haskell (certainly the Haskell proponents seem to emphasize the wonders of currying a lot more than their ML counterparts). I'm familiar with a number of Lisp dialects, and none feature currying as a built-in feature, as it's mostly regarded as infrequently used syntactic sugar (between macros and good old fashioned sequential assignment, there's not a whole lot that can be done nearly as efficiently or succinctly with currying, and of course the currying operator itself is easy enough to implement using the former).
Someone mentioned Fortran, and the situation is exactly the same. The original Fortran was limited to 6 character variable names (the first one of which was used for manifest typing) and had no real conditionals!
What both have in common is evolutionary growth through the support and input of their user communities. What differs between them is the relatively linear progression of Fortran, and the wild branching out and subsequent collision of Lisp (which unfortunately is completely absent from either Levenez's or O'Reilly's charts). It'll be interesting to see what will happen to the overabundant weedy garden of today's scripting languages in the same span into the future.
Where Wilson goes wrong is in assuming that this kind of environment will be built based on plug-ins. The interrelationships needed between the components to get the required level of functionality are too great. What many people have already noted is that the current Unix environment is in fact based on plug-in development. Editors, debuggers and compilers are modularized as programs, with clean lines of communication between them in the forms of files and streams (which Unix again abstracts to one concept). The limitation of this system lies in the fact that the modules all use their own separate address spaces, and hence each one has to have a private representation of the program. This can't be mitigated by having the separate tools communicate to a central database (this is the most that Wilson's proposal of using XML as the underlying format can accomplish), because then the method of communication would be the limiting factor. Of course, you can use the neutral code-data representation to make the communications between the modules and the database be in terms of sending closures (from reading the paper, I don't think Wilson even considers this), but then you've just designed a single distributed address space, and in the process removed all the encapsulation and modularity advantages of the communication links (not to mention introducing a whole slew of concurrency issues)!
One such integrated system has been built in the past, called Interlisp. Barstow, Shrobe, and Sandewall's book (mentioned above) has a few papers that describe the system, but briefly a few lessons can be distilled from it. First of all, the system itself was an integrated development environment for a dialect of Lisp, where everything was done in one in-core address space: source code (including comments) was represented by data structures in memory, upon which the structure editor (residing in the same address space) operated directly. Code could either be interpreted from the data structure or compiled by the (yes, in-core) compiler. There were several extended packages (besides a Lisp macro-like facility), notably the structure editor and "Conversational LISP," a pseudo-natural language command-prompt parsing system. Although source code (and data) could be serialized to files (there was a sophisticated change-tracking facility that took care of this), the usual way of working was by saving the core image to disk and loading it next session, so the whole environment was persistent. There were hooks for everything from the parser to the compiler to error handling down to the most basic frame-handling code of the stack-based VM, and in order to implement the facilities mentioned above (and some other ones I left out, like the ever-present DWIM automatic error-correction facility) the code took full advantage of them. This caused some trouble when it came to portability of the components and the Interlisp itself (the heavy interdependence caused many problems in bootstrapping the system). Some of these incidents are documented in Barstow et al.'s book, but the Interlisp bootstrapping difficulty has been mentioned in all of the Interlisp porting papers I've read. Unfortunately, I don't think a system with those capabilities can be built with the rescrictions of modularization, since all of the things it did are applicable to programming in any language, and to do them required precisely the
The operating system (the proper terminology would probably be "monitor") for the CDC 6x00 computers was manually disassembled into symbolic assembler from the octal code Cray and his team wrote for it. According to folklore, they had a strong dislike of anything to do with programming. Another thing I've recently learned about Cray is that he designed the Cray 1 and several subsequent models as a semicircle of cabinets because he liked to meditate in the alcove they formed. If nothing else, Seymour Cray was the prototypical eccentric genius.
In case you didn't notice by his frequent mentioning of it, or by watching Roger and Me, Michael Moore was born and raised in Flint, Michigan, which last time I checked was in the US of A. Now what's all this about Greek gods?
If anybody wants to try out Xerox's Unistroke alphabet, a simple text editor that's trained to recognize Unistrokes is part of the demos that come with Garnet (source comes under a public domain license). Personally, I'm not too impressed, but then again, I find the whole notion of pen computing more of an annoying throwback to the 60s than anything else.
To be serious, what the other poster said about electrical plug-ins is perfectly correct, and they work quite well at -40 degrees Celsius (ok, this is the same as it is in Fahrenheit, but the fact is almost everyone here in Calgary has one on their car, and it does get that cold on occasions). Put your car in an enclosed garage (it doesn't have to be heated, just keep the wind and snow out) and you won't have any problems at all.
There are probably better books written on the subject, but I've read Jamie Kassler's Music, Science, Philosophy: Models in the Universe of Thought, which deals extensively with automatic music generation in the past several hundred years. There have indeed been dice-based, rule-based and wind-up based music generation systems going all the way back to the 16th century, and the basic ideas stem all the way from Plato.