If you want to be mean, you can always bring up this one:
Larry Wall never understood Lisp
Guido Van Rossum once read a book on Lisp
Yukihiro Matsumoto once read a book on Lisp and understood some of it
(from
http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg00829.html,
which contains a link to the "original" Usenet posting)
A language that took a lot more of the ideas from Lisp is REBOL
(www.rebol.com). It's actually a great little language, and I love
using it. However, once you really get into it, you realize just how
important those parentheses in Lisp are. :-)
Jeff M.
Stefan Scholl wrote:
> http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/179642
>
> Quote: "So, Ruby was a Lisp originally, in theory." :-)
>
Nice find. It says:
> Hi,
>
> In message "Re: Ruby's lisp features."
> on Mon, 13 Feb 2006 02:38:18 +0900, Edward Kenworthy <edward / kenworthy.info> writes:
>
> |I've been programming for more years than I care to remember and am
> |enjoying programming in Ruby (especially on Rails). So far I've found
> |nothing "new" (to me) in Ruby, with the exception of the lisp-like
> |features and that's something I'd really like to explore.
>
> |Anyone able to point me to a resource please?
>
> Ruby is a language designed in the following steps:
>
> * take a simple lisp language (like one prior to CL).
> * remove macros, s-expression.
Oops.
> * add simple object system (much simpler than CLOS).
Uh-oh.
> * add blocks, inspired by higher order functions.
Add?
> * add methods found in Smalltalk.
Add?
> * add functionality found in Perl (in OO way).
>
> So, Ruby was a Lisp originally, in theory.
> Let's call it MatzLisp from now on. ;-)
Bzzt. No code-as-data, no Lisp. Well, nice to see Matz paying backhanded
homage to Lisp.
Only he did not answer the OPs question, which was cool: "Hey, the only
thing interesting about Ruby are these Lisp features...". Is Matz afraid
everyone is going to dump Ruby and take up Lisp?
kt
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton wrote:
> Stefan Scholl wrote:
> > Ruby is a language designed in the following steps:
> >
> > * take a simple lisp language (like one prior to CL).
> > * remove macros, s-expression.
>
> Oops.
* add an idiotic read syntax that can't figure out whether it's Algol,
Fortran or C. Nested blocks end by mixtures of end } end end } } end
} ...
> > * add simple object system (much simpler than CLOS).
>
> Uh-oh.
Simple things for simple minds.
Kaz Kylheku wrote:
> Simple things for simple minds.
This need not be a Bad Thing. Most programmers probably only do simple
things, so it's a lot better to give them simple tools. Ruby resembles
Smalltalk pretty much--and this was designed for children. So I'd
actually recommend Ruby to those who refrain from learning Lisp. Or
Smalltalk/Squeak for kids. The smartest grown-up kids or anyone with
greater ambitions (and the capabilties mindwise) will sooner or later
discover that there may be better tools for the task. RtL tells you this.
Actually, I stopped advocating Lisp to "everyone". It's useless anyway
if it won't solve a specific problem they've got. Also, if people don't
actually want to learn The Lisp Way few of their contributions will be
of any use to the Lisp community.
Having all the smartest minds in the world be Lisp programmers would be
great, though. So never stop advocating Lisp or writing books about it. ;)
Thomas Schilling wrote:
> Kaz Kylheku wrote:
>
>
>>Simple things for simple minds.
>
>
> This need not be a Bad Thing. Most programmers probably only do simple
> things, so it's a lot better to give them simple tools.
<heh-heh> It's OK, you can give them powerful tools, they just won't use
them. We once discovered a programmer who had cut and paste code twenty
times rather than write a function in VAX Basic.
But, no, "simple tools for simple programmers" is a terrible approach.
The problem dictates the solution, not the tool. And if the tool cannot
implement the solution, game over. If you need multiple inheritance and
do not have it, hell, you need a better programmer, not worse.
Meanwhile, The Myth of the Man-Month math positively rewards a smaller
team of brighter people using a more powerful tool.
Finally, jeez, Lisp can be as simple as you want it to be. And when you
puts its most sophisticate tools to work, it gets even simpler. Go
figger. Anyway, Java, Python, and Ruby all got it wrong when they dumbed
down their languages, but that's OK, Lisp would have pushed them into
the sea anyway.
kt
--
Cells: http://common-lisp.net/project/cells/
"Have you ever been in a relationship?"
Attorney for Mary Winkler, confessed killer of her
minister husband, when asked if the couple had
marital problems.
Ken Tilton wrote:
> But, no, "simple tools for simple programmers" is a terrible approach.
> The problem dictates the solution, not the tool. And if the tool cannot
> implement the solution, game over. If you need multiple inheritance and
> do not have it, hell, you need a better programmer, not worse.
Ok, you're right. I was concerned about the problem of dealing with
error messages. When a user using only a subset of the language makes
an error and gets an error message that confronts him/her with some
complicated internals. See for example Haskell error messages or C++
template error message (it's three lines course of full expansion of the
templates). Or in lisp, say, you misuse PUSH and the compiler complains
somewhat like "(QUXGRIBBLE blub) is not a place".
But sensible error messages might be a special art for itself, so more
or less language independent. So it boils down to some environmental
issues. Anyone care writing and maintaining(!) an Eclipse (yuck) Plugin
for Lisp. (Ain't there already one.) No, I don't volunteer.
But really, I'd still prefer quality over quantity for Lisp hackers.
> Meanwhile, The Myth of the Man-Month math positively rewards a smaller
> team of brighter people using a more powerful tool.
Agreed.
-ts
Thomas Schilling wrote:
> Ken Tilton wrote:
>
> > But, no, "simple tools for simple programmers" is a terrible approach.
> > The problem dictates the solution, not the tool. And if the tool cannot
> > implement the solution, game over. If you need multiple inheritance and
> > do not have it, hell, you need a better programmer, not worse.
>
> Ok, you're right. I was concerned about the problem of dealing with
> error messages. When a user using only a subset of the language makes
> an error and gets an error message that confronts him/her with some
> complicated internals. See for example Haskell error messages or C++
> template error message (it's three lines course of full expansion of the
> templates). Or in lisp, say, you misuse PUSH and the compiler complains
> somewhat like "(QUXGRIBBLE blub) is not a place".
Something you can do is to run the code on several different CL
implementations (if you can). They tend to give different error
messages, which become informative when taken together
> But sensible error messages might be a special art for itself, so more
> or less language independent.
Yes, some of it certainly is.
(Also Macros should be written in such a way as to generate error
messages when given incorrect inputs, rather than generate incorrect
code.)
Hi Ken,
>>>>> "Ken" == Ken Tilton <·········@gmail.com> writes:
Ken> The Myth of the Man-Month math ...
Is that supposed to be a tongue-twister? :-)
'Andreas
--
Wherever I lay my .emacs, there's my $HOME.
On 2006-03-29, Ken Tilton <·········@gmail.com> wrote:
> Stefan Scholl wrote:
>> http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/179642
>>
>> Quote: "So, Ruby was a Lisp originally, in theory." :-)
>>
>
> Nice find. It says:
>
>> Hi,
>>
>> In message "Re: Ruby's lisp features."
>> on Mon, 13 Feb 2006 02:38:18 +0900, Edward Kenworthy <edward /
>> kenworthy.info> writes:
>>
>> |I've been programming for more years than I care to remember and
>> |am enjoying programming in Ruby (especially on Rails). So far
>> |I've found nothing "new" (to me) in Ruby, with the exception of
>> |the lisp-like features and that's something I'd really like to
>> |explore.
>>
>> |Anyone able to point me to a resource please?
So, did anyone point him over here, or maybe to PCL? :)
-- L
> Stefan Scholl wrote:
>> http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/179642
>> Quote: "So, Ruby was a Lisp originally, in theory." :-)
My favorite one is "Ruby is not as good as Lisp, but it's good enough
for ordinary people".
--
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (1) 53 14 59 22 ······@xemacs.org
Didier Verna wrote:
> > Stefan Scholl wrote:
> >> http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/179642
> >> Quote: "So, Ruby was a Lisp originally, in theory." :-)
>
> My favorite one is "Ruby is not as good as Lisp, but it's good enough
> for ordinary people".
That kind of argument is only compelling with physical tools. E.g. a
cheap camera with a fixed lens, and no through-the-lens viewfinder is
not as good as a professional model, but good enough for most people.
And, by golly, it costs much, much less!
If it didn't cost less, guess what? People wouldn't buy the inferior
item, unless they were stupid and liked throwing money away, or they
really, really needed some specific attribute of the smaller unit, like
its smaller size.
The crappy little programming language analogous to that shitty camera,
except that it doesn't cost less. And isn't really easier to use
either. Sticking with the analogy, the better camera has the
point-and-click simplicity to make it behave like the low-end one in
all the same situations.
What's worse, when you are dealing with physical goods like cameras,
when you go to the mass market crap that's good enough for most people,
your choices tend to increase rather than decrease. Things tend to get
more exclusive toward the higher end. But in programming languages,
when you go to the crappy low end, you are typically locked to a single
implementation. If you write any body of code in that language, only
one implementation will run it.
It's precisely this kind of choice that threatens the peddlers of
lesser languages. They have no place in an environment where there is a
mature language, because their lives revolve around the idea of
inventing some new syntax and using it to gather worshippers.
If you want to create crappy software that, in spite of itself, gathers
a religious following, the way to do that is by inventing a programming
language and implementation combo.
A crappy text editor won't do that. A crappy game won't do that. A
crappy operating system won't do that. Nope; if you have a mediocre
software talent combined with a craving for geek fame, your best
ticket is to make a crappy programming language. It's a nice trick.
Better programmers than you will wrestle with that language and make
things that work, and then those things that work will, guess what,
reflect nicely on /you/, even though you had little to do with it!
But have no place in Lisp, where you are reduced to a macro writer who
is on level ground with everybody else. Trouble is that Lisp is where a
lot of the good ideas are, and it's difficult to conceal your sources.
So you need some good-sounding wishy washy spin about why you aren't
just using Lisp, and why your followers shouldn't either. One argument
you can pull out, "Yes, I do know Lisp. But, people, if Lisp was so
great, I wouldn't have gone to all the trouble to create this new
thing? My only motivation is to create something better for myself than
what I have used before."
"Kaz Kylheku" <········@gmail.com> writes:
>
>> My favorite one is "Ruby is not as good as Lisp, but it's good enough
>> for ordinary people".
>
> That kind of argument is only compelling with physical tools. E.g. a
> cheap camera with a fixed lens, and no through-the-lens viewfinder is
> not as good as a professional model, but good enough for most people.
>
> And, by golly, it costs much, much less!
>
> If it didn't cost less, guess what? People wouldn't buy the inferior
> item, unless they were stupid and liked throwing money away, or they
> really, really needed some specific attribute of the smaller unit,
> like its smaller size.
But consider a counter-example: homebrewing. It's cheaper to make beer
using all-grain methods, and (sometimes much) more expensive to use
extract or grain-and-extract methods--and all-grain brewing isn't _that_
much more difficult. But it _is_ somewhat more difficult and requires
more attention to detail, and is far less common.
> The crappy little programming language analogous to that shitty
> camera, except that it doesn't cost less. And isn't really easier to
> use either.
I think that you're deceiving yourself there: Lisp pretty obviously has
a more difficult learning curve than other languages, at least for the
vast majority of people.
Not that it's not a better language; I firmly believe that. I also
believe that all-grain brewing is a better way to make beer. I'll even
say that most programmers should graduate to Lisp at some point in their
careers, just as most brewers should graduate to all-grain brewing. But
I can understand why members of both groups don't use the more advanced
methods.
--
Robert Uhl <http://public.xdi.org/=ruhl>
When anti-gun activists list the number of deaths per year from
firearms, they neglect to mention that 60 percent of the 30,000 figure
they often use are suicides. They also fail to mention that at least
three-quarters of the 12,000 homicides are criminals killing other
criminals in disputes over illicit drugs, or police shooting criminals
engaged in felonies. Subtracting those, we are left with no more than
3,000 deaths that I think most would consider truly lamentable.
Stefan Scholl <······@no-spoon.de> writes:
> http://ruby-talk.org/cgi-bin/scat.rb/ruby/ruby-talk/179642
>
> Quote: "So, Ruby was a Lisp originally, in theory." :-)
So he lost me at step two of his design process:
> Ruby is a language designed in the following steps:
>
> * take a simple lisp language (like one prior to CL).
> * remove macros, s-expression.
-Peter
--
Peter Seibel * ·····@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/