Could it be that Lisp is taught poorly? Lots of people don't like calculus, even though they were taught it at school.
Could it be that freshmeat is not representative of the pinnacle of software engineering? That popularity is not the only possible outcome for a perfectly good language?
People who are open-minded enough to get used to the white-space significance of Python *ought* to be more than open-minded enough to accept Lisp syntax.
Why some of them get cranky and defensive when faced by Lisp is a great mystery to me. Maybe they only have room in their head for one language.
Assuming you are representing Smalltalk accurately, that seems to be a more "quirky" evaulation rule than most macros use.
How am I supposed to know that a simple expression like [i < 10], which looks like it should be a simple true/false test on the current value of i, somehow turns magically into a loop when followed by do? How am I supposed to know if it starts at 0? or 1? (That seems to be an artificial choice, after all there are plenty more integers like -1, -2, -3,..., hey, an infinite number, in fact!... which could satisfy that expression.) And how do I know that i takes only integer values?
Seems like any feature put in the language by a good language designer is fine by you, but the second anyone uses a Lisp macro to extend the language in a useful way...WHOA, YOU'RE GETTING QUIRKY!!! STOP IT, OR SOMEONE COULD LOSE AN EYE!!!
How about we just call all the Lisp programmers "language designers" and then they are allowed to get as quirky as they want?
Or how about you learn how Lisp programmers actually work or shut the fuck up about it?
You're obviously a troll, but the claim that C++ programmers "get the code out" faster than Lisp programmers is a huge laugh.
How long do you wait for a re-compile when you've modified a header in your program? Most Lisp implementations compile as fast as you can type control-x control-e into your Emacs.
Linear thinking, by the way, reads from the beginning (where things like "defun" and "let" and "loop" let you know what is going on, and the automatic indentation shows you the organization), and by the time you've read the last non-parenthesis item, you understand it all, and the final group of parenthesis is not needed any more.
You seem to read your code from the bottom of the screen going up. That could explain why you have trouble understanding Lisp programs. Try turning your monitor right-side up, and see if that helps.
Well, how about adding object-oriented programming to a language which previously did not include it?
Multiple pre-CLOS object-oriented extensions to Lisp were written using heavy-duty macrology.
How about adding Prolog-style logic programming to a language which previously did not include it?
You can do so in Lisp, and macros are the best tool for the job.
How about adding an English-like syntax for defining common looping constructs? Lisp's infamous LOOP macro could be and was developed by *users* who didn't have to wait for some language implementor to do it for them.
What about allowing simple application-oriented forms to declare and define multiple associated functions and data structures?
The basic fact is that Lisp programmers f*cking INVENTED the use of closures in programming, and they STILL PREFER MACROS by a large margin to implement control structures. Do you think they all are brainwashed, or stupid amnesiacs, or what? Does learning "defmacro" somehow block all memory of "lambda"? If it were just a matter of "good closure syntax", we'd use defmacro to define a nicer syntax and use it. But the plain fact is that the syntax is superficial---the expressive power is fundamental.
The code transformations possible greatly outnumber the total number of closures it is reasonable to ask a higher-order-function user to pass it. Furthermore, forcing the use of closures means the user of your utility has to jump through more hoops to use it, and makes your design more complicated.
Argh, Slashdot seems to have lost my post. Here I go again.
Your point was not missed.
Lisp can pass around functions as well, *without* any performance hit, because our anonymous functions are compiled to machine code in advance just like our named functions are. But--guess what?--we don't use that mechanism to implement control structures because it turns out to be LESS readable and LESS convenient than real Lisp macros.
You plainly *misrepresent* Lisp macros if you believe they are about moving basic operations to read-time instead of run-time. They are about implementing program TRANSFORMATIONS that obviously have to occur before compile-time, because, once the program is running, it is too late to transform it. (Although there is still plenty of dynamic behavior a running program to use, including compiling new code. But that is more along the lines of introspection and reflection, not code transformation.)
Argh, Slashdot seems to have lost my post. Here I go again.
I didn't miss your point.
Lisp can pass around functions as well, *without* any performance hit, because our anonymous functions are compiled to machine code in advance just like our named functions are. But--guess what?--we don't use that power to implement control structures because it turns out to be LESS readable and LESS convenient than real Lisp macros.
You plainly *misrepresent* Lisp macros if you believe they are about moving basic operations to read-time instead of run-time. They are about implementing program TRANSFORMATIONS that obviously have to occur before compile-time, because, once the program is running, it is too late to transform it. (Although there is still plenty of dynamic behavior a running program to use, including compiling new code. But that is more along the lines of introspection and reflection, not code transformation.)
Passing around functions is something Lisp is perfectly capable of doing. (And without any performance hit, because our anonymous functions are compiled to machine code just like our named functions.) But--guess what?--we don't use it to implement control structures, even though we could. One quickly finds that the function-passing style is LESS readable and LESS convenient than real Lisp macros.
You plainly misrepresent Lisp macros if you claim they are about moving basic operations to read-time instead of run-time. They implement program *transformations* that BY DEFINITION must occur at code-reading time (but before compile-time). By the time the program actually runs, it is too late to rewrite it, after all.
The point of Lisp macros is NOT run-time efficiency.
It is PROGRAM WRITING-time efficiency.
As a simple example, say you need a control structure which ensures that files are closed properly on abnormal exit. You can, of course write this with an
(let ((stream (open "foo.txt"))
(unwind-protect...your code to write stuff to foo.txt...
(when stream (close stream)))) ; this gets executed "no matter what"
But, you decide this is too hard to remember to do every time.
(with-open-file (stream "foo.txt")...code to work on foo.txt... )
That is, you have added a control structure to the language which transparently implements the otherwise annoying hassle of doing the right thing every time. The resulting code is more compact, MORE readable (because with-open-file replaces a verbose, spread-out unwind-protect form), and makes robust code EASIER TO WRITE.
You can do similar things to encapsulate database transactions, or what have you, or implement iterations over complicated data structures.
The way Lisp macros lead to program efficiencies is secondary: the macros are writing your program, and you can give them enough description of the problem with enough context for the macros to implement optimizations that would otherwise be a total pain to do by hand. Essentially, you write a compiler which takes your problem description and emits optimized Lisp code to solve the problem. Conventional compilers take source code and emit machine code. Lisp-based compilers take source code and emit Lisp code which is almost always in the form of machine code instructions. Macros make that kind of thing almost trivial to write.
Then, in a suitable init file (such as.xinitrc) you want to put a command
xmodmap $HOME/.xmodmap
to load it when you start up or just type it from the command line to try it out: You can do it one line at a time by using the syntax
xmodmap -e "keycode 72 = parenright bracketright"
Note: the alternative keysym syntax is a briar patch: it allows you to make all the keys which emit left brackets to now emit left parentheses, but then it doesn't offer you a way to change only the ORIGINAL left parenthesis key to emit a left bracket. Perhaps your xmodmap has a swap syntax, but my clunky Solaris environment does not. The keycodes are unfortunately not guaranteed to be portable, but hey, how many machines will you need to customize?
Yet, the Common Lisper's perspective is that the power to reshape the language to suit the problem (not to suit the individual user per se) is such a useful and time-saving innovation that no one should deprive the programmers of it. After all, people can write unreadable code in Fortran or C, but we don't take those languages away.
Crippling everybody because bad programmers would write bad code seems like winning the wrong battle. Which pretty much shows what side of the fence I live on.
To polarize it, "readability" doesn't count for much if we have to stick at the level of Dick-and-Jane. Faulkner and Joyce might be "unreadable" compared to Basic English, but you can't translate it back.
You can also get a real, live Lisp machine from Symbolics for something less than $1500 if you are willing to live with a MacIvory II processor in a 199x-era Macintosh.
http://lemonodor.com/archives/001190.html shows a November 1985 quote for a Symbolics 3675 with 474 MB disk, 8 Megawords of memory, 24-bit graphics card, monitor, and console, which came out to $124,900. (*after* a Christmas discount of roughly 30%)
Lisp machines were mostly HARDWARE machines which were designed to support Lisp efficiently. Nothing "virtual" about it. (Although the last survivor of the era, Symbolics Genera currently runs on a virtual machine on Digital Alphas that emulates the original Ivory processor.)
This was necessary at the time to support Lisp environments that were competitive in runtime performance with C/Fortran type software on conventional processors. Nowadays, the tradeoffs are different.
There was no concept of an identical Lisp environment executing on vastly different infrastructure. If you had a different processor, say a DEC machine, you had a different Lisp implementation.
It was generally possible to port basic Lisp programs between Lisp machine implementations and more conventional Lisp environments, but a lot of the joy of using the Lisp machines was that the OS and everything on the machine understood and was designed around Lisp, instead of an environment in which the basic OS was designed for conventional languages.
As for what Lisp is "good for", it is a general-purpose programming language. It's not particularly biased toward text or "binary", whatever that is supposed to mean.
Yes, SLIME implement Meta-. Emacs also implements Meta-. for C.
The difference is that (AFAIK) SLIME stops at the edge of the Lisp implementation, where Genera would keep going all the way down to the microcode executing on the hardware.
Your post makes me think I need to take a closer look at SLIME, though. I mostly use old-style ilisp-mode.
Yes, Lisp had OO added after Lisp was already a mature language. (Although it is included explicitly in the ANSI Common Lisp standard, so it's as much part of the language as CONS is.) So what? Common Lisp also added lexical scope to Lisp, but you can hardly tell Lisp wasn't this way from the creation.
*Except* for built-in Lisp functions not being extensible generic functions, you can hardly tell OO wasn't part of Lisp from the beginning. This flaw turns out not to be a big deal. The reason it is such a clean extension is mostly because the surgeons who added it on had the power of Lisp macros to design with.
To compare this to the Frankenstein-like addition that OO is to Perl or C++ is needlessly provocative. Language "surgery" doesn't have to be done with chainsaws.
However, [Python] does have a lot of the features that many of us liked about Lisp,
The comparison is a bit complicated.
From the starting point of, say, C++, Python has a lot of the same kind of appeal that Common Lisp does, and for many of the same reasons. In philosophy, however, the Pythonistas and the Lispniks seem to have much to disagree about.
For instance, it seems (from the noises I hear over in Lisp forums), that Guido actively works to eliminate Lisp-isms in favor of his own "clearer" syntax. Whereas the Common Lisp folks tend to keep stuff around *forever*, and if someone invents a clearer replacement, they migrate to it, but nobody cares much that the old stuff is left behind. However, Schemers like the "one elegant way instead of three different ways". Whether you consider Scheme to be a Lisp or not is a great way to start a flame war.
Where this matters most is in Lisp macros. (For the nth time, these have nothing to do with C preprocessor macros, rather, they let you implement language extensions using the full power of the language, and with seamless integration to the original language and other extensions). Lispniks would never give those up. Pythonistas seem to not understand what the big deal about macros is. Schemers don't like macros because it is possible to write buggy macros, and want their own elegant, bulletproof mechanisms to define language extensions. This is yet another great way to start flame wars.
Except a lot of the really powerful stuff (Genera), was developed commercially at Symbolics, which is still very much a commercially licensed product (although it comes with almost all source code.)
Think "ultimate programmer workstation" where you can get the source to *any* function in an API by hitting Meta-., and replace it with your own code, if you wish. And point to *any* object on the screen, and hit a mouse button, and the data object inspector lets you see and manipulate it.
At least from what I understand, this stage of development was a hundred man-years or more of improvement over the MIT Lispm stuff. But hey, maybe this is a start.
I always thought corporate (funded) research basically was "working out the details" as you call it and innovation was basically just ideas that flashed into the minds of people knowing a lot about something and thinking a lot about it.
Yes, but the way you get smart people to know a lot about something and to think a lot about it is to give them a stable, well-funded job which requires them to do that. Namely, make them a (corporate- or government-) funded researcher.
Then, you get the benefit of smart people working on tough "details" and the chance to catch any inspiration they might get as a bonus.
Your attitude seems to be "it's OK to be a total ignoramous because learning is just too damn difficult."
Which is prescription for raising a nation of fucking idiots.
Math is the *one* subject in which it becomes exquisitely clear what a logical argument is. Maybe if we actually taught everybody trigonometry, instead of reserving it for just the "smartest" kids, we wouldn't have so many people in America unqualified for anything beyond Walmart check-out clerk.
Your understanding of the legal system is as confused as your understanding of markets.
Key to the common law system is the *adversarial* nature of the process. The utilities get to hire whatever experts they can find to say whatever is in their favor. It's completely *un*scientific. And courts don't go sniffing around for cases that might be filed.
Also, your process requires actual harm *to occur* before compensation happens. How about we *prevent* the harm by regulation instead of fighting the utilities to pay our estates for our shortened lives?
If no one "owns" the oxygen that floats into your airspace, how do *you* come to own it? What about the oxygen that floats from your airspace into mine, do I get to breathe that, or do I have to bottle it and return it to you? Seems like you haven't thought this "everyone owns the air" all the way through. If the poisonous gas floats into your airspace, I guess you own that too.
And exactly how are the police supposed to protect your neighbors without protecting you? Drop all the felons off on the edge of your property, and point them your way? Sounds like a pretty negative externality to me.
I just recognized your slashdot handle, and I'm not surprised you have a totally warped idea of how markets should work. You've posted crazier ideas before.
Sitting around on your private land, you are taking advantage of the police who tend to prevent bandits coming to your door and "politely" asking to take away all your valuable goods. You breathe in oxygen and exhale carbon dioxide which could have been used by someone else. When you take a shit, you (hopefully) flush your waste into the public sewer, where it becomes someone else's problem. When you go to your well (privately drilled, right?) you take water from an underground aquifer that is shared with your neighbor. Sure hope some unidentifiable person didn't decide to inject a lot of benzene or dioxin or any other nasty carcinogen or mutagen down into the water table. I also hope your neighbor decided public sewers were worth the fees, and didn't just let it run downhill toward you.
Unless you can absolutely trace the pollution, polluters will just point the finger at each other; and, hey, if we can't force them to pay taxes, how are we going to force them to tell the truth?
"All that black stuff coming out of our smokestack? Perfectly harmless. Not even vaguely similar to the black stuff the plaintiff is coughing up in his phlegm. What's that? The plaintiff would like to take a sample? Why that would be a violation of our private property rights! How could the court support such tresspassing!"
The costs of such individual litigation would be enormous. And the likelihood that individuals would have the resources to take on huge utilities is low. It would entail virtually endless arguing about what fraction of your terrible respiratory disease was due to what emission of what substance on what date at what place, in order to penalize each polluter to the proper extent, not even considering the terrible burden of waiting until respiratory distress rises to the medically detectable level (in order to meet the burden of proof you set.)
Totally unworkable, except in your Ayn Rand fantasy-land.
Slashdot Mirror
Could it be that Lisp is taught poorly? Lots of people don't like calculus, even though they were taught it at school.
Could it be that freshmeat is not representative of the pinnacle of software engineering? That popularity is not the only possible outcome for a perfectly good language?
People who are open-minded enough to get used to the white-space significance of Python *ought* to be more than open-minded enough to accept Lisp syntax.
Why some of them get cranky and defensive when faced by Lisp is a great mystery to me. Maybe they only have room in their head for one language.
Assuming you are representing Smalltalk accurately, that seems to be a more "quirky" evaulation rule than most macros use.
..., hey, an infinite number, in fact! ... which could satisfy that expression.) And how do I know that i takes only integer values?
How am I supposed to know that a simple expression like [i < 10], which looks like it should be a simple true/false test on the current value of i, somehow turns magically into a loop when followed by do? How am I supposed to know if it starts at 0? or 1? (That seems to be an artificial choice, after all there are plenty more integers like -1, -2, -3,
Seems like any feature put in the language by a good language designer is fine by you, but the second anyone uses a Lisp macro to extend the language in a useful way...WHOA, YOU'RE GETTING QUIRKY!!! STOP IT, OR SOMEONE COULD LOSE AN EYE!!!
How about we just call all the Lisp programmers "language designers" and then they are allowed to get as quirky as they want?
Or how about you learn how Lisp programmers actually work or shut the fuck up about it?
You're obviously a troll, but the claim that C++ programmers "get the code out" faster than Lisp programmers is a huge laugh.
How long do you wait for a re-compile when you've modified a header in your program? Most Lisp implementations compile as fast as you can type control-x control-e into your Emacs.
Linear thinking, by the way, reads from the beginning (where things like "defun" and "let" and "loop" let you know what is going on, and the automatic indentation shows you the organization), and by the time you've read the last non-parenthesis item, you understand it all, and the final group of parenthesis is not needed any more.
You seem to read your code from the bottom of the screen going up. That could explain why you have trouble understanding Lisp programs. Try turning your monitor right-side up, and see if that helps.
Some slashdot server decided to freeze up and take an hour to include my posts. Sorry.
Well, how about adding object-oriented programming to a language which previously did not include it?
Multiple pre-CLOS object-oriented extensions to Lisp were written using heavy-duty macrology.
How about adding Prolog-style logic programming to a language which previously did not include it?
You can do so in Lisp, and macros are the best tool for the job.
How about adding an English-like syntax for defining common looping constructs? Lisp's infamous LOOP macro could be and was developed by *users* who didn't have to wait for some language implementor to do it for them.
How about a whole book's worth of code?
What about allowing simple application-oriented forms to declare and define multiple associated functions and data structures?
The basic fact is that Lisp programmers f*cking INVENTED the use of closures in programming, and they STILL PREFER MACROS by a large margin to implement control structures. Do you think they all are brainwashed, or stupid amnesiacs, or what? Does learning "defmacro" somehow block all memory of "lambda"? If it were just a matter of "good closure syntax", we'd use defmacro to define a nicer syntax and use it. But the plain fact is that the syntax is superficial---the expressive power is fundamental.
The code transformations possible greatly outnumber the total number of closures it is reasonable to ask a higher-order-function user to pass it. Furthermore, forcing the use of closures means the user of your utility has to jump through more hoops to use it, and makes your design more complicated.
Argh, Slashdot seems to have lost my post. Here I go again.
Your point was not missed.
Lisp can pass around functions as well, *without* any performance hit, because our anonymous functions are compiled to machine code in advance just like our named functions are. But--guess what?--we don't use that mechanism to implement control structures because it turns out to be LESS readable and LESS convenient than real Lisp macros.
You plainly *misrepresent* Lisp macros if you believe they are about moving basic operations to read-time instead of run-time. They are about implementing program TRANSFORMATIONS that obviously have to occur before compile-time, because, once the program is running, it is too late to transform it. (Although there is still plenty of dynamic behavior a running program to use, including compiling new code. But that is more along the lines of introspection and reflection, not code transformation.)
Argh, Slashdot seems to have lost my post. Here I go again.
I didn't miss your point.
Lisp can pass around functions as well, *without* any performance hit, because our anonymous functions are compiled to machine code in advance just like our named functions are. But--guess what?--we don't use that power to implement control structures because it turns out to be LESS readable and LESS convenient than real Lisp macros.
You plainly *misrepresent* Lisp macros if you believe they are about moving basic operations to read-time instead of run-time. They are about implementing program TRANSFORMATIONS that obviously have to occur before compile-time, because, once the program is running, it is too late to transform it. (Although there is still plenty of dynamic behavior a running program to use, including compiling new code. But that is more along the lines of introspection and reflection, not code transformation.)
I didn't miss your point.
Passing around functions is something Lisp is perfectly capable of doing. (And without any performance hit, because our anonymous functions are compiled to machine code just like our named functions.) But--guess what?--we don't use it to implement control structures, even though we could. One quickly finds that the function-passing style is LESS readable and LESS convenient than real Lisp macros.
You plainly misrepresent Lisp macros if you claim they are about moving basic operations to read-time instead of run-time. They implement program *transformations* that BY DEFINITION must occur at code-reading time (but before compile-time). By the time the program actually runs, it is too late to rewrite it, after all.
NO. YOU ARE ABSOLUTELY WRONG.
...your code to write stuff to foo.txt...
,pathname)) ,@body ,stream-sym (close ,stream-sym)))))
...code to work on foo.txt...
The point of Lisp macros is NOT run-time efficiency.
It is PROGRAM WRITING-time efficiency.
As a simple example, say you need a control structure which ensures that files are closed properly on abnormal exit. You can, of course write this with an
(let ((stream (open "foo.txt"))
(unwind-protect
(when stream (close stream)))) ; this gets executed "no matter what"
But, you decide this is too hard to remember to do every time.
So you invent (if it didn't already exist)
(defmacro with-open-file ((stream-sym pathname) &body body)
`(let ((,stream-sym (open
(unwind-protect
(when
Then, you can simply say
(with-open-file (stream "foo.txt")
)
That is, you have added a control structure to the language which transparently implements the otherwise annoying hassle of doing the right thing every time. The resulting code is more compact, MORE readable (because with-open-file replaces a verbose, spread-out unwind-protect form), and makes robust code EASIER TO WRITE.
You can do similar things to encapsulate database transactions, or what have you, or implement iterations over complicated data structures.
The way Lisp macros lead to program efficiencies is secondary: the macros are writing your program, and you can give them enough description of the problem with enough context for the macros to implement optimizations that would otherwise be a total pain to do by hand. Essentially, you write a compiler which takes your problem description and emits optimized Lisp code to solve the problem. Conventional compilers take source code and emit machine code. Lisp-based compilers take source code and emit Lisp code which is almost always in the form of machine code instructions. Macros make that kind of thing almost trivial to write.
You want to learn about xmodmap
.xmodmap) which has lines like
.xinitrc) you want to put a command
First, do xmodmap -pke
That will print out the current keymap you have.
Then, you want to find lines like
keycode 45 = 9 parenleft
keycode 46 = 0 parenright
keycode 71 = bracketleft braceleft
keycode 72 = bracketright braceright
(the lines show unshifted shifted)
Then, you want to create a file (call it
keycode 45 = 9 braceleft
keycode 46 = 0 braceright
keycode 71 = parenleft bracketleft
keycode 72 = parenright bracketright
Then, in a suitable init file (such as
xmodmap $HOME/.xmodmap
to load it when you start up or just type it from the command line to try it out: You can do it one line at a time by using the syntax
xmodmap -e "keycode 72 = parenright bracketright"
Note: the alternative keysym syntax is a briar patch: it allows you to make all the keys which emit left brackets to now emit left parentheses, but then it doesn't offer you a way to change only the ORIGINAL left parenthesis key to emit a left bracket. Perhaps your xmodmap has a swap syntax, but my clunky Solaris environment does not. The keycodes are unfortunately not guaranteed to be portable, but hey, how many machines will you need to customize?
Well, I can't argue with your phrasing.
Yet, the Common Lisper's perspective is that the power to reshape the language to suit the problem (not to suit the individual user per se) is such a useful and time-saving innovation that no one should deprive the programmers of it. After all, people can write unreadable code in Fortran or C, but we don't take those languages away.
Crippling everybody because bad programmers would write bad code seems like winning the wrong battle. Which pretty much shows what side of the fence I live on.
To polarize it, "readability" doesn't count for much if we have to stick at the level of Dick-and-Jane. Faulkner and Joyce might be "unreadable" compared to Basic English, but you can't translate it back.
Shift-0? What kind of stone age are you living in, man?
.
Remap your keyboard so the parentheses replace the (mostly useless?) square brackets.
Kind of like http://www.asl.dsl.pipex.com/symbolics/photos/IO/
You can also get a real, live Lisp machine from Symbolics for something less than $1500 if you are willing to live with a MacIvory II processor in a 199x-era Macintosh.
Didn't they used to cost more than $50,000 each?
http://lemonodor.com/archives/001190.html shows a November 1985 quote for a Symbolics 3675 with 474 MB disk, 8 Megawords of memory, 24-bit graphics card, monitor, and console, which came out to $124,900. (*after* a Christmas discount of roughly 30%)
The parent is very confused.
Lisp machines were mostly HARDWARE machines which were designed to support Lisp efficiently. Nothing "virtual" about it. (Although the last survivor of the era, Symbolics Genera currently runs on a virtual machine on Digital Alphas that emulates the original Ivory processor.)
This was necessary at the time to support Lisp environments that were competitive in runtime performance with C/Fortran type software on conventional processors. Nowadays, the tradeoffs are different.
There was no concept of an identical Lisp environment executing on vastly different infrastructure. If you had a different processor, say a DEC machine, you had a different Lisp implementation.
It was generally possible to port basic Lisp programs between Lisp machine implementations and more conventional Lisp environments, but a lot of the joy of using the Lisp machines was that the OS and everything on the machine understood and was designed around Lisp, instead of an environment in which the basic OS was designed for conventional languages.
As for what Lisp is "good for", it is a general-purpose programming language. It's not particularly biased toward text or "binary", whatever that is supposed to mean.
Yes, SLIME implement Meta-. Emacs also implements Meta-. for C.
The difference is that (AFAIK) SLIME stops at the edge of the Lisp implementation, where Genera would keep going all the way down to the microcode executing on the hardware.
Your post makes me think I need to take a closer look at SLIME, though. I mostly use old-style ilisp-mode.
Yes, Lisp had OO added after Lisp was already a mature language. (Although it is included explicitly in the ANSI Common Lisp standard, so it's as much part of the language as CONS is.) So what? Common Lisp also added lexical scope to Lisp, but you can hardly tell Lisp wasn't this way from the creation.
*Except* for built-in Lisp functions not being extensible generic functions, you can hardly tell OO wasn't part of Lisp from the beginning. This flaw turns out not to be a big deal. The reason it is such a clean extension is mostly because the surgeons who added it on had the power of Lisp macros to design with.
To compare this to the Frankenstein-like addition that OO is to Perl or C++ is needlessly provocative. Language "surgery" doesn't have to be done with chainsaws.
However, [Python] does have a lot of the features that many of us liked about Lisp,
The comparison is a bit complicated.
From the starting point of, say, C++, Python has a lot of the same kind of appeal that Common Lisp does, and for many of the same reasons. In philosophy, however, the Pythonistas and the Lispniks seem to have much to disagree about.
For instance, it seems (from the noises I hear over in Lisp forums), that Guido actively works to eliminate Lisp-isms in favor of his own "clearer" syntax. Whereas the Common Lisp folks tend to keep stuff around *forever*, and if someone invents a clearer replacement, they migrate to it, but nobody cares much that the old stuff is left behind. However, Schemers like the "one elegant way instead of three different ways". Whether you consider Scheme to be a Lisp or not is a great way to start a flame war.
Where this matters most is in Lisp macros. (For the nth time, these have nothing to do with C preprocessor macros, rather, they let you implement language extensions using the full power of the language, and with seamless integration to the original language and other extensions). Lispniks would never give those up. Pythonistas seem to not understand what the big deal about macros is. Schemers don't like macros because it is possible to write buggy macros, and want their own elegant, bulletproof mechanisms to define language extensions. This is yet another great way to start flame wars.
Except a lot of the really powerful stuff (Genera), was developed commercially at Symbolics, which is still very much a commercially licensed product (although it comes with almost all source code.)
Think "ultimate programmer workstation" where you can get the source to *any* function in an API by hitting Meta-., and replace it with your own code, if you wish. And point to *any* object on the screen, and hit a mouse button, and the data object inspector lets you see and manipulate it.
At least from what I understand, this stage of development was a hundred man-years or more of improvement over the MIT Lispm stuff. But hey, maybe this is a start.
I always thought corporate (funded) research basically was "working out the details" as you call it and innovation was basically just ideas that flashed into the minds of people knowing a lot about something and thinking a lot about it.
Yes, but the way you get smart people to know a lot about something and to think a lot about it is to give them a stable, well-funded job which requires them to do that. Namely, make them a (corporate- or government-) funded researcher.
Then, you get the benefit of smart people working on tough "details" and the chance to catch any inspiration they might get as a bonus.
This is a switch. When is the last time you heard of somebody worried about "perfect" software?
Online recommendation engines are not going to get perfect anytime soon.
(Oooh, lots of delicious troll lines come to mind. But I will restrain myself.)
Your attitude seems to be "it's OK to be a total ignoramous because learning is just too damn difficult."
Which is prescription for raising a nation of fucking idiots.
Math is the *one* subject in which it becomes exquisitely clear what a logical argument is. Maybe if we actually taught everybody trigonometry, instead of reserving it for just the "smartest" kids, we wouldn't have so many people in America unqualified for anything beyond Walmart check-out clerk.
Your understanding of the legal system is as confused as your understanding of markets.
Key to the common law system is the *adversarial* nature of the process. The utilities get to hire whatever experts they can find to say whatever is in their favor. It's completely *un*scientific. And courts don't go sniffing around for cases that might be filed.
Also, your process requires actual harm *to occur* before compensation happens. How about we *prevent* the harm by regulation instead of fighting the utilities to pay our estates for our shortened lives?
If no one "owns" the oxygen that floats into your airspace, how do *you* come to own it? What about the oxygen that floats from your airspace into mine, do I get to breathe that, or do I have to bottle it and return it to you? Seems like you haven't thought this "everyone owns the air" all the way through. If the poisonous gas floats into your airspace, I guess you own that too.
And exactly how are the police supposed to protect your neighbors without protecting you? Drop all the felons off on the edge of your property, and point them your way? Sounds like a pretty negative externality to me.
I just recognized your slashdot handle, and I'm not surprised you have a totally warped idea of how markets should work. You've posted crazier ideas before.
Sitting around on your private land, you are taking advantage of the police who tend to prevent bandits coming to your door and "politely" asking to take away all your valuable goods. You breathe in oxygen and exhale carbon dioxide which could have been used by someone else. When you take a shit, you (hopefully) flush your waste into the public sewer, where it becomes someone else's problem. When you go to your well (privately drilled, right?) you take water from an underground aquifer that is shared with your neighbor. Sure hope some unidentifiable person didn't decide to inject a lot of benzene or dioxin or any other nasty carcinogen or mutagen down into the water table. I also hope your neighbor decided public sewers were worth the fees, and didn't just let it run downhill toward you.
Unless you can absolutely trace the pollution, polluters will just point the finger at each other; and, hey, if we can't force them to pay taxes, how are we going to force them to tell the truth?
"All that black stuff coming out of our smokestack? Perfectly harmless. Not even vaguely similar to the black stuff the plaintiff is coughing up in his phlegm. What's that? The plaintiff would like to take a sample? Why that would be a violation of our private property rights! How could the court support such tresspassing!"
The costs of such individual litigation would be enormous. And the likelihood that individuals would have the resources to take on huge utilities is low. It would entail virtually endless arguing about what fraction of your terrible respiratory disease was due to what emission of what substance on what date at what place, in order to penalize each polluter to the proper extent, not even considering the terrible burden of waiting until respiratory distress rises to the medically detectable level (in order to meet the burden of proof you set.)
Totally unworkable, except in your Ayn Rand fantasy-land.
Note the $20/barrel figure depends on the cost of energy to produce the steam. It's not a fixed, universal figure.