Hello:
I am a beginner of Lisp, but from recent discussion it's not hard to
find the weakness of Lisp. That it,
1, the syntax of the language is not intuitive enough, which would
make people afraid of learning it.
2, the implementation decides too much, maybe it's because the
standard specification is outdated or the Lisp language itself is
heavily based on the implementation, and it's hard to find a decent
implementation on Win 32 platform( at least for me ).
3. it's hard to write effective and/or efficient lisp program, I
remember there are many advanced C++ or Java books, but even the
simplest lisp book is difficult enough so I think it would be harder to
find an advanced one.
Besides those obvious reasons, what really hurts Lisp is the lack of
connection to the real world. The world is evolving, now we have SOA
(Service Oriented Architecture), we have MDA( Model Driven
Architecture? ), and Lisp's best weapon, the powerful macroes, can be
replaced by simple code generators; dynamically typed is nice to
develop in the beginning, but in the end I think these types are fixed,
so that even with a better development speed, languages with static
types would eventually catched up with better performance, and the RAD
tool would really helps those static typed language more.
That is,
If a Lisp web application needs 3 months to develop, a Java web
application might take 6 months, but with the help of development
tools, Java web application can be shortened to maybe 4 months. Yes it
still takes more time than the Lisp one, but either it's easier to
extend with components that are ready, and it's easier to find people
to maintain the code.
From my own view, Lisp is a fun language with a steep learning curve,
and it's not that practical, what Lisp needs I think are
1, better FFI. What makes Ruby's libraries grow that fast, one reason
is the easiness to extend with C. I think currently it's hard to make
lots of project in pure Lisp, but lending from other languages (like C)
might be a shortcut.
2, syntax sugar. Though Lisp has a good macro system can define what
language you need, but what most people need is a readable syntax. If
there is a way to define some syntax with a more intuitive way, it
might attract more people.
3. integration. What makes Ruby succeed is not only the language
itself, but rubygems, ri, erb, drb, rdoc, rake, irb... all makes an
important part. That's outside the language, but it really helps the
language. Even with those tools, Ruby still needs a killer ap Rail to
become popular, and Lisp I think lacks more in these aspects.
That's my opinion.
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
Whatever weakness you may find, I hope you don't miss out on the raw
power of the "code is data" property.
············@gmail.com wrote:
> language. Even with those tools, Ruby still needs a killer ap Rail to
> become popular, and Lisp I think lacks more in these aspects.
I think SLIME is a killer app. Cross-platform, self-documenting,
interactive IDE.
> That's my opinion.
And, as Kenny would say, an original one, too.
On 18 Aug 2006 13:53:11 -0700, "jmckitrick" <···········@yahoo.com>:
>I think SLIME is a killer app. Cross-platform
AFAIK, SLIME is not cross-platform. It works only under one OS: emacs.
Fabien LE LEZ <········@gramster.com> writes:
> On 18 Aug 2006 13:53:11 -0700, "jmckitrick" <···········@yahoo.com>:
>
>>I think SLIME is a killer app. Cross-platform
>
> AFAIK, SLIME is not cross-platform. It works only under one OS: emacs.
No, it works under climacs and vim too, though those ports are less
mature.
Christophe
Christophe Rhodes <·····@cam.ac.uk> writes:
> Fabien LE LEZ <········@gramster.com> writes:
>
>> On 18 Aug 2006 13:53:11 -0700, "jmckitrick" <···········@yahoo.com>:
>>
>>>I think SLIME is a killer app. Cross-platform
>>
>> AFAIK, SLIME is not cross-platform. It works only under one OS: emacs.
>
> No, it works under climacs and vim too, though those ports are less
> mature.
Aquamacs, as well; in fact, it's bundled in...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Wed, 23 Aug 2006 07:07:23 +0100, Christophe Rhodes
<·····@cam.ac.uk>:
>> AFAIK, SLIME is not cross-platform. It works only under one OS: emacs.
>
>No, it works under climacs
... which is completely different from emacs :-p
>and vim too,
At last a piece of good news!
Is vim good enough to program in Lisp? I mean, does it know about Lisp
indentation and syntax?
I'm used to your usual MS-Windows-based editor (like Textpad or
Ultraedit), so I find it difficult to switch to emacs. And weird as it
may seem, vim feels easier to grasp, even if it's even more different.
Fabien LE LEZ wrote:
> On Wed, 23 Aug 2006 07:07:23 +0100, Christophe Rhodes
> <·····@cam.ac.uk>:
>
> >> AFAIK, SLIME is not cross-platform. It works only under one OS: emacs.
> >
> >No, it works under climacs
>
> ... which is completely different from emacs :-p
>
> >and vim too,
>
> At last a piece of good news!
>
> Is vim good enough to program in Lisp? I mean, does it know about Lisp
> indentation and syntax?
>
> I'm used to your usual MS-Windows-based editor (like Textpad or
> Ultraedit), so I find it difficult to switch to emacs. And weird as it
> may seem, vim feels easier to grasp, even if it's even more different.
Using Emacs to edit files needn't really vastly different than using
the editors you mention. You can do most things through menus if you
like things that way.
If you download Emacs 22 and enable cua-mode you can use the normal
keybindings used in Windows programs.
Vi is really quite different.
On 23 Aug 2006 10:05:16 -0700, "Rob Thorpe"
<·············@antenova.com>:
>Using Emacs to edit files needn't really vastly different than using
>the editors you mention.
>[...]
>Vi is really quite different.
You might have found the problem: Emacs is partly the same as the
"usual Windows editors", but not completely, so it feels weird to
switch between emacs and another editor.
Vim, OTOH, is completely different. So, when you start vim, you are in
another world, without any reference to any other editor.
Allow me to try a parallel:
When a C++ programmer learns Java, he's annoyed by the features he had
in C++, that aren't in Java. That's because C++ and Java are similar.
OTOH, if a C++ programmer learns Lisp, he can't make any comparison,
since the two languages are so different. So, he forgets about C++ and
just learns Lisp as something completely new.
Fabien LE LEZ wrote:
> On 23 Aug 2006 10:05:16 -0700, "Rob Thorpe"
> <·············@antenova.com>:
>
> >Using Emacs to edit files needn't really vastly different than using
> >the editors you mention.
> >[...]
> >Vi is really quite different.
>
> You might have found the problem: Emacs is partly the same as the
> "usual Windows editors", but not completely, so it feels weird to
> switch between emacs and another editor.
>
> Vim, OTOH, is completely different. So, when you start vim, you are in
> another world, without any reference to any other editor.
>
>
> Allow me to try a parallel:
> When a C++ programmer learns Java, he's annoyed by the features he had
> in C++, that aren't in Java. That's because C++ and Java are similar.
>
> OTOH, if a C++ programmer learns Lisp, he can't make any comparison,
> since the two languages are so different. So, he forgets about C++ and
> just learns Lisp as something completely new.
In my experience that isn't really true. What most Windows editors
support is more or less a subset of what Emacs is capable of doing. So
you really just have to learn more.
But if you really want to learn some completely different keypresses,
how about Emacs in VIper mode emulating VI. You get the same weirdness
as VI and you get an editor with more features.
On 2006-08-23, Fabien LE LEZ <········@gramster.com> wrote:
> On Wed, 23 Aug 2006 07:07:23 +0100, Christophe Rhodes
><·····@cam.ac.uk>:
>
>>> AFAIK, SLIME is not cross-platform. It works only under one OS:
>>> emacs.
>>
>>No, it works under climacs
>
> ... which is completely different from emacs :-p
>
>>and vim too,
>
> At last a piece of good news!
>
> Is vim good enough to program in Lisp? I mean, does it know about
> Lisp indentation and syntax?
Out of the box, it knows about most indentation and syntax, but has
some (minor) differences of opinion with Emacs about indentation.
It's not (yet) smart enough to indent local functions (e.g. from FLET)
correctly automatically. It has other (IMHO) minor flaws, but then
I've never used Emacs for any length of time, so we might disagree on
what's "minor". :)
This[1] page has links to most (all?) of the widely-known resources on
Lisping with Vim. See in particular the link about Slim-Vim[2].
Note that it says "Slim-Vim is not for the faint of heart". That's
still pretty true, we're not all that user-friendly yet, but we're
working on it. Even if you find that it doesn't yet fit your needs,
feel free to post to the mailing list (or just to me, and I'll echo it
to the list) about what you'd need it to do before you could use it.
(E.g. features in slim-vim itself, pre-compiled binaries for some
specific platform, etc.)
-- Larry Clapp
Slim-Vim Project Champion
Slim-Vim is a project of the Lisp Gardeners
[1] http://www.cliki.net/vim
[2] http://wiki.alu.org/Slim-Vim
Larry Clapp wrote:
> On 2006-08-23, Fabien LE LEZ <········@gramster.com> wrote:
> > On Wed, 23 Aug 2006 07:07:23 +0100, Christophe Rhodes
<snip>
>
> Note that it says "Slim-Vim is not for the faint of heart". That's
> still pretty true, we're not all that user-friendly yet, but we're
> working on it.
"We" the mailing list and authors are very user-friendly :)
Slim-vim can still be a bit grumpy though :)
Cheers
Brad
[Note: posted and mailed, since I have questions on both SLIME in
general and on Slim-Vim]
On Wed, 23 Aug 2006 14:09:57 GMT, Larry Clapp <·····@theclapp.org>
wrote the following on comp.lang.lisp:
>Note that it says "Slim-Vim is not for the faint of heart".
Yup. I'm still trying to figure out how many files I have to download.
The "how to install" page mixes binary downloads and source-code
downloads[*], and, actually, I don't really understand the structure
(or the function?) of SLIME, even on emacs.
[*] And the fact I'm running Windows doesn't help :-/
Is SLIME actually a compiler, or just an interface to a compiler that
has to be installed beforehand? (BTW, is "compiler" the right word)?
Is Slim-Vim a version of SLIME modified for Vim? Or an interface
between SLIME and Vim? Or something else?
Ain't there one big file I could download, that contains all that's
necessary?
Well, anyway, for now I use vim and GNU Common Lisp separately (I like
GCL, it's just one big .exe that contains everything :-) ), and it's
sufficient to start learning the basics of the language.
Le Wed, 23 Aug 2006 21:28:48 +0200, Fabien LE LEZ a écrit :
> Is SLIME actually a compiler, or just an interface to a compiler that
> has to be installed beforehand? (BTW, is "compiler" the right word)?
It's an interface to a CL implementation, which could be either a
compiler or an interpreter, usually both.
Quickly,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Pierre THIERRY wrote:
> Le Wed, 23 Aug 2006 21:28:48 +0200, Fabien LE LEZ a écrit :
> > Is SLIME actually a compiler, or just an interface to a compiler that
> > has to be installed beforehand? (BTW, is "compiler" the right word)?
>
> It's an interface to a CL implementation, which could be either a
> compiler or an interpreter, usually both.
>
Just to elaborate a bit further. Slime is usually ment to mean the
software system that is able to interact with a running Lisp process
from Emacs. It is effectively an IDE which supports multiple Lisp
backends, and uses Emacs as the front end.
Slime is therefore two parts of code:
Backend : This is called Swank, it runs on the host Lisp (ie, SBCL),
and provides implementation specific features.
Frontend: Also called Slime, written in Emacs Lisp it talks to the
backend over a network socket and provides the user with fancy editing
and debugging facilities.
Slim-Vim is an alternate frontend. The backend (Swank) remains exactly
the same. Slim-Vim is written is Lisp, and requires a Vim7 patched
with ECL to run.
To run Slim-Vim you will need
1) Slime, to provide the backend. I am running against v2, others
against CVS.
2) Vim patched with ECL, which is found at http://theclapp.org/repos/,
either as a Darcs repo or a daily tarball
3) Slim-Vim (also from above), the actual Lisp code that we run within
Vim
4) ECL-repl, more Lisp code that lets you access the Vim Lisp
interpreter. Eventually this will not be a requirement.
At the moment there is no "one big file", that is a long way down the
maturity line for us.
Cheers
Brad
·············@gmail.com" <············@gmail.com> writes:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
<...some stuff...>
I think those are weaknesses FOR you, due to weaknesses IN you. Which
is fine, but don't get grandiose and claim these are THE weaknesses.
The stuff listed don't even appear to be "weaknesses" at all.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
············@gmail.com wrote:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
>
> 1, the syntax of the language is not intuitive enough, which would
> make people afraid of learning it.
This is the wrong approach. You should be spending only a very brief
amount of time learning any language. What really counts is how well
the language works once you know it. Dumbing the language down for the
sake of newcomers is foolish.
> 2, the implementation decides too much, maybe it's because the
> standard specification is outdated or the Lisp language itself is
> heavily based on the implementation, and it's hard to find a decent
> implementation on Win 32 platform( at least for me ).
The implementation decides too much? The language you're trolling for,
Ruby, is nothing _but_ an implementation!
> 3. it's hard to write effective and/or efficient lisp program, I
"Effective" and "efficient" are pretty different concepts.
> remember there are many advanced C++ or Java books, but even the
> simplest lisp book is difficult enough so I think it would be harder to
> find an advanced one.
Yes, learning things takes work.
> Besides those obvious reasons, what really hurts Lisp is the lack of
> connection to the real world. The world is evolving, now we have SOA
> (Service Oriented Architecture), we have MDA( Model Driven
> Architecture? ), and Lisp's best weapon, the powerful macroes, can be
Do you think Lisp is buzzword-proof? Do you think it's impossible to
use these things in Lisp? Have you learned enough Lisp to be sure they
aren't obviated by other features of Lisp (a la "Design Patterns")?
Would you like to explain why these things are so important to you?
> replaced by simple code generators; dynamically typed is nice to
> develop in the beginning, but in the end I think these types are fixed,
> so that even with a better development speed, languages with static
> types would eventually catched up with better performance, and the RAD
> tool would really helps those static typed language more.
RAD tool? Have you used a commercial IDE or even SLIME?
>
> That is,
>
> If a Lisp web application needs 3 months to develop, a Java web
> application might take 6 months, but with the help of development
> tools, Java web application can be shortened to maybe 4 months. Yes it
This is such a bogus, obviously-from-thin-air set of numbers. Why even
bother?
> still takes more time than the Lisp one, but either it's easier to
> extend with components that are ready, and it's easier to find people
> to maintain the code.
>
> From my own view, Lisp is a fun language with a steep learning curve,
> and it's not that practical, what Lisp needs I think are
>
> 1, better FFI. What makes Ruby's libraries grow that fast, one reason
> is the easiness to extend with C. I think currently it's hard to make
> lots of project in pure Lisp, but lending from other languages (like C)
> might be a shortcut.
OK, OK. Now you're just being loco. Have you ever programmed with
CFFI? Have you? Do you really find it inferior to Ruby's FFI?
> 2, syntax sugar. Though Lisp has a good macro system can define what
> language you need, but what most people need is a readable syntax. If
> there is a way to define some syntax with a more intuitive way, it
> might attract more people.
It's only unreadable if you want it to be.
> 3. integration. What makes Ruby succeed is not only the language
> itself, but rubygems, ri, erb, drb, rdoc, rake, irb... all makes an
> important part. That's outside the language, but it really helps the
> language. Even with those tools, Ruby still needs a killer ap Rail to
> become popular, and Lisp I think lacks more in these aspects.
>
> That's my opinion.
P.S. Are you aware of the effect that having an e-mail address with
"sailormoon" in it has on your credibility?
Bill Atkins wrote:
> ············@gmail.com wrote:
> > Hello:
Sailor!
> P.S. Are you aware of the effect that having an e-mail address with
> "sailormoon" in it has on your credibility?
I only imagine someone from the gay '20s tap dancing upon the cosmos.
Cheers,
Brandon Van Every
············@gmail.com wrote:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
>
Your list of weaknesses is incomplete. You should have start with Lot's
of Irritating Stupid Parentheses...and probably end there too. :))
Oh wait, you actually stated with it.
Then why did you bother to to continue ?
> 1, better FFI. What makes Ruby's libraries grow that fast, one reason
> is the easiness to extend with C. I think currently it's hard to make
> lots of project in pure Lisp, but lending from other languages (like C)
> might be a shortcut.
The problem is that this easy extension is a reason why it is one of
the slowest script programming languages (only TCL is worse).
> 3. integration. What makes Ruby succeed is not only the language
> itself, but rubygems, ri, erb, drb, rdoc, rake, irb... all makes an
> important part. That's outside the language, but it really helps the
> language.
I think for most of the tools there are good Lisp replacement. Some of
the ruby tools (and i write this as a ruby tool developer who knows a
lot about them) really aren't as good as you think. So it seems that
you neither looked at ruby nor lisp in detail.
llothar wrote in comp.lang.lisp:
> The problem is that this easy extension is a reason why [Ruby] is one of
> the slowest script programming languages (only TCL is worse).
Do you have quantitative figures for that assertion, or is it based on
comparing with an ancient version like the 7.* series of interpreters
(which were indeed slow, but are also around 10 years old)? Or worse
still, are you just parrotting some random hearsay off "teh intarweb"?
If I introduce some actual information into this discussion
(http://shootout.alioth.debian.org/) we see that reality is much less
clear cut and everything depends on the specifics. On the other hand,
for the specific case of Tcl vs. Ruby,
http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=tcl&lang2=ruby
indicates that Tcl usually smacks Ruby into the ground. :-)
[F'ups set; this isn't Lisp-related.]
Donal.
···············@man.ac.uk wrote:
> llothar wrote in comp.lang.lisp:
> > The problem is that this easy extension is a reason why [Ruby] is one of
> > the slowest script programming languages (only TCL is worse).
>
> Do you have quantitative figures for that assertion, or is it based on
> comparing with an ancient version like the 7.* series of interpreters
> (which were indeed slow, but are also around 10 years old)? Or worse
> still, are you just parrotting some random hearsay off "teh intarweb"?
>
> If I introduce some actual information into this discussion
> (http://shootout.alioth.debian.org/) we see that reality is much less
> clear cut and everything depends on the specifics. On the other hand,
> for the specific case of Tcl vs. Ruby,
> http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=tcl&lang2=ruby
> indicates that Tcl usually smacks Ruby into the ground. :-)
>
> [F'ups set; this isn't Lisp-related.]
>
> Donal.
Lothar is the developer of an IDE for Ruby, part of which required
custom rebuilding of the Ruby interpreter itself (if I remember
correctly), so I'd say he's very qualified to make such statements. The
Shootout is fun and all, but it hardly represents reality, much less
anything that is "clear cut".
············@gmail.com wrote:
> From my own view, Lisp is a fun language with a steep learning curve,
> and it's not that practical, what Lisp needs I think are
>
> 1, better FFI. What makes Ruby's libraries grow that fast, one reason
> is the easiness to extend with C. I think currently it's hard to make
> lots of project in pure Lisp, but lending from other languages (like C)
> might be a shortcut.
>
> 2, syntax sugar. Though Lisp has a good macro system can define what
> language you need, but what most people need is a readable syntax. If
> there is a way to define some syntax with a more intuitive way, it
> might attract more people.
>
> 3. integration. What makes Ruby succeed is not only the language
> itself, but rubygems, ri, erb, drb, rdoc, rake, irb... all makes an
> important part. That's outside the language, but it really helps the
> language. Even with those tools, Ruby still needs a killer ap Rail to
> become popular, and Lisp I think lacks more in these aspects.
>
> That's my opinion.
If you want to program in Ruby, program in Ruby. It doesn't make sense
to take an existing language and change it to make it like another one
that already exists. It would just remove one option from the
fortunately broad set of possible programming approaches.
You know, different people have different needs.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
············@gmail.com wrote:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
>
> 1, the syntax of the language is not intuitive enough, which would
> make people afraid of learning it.
What could be easier. List the function, then its arguments. Geez.
What does the world have to do to make you happy?
> 2, the implementation decides too much, maybe it's because the
> standard specification is outdated or the Lisp language itself is
> heavily based on the implementation, and it's hard to find a decent
> implementation on Win 32 platform( at least for me ).
It's never been easier. I think you just like to complain.
> 3. it's hard to write effective and/or efficient lisp program, I
> remember there are many advanced C++ or Java books, but even the
> simplest lisp book is difficult enough so I think it would be harder to
> find an advanced one.
>
It's hard to write effectively or efficiently in general. It's hard to
program. How does lisp make it harder for you? There are a number of
good books and papers on how to optimize lisp program performance.
> Besides those obvious reasons, what really hurts Lisp is the lack of
> connection to the real world. The world is evolving, now we have SOA
> (Service Oriented Architecture), we have MDA( Model Driven
> Architecture? ), and Lisp's best weapon, the powerful macroes, can be
> replaced by simple code generators; dynamically typed is nice to
> develop in the beginning, but in the end I think these types are fixed,
> so that even with a better development speed, languages with static
> types would eventually catched up with better performance, and the RAD
> tool would really helps those static typed language more.
>
> That is,
>
> If a Lisp web application needs 3 months to develop, a Java web
> application might take 6 months, but with the help of development
> tools, Java web application can be shortened to maybe 4 months. Yes it
> still takes more time than the Lisp one, but either it's easier to
> extend with components that are ready, and it's easier to find people
> to maintain the code.
You need an order of magnitude difference before you'll get off your
favorite platform. Understandable. But where are you pulling these
numbers from?
>
> From my own view, Lisp is a fun language with a steep learning curve,
> and it's not that practical, what Lisp needs I think are
Why is it steeper than other programming languages?
>
> 1, better FFI. What makes Ruby's libraries grow that fast, one reason
> is the easiness to extend with C. I think currently it's hard to make
> lots of project in pure Lisp, but lending from other languages (like C)
> might be a shortcut.
>
You can't even get your hands on a decent implementation of Lisp, but
you can state with certainty that the FFI is bad. Perhaps you're right
on this point, but you haven't convinced me yet.
> 2, syntax sugar. Though Lisp has a good macro system can define what
> language you need, but what most people need is a readable syntax. If
> there is a way to define some syntax with a more intuitive way, it
> might attract more people.
>
Readable is clearly in the eye of the beholder. I've never had a
problem reading lisp. But this has been said before by other people who
are accustomed to more punctuation. I guess punctuation is what makes a
programming language powerful and expressive.
> 3. integration. What makes Ruby succeed is not only the language
> itself, but rubygems, ri, erb, drb, rdoc, rake, irb... all makes an
> important part. That's outside the language, but it really helps the
> language. Even with those tools, Ruby still needs a killer ap Rail to
> become popular, and Lisp I think lacks more in these aspects.
>
> That's my opinion.
>
Why not write one?
Michael Tuchman wrote:
> ············@gmail.com wrote:
> >
> > 1, the syntax of the language is not intuitive enough, which would
> > make people afraid of learning it.
>
> What could be easier. List the function, then its arguments. Geez.
> What does the world have to do to make you happy?
Excellent question!
The answer is that the world has to show its attention by responding to
his trolling.
Well, I might be wrong, but that's what I think currenctly, maybe I'll
change my mind after several months.
This is not called trolling. I just think why Lisp is not popular,
there must be some reasons, I offer my comments, and if you don't
concur, you can make your own comments.
I am just reading the book "Hackers and Painters", if Lisp is really as
good as what Paul Graham said, well, I think it is, but there must be
something wrong to make it unpopular. The first thing is, if you want
to persuade some people to use Lisp, how do you do??
Understanding the weakness of a language is an important part, I don't
think there is a perfect language, but if you want to make it more
popular, you cannot just ignore the weakness not to overcome.
············@gmail.com wrote:
> I just think why Lisp is not popular,
> there must be some reasons,
...
> Understanding the weakness of a language is an important part,
Popularity and technical quality very often do not go hand in hand.
Understanding weaknesses is important, but I don't think you've grasped
Lisp's.
·············@gmail.com" <············@gmail.com> writes:
> Well, I might be wrong, but that's what I think currenctly, maybe I'll
> change my mind after several months.
>
> This is not called trolling. I just think why Lisp is not popular,
> there must be some reasons, I offer my comments, and if you don't
> concur, you can make your own comments.
>
> I am just reading the book "Hackers and Painters", if Lisp is really as
> good as what Paul Graham said, well, I think it is, but there must be
> something wrong to make it unpopular. The first thing is, if you want
> to persuade some people to use Lisp, how do you do??
No, no, no. When you have a nuclear missile, you don't try to
persuade everybody to have one too. On the contrary, you try to
persuade them that it's bad. That even normal nuclear power plants
are bad. You finance Greenpiss to have the message spread everywhere.
And you keep your strategical advantage for yourself!
> Understanding the weakness of a language is an important part, I don't
> think there is a perfect language, but if you want to make it more
> popular, you cannot just ignore the weakness not to overcome.
Who said we wanted to make it more popular?
Actually, we should actively make it less popular and less visible.
Let's start a secret society.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"This statement is false." In Lisp: (defun Q () (eq nil (Q)))
Pascal Bourguignon wrote:
> ·············@gmail.com" <············@gmail.com> writes:
...
> > I am just reading the book "Hackers and Painters", if Lisp is really as
> > good as what Paul Graham said, well, I think it is, but there must be
> > something wrong to make it unpopular. The first thing is, if you want
> > to persuade some people to use Lisp, how do you do??
...
> Who said we wanted to make it more popular?
>
> Actually, we should actively make it less popular and less visible.
> Let's start a secret society.
Haven't you heard? We already have one.
...Oops.
··············@hotmail.com <············@gmail.com> wrote:
> Pascal Bourguignon wrote:
>> Actually, we should actively make it less popular and less visible.
>> Let's start a secret society.
>
> Haven't you heard? We already have one.
There's no "we" in Lisp.
Pascal Bourguignon wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
> > Well, I might be wrong, but that's what I think currenctly, maybe I'll
> > change my mind after several months.
> >
> > This is not called trolling. I just think why Lisp is not popular,
> > there must be some reasons, I offer my comments, and if you don't
> > concur, you can make your own comments.
> >
> > I am just reading the book "Hackers and Painters", if Lisp is really as
> > good as what Paul Graham said, well, I think it is, but there must be
> > something wrong to make it unpopular. The first thing is, if you want
> > to persuade some people to use Lisp, how do you do??
>
> No, no, no. When you have a nuclear missile, you don't try to
> persuade everybody to have one too. On the contrary, you try to
> persuade them that it's bad. That even normal nuclear power plants
> are bad. You finance Greenpiss to have the message spread everywhere.
> And you keep your strategical advantage for yourself!
>
>
> > Understanding the weakness of a language is an important part, I don't
> > think there is a perfect language, but if you want to make it more
> > popular, you cannot just ignore the weakness not to overcome.
>
> Who said we wanted to make it more popular?
>
> Actually, we should actively make it less popular and less visible.
> Let's start a secret society.
>
I've heard Lisp programmers are not really programmers but a class of
high priests. And macros are really a kind of esoteric magic.
So I conclude that the secret society already exists, and that you post
the "let's start a secret society" to hide that fact. Like a macro that
runs in our heads! Clever, like a lisp programmer^H^H^H high priest.
"Nicolay Giraldo" <·········@gmail.com> writes:
> high priests. And macros are really a kind of esoteric magic.
Indeed:
Casting SPELs in Lisp
http://www.lisperati.com/casting.html
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
The Common Lisp Directory: http://www.cl-user.net
Pascal Bourguignon wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
> > Well, I might be wrong, but that's what I think currenctly, maybe I'll
> > change my mind after several months.
> >
> > This is not called trolling. I just think why Lisp is not popular,
> > there must be some reasons, I offer my comments, and if you don't
> > concur, you can make your own comments.
> >
> > I am just reading the book "Hackers and Painters", if Lisp is really as
> > good as what Paul Graham said, well, I think it is, but there must be
> > something wrong to make it unpopular. The first thing is, if you want
> > to persuade some people to use Lisp, how do you do??
>
> No, no, no. When you have a nuclear missile, you don't try to
> persuade everybody to have one too. On the contrary, you try to
> persuade them that it's bad. That even normal nuclear power plants
> are bad. You finance Greenpiss to have the message spread everywhere.
> And you keep your strategical advantage for yourself!
I'd like to hire a team of assassins to shoot everyone in the head who
thinks the way you do. Because your nuke hoarding is keeping me out of
a job right now.
Cheers,
Brandon Van Every
"Mallor" <···········@gmail.com> writes:
>> No, no, no. When you have a nuclear missile, you don't try to
>> persuade everybody to have one too. On the contrary, you try to
>> persuade them that it's bad. That even normal nuclear power plants
>> are bad. You finance Greenpiss to have the message spread everywhere.
>> And you keep your strategical advantage for yourself!
>
> I'd like to hire a team of assassins to shoot everyone in the head who
> thinks the way you do.
Well, the way I write is not always the way I think, so beware what you wish.
> Because your nuke hoarding is keeping me out of
> a job right now.
Find some customers. Then use your lisp skills to fulfill their needs
(no need to tell them your magic was done with just parentheses).
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Do not adjust your mind, there is a fault in reality"
-- on a wall many years ago in Oxford.
Pascal Bourguignon wrote:
> "Mallor" <···········@gmail.com> writes:
> >> No, no, no. When you have a nuclear missile, you don't try to
> >> persuade everybody to have one too. On the contrary, you try to
> >> persuade them that it's bad. That even normal nuclear power plants
> >> are bad. You finance Greenpiss to have the message spread everywhere.
> >> And you keep your strategical advantage for yourself!
> >
> > I'd like to hire a team of assassins to shoot everyone in the head who
> > thinks the way you do.
>
> Well, the way I write is not always the way I think, so beware what you wish.
Ok, we'll do a web search and shoot people based on what they write.
You can recant in your last moments...
> > Because your nuke hoarding is keeping me out of
> > a job right now.
>
> Find some customers. Then use your lisp skills to fulfill their needs
> (no need to tell them your magic was done with just parentheses).
Currently I'm not financed for such things. The poverty is currently
dire as often happens. Hopefully the economy is way better now and
it'll be much easier to re-enter the computer industry since the last
time I tried. Got past a Volt screener and got an interview the other
day, so that's a good sign.
2 years ago I did something I thought would be strategically important.
I created a local group for advanced programming languages.
Originally it was the OCaml group, then ML-SIG Seattle, then it became
SeaFunc. I thought, in the course of jabbering on about functional
programming and so forth, I'd run into someone that had a job. Never
happened. SeaFunc just doesn't have a business / entrepreneurial /
money draw, and nobody in SeaFunc has had the gumption to work on such
things. The few people who are getting paid to do functional
programming already have their jobs, and they don't care enough about
the strategic employment landscape to do any real work about it. In
fairness, my colleagues are typically overworked.
Recently, David Pezely wanted to re-launch LispSea for Lispers in
Seattle. Wanted to focus more on the business moxy that SeaFunc is
missing. But, he despaired when people didn't jump on the bandwagon as
fast as he wanted. SeaFunc may not be all things to all people, but it
has lasted 2 years and is still slowly growing. I offered / threatened
to take over leadership of LispSea, since I know what it takes to keep
people coming to meetings. (It's really simple. You call meetings +
make sure you always show up for your meetings.) I'll stir the pot on
LispSea again when I've put out my own fires.
I also plan to go bug the Washington Software Alliance, when I have
more to demonstrate with Chicken Scheme.
I believe if I had been in the SF Bay Area, Boston, or NYC, I would
have solved these money problems awhile ago. Up here in Seattle, I
very much feel we're all living in Microsoft's C# shadow.
Anyways there are prerequisites to being an actual consultant. I
declared myself a consultant in name only in 1998, then never actually
did it. Those were the times. "Consultant" simply meant "you will now
pay me more money, because computer people are valuable." That
changed. By the time I started figuring out what a real Consultant
does, it was the height of the bust. Those $50..$100/hr gigs weren't
happening anymore. I couldn't even get hired as a $20/hr tester, nor
could anyone else I knew, no matter what their qualifications. So I
learned how to gather signatures, and the rest is historical accident.
Won't get fooled the next time though.
Cheers,
Brandon Van Every
On Sun, 20 Aug 2006 23:10:22 +0200, Mallor <···········@gmail.com> wrote:
> Anyways there are prerequisites to being an actual consultant. I
> declared myself a consultant in name only in 1998, then never actually
> did it. Those were the times. "Consultant" simply meant "you will now
> pay me more money, because computer people are valuable." That
> changed. By the time I started figuring out what a real Consultant
> does, it was the height of the bust. Those $50..$100/hr gigs weren't
> happening anymore. I couldn't even get hired as a $20/hr tester, nor
> could anyone else I knew, no matter what their qualifications. So I
> learned how to gather signatures, and the rest is historical accident.
> Won't get fooled the next time though.
>
>
> Cheers,
> Brandon Van Every
>
You might want to buy 'The web buisness design kit' (www.sitepoint.com)
You are trying to compete on price.
A bad idea. Cheap rearly sells a concept.
You need to convince them that you are the right man for the job.
Then you charge the according to what it is woth to them.
Quantify it. Do marker research. Research the prospect.
You will never sell anything is anyone has ever heard of you.
Take care of old customers. reward tem if they come up with
new clients. (make it woth their while)
Create a unique profile. What do you have that the competitors do not.
get PR.
etc.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Sun, 20 Aug 2006 23:10:22 +0200, Mallor <···········@gmail.com> wrote:
>
>
> > Anyways there are prerequisites to being an actual consultant. I
> > declared myself a consultant in name only in 1998, then never actually
> > did it. Those were the times. "Consultant" simply meant "you will now
> > pay me more money, because computer people are valuable." That
> > changed. By the time I started figuring out what a real Consultant
> > does, it was the height of the bust. Those $50..$100/hr gigs weren't
> > happening anymore. I couldn't even get hired as a $20/hr tester, nor
> > could anyone else I knew, no matter what their qualifications. So I
> > learned how to gather signatures, and the rest is historical accident.
> > Won't get fooled the next time though.
> >
> >
> > Cheers,
> > Brandon Van Every
> >
>
> You might want to buy 'The web buisness design kit' (www.sitepoint.com)
> You are trying to compete on price.
> A bad idea. Cheap rearly sells a concept.
> You need to convince them that you are the right man for the job.
> Then you charge the according to what it is woth to them.
> Quantify it. Do marker research. Research the prospect.
> You will never sell anything is anyone has ever heard of you.
> Take care of old customers. reward tem if they come up with
> new clients. (make it woth their while)
> Create a unique profile. What do you have that the competitors do not.
> get PR.
> etc.
These are great, and I read about such things during the bust, when I
finally fished the Consulting books off the library shelves and found
out what I was supposed to be doing. But these things require gobs of
time to realize, and I have no working capital whatsoever. I simply
can't do any of this right now. I hope to be in better shape a year
from now. At present, if I can keep from getting evicted in 2 weeks
I'm happy.
Cheers,
Brandon Van Every
············@gmail.com wrote:
> I am just reading the book "Hackers and Painters", if Lisp is really as
> good as what Paul Graham said, well, I think it is, but there must be
> something wrong to make it unpopular. The first thing is, if you want
> to persuade some people to use Lisp, how do you do??
It's a common fallacy to think that popular things are good and
unpopular things are bad. Just think about other areas (music, movies,
cars, etc.) and ask yourself the question whether that's the case in
those fields.
You may also want to read http://www.paulgraham.com/popular.html
> Understanding the weakness of a language is an important part, I don't
> think there is a perfect language, but if you want to make it more
> popular, you cannot just ignore the weakness not to overcome.
One of the typical gut reactions when people encounter Lisp for the
first time seems to be to say to themselves: "Hey, this language should
be different." They even can list some ideas how it should be different.
What's essential to grasp is this:
- Different people have different ideas how different Lisp should be,
and these ideas are not necessarily compatible. What would be necessary
is that different Lispers would have to find a compromise and define a
common ground. But that's what ANSI Common Lisp already is: the result
of a standardization process where lots of users of the language have
agreed on a common ground.
- One reason why people think that Lisp should be different when they
first encounter it is probably that it has ways to make it different -
to add language extensions and even remove existing ones. It's indeed
possible to turn Common Lisp upside down and make it behave in a
completely different way, at least theoretically. The next step is to
understand that you can just do it and that there is no need to convince
others of your own version of Lisp. Everyone can just use the one that
best suits their needs.
The habit of trying to convince others to change a language and how to
change it probably comes from the fact that in other languages, you
don't have that power yourself, so there, convincing others is the
_only_ way to change them. It's important to first get used to having
such power at hand and using it.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
>
> The habit of trying to convince others to change a language and how to
> change it probably comes from the fact that in other languages, you
> don't have that power yourself, so there, convincing others is the
> _only_ way to change them. It's important to first get used to having
> such power at hand and using it.
That's only half true. Getting traction within an institution is quite
another matter from just making a personal decision.
Cheers,
Brandon Van Every
Pascal Costanza wrote:
> One of the typical gut reactions when people encounter Lisp for the
> first time seems to be to say to themselves: "Hey, this language should
> be different." They even can list some ideas how it should be different.
Funny, after learning Lisp I had this thought with every *other*
programming language I looked at :)
············@gmail.com wrote:
> The first thing is, if you want
> to persuade some people to use Lisp, how do you do??
Write something that people highly value, then market the hell out of
it. Tell them how you did it in Lisp. Whining about "my software
system is complex, it has problems" is NOT the way forwards. ALL
modern software systems are ridiculously complex and time consuming.
It doesn't stop the winners from displacing the losers.
> Understanding the weakness of a language is an important part, I don't
> think there is a perfect language, but if you want to make it more
> popular, you cannot just ignore the weakness not to overcome.
Sure you can. C++ is riddled with weaknesses and does fine. Look how
bloody popular GNU Autoconf is, despite its weaknesses. Put a big
enough engine on a brick and it will fly.
Cheers,
Brandon Van Every
On 2006-08-18 18:16:18 +0100, ·············@gmail.com"
<············@gmail.com> said:
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
The "weaknesses" you present are serious only in that they hinder
a wider adoption by people who refuse to look beyond the surface
(been there, done that).
But the very same "weaknesses", taken from the opposite point
of view, are strength. They force you to _understand_ another
way of looking at problems, and once you do, well, you just
get over them and carry on, because they're not that important
at all!
I remember, when first starting Lisp using the Winston & Horn
book, saying to myself: "I won't ever use those stupid "car" and
"cdr" names when far better replacements like "first" and "rest"
do exist and are now standard". Guess what? Browsing my code,
I can still find the odd "car" or "cdr" here and there, but not
even a trace of "first" or "rest"!
The kind of arguments you present is a bit like saying that
Chinese is worthless just because _you_ cannot decipher it...
Let's see if you have the courage and motivation to produce
your first two or three non trivial Lisp programs, and then,
what your perception will turn out to be.
--
JFB
verec wrote:
> The kind of arguments you present is a bit like saying that
> Chinese is worthless just because _you_ cannot decipher it...
Oh, this reminds me of a long standing stupidity:
Kenny thinks that this is a bad example:
> From: Ken Tilton
> Date: Mon, Apr 3 2006 10:32 am
> Groups: comp.lang.lisp
>
> Hmmm. From the "Why Lisp?" essay:
>
> > As for being impossibly complex, it's not any more complex than any
> > other programming language. (Those who don't know Chinese think it's
> > hard too, but the Chinese don't!)"
>
> Er, bad example. Tone to differentiate meaning? A language of nothing
> but idiomatic expressions? Fuggedaboutit.
When Kenny made this outrageous claim I went to every Chinese person in
my laboratory (5 of them at the time) and asked each of them separately
whether they thought that Chinese was hard. (It's actually a little
hard to formulate this question correctly beacuse "hard" is very
ambiguous -- harder to learn? than what? harder to speak? than what?
about what?) Anyway, after some negotiation of what "hard" meant, every
single native Chinese speaker that I interviewed thought that Kenny was
wrong, i.e., that Chinese was easy (if you grew up with it).
Conclusion: 5 out of 5 Chinese don't think that Chinese is hard. I.e.,
Kenny is (at least statistically speaking) wrong. QED (and, no, I don't
mean: "...has the power of a turning machine!" :-)
········@gmail.com wrote:
> verec wrote:
>
>>The kind of arguments you present is a bit like saying that
>>Chinese is worthless just because _you_ cannot decipher it...
>
>
> Oh, this reminds me of a long standing stupidity:
>
> Kenny thinks that this is a bad example:
>
>
>>From: Ken Tilton
>>Date: Mon, Apr 3 2006 10:32 am
>>Groups: comp.lang.lisp
>>
>>Hmmm. From the "Why Lisp?" essay:
>>
>>
>>>As for being impossibly complex, it's not any more complex than any
>>>other programming language. (Those who don't know Chinese think it's
>>>hard too, but the Chinese don't!)"
>>
>>Er, bad example. Tone to differentiate meaning? A language of nothing
>>but idiomatic expressions? Fuggedaboutit.
>
>
> When Kenny made this outrageous claim I went to every Chinese person in
> my laboratory ...
That is actually a little scary. And confused. You made a bad analogy
(there are no good ones, but you found a new low) between Lisp
complexity and Chinese complexity, when one cannot even compare computer
languages with natural languages, nor how they are learned, nor are
computer languages ever learned in infancy.*
> Anyway, after some negotiation of what "hard" meant,..
Took a while to get the results you were after, eh? PWUAAHAHAHAHAAA.
(But kudos for the full disclosure of rampant investigator bias.)
How about "difficult" as a definition? Re Mandarin, on
http://www.micheloud.com/FXM/LA/la/index.htm:
"Immensely difficult, be it in its maddening writing or most tricky
pronunciation. Learning it is the language achievement par excellence. "
Yes, that's the way to market Lisp.
<sigh>
kenny
* Yes, it is true that Kent Pitman was raised by a closet full of Lisp
Machines, but the exception only proves the rule. hth, k
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
> That is actually a little scary. And confused. You made a bad analogy
> (there are no good ones, but you found a new low) between Lisp
> complexity and Chinese complexity,
No. The analogy I made was between people who think that Chinese is
hard who don't know it, and people who think that Lisp is hard who
don't know it.
········@gmail.com wrote:
>>That is actually a little scary. And confused. You made a bad analogy
>>(there are no good ones, but you found a new low) between Lisp
>>complexity and Chinese complexity,
>
>
> No. The analogy I made was between people who think that Chinese is
> hard who don't know it, and people who think that Lisp is hard who
> don't know it.
>
Please, the only thing interesting at this point are the negotiations
over the word "hard". Obviously you did not get the answer you wanted
the first time, or there would have been no negotiations. How many times
did each one say, "Are you kidding? Chinese is incredibly hard." before
you finally got, "Oh, well if you are going to put the question like
that...".
kenny (just hoping you do not work in research!)
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
> kenny (just hoping you do not work in research!)
Believe me, you don't really want to go here....
(You are like a self-troll -- everything you write just screams: Hit
me!)
········@gmail.com wrote:
>>kenny (just hoping you do not work in research!)
>
>
> Believe me, you don't really want to go here....
If you do not tell me where to go, I will not tell you where to go,
tempting as it may be.
You obviously have not the slightest clue on how to do research. You
took a poll and then argued with respondents over their answers and
recast the question until you got the answer you wanted. Try getting
that past a peer review, as if you know what that is.
I wouldn't trust you interviewing any life form with more intelligence
than.... than... I don't know... a cyanobacterium?
>
> (You are like a self-troll -- everything you write just screams: Hit
> me!)
>
Arguments from self-reference are always welcome.
C'mon, cut the ad bacterium crap, tell us about the negotiations over
the meaning of the word "hard". You used that to characterize me as
stupid, and I demand satisfaction. Or a retraction.*
"Ni hao, michael. Do you think chinese is a hard language?"
"Fuck yeah, jeff."
"no, I mean harder than, say, English or Swahili."
"What part of 'fuck yeah' do you not understand?"
"No, I mean, for you is it hard?"
"Jeff, I was born in Kiaoshung."
"So Chinese is easy?"
"You call that easy?"
"Yeah."
"Yes, Jeff, Chinese is easy."
"And Kenny is stupid?"
"OK, now you are scaring me, Jeff."
"Just say it!"
"Ok, Ok! Kenny is stupid! Now let go of me!"
kenzo
* As was the case last time, a simple "Phhhhhhhhht!" will serve as a
concession speech. k
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
[...Long, admittedly extremely funny, monologue snipped...]
I have to truly say that I can't think of a good comeback to that;
speechless, I bow to a greater comedic intellect!
········@gmail.com wrote:
> [...Long, admittedly extremely funny, monologue snipped...]
>
> I have to truly say that I can't think of a good comeback to that;
> speechless, I bow to a greater comedic intellect!
>
I thought you'd like that "ad bacterium" bit.
:)
kz
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On 2006-08-19 17:35:27 +0100, ········@gmail.com said:
> When Kenny made this outrageous claim I went to every Chinese person in
> my laboratory (5 of them at the time) and asked each of them separately
> whether they thought that Chinese was hard.
If Chinese was so much harder than other languages it would probably
not be spoken by quite so many people.
On 2006-08-19, Tim Bradshaw <···@tfeb.org> wrote:
> On 2006-08-19 17:35:27 +0100, ········@gmail.com said:
>
>> When Kenny made this outrageous claim I went to every Chinese person in
>> my laboratory (5 of them at the time) and asked each of them separately
>> whether they thought that Chinese was hard.
>
> If Chinese was so much harder than other languages it would probably
> not be spoken by quite so many people.
>
From what little I know about it, its not. Saying chinese is spoken
here is like saying european is spoken here. They are a bunch of
seperate languages that share a common writing system. The only thing
that could be genericly called chinese is the offical dialect, simplafied
manderin I think, that is taught as the "common tounge" in schools.
marc
--
······@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
········@gmail.com writes:
> Conclusion: 5 out of 5 Chinese don't think that Chinese is hard. I.e.,
> Kenny is (at least statistically speaking) wrong. QED (and, no, I don't
> mean: "...has the power of a turning machine!" :-)
There is a lighthearted but seemingly well-argued paper that says
otherwise, "Why Chinese is so damn hard" by David Moser, Sino-Platonic
Papers #27, 1991. Worth reading even if one isn't really into chinese,
just because it's also fun.
http://www.pinyin.info/readings/texts/moser.html
http://www.pinyin.info/readings/texts/1991Moser.pdf#search=%22David%20Moser%20Why%20Chinese%20is%20so%22
I don't really have an opinion; my skills in chinese are limited to
which bathroom signs indicate I should remain outside.
Best,
Thomas
--
Thomas Lindgren
> > Conclusion: 5 out of 5 Chinese don't think that Chinese is hard. I.e.,
> > Kenny is (at least statistically speaking) wrong. QED (and, no, I don't
> > mean: "...has the power of a turning machine!" :-)
>
> There is a lighthearted but seemingly well-argued paper that says
> otherwise, "Why Chinese is so damn hard" by David Moser, Sino-Platonic
> Papers #27, 1991. Worth reading even if one isn't really into chinese,
> just because it's also fun.
>
> http://www.pinyin.info/readings/texts/moser.html
You apparently didn't actually read this paper; It mostly complains
about the writing system, not the language. The one two places that
complain about the language itself are complaints that you can't figure
it out unless you're chinese. He even admits this: "Notes: 1. I am
speaking of the writing system here, but the difficulty of the writing
system has such a pervasive effect on literacy and general language
mastery that I think the statement as a whole is still valid." Also,
his pseudo-science is even worse than my pseudo-science. He says:
"Which means that Chinese is also hard for them, for Chinese people.
[note 1, above] If you don't believe this, just ask a Chinese person."
First, note again that he's talking about the writring system. Second,
at least I actually asked some people. He didn't, as far as is reported
here, anyhow. Finally, and most tellingly, he actually AGREES with me:
"Why Chinese Is So Damn Hard by David Moser University of Michigan
Center for Chinese studies; The first question any thoughtful person
might ask when reading the title of this essay is, "Hard for whom?" A
reasonable question. After all, Chinese people seem to learn it just
fine. When little Chinese kids go through the "terrible twos", it's
Chinese they use to drive their parents crazy, and in a few years the
same kids are actually using those impossibly complicated Chinese
characters to scribble love notes and shopping lists. So what do I mean
by "hard"? Since I know at the outset that the whole tone of this
document is going to involve a lot of whining and complaining, I may as
well come right out and say exactly what I mean. I mean hard for me, a
native English speaker trying to learn Chinese as an adult, going
through the whole process with the textbooks, the tapes, the
conversation partners, etc., the whole torturous rigmarole. I mean hard
for me -- and, of course, for the many other Westerners who have spent
years of their lives bashing their heads against the Great Wall of
Chinese. If this were as far as I went, my statement would be a pretty
empty one. Of course Chinese is hard for me. After all, any foreign
language is hard for a non-native, right? Well, sort of. Not all
foreign languages are equally difficult for any learner. It depends on
which language you're coming from. A French person can usually learn
Italian faster than an American, and an average American could probably
master German a lot faster than an average Japanese, and so on. So part
of what I'm contending is that Chinese is hard compared to ... well,
compared to almost any other language you might care to tackle. What I
mean is that Chinese is not only hard for us (English speakers), but
it's also hard in absolute terms. Which means that Chinese is also hard
for them, for Chinese people." Go to Note 1, above.
········@gmail.com writes:
> > > Conclusion: 5 out of 5 Chinese don't think that Chinese is hard. I.e.,
> > > Kenny is (at least statistically speaking) wrong. QED (and, no, I don't
> > > mean: "...has the power of a turning machine!" :-)
> >
> > There is a lighthearted but seemingly well-argued paper that says
> > otherwise, "Why Chinese is so damn hard" by David Moser, Sino-Platonic
> > Papers #27, 1991. Worth reading even if one isn't really into chinese,
> > just because it's also fun.
> >
> > http://www.pinyin.info/readings/texts/moser.html
>
> You apparently didn't actually read this paper; It mostly complains
> about the writing system, not the language. The one two places that
> complain about the language itself are complaints that you can't figure
> it out unless you're chinese. /.../
Huh? Where did you say you were only considering spoken chinese? The
only point where that assumption even appears in what you wrote is as
part of a question on whether it should be considered as part of being
"hard" or not. (See below.)
On consideration, I realize this is not really a big issue for me, and
I've spent more time on this than it's worth already. Bye.
>> When Kenny made this outrageous claim I went to every Chinese person in
>> my laboratory (5 of them at the time) and asked each of them separately
>> whether they thought that Chinese was hard. (It's actually a little
>> hard to formulate this question correctly beacuse "hard" is very
>> ambiguous -- harder to learn? than what? harder to speak? than what?
>> about what?) Anyway, after some negotiation of what "hard" meant, every
>> single native Chinese speaker that I interviewed thought that Kenny was
>> wrong, i.e., that Chinese was easy (if you grew up with it).
>> Conclusion: 5 out of 5 Chinese don't think that Chinese is hard. I.e.,
>> Kenny is (at least statistically speaking) wrong. QED (and, no, I don't
>> mean: "...has the power of a turning machine!" :-)
--
Thomas Lindgren
> Huh? Where did you say you were only considering spoken chinese? The
> only point where that assumption even appears in what you wrote is as
> part of a question on whether it should be considered as part of being
> "hard" or not. (See below.)
> On consideration, I realize this is not really a big issue for me, and
> I've spent more time on this than it's worth already. Bye.
Well, although I agree with this sentiment, just for the record:
> >> When Kenny made this outrageous claim I went to every Chinese person in
> >> my laboratory (5 of them at the time) and asked each of them separately
> >> whether they thought that Chinese was hard. (It's actually a little
> >> hard to formulate this question correctly beacuse "hard" is very
> >> ambiguous -- harder to learn? than what? harder to speak? than what?
^^^^^^^
> >> about what?)
;;; [Note that "read" or "write" isn't among the questions.]
> >> Anyway, after some negotiation of what "hard" meant, every
> >> single native Chinese speaker that I interviewed thought that Kenny was
^^^^^^^^^
> >> wrong, i.e., that Chinese was easy (if you grew up with it).
> >> Conclusion: 5 out of 5 Chinese don't think that Chinese is hard. I.e.,
> >> Kenny is (at least statistically speaking) wrong. QED (and, no, I don't
^^^^^^^^^^ :-)
> >> mean: "...has the power of a turning machine!" :-)
············@gmail.com wrote:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
>
> 1, the syntax of the language is not intuitive enough, which would
> make people afraid of learning it.
This seems to be what almost _every single_ beginner believes is a
weakness, then tries to "fix" - then sooner or later realize that they
where wrong when they are not so much beginners any more.
"Intuitive" is here based on expectations. Who cares about people
wanting to "learn" by doing something similar to what the already know?
The more this is the less point there is, and they _should_ be wanting
the opposite. Yeah! - They should really just stick to what they
already are doing, STFU and "store" what others are saying for later
investigation. Then do this in a sensible, real and honest way when
they have the time required.
This is just plain stupid and pointless in so many ways - Lisp is
different, and it really-really should be. Where are the real questions
and the will to explore? - All I see is premature judgement. :}
> 2, the implementation decides too much, maybe it's because the
> standard specification is outdated or the Lisp language itself is
> heavily based on the implementation,
I do not understand what you mean here. I have never used a language
more flexible than Common Lisp, and I do not see what you mean here at
all.
(defpackage :my-lisp
(use :cl)
(shadow :stuff .......))
(defmethod stuff ...)
?? what do you want ??
> and it's hard to find a decent implementation on Win 32 platform( at least for me ).
(Ok, I do not know much about Win32 or support there at all - maybe
someone else can help here?) If you start developing your application
on SBCL today; SBCL will be ported to- and stable on Win32 when you are
done. There are other options that exist now like CLISP, and if you
mean in general (non-free) Lispworks and ACL exists and are after what
I've understood very good.
Btw .. If you are developing web-applications; you do not want to do
this on Win32 anyway. (.. ok, i'm a biased freak/hippie/etc. .. but so
is - well - google for instance ..)
> 3. it's hard to write effective and/or efficient lisp program,
Yeah - yeah; software and stuff and stuff is hard. People here seems
happy to help if you have _concrete questions_ about optimization and
other stuff; why don't you give them and Lisp a honest try? :)
> I remember there are many advanced C++ or Java books, but even the
> simplest lisp book is difficult enough so I think it would be harder to
> find an advanced one.
Uhm .. ok? I'm drunk; but I do not think I'd understand what you mean
here even if I wasn't.
> Besides those obvious reasons,
..yeah..
> what really hurts Lisp is the lack of
> connection to the real world. The world is evolving, now we have SOA
> (Service Oriented Architecture), we have MDA( Model Driven
> Architecture? ),
Yeah, bring on the buzzwords ..O_o.. hah .. what do you really want to
_do_? I think you might find that Lisp has support for most of the
things you'd do in other languages and that Lisp lacks support for some
of the things you'd never (want to?) do in other languages even if they
existed there. I might just be lucky though; Lisp has support for stuff
that does not even exist in other languages at all.
> and Lisp's best weapon, the powerful macroes, can be
> replaced by simple code generators;
Erm - no, they can not.
> dynamically typed is nice to develop in the beginning, but in the end I think these types are fixed,
> so that even with a better development speed, languages with static
> types would eventually catched up with better performance,
You can add type-declaration and optimize in general when/if you want.
You have a _choice_ in Lisp. In static languages you do not; you are
stuck from the very beginning and must decide types etc. way too early
leading to a lot of work later - especially when doing non-trivial and
explorative development.
In Lisp this gives you the ability to do this as a last step in the
development-process. You might have heard "premature optimization is
the root of all evil" and with Lisp you can optimize more stuff later.
Performance? You have compilers - even free ones - that rival and
sometimes exceed optimized C. Take for instance
http://weitz.de/cl-ppcre/ or http://bknr.net/submission/39808 ; and you
have c.l.l. where you can ask for advice for your own stuff. In the
worst case scenario - after failing to optimize enough using what is
available in Lisp - you can rewrite parts of your project in C (FFI in
Lisp is easy) when you are done with the development of it and need to
optimize the bottlenecks that often/always(?) turns out to be small
isolated parts anyway.
> and the RAD tool would really helps those static typed language more.
> That is, If a Lisp web application needs 3 months to develop, a Java web
> application might take 6 months, but with the help of development
> tools, Java web application can be shortened to maybe 4 months. Yes it
> still takes more time than the Lisp one, but either it's easier to
> extend with components that are ready,
No way; RAD-tools cannot _ever_ replace real coding nor remotely
compete with Lisp or typeless languages(?) in explorative development
which is what all non-trivial development is. Ok, so I might be biased
again. :}
> and it's easier to find people to maintain the code.
Yup; I guess this might be somewhat true - or maybe I've never
developed anything worth maintaining yet. Have you - in Lisp?
> From my own view, Lisp is a fun language with a steep learning curve,
> and it's not that practical, what Lisp needs I think are
>
> 1, better FFI. What makes Ruby's libraries grow that fast, one reason
> is the easiness to extend with C. I think currently it's hard to make
> lots of project in pure Lisp, but lending from other languages (like C)
> might be a shortcut.
Have you seen CFFI? Wrapping a C-lib is fast; and using some macros to
help with the repetition makes it even faster.
> 2, syntax sugar. Though Lisp has a good macro system can define what
> language you need, but what most people need is a readable syntax. If
> there is a way to define some syntax with a more intuitive way, it
> might attract more people.
No, it is the other way around; it is people that should adjust here -
not Lisp. The (lack of) syntax in Lisp is what makes it a great
language - the "more people"-part do not understand this. If you or
"more people" do not want to learn something new; simply do something
else.
> 3. integration. What makes Ruby succeed is not only the language
> itself, but rubygems, ri, erb, drb, rdoc, rake, irb... all makes an
> important part. That's outside the language, but it really helps the
> language. Even with those tools, Ruby still needs a killer ap Rail to
> become popular, and Lisp I think lacks more in these aspects.
You did not develop Rails, and you have not developed a killer app
using Lisp - so ..
> That's my opinion.
..you do not have the "right" to judge what turns out to be your
opinion about the _potential_ of something you do not seem to know or
know enough of.
It also turns out that I think Lisp already has some killer apps
besides the language itself(!). Maybe you should give Lisp a chance and
see what's available?
--
mvh, Lars Rune Nøstdal
http://lars.nostdal.org/
·············@gmail.com" <············@gmail.com> writes:
> That's my opinion.
Are you sure? Someone posts something like this every week.
You didn't think you were posting something new did you?
--
The lithobraker. Zero distance stops at any speed.
This post uses 100% post consumer electrons and 100% virgin photons.
At 2.6 miles per minute, you don't really have time to get bored.
--- Pete Roehling on rec.motorcycles
Okay, I apologize for posting such topic, and I'm currently learning
Lisp.
Though my work is based on C++, Java and C#. I learned D and Ruby by
myself, and now it's the turn of Lisp. I have tried to learn Haskell,
but it's too hard, in my opinion the barrier to learn Haskell is even
larger than Lisp.
By the way, my job requires to use the UML tool, Rational Rose, not the
latest version, it's the 2003 version. I found it can generate many
kinds of languages, including Ada, but not including Lisp. I am not
sure if the latest version add Lisp as a supported language.
Though, I really hate to use Rational Rose because you need to do lots
of tedious work, copy and paste, but in my opinion, a larger project
(In my project there are over 50 people including SA(System Analyist)
SD(System Designer) PG(Programmer) and Testers) including many people
of different aspects to co-work, can it be done by Lisp ?
I think it can be, if the entire software development tool is written
in Lisp, SA write down the Lisp code about the requirements and some
rules, and then generates documentation from the code to the users, so
that SD can reuse the raw code from SA, not the documentation already
generated, to design the architecture and database relations, and
workflows and so on, and then SD simply writes the code generators for
the projects and then generates the codes to Lisp. The entire work
might be based on XML, but Lisp Codes wins for including the codes
besides the data.
I am not sure if such assumption is possible, or maybe it's already
done but I don't know.
············@gmail.com wrote:
> Okay, I apologize for posting such topic, and I'm currently learning
> Lisp.
>
> Though my work is based on C++, Java and C#. I learned D and Ruby by
> myself, and now it's the turn of Lisp. I have tried to learn Haskell,
> but it's too hard, in my opinion the barrier to learn Haskell is even
> larger than Lisp.
As someone who is actively investigating both Lisp and Haskell, I can't
agree more. Learning either one of them is difficult.
So is learning, say, differential equations.
Perhaps the functional restrictions of Haskell and the wonderful
syntactic simplicity of Lisp convey more than just a steep learning
curve? You could break the rules in either one of them and forsake the
logic behind those rules (and please, do) but if you do so before
really understanding why they're there, how can you know if what you
throw away is not more beneficial than what you gain?
So yeah, coming to understand the significance of a two line syntax or
the power of a monad might take a few days of work, but it's rewarding.
·············@gmail.com" <············@gmail.com> writes:
> Though my work is based on C++, Java and C#. I learned D and Ruby by
> myself, and now it's the turn of Lisp. I have tried to learn Haskell,
> but it's too hard, in my opinion the barrier to learn Haskell is even
> larger than Lisp.
The barrier is caused by working too much with C and its offspring.
> By the way, my job requires to use the UML tool, Rational Rose, not the
> latest version, it's the 2003 version. I found it can generate many
> kinds of languages, including Ada, but not including Lisp. I am not
> sure if the latest version add Lisp as a supported language.
I wouldn't think that it would, nor would I want it to. See below.
> Though, I really hate to use Rational Rose because you need to do lots
> of tedious work, copy and paste, but in my opinion, a larger project
> (In my project there are over 50 people including SA(System Analyist)
> SD(System Designer) PG(Programmer) and Testers) including many people
> of different aspects to co-work, can it be done by Lisp ?
Doing lots of redundant, tedious work is exactly what Lisp is best at
helping you avoid. The reasons for using Rational Rose and those for
using Lisp are disjoint sets.
> I think it can be, if the entire software development tool is written
> in Lisp, SA write down the Lisp code about the requirements and some
> rules, and then generates documentation from the code to the users, so
> that SD can reuse the raw code from SA, not the documentation already
> generated, to design the architecture and database relations, and
> workflows and so on, and then SD simply writes the code generators for
> the projects and then generates the codes to Lisp. The entire work
> might be based on XML, but Lisp Codes wins for including the codes
> besides the data.
Why not just cut out all the redundant, tedious work and do all the
jobs you listed yourself using Lisp? If you really need to work with
other people, then you can do it without help.
What is it about the current generation of programmers that prevents
them from designing and documenting an API without having to be
hand-held and coerced through the process by ridiculously overpriced
and overvalued software like Rational Rose?
> By the way, my job requires to use the UML tool, Rational Rose, not the
> latest version, it's the 2003 version. I found it can generate many
> kinds of languages, including Ada, but not including Lisp. I am not
> sure if the latest version add Lisp as a supported language.
Here's something that should (if you understand it) shake your view of
things:
Rational Rose is *internally* essentially a Lisp system. In fact, you
don't need to output Lisp for Rational Rose because Rational Rose IS
Lisp: "The format of petal files generated by Rational Rose (ending
with .mdl or .ptl) ... looks roughly like a lisp data structure,
consisting of several nested levels enclosed in parentheses which form
a tree of nodes. Take a look at one of your files yourself to see what
I mean. The main data structure are "objects", i.e., items like
(object Petal version 42 _written "Rose 4.5.8163.3" charSet 0)" (from:
http://crazybeans.sourceforge.net/ CrazyBeans/ doc/ grammar.pdf).
I'll bet you any amount of money that I can do thing in Lisp based on
the above that will make your head spin -- stuff you never even DREAMed
you could do with Rational Rose!
The same is true for any sufficiently complex program (See:
http://en.wikipedia.org/ wiki/ Greenspun%27s_Tenth_Rule).
Another example, I use Mathematica all the time. Mathematica is about
the most complex program you'll every encounter. Mathematica is
essentially a Lisp engine inside. In addition, most modern game AIs are
essentially implementations of Lisp, followed by a rule system,
followed by rules.
So when you learn Lisp, you're learning not how to hack trivial surface
junk that does web page I/O and the like (although you can do that
too), you're learning about the deep heart of the most important,
complex, and interesting software on the planet -- bar none!
You want to hack what everyone else in the world hacks, please feel
free to use the languages that everyone else uses. But if you want to
understand how to build software that is fundamental, critically
important, and, when it gets right down to it, *fun*, try to turn off
your critic for a couple of days; I think that you'll come to love
those parentheses as we do.
Le Sat, 19 Aug 2006 09:23:40 -0700, JShrager a écrit :
> So when you learn Lisp, you're learning not how to hack trivial
> surface junk that does web page I/O and the like (although you can do
> that too)
You can, and with an astonishing productiviy! I was going to be much
late in the delivery of a web application for my current customer. As
I've previously said, I discovered Lisp only two months ago, with
Seibel's PCL.
About 2 weeks ago, I decided to give Lisp a try, following my instinct
on it. I struggled a bit with AllegroServe and switched to Araneida, and
finally chose Allegro's htmlgen for outputing HTML (although I may
switch later on something more flexible). I choose Elephant to avoid
bothering with database stuff and have easy persistence (and with CLSQL
and sqlite, I didn't even need a full-fledge DB server running when
hacking my app).
Not only I could try and be somewhat efficient with many tools and
libraries in a indecently short time, and make a choice about them, but
after that I still had time to write a first quick & dirty ad hoc
implementation of three functions serving pages, and then rewrite it in
a generalized way with macros. Now I define a product in (1+ n) lines
when it has n slots, and my main macro creates lamda functions stored in
plists used to serve pages. It is incredibly flexible and easy to use.
I just find it hard to believe how fast it was running and how easy it
was to move from an ad hoc prototype to a fully generalized system. Now
I can ask myself if I later add incredibly powerful tools in my app like
the ability for the customer to fully customize every bit of it. It
would have been insanely difficult in PHP, Perl or whatever else than
Lisp. I *know* it will just be fun in Lisp...
Happily,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
I agree with everything Pierre says, even though we apparently took
different approaches in our web apps.
A couple of years ago, I fell for the 'Python is as great as Lisp but
easier' and I took a detour into Python and pyGTK. I got PCL last
year, and used it for experimenting and learning, after I got bored
with Python. I left my Win32 job last November, and started developing
a web app for a startup company. It's mostly ajax and a few static
pages on the front end, some special business logic, and a db backend.
I've never been so challenged and yet so rewarded for my efforts. I
convinced the CEO to let me use lisp rather than php, and there have
been no regrets by anyone involved.
I can't say enough about how much I've enjoyed this step in my
programming career. I've learned a better language, and I've become
(and will continue to become) a better programmer.
Le Sun, 20 Aug 2006 03:11:17 +0200, Pierre THIERRY a écrit :
> Now I define a product in (1+ n) lines when it has n slots, and my
> main macro creates lamda functions stored in plists used to serve
> pages. It is incredibly flexible and easy to use.
I jusk asked myself wether my lambdas were compiled, and was ahppy to
see that they were indeed, without any effort from me.
Is there generally a way to avoid compilation of a function or lambda
function, and are there situations where this could serve any purpose?
Curiously,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Pierre THIERRY <···········@levallois.eu.org> writes:
> Le Sun, 20 Aug 2006 03:11:17 +0200, Pierre THIERRY a �crit�:
>> Now I define a product in (1+ n) lines when it has n slots, and my
>> main macro creates lamda functions stored in plists used to serve
>> pages. It is incredibly flexible and easy to use.
>
> I jusk asked myself wether my lambdas were compiled, and was ahppy to
> see that they were indeed, without any effort from me.
>
> Is there generally a way to avoid compilation of a function or lambda
> function, and are there situations where this could serve any purpose?
Use an interpreter and don't call COMPILE?
Otherwise, you can use QUOTE.
(defparameter *f* (quote (lambda (x) (+ 1 x))))
(defun double (le)
(list (first le) (second le) `(* 2 ,(third le))))
(defparameter *2f* (compile nil (double *f*)))
(funcall *2f* 3)
--> 8
--
__Pascal Bourguignon__ http://www.informatimago.com/
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.
On Sat, 19 Aug 2006 06:04:02 +0200, ············@gmail.com
<············@gmail.com> wrote:
>
> Okay, I apologize for posting such topic, and I'm currently learning
> Lisp.
>
> Though my work is based on C++, Java and C#. I learned D and Ruby by
> myself, and now it's the turn of Lisp. I have tried to learn Haskell,
> but it's too hard, in my opinion the barrier to learn Haskell is even
> larger than Lisp.
>
There are basically 4 different programming paradigms.
1. procedural programming (Pascal) (the one you know)
2. logical programming (Prolog)
3. functional programming (Haskell)
4. object oriented programming (Smalltalk) (You probably know a bit about
this too)
Note that the language I mentioned in the parenthesis is just a
example of a 'pure' form which cultivates mostly that style.
If you know all four of the disciplines you can pretty much understand
all programming languages. Yes it is difficult to do something
differently that what you are used to, but worth the effort to learn.
You will soon see that each style has it's virtues and that.
You claim that Lisp is difficult. This is because because Paul Graham
teaches a functional style of programming. It is not so much Lisp
but functional thinking you have a problem with.
Note that Lisp is heterogeneous in that it supports 1, 3 and 4.
2 is usually supported by a library.
This does demand that you have experience with all 4 and
that you know their strength and shortcomings. This can only come
from experience.
You might like Peter Norvigs article.
Learning how to program in 2 weeks or learning how to program in 10 years.
(www.norvig.com)
Programming is easy. Programming well is hard.
John
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Sat, 19 Aug 2006 09:45:38 +0200, John Thingstad wrote:
> There are basically 4 different programming paradigms.
I count a few more.
>
> 1. procedural programming (Pascal) (the one you know)
> 2. logical programming (Prolog)
> 3. functional programming (Haskell)
> 4. object oriented programming (Smalltalk) (You probably know a bit about
> this too)
5. Stack programming (Forth)
6. Assembly and machine code programming
These could be classed as subsets of procedural, except they both demand
different ways of looking at the problem and (especially) decomposing it
to build a solution.
Stack programming favors great numbers of little functions (as per Chuck
Moore, a stack four deep is all a word should ever need [1]) and an
extremely bottom-up style.
[1] <http://www.ultratechnology.com/1xforth.htm>
Assembly/machine code programming favors very machine-specific
programming, possibly to the point of structuring the code around a
handful of machine-specific features/opcodes. (Such as a very optimized
music encoder written for a modern Pentium being built around MMX and SSE
opcodes.)
Lisp does not really support stack programming at all and only supports
machine code by dropping into FFIs of some form. It is interesting to
note, however, that Lisp is commonly coded in a way similar to the way
Forth is (small functions, bottom-up, language building). I guess that
exploratory programming demands similar things of all styles.
> If you know all four of the disciplines you can pretty much understand
> all programming languages. Yes it is difficult to do something
> differently that what you are used to, but worth the effort to learn.
> You will soon see that each style has it's virtues and that.
This is something I firmly agree with. Learn as many paradigms as you can,
and learning languages will become much easier (and more fun, might I add ;)).
>
> Programming is easy. Programming well is hard.
Another quote for the ol' fortune file. ;)
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Sun, 20 Aug 2006 05:04:48 +0200, Pascal Bourguignon wrote:
> Chris Barts <··············@tznvy.pbz> writes:
>> Lisp does not really support stack programming at all
>
> Really? You don't need a lot to have it support stack programming:
You proved my point: I could say C supports OO programming [1] if you
allowed me to build the entire object system.
[1] (That is, Smalltalk and Simula OO, including such things as
inheritance and polymorphism. Common Lisp gives you random access to all
of the concepts traditionally bundled together under the banner OO right
out of the box, and in a standard fashion.)
<snip very cool code>
>
>> and only supports machine code by dropping into FFIs of some
>> form.
>
> It also supports machine code with LAP (or VOP or any other
> implementation dependant mechanism). All right, there's no _standard_
> way to support machine code, but then, there's no standard machine
> code either...
Lisp is no worse in this area than any other language, and much better
than some. I'll look up your abbreviations as I've never heard of either
of them.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On 2006-08-20 04:33:27 -0400, Chris Barts <··············@tznvy.pbz> said:
> You proved my point: I could say C supports OO programming [1] if you
> allowed me to build the entire object system.
Yes, but how many lines of c would one need to implement a smalltalk?
How many lines of forth to implement a lisp?
Raffael Cavallaro wrote:
> How many lines of forth to implement a lisp?
A Lisp (an interpreter for a dynamically scoped Scheme variant)
implemented in Forth can be found at
http://www.complang.tuwien.ac.at/~schani/lisp.tar.gz. Counting
Non-empty, non-comment lines it's 372 lines of Forth. So not that many.
Ok, a complete Common Lisp compiler would be a /bit/ longer...
On Mon, 21 Aug 2006 01:46:03 -0700, Christopher Koppler wrote:
> A Lisp (an interpreter for a dynamically scoped Scheme variant)
Interesting how many old-style Lisps use dynamic scope and how few of the
modern ones do. Emacs Lisp is another example.
> implemented in Forth can be found at
> http://www.complang.tuwien.ac.at/~schani/lisp.tar.gz. Counting
> Non-empty, non-comment lines it's 372 lines of Forth. So not that many.
A count of words might be more useful, but SLOC is the standard bogus
metric.
> Ok, a complete Common Lisp compiler would be a /bit/ longer...
And mostly written in Lisp.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Sun, 20 Aug 2006 21:31:19 -0400, Raffael Cavallaro wrote:
> On 2006-08-20 04:33:27 -0400, Chris Barts <··············@tznvy.pbz> said:
>
>> You proved my point: I could say C supports OO programming [1] if you
>> allowed me to build the entire object system.
>
> Yes, but how many lines of c would one need to implement a smalltalk?
> How many lines of forth to implement a lisp?
Yes, implementing foo in a high-level language usually costs fewer lines
of code than implementing foo in a medium- or low-level language (and
Forth can be the moral equivalent of a macro assembler at times). [1] But
that does not change the fact that it is somewhat dishonest to say that
language foo supports bar when you really mean that implementing bar in
foo from scratch isn't that difficult.
[1] (The exception is when the task is impossible, like writing a device
driver in a language that has neither real pointers nor an FFI, or goes
completely against the grain of the language, like writing a text editor
in Mathematica. Another exception might be when, in the absence of an FFI,
a library can be used in one language but not any other.)
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On 2006-08-21 05:34:32 -0400, Chris Barts <··············@tznvy.pbz> said:
> Yes, implementing foo in a high-level language usually costs fewer lines
> of code than implementing foo in a medium- or low-level language (and
> Forth can be the moral equivalent of a macro assembler at times). [1] But
> that does not change the fact that it is somewhat dishonest to say that
> language foo supports bar when you really mean that implementing bar in
> foo from scratch isn't that difficult.
Right - please don't mistake me as one claiming that common lisp
supports stack programming - it clearly doesn't out of the box. The
point is that doing so is a fairly small exercise. As you say
"implementing foo in a high-level language usually costs fewer lines of
code than implementing foo in a medium- or low-level language." That
being the case I think it makes most sense to use that language that
will incur the lowest development cost for new features.
In other words, to echo Kenny's refrain, for practical work it makes
most sense to use the language that covers the largest range of
paradigms and useful features out of the box and can add the others at
the smallest cost - i.e., common lisp.
Pascal Bourguignon <···@informatimago.com> writes:
> Chris Barts <··············@tznvy.pbz> writes:
>> Lisp does not really support stack programming at all
>
> Really? You don't need a lot to have it support stack programming:
<small language implementation omitted>
It always amazes me when you do that. :-)
--
Fred Gilham ······@csl.sri.com
In the course of making code more readable, performance was
accidentally improved by about 20%. --- From BRL 2.1.23 release notes
············@gmail.com wrote:
> Though my work is based on C++, Java and C#. I learned D and Ruby by
> myself, and now it's the turn of Lisp. I have tried to learn Haskell,
> but it's too hard, in my opinion the barrier to learn Haskell is even
> larger than Lisp.
You might try Haskell for C Programmers
(http://www.haskell.org/~pairwise/intro/intro.html). I found it helpful.
·············@gmail.com" <············@gmail.com> writes:
> 1, the syntax of the language is not intuitive enough, which would
> make people afraid of learning it.
There is no syntax in lisp.
Well, there is, but it's simplistic compared to any other programming
language (but perhaps brainfuck or intercal).
sexp ::= number | symbol | '(' sexp_list ')' .
sexp_list ::= | sexp sexp_list .
That's it, there nothing else.
Well, there are reader macros, but this doesn't really count, they're
just a bunch of user definable functions used to produce lisp object
from a stream.
So, I'd say, yes, perhaps such a syntax is not intuitive, but who
needs it to be intuitive when it's so simple?
--
__Pascal Bourguignon__ http://www.informatimago.com/
"A TRUE Klingon warrior does not comment his code!"
> 1, the syntax of the language is not intuitive enough, which would
> make people afraid of learning it.
Effectively, LISP has no syntax. You write code in an AST (abstract
syntax tree) which is directly parsed.
If you want to claim LISP should develop syntax, may I suggest you
learn Python? It's a beautiful language, in many ways it's very
LISP-like, and it has syntax.
> 2, the implementation decides too much, maybe it's because the
> standard specification is outdated or the Lisp language itself is
> heavily based on the implementation, and it's hard to find a decent
> implementation on Win 32 platform( at least for me ).
As compared to, say, Perl, Python or Ruby, which are defined entirely
by their implementation, with no standards documents available.
There are many good Win32 LISPs. Which ones have you tried? What
precise shortcomings have you discovered? I'm sure the Win32 users on
the newsgroup will be more than happy to give their recommendations.
> 3. it's hard to write effective and/or efficient lisp program, I
Effective and efficient are orthogonal ideas.
The effectiveness of a program has almost nothing to do with the
language you choose. It has far more to do with how well you
understand the problem you're trying to solve, and how clear your
vision is of the solution you're trying to create.
The efficiency of a program is dependent primarily on your choice of
algorithm, and secondarily on your choice of language. A quicksort
written purely in Python will be much more efficient than a bubblesort
written in hand-tuned Assembler.
Once your algorithm is selected and it's time to start compiling down
to bare metal, then you begin to learn what a compiler is. A compiler
isn't something magical. It's an expert system, nothing more... more
precisely, a compiler is an expert system for the construction of
Assembly. When you look at a simple C program
=====
#include <stdio.h>
int main()
{
printf("Hello, World!\n");
return 0;
}
=====
... that's not a program at all. It's not a program until it's an
executable. The source code you're looking at is really just input to
an expert system which will generate your executable for you.
With me so far?
Now think about this: if the primary measure of the efficiency of a
compiler is the effectiveness of its expert system... and if LISP has a
50-year history of excellence in expert systems... what can you
probably infer about LISP compilers?
Me, I come up with "... there probably exist a few LISP systems that
can produce executable code that's just as quick, terse and efficient
as the best C compilers."
And, y'know what? That's exactly true.
> Besides those obvious reasons, what really hurts Lisp is the lack of
> connection to the real world. The world is evolving, now we have SOA
> (Service Oriented Architecture), we have MDA( Model Driven
> Architecture? ), and Lisp's best weapon, the powerful macroes, can be
> replaced by simple code generators;
[scratches his head]
In what way is a LISP macro _not_ a code generator?
And how does LISP fail to adapt to modern programming styles? CLOS is
still the object-oriented system to die for. Continuations beat the
pants off exception handling. Inference engines are almost trivial
(see _The Reasoned Schemer_ for more examples than you can shake a
stick at).
> 1, better FFI. What makes Ruby's libraries grow that fast, one reason
Have you actually used LISP's FFI?
> 2, syntax sugar. Though Lisp has a good macro system can define what
> language you need, but what most people need is a readable syntax.
I can read LISP just fine. So can all other LISP programmers I know.
The LISP syntax may not be newbie-friendly, but then again, neither is
Java's or C's.
Spend a month working with LISP for an hour each day. Then come back
and tell us whether you find LISP readable or not. I'll bet you a buck
that within just a couple of days you'll start appreciating the
parenthesis, much as in just a couple of days most Python programmers
start to appreciate the indentation.
> That's my opinion.
... and, unfortunately, not a very well-formed one at this point,
probably due to your lack of exposure to LISP. Why not spend just a
month working with LISP, and then give us your new opinion? We'd love
to hear it.
·············@gmail.com" <············@gmail.com> writes:
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp.
You might want to read this essay:
http://dept-info.labri.fr/~strandh/Essays/wrong.text
that I wrote quite a while ago, after one of the previous posts that
was pretty much identical to yours.
--
Robert Strandh
---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------
Robert Strandh wrote:
> ---------------------------------------------------------------------
> Greenspun's Tenth Rule of Programming: any sufficiently complicated C
> or Fortran program contains an ad hoc informally-specified bug-ridden
> slow implementation of half of Common Lisp.
> ---------------------------------------------------------------------
If that is true, then it is also true that any sufficiently complicated
C or Fortran program contains an ad hoc informally-specified
bug-ridden slow implementation of half of ANSI Forth.
You say that program X does not? I say that it doesn't because
it isn't sufficiently complex.
············@gmail.com wrote:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
>
> 1, the syntax of the language is not intuitive enough, which would
> make people afraid of learning it.
> 2, the implementation decides too much, maybe it's because the
> standard specification is outdated or the Lisp language itself is
> heavily based on the implementation, and it's hard to find a decent
> implementation on Win 32 platform( at least for me ).
> 3. it's hard to write effective and/or efficient lisp program, I
> remember there are many advanced C++ or Java books, but even the
> simplest lisp book is difficult enough so I think it would be harder to
> find an advanced one.
>
You seem to be writing not about Lisp, but about Commune Lisp.
Don't ever mistake that bloated monstrosity for Lisp.
Have a look at newLisp.
············@gmail.com wrote:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
well, i was a beginner to programming when i started learning Common
Lisp. before that io triedmany langugaes like Python, Scheme etc etc.
> 1, the syntax of the language is not intuitive enough, which would
> make people afraid of learning it.
non-sense. for me as a beginner to programmer, syntax was much friendly
but that happened after 2 days of interaction.
> 2, the implementation decides too much, maybe it's because the
> standard specification is outdated or the Lisp language itself is
> heavily based on the implementation, and it's hard to find a decent
> implementation on Win 32 platform( at least for me ).
every implementation is entirely-different in some
aspects.Implementationn are created according to the needs of solution
for some complex problems in different domains.
you are confused in that: you want to become a good programmer, i
suppose as you are trying Common Lisp, & you are using windows. how is
thi spossible. try Linux. after 6 months you will never like to work on
windows for your entire life.
> 3. it's hard to write effective and/or efficient lisp program, I
> remember there are many advanced C++ or Java books, but even the
> simplest lisp book is difficult enough so I think it would be harder to
> find an advanced one.
utter non-sense. it seems like you did not Google for "Touretzky
book",much easier than "How to think like a computer Scientist". also
try www.gigamonkeys.com/book. it looks tough & it is but may be because
it is very-different.
> Besides those obvious reasons, what really hurts Lisp is the lack of
> connection to the real world.
again, utter-nonsense. you did not read
http://www.paulgraham.com/avg.html. you dont read enough about your
profession. that's why you ask question like Blub Programmers ask but
you can change that.
> The world is evolving, now we have SOA
> (Service Oriented Architecture), we have MDA( Model Driven
> Architecture? ), and Lisp's best weapon, the powerful macroes, can be
> replaced by simple code generators;
you can wait for that, it may happen not before 2016, even then
*technically* that "replacement" willnot be able to compete in solving
some complex-problems. WHY? who created Common Lisp...Hacker who built
the Internet & who created UNIX,Linux, BSDs. not to mention NASA used
CLISP (may be some other). they debugged a programme in the space ship
millions miles away from earth using a Common Lisp compiler.
> If a Lisp web application needs 3 months to develop, a Java web
> application might take 6 months, but with the help of development
> tools, Java web application can be shortened to maybe 4 months. Yes it
> still takes more time than the Lisp one, but either it's easier to
> extend with components that are ready, and it's easier to find people
> to maintain the code.
this depends on the specific web-application problem you are working
on. Common Lisp is not the solution to every problem & neither is JAVA
nor C++. & on most of the time Lisp wins.
yeah, i agree with one point, Lisp Hackers are rare & i bet so is the
situation for Java hackers.you can find lots of people coding in
Java/.NET but it doesn't make them excellent programmers.
> From my own view, Lisp is a fun language with a steep learning curve,
> and it's not that practical, what Lisp needs I think are
Common Lisp is 100% practical & C+++ & Ruby are too.
> 1, better FFI. What makes Ruby's libraries grow that fast, one reason
> is the easiness to extend with C. I think currently it's hard to make
> lots of project in pure Lisp, but lending from other languages (like C)
> might be a shortcut.
>
3 months ago i tried to learn Ruby, it was easier may be because i am
no longer a beginning programmer or may be it is really easy but Ruby
felt like a patch-up work of Common Lisp, thats all i can say.
> 2, syntax sugar. Though Lisp has a good macro system can define what
> language you need, but what most people need is a readable syntax. If
> there is a way to define some syntax with a more intuitive way, it
> might attract more people.
i am *neither* a lover nor a hater of Lisp paranthesis & macros. what i
found Common Lisp lets you think in terms of problems & is much more
abstract than any other langugae i have seen. it saves lots of time &
energy like youo save when you switch from Windows to Linux.
> 3. integration. What makes Ruby succeed is not only the language
> itself, but rubygems, ri, erb, drb, rdoc, rake, irb... all makes an
> important part. That's outside the language, but it really helps the
> language. Even with those tools, Ruby still needs a killer ap Rail to
> become popular, and Lisp I think lacks more in these aspects.
>
> That's my opinion.
If you like Ruby, then learn Ruby. learning Common Lisp then, will be a
wastage of time. even i like the syntax of ruby :-) & make sure
somewhere after 3-4 years when you have enough experience with this
profession, then, try Common Lisp, it is better.
thanks
"arnuld"
············@gmail.com wrote:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
>
> 1, the syntax of the language is not intuitive enough, which would
> make people afraid of learning it.
Baloney. It's only parentheses. If anyone had shown me Common Lisp
when I was in 8th grade, I would have worked miracles! I was doing
algebra, was obsessed with factoring equations, and won my regional
MathCounts competition. As it was, I knew Atari BASIC, knew most of
the Atari 800 memory map since it was only 64K, and wrote a game for
math class that made heavy duty use of cookbook assembly strings
provided by Antic magazine. Nobody taught me a damn thing in
computers, I did it all on my own with a few books that I picked out
and bought myself. There were about 5 other guys just as smart as
myself, who could have done or did do similar sorts of things.
Sure, if you're afraid of math, you should rightly be afraid of Lisp.
It's not for dummies. But people will also get over things they're
afraid of, if there's money in it. The problem with programming
languages en masse is just what people are familiar with.
> 2, the implementation decides too much, maybe it's because the
> standard specification is outdated or the Lisp language itself is
> heavily based on the implementation,
Not much of an objection in the real world of gigantic modern software
systems. Do you bitch and moan about Windows APIs? Well yes, actually
I do, and I avoid them... but it doesn't stop legions of people from
using them every day. Being a programmer means looking up shit, and
learning how to ignore shit.
> and it's hard to find a decent
> implementation on Win 32 platform( at least for me ).
No it isn't, you just have to pay for them.
> 3. it's hard to write effective and/or efficient lisp program,
> remember there are many advanced C++ or Java books, but even the
> simplest lisp book is difficult enough so I think it would be harder to
> find an advanced one.
I don't know whose marketing Kool-Aid you swallowed if you think it's
easy to write programs in C++ ! What a cantankerous language. Doesn't
stop legions of people from using it. Sure, it's easier for a beginner
to code in Python than in Lisp, because Python was designed with
simplicity in mind. At the opposite end, Perl was designed with the
Unix power programmer in mind. There's nothing easy about $_ or
regular expressions. Nevertheless, the meme of the power Unix hacker
has lived long and propsered, grotesque as it may be to us Windows/Mac
types who are more interested in usability. Perversely, if Lisp were
made *more* difficult in a way attractive to Unixen, it might be more
popular. Is it too late to throw some $ signs into the spec?
Another route of invasion is academia. People think C++ or Java are
"easy" because they spend years learning them in college. They're not
easy at all, it's just sunk cost. Hard to get people to sink the cost
into Lisp or Scheme though. So they get a little exposure to them, it
takes time to master, that time is not allocated, people go WTF? and so
lotsa people who don't like Lisp / Scheme are dumped into the
workforce.
> Besides those obvious reasons, what really hurts Lisp is the lack of
> connection to the real world. The world is evolving, now we have SOA
> (Service Oriented Architecture), we have MDA( Model Driven
> Architecture? ),
Me no speaka Enterprise Gobbledygoo. Why do people assume their
problem domain is everyone else's? Perhaps it's a corollary to "every
language gets popular via the Web." Thus, the majority of developers
will rate your language as a Web language.
> If a Lisp web application needs 3 months to develop, a Java web
> application might take 6 months, but with the help of development
> tools, Java web application can be shortened to maybe 4 months. Yes it
> still takes more time than the Lisp one, but either it's easier to
> extend with components that are ready, and it's easier to find people
> to maintain the code.
Lisp's problem is lack of installed base and corporate muscle. Java
has Sun, C# has Microsoft. Lisp had its heydey, but machines of the
1980s weren't so powerful. Now the machines are ready for Lisp, but
the mindshare has moved on to other things. Technology alone will not
create any drastic sea change in how anyone does anything. It takes
marketing.
> 1, better FFI. What makes Ruby's libraries grow that fast, one reason
> is the easiness to extend with C. I think currently it's hard to make
> lots of project in pure Lisp, but lending from other languages (like C)
> might be a shortcut.
Yeah, there's nothing common about any Common Lisp C FFI.
> 2, syntax sugar. Though Lisp has a good macro system can define what
> language you need, but what most people need is a readable syntax. If
> there is a way to define some syntax with a more intuitive way, it
> might attract more people.
Well go bang on Dylan again or whatever. Lisp For Dummies has been
tried. Lisp doesn't need a new syntax. It needs a popular problem
domain where people really need what Lisp can do.
> 3. integration. What makes Ruby succeed is not only the language
> itself, but rubygems, ri, erb, drb, rdoc, rake, irb... all makes an
> important part. That's outside the language, but it really helps the
> language. Even with those tools, Ruby still needs a killer ap Rail to
> become popular, and Lisp I think lacks more in these aspects.
Just another instance of the Web driving all the marketing and
community solidarity. Lisp developers aren't synonymous with web
developers. Especially since there are so many languages that have
grabbed a big slice of the Web pie.
Cheers,
Brandon Van Every
Mallor wrote:
> Another route of invasion is academia. People think C++ or Java are
> "easy" because they spend years learning them in college. They're not
> easy at all, it's just sunk cost.
Sure 'nuf. I wrote C++ for years and thought it
was grand. Since then, I've done Tcl, Forth, Java, Python,
and (for a few months now) Lisp, and each of those was
successively more pleasant to work with. Writing merely
correct (let alone efficient) C++ code is really fucking
hard. It's like trying to carry on a conversation with
someone who randomly pokes you in the eye with a stick.
-- JK
On Wed, 23 Aug 2006 17:28:58 GMT, Joe Knapka <·········@kneuro.net>:
>Writing merely
>correct (let alone efficient) C++ code is really fucking
>hard.
I can't agree with you on that point.
Learning C++ is hard. And long. And time-consuming. And the fact that
lots of C++ teachers know C very well and a tiny little bit of C++,
sure doesn't help.
But when you've learnt it properly, actually using it is quite easy.
Fabien LE LEZ wrote:
[about C++]
> But when you've learnt it properly, actually using it is quite easy.
The same could be said about alligator wrestling :-)
-- JK
Joe Knapka wrote:
> Fabien LE LEZ wrote:
>
> [about C++]
>
>> But when you've learnt it properly, actually using it is quite easy.
>
>
> The same could be said about alligator wrestling :-)
I'll wait for Jeff to jump in with Mandarin.
kenny
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Joe Knapka wrote:
> > Fabien LE LEZ wrote:
> >
> > [about C++]
> >
> >> But when you've learnt it properly, actually using it is quite easy.
> >
> >
> > The same could be said about alligator wrestling :-)
>
> I'll wait for Jeff to jump in with Mandarin.
What; now you have a problem with oranges!? Tell me that you haven't
taken the course on how do defend yourself against a man who attacks
you with fresh fruit!
Isn't that required for New Yorkers? (Or do you just have to learn how
to defend yourself against Law & Order stunt scenes?)
········@gmail.com wrote:
> Ken Tilton wrote:
> > Joe Knapka wrote:
> > > Fabien LE LEZ wrote:
> > >
> > > [about C++]
> > >
> > >> But when you've learnt it properly, actually using it is quite easy.
> > >
> > >
> > > The same could be said about alligator wrestling :-)
> >
> > I'll wait for Jeff to jump in with Mandarin.
>
> What; now you have a problem with oranges!? Tell me that you haven't
> taken the course on how do defend yourself against a man who attacks
> you with fresh fruit!
> Isn't that required for New Yorkers? (Or do you just have to learn how
> to defend yourself against Law & Order stunt scenes?)
You and Kenny are both being ridiculous. Stop hammering the groups
with this childish back and forth.
Brad
bradb wrote:
> ········@gmail.com wrote:
>
>>Ken Tilton wrote:
>>
>>>Joe Knapka wrote:
>>>
>>>>Fabien LE LEZ wrote:
>>>>
>>>>[about C++]
>>>>
>>>>
>>>>>But when you've learnt it properly, actually using it is quite easy.
>>>>
>>>>
>>>>The same could be said about alligator wrestling :-)
>>>
>>>I'll wait for Jeff to jump in with Mandarin.
>>
>>What; now you have a problem with oranges!? Tell me that you haven't
>>taken the course on how do defend yourself against a man who attacks
>>you with fresh fruit!
>>Isn't that required for New Yorkers? (Or do you just have to learn how
>>to defend yourself against Law & Order stunt scenes?)
>
>
> You and Kenny are both being ridiculous. Stop hammering the groups
> with this childish back and forth.
Look behind you, it sailed over your head. :)
kenny
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
> You and Kenny are both being ridiculous. Stop hammering the groups
> with this childish back and forth.
This isn't childish back and forth; *THIS* is childish back and forth:
http://www.cs.cmu.edu/~sef/Orig-Smiley.htm
(There are at least 3 ways in which this is on-topic; Can you ID them?)
---------------------
"Those who cannot learn humor are doomed!"
-- Me
On Wed, 23 Aug 2006 20:53:54 GMT, Joe Knapka <·········@kneuro.net>:
>> But when you've learnt it properly, actually using it is quite easy.
>
>The same could be said about alligator wrestling :-)
Or the computer version: wrestling with/using emacs :-p
Back on the (off-)topic, the difficulty and the power of C++ is the
insane number of features if offers[*]. Think of Lisp's "loop"
structure, but language-wide.
C++ even has, like Lisp, a Turing-complete compile-time language, the
"template" mechanism, which at least twelve people in the world fully
understand (one of them being Andrei Alexandrescu -- and I still
haven't read his book; I really need 72 hours per day and 21 days a
week. But I digress.)
Another power and difficulty of C++ is that the compiler trusts the
programmer, and let him do (nearly) whatever he pleases.
If the programmer wants a direct access to the memory ("char*" and
stuff), good manuals will tell him that it's probably a bad idea, but
the compiler will accept that without a warning.
In other words, good C++ programmers will, 99.9% of the time, use
techniques that don't allow the gun to be directed at the foot[***];
and the 0.1% remaining[****], they will be extremely careful, in order
to keep a reasonable number of toes.
[*] It's also difficult for implementers: while Intel and Comeau
painfully managed to implement all the features, Microsoft didn't even
try[**], and the maintainers of g++ decided they didn't have enough
manpower to do so.
[**] I could talk about "export", and the position of Herb Sutter, a
Microsoft employee, but that has already been discussed elsewhere, and
that *really* would be off-topic.
[***] I've heard that it's also possible in C, but it's rather tedious
and time-consuming.
[****] How well does Lisp handle those very low-level and/or
performance-critical cases, like decoding MPEG-4 video and sending it
to the graphics card's RAM?
[And yes, I did manage, a couple of times, to really mess the video
card memory. Rebooting a PC properly with nothing sensible visible on
the monitor is something I'm glad I don't have to do every day.
Fabien LE LEZ wrote:
<SNIP>
> [****] How well does Lisp handle those very low-level and/or
> performance-critical cases, like decoding MPEG-4 video and sending it
> to the graphics card's RAM?
Accessing RAM can be done in an implementation specific way, but I
won't comment more because I've not done it myself.
I have examined simple floating point math under SBCL. The test is to
add the 3D vector A to B and place it in the already existing vector A.
Put it in a loop and call it a few hundred thousand times. Exactly
the thing that C is good at and takes 5 minutes to code up.
Using GCC4 -O3 for the C code, and doing the right things in SBCL, SBCL
runs less than 2% slower on my machine.
Admittedly, it took a while to get the Lisp code fast, but I'd never
optimised Lisp before either. Basically doing that test convinced me
that Lisp is plenty fast enough for me.
Cheers
Brad
> I have examined simple floating point math under SBCL. The test is to
> add the 3D vector A to B and place it in the already existing vector A.
> Put it in a loop and call it a few hundred thousand times. Exactly
> the thing that C is good at and takes 5 minutes to code up.
> Using GCC4 -O3 for the C code, and doing the right things in SBCL, SBCL
> runs less than 2% slower on my machine.
> Admittedly, it took a while to get the Lisp code fast, but I'd never
> optimised Lisp before either. Basically doing that test convinced me
> that Lisp is plenty fast enough for me.
>
> Cheers
> Brad
Well, at least some one agrees with me. I did tests in other
directions, by writing C and Lisp code which did exactly the same, and
I came to the same conclusions. I think I had even a test which was
faster in Common Lisp than in C (using CMUCL, I think).
Jurgen
bradb wrote:
>
> Accessing RAM can be done in an implementation specific way, but I
> won't comment more because I've not done it myself.
>
> I have examined simple floating point math under SBCL. The test is to
> add the 3D vector A to B and place it in the already existing vector A.
> Put it in a loop and call it a few hundred thousand times. Exactly
> the thing that C is good at and takes 5 minutes to code up.
> Using GCC4 -O3 for the C code, and doing the right things in SBCL, SBCL
> runs less than 2% slower on my machine.
> Admittedly, it took a while to get the Lisp code fast, but I'd never
> optimised Lisp before either. Basically doing that test convinced me
> that Lisp is plenty fast enough for me.
>
> Cheers
> Brad
I think 'gcc4 -O3' is not the fastest C/C++ compiler.
At least it should be 'g++ -march=pentium4 -msse -msse2 -mfpmath=sse
-ffast-math -O3'.
Also new restrict C keyword could help.
void add(real * __restrict__ from, real * __restrict__ to, real val)
{
int i;
for(i=0;i<size;i++)
{
to[i]=from[i]+val;
}
}
And Intel C++ compiler generates better code than gcc. Simple loops
that you are using could be translated into see/see2 packed simd
instructions - more than 2x speedup. Intel compiler also supports
profile-guided optimizations.
Alexander wrote:
> bradb wrote:
> I think 'gcc4 -O3' is not the fastest C/C++ compiler.
> At least it should be 'g++ -march=pentium4 -msse -msse2 -mfpmath=sse
> -ffast-math -O3'.
> Also new restrict C keyword could help.
> void add(real * __restrict__ from, real * __restrict__ to, real val)
> {
> int i;
> for(i=0;i<size;i++)
> {
> to[i]=from[i]+val;
> }
> }
> And Intel C++ compiler generates better code than gcc. Simple loops
> that you are using could be translated into see/see2 packed simd
> instructions - more than 2x speedup. Intel compiler also supports
> profile-guided optimizations.
I'll concede that gcc4 doesn't generate the fastest C code. However,
GCC is the compiler that I (and most other people) have easy access to.
I would guess that for people that truely want insane performance, you
will eventually drop down to assembler.
Now, here is where things get truely interesting for Lisp (SBCL in
particular). You can write your own functions (see
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/b1cdf3a5106abe59/33914863c32dadc7?lnk=gst&q=vop+logand&rnum=1#33914863c32dadc7)
in assembly language, and they can then be used by SBCL just as regular
functions. You can even, for example, override internal functions.
Cheers
Brad
Alexander wrote:
> bradb wrote:
>
> >
> > Accessing RAM can be done in an implementation specific way, but I
> > won't comment more because I've not done it myself.
> >
> > I have examined simple floating point math under SBCL. The test is to
> > add the 3D vector A to B and place it in the already existing vector A.
> > Put it in a loop and call it a few hundred thousand times. Exactly
> > the thing that C is good at and takes 5 minutes to code up.
> > Using GCC4 -O3 for the C code, and doing the right things in SBCL, SBCL
> > runs less than 2% slower on my machine.
> > Admittedly, it took a while to get the Lisp code fast, but I'd never
> > optimised Lisp before either. Basically doing that test convinced me
> > that Lisp is plenty fast enough for me.
> >
> > Cheers
> > Brad
>
> I think 'gcc4 -O3' is not the fastest C/C++ compiler.
> At least it should be 'g++ -march=pentium4 -msse -msse2 -mfpmath=sse
> -ffast-math -O3'.
> Also new restrict C keyword could help.
The data sets could intersect, so definately.
> void add(real * __restrict__ from, real * __restrict__ to, real val)
> {
> int i;
> for(i=0;i<size;i++)
> {
> to[i]=from[i]+val;
> }
> }
> And Intel C++ compiler generates better code than gcc. Simple loops
> that you are using could be translated into see/see2 packed simd
> instructions - more than 2x speedup. Intel compiler also supports
> profile-guided optimizations.
For a Pentium4 SSE would probably not make a huge amount of difference.
SSE on the P4 is normally not greatly better than normal floating
point. To use it well on the P4 requires all kinds of low level
tinkering. That said the speedup would be better with other processor
types.
I agree that Intel C compiler generates better code, but the difference
is not all that great. Several submissions to the SPEC benchmark
have been done using GCC, its not that far behind. Both support PGO.
Code like the above generally doesn't test the compiler much though,
since the processor will process each element of the arrays quickly.
It's likely to benchmark more the memory heirachy and the prefetcher.
Real programs are the best benchmarks.
bradb <··············@gmail.com> wrote:
+---------------
| Fabien LE LEZ wrote:
| > [****] How well does Lisp handle those very low-level and/or
| > performance-critical cases, like decoding MPEG-4 video and sending it
| > to the graphics card's RAM?
|
| Accessing RAM can be done in an implementation specific way, but I
| won't comment more because I've not done it myself.
+---------------
I use the SYSTEM:SAP-REF-{8,16,32} functions is CMUCL quite a lot
in low-level hardware debugging user-mode code for peeking/poking
at hardware being developed/debugged. The compiler does quite a
good job of optimizing uses of them. The bottleneck for throughput
of code that copies bytes/words to/from device registers/memory is
almost always the CPU pipeline stalls caused by accessing the hardware
device as uncached memory, not the CL code per se. E.g., scanning
64 MiB of a certain PCI-X device's RAM for ECC errors, which takes
two 32-bit uncached reads per 32 bits (one to read a word and one
to read the ECC error register) takes ~30 s realtime or ~230 ns/read,
which is about right for an Opteron going across a 2-3 HT links to get
to a PCI-X and then through the hardware device to its attached SDRAM.
CMUCL has been a big help for me in doing this kind of user-mode
hardware debugging. Back in the the mid-90's I used MzScheme
for this sort of thing, but it was way slower. [And before that
I used Tcl, which was way, *WAY* slower!!]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Fabien LE LEZ wrote:
> On Wed, 23 Aug 2006 20:53:54 GMT, Joe Knapka <·········@kneuro.net>:
>
>
>>>But when you've learnt it properly, actually using it is quite easy.
>>
>>The same could be said about alligator wrestling :-)
>
>
> Or the computer version: wrestling with/using emacs :-p
>
> Back on the (off-)topic, the difficulty and the power of C++ is the
> insane number of features if offers[*]. Think of Lisp's "loop"
> structure, but language-wide.
Yes. And those features tend to interact in unexpected ways.
Most of Scott Meyers's advice in "Effective C++" etc is directly
related to the problem of preventing self-inflicted foot injuries.
By comparison, you can explain the basic semantics of Lisp (well,
Scheme anyway) in a few sentences, and for the most part that
brief explanation will serve as a reliable mental model of the
language. I'm by no means a Lisp expert, but I've yet to be
shocked or even deeply surprised by the behavior of Lisp
code I wrote. When things go pear-shaped, it's usually pretty
obvious where I screwed up.
(Well, I take that back. I was a somewhat surprised when
I discovered, by writing a list-handling function in the
natural recursive way, that the default maximum call-stack
depth in Emacs Lisp is only something like 1000 calls. Kinda
sucks, but hey, it's just an editor.)
> C++ even has, like Lisp, a Turing-complete compile-time language, the
> "template" mechanism,
Gah. Just... gah. :-P
> which at least twelve people in the world fully
> understand
Which almost certainly means that a lot of people who write
C++ compilers don't fully understand the language. Now *there's*
a warm fuzzy for you!
> (one of them being Andrei Alexandrescu -- and I still
> haven't read his book; I really need 72 hours per day and 21 days a
> week. But I digress.)
>
> Another power and difficulty of C++ is that the compiler trusts the
> programmer, and let him do (nearly) whatever he pleases.
> If the programmer wants a direct access to the memory ("char*" and
> stuff), good manuals will tell him that it's probably a bad idea, but
> the compiler will accept that without a warning.
> In other words, good C++ programmers will, 99.9% of the time, use
> techniques that don't allow the gun to be directed at the foot[***];
> and the 0.1% remaining[****], they will be extremely careful, in order
> to keep a reasonable number of toes.
But why would you even want to use a language that makes
it so easy to hurt yourself, when simple, effective
alternatives are available?
Anyway, I don't want to get into a language pissing
contest, so we should probably drop this. I'll let you
have the last word if you reply.
Cheers,
-- JK
On Thu, 24 Aug 2006 06:14:17 GMT, Joe Knapka <·········@kneuro.net>:
>But why would you even want to use a language that makes
>it so easy to hurt yourself,
OTOH, it's also easy not too.
>Anyway, I don't want to get into a language pissing
>contest, so we should probably drop this.
I suppose so. [Note that this thread was a troll from the very
beginning.]
Actually I wrote that long message just before going to bed, when my
mind was free to go whereever it wanted without much control.
And anyway, after six years of C++ and three days of Lisp, I'm not
ready yet to either compare them properly, nor to admit that Lisp can
replace C++ completely.
>I'll let you have the last word if you reply.
Yay, I got the last word!
Fabien LE LEZ schrieb:
> On Wed, 23 Aug 2006 20:53:54 GMT, Joe Knapka <·········@kneuro.net>:
>
>>> But when you've learnt it properly, actually using it is quite easy.
>> The same could be said about alligator wrestling :-)
>
> Or the computer version: wrestling with/using emacs :-p
>
> Back on the (off-)topic, the difficulty and the power of C++ is the
> insane number of features if offers[*]. Think of Lisp's "loop"
> structure, but language-wide.
> C++ even has, like Lisp, a Turing-complete compile-time language, the
> "template" mechanism, which at least twelve people in the world fully
> understand (one of them being Andrei Alexandrescu -- and I still
> haven't read his book; I really need 72 hours per day and 21 days a
> week. But I digress.)
>
> Another power and difficulty of C++ is that the compiler trusts the
> programmer, and let him do (nearly) whatever he pleases.
Well, C++ and Lisp are very similar here. Try to modify a char* const,
initialized with a literal string. The C++ compiler usually does not
give a warning, even at highest level. And quite frequently similar
questions arise here on c.l.l... (TODO: check answers, not questions)
> If the programmer wants a direct access to the memory ("char*" and
> stuff), good manuals will tell him that it's probably a bad idea, but
> the compiler will accept that without a warning.
Only if you explicitly tell so, but some rare cases when the 'feature'
was imported from C, but some special case when...
> In other words, good C++ programmers will, 99.9% of the time, use
> techniques that don't allow the gun to be directed at the foot[***];
> and the 0.1% remaining[****], they will be extremely careful, in order
> to keep a reasonable number of toes.
>
Didn't work. Don't walk. Fly. `~==== (cough)
>
>
>
> [*] It's also difficult for implementers: while Intel and Comeau
> painfully managed to implement all the features, Microsoft didn't even
> try[**], and the maintainers of g++ decided they didn't have enough
> manpower to do so.
>
> [**] I could talk about "export", and the position of Herb Sutter, a
> Microsoft employee, but that has already been discussed elsewhere, and
> that *really* would be off-topic.
>
> [***] I've heard that it's also possible in C, but it's rather tedious
> and time-consuming.
>
Well, of course it's possible in C. Just write:
int main()
{
return 0;
}
No leaks. All toes. And no gun in sight.
> [****] How well does Lisp handle those very low-level and/or
> performance-critical cases, like decoding MPEG-4 video and sending it
> to the graphics card's RAM?
> [And yes, I did manage, a couple of times, to really mess the video
> card memory. Rebooting a PC properly with nothing sensible visible on
> the monitor is something I'm glad I don't have to do every day.
>
Le Thu, 24 Aug 2006 01:10:22 +0200, Fabien LE LEZ a écrit :
> How well does Lisp handle those very low-level and/or
> performance-critical cases, like decoding MPEG-4 video and sending it
> to the graphics card's RAM?
Is it really that important to be able to mess with the graphic card's
memory to achieve fast MPEG decoding? If it's needed to send the result
of some algorithm directly to that memory, then you only need some FFI
to send data processed in Lisp, don't you?
Curiously,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
On Thu, 24 Aug 2006 22:18:44 +0200, Pierre THIERRY
<···········@levallois.eu.org>:
>Is it really that important to be able to mess with the graphic card's
>memory to achieve fast MPEG decoding?
Nope. But to send the resulting images to the video card, you have to.
And under Windows, the only fast enough way to do that is to ask
DirectDraw to give me direct access to (part of?) the video card's
memory.
On 18 Aug 2006 10:16:18 -0700, ·············@gmail.com"
<············@gmail.com>:
> I am a beginner of Lisp,
Me too. I've discovered this language a few hours ago.
However, I'm rather experienced in C++, so allow me to try a
comparison.
> 1, the syntax of the language is not intuitive enough, which would
>make people afraid of learning it.
Well, about anything new is counter-intuitive.
When I was at school, I bought a HP48G calculator. It used
reverse-polish notation: to add two and three, you had to type
2 3 +
At first, many found that it was awfully counter-intuitive. And it is.
But when I got the hang of it (after a few days), I discovered that it
was more efficient than the usual way.
Have a look at <http://gotw.ca/gotw> to see how intuitive C++ is ;-)
> 2, the implementation decides too much, maybe it's because the
>standard specification is outdated or the Lisp language itself is
>heavily based on the implementation, and it's hard to find a decent
>implementation on Win 32 platform( at least for me ).
Just try to compile code written for VC++ with g++ (on Windows), or
vice-versa.
C++ is perfectly standardized, and it is possible to write portable
code, but in practice, each implementation adds its own features; and
programmers that aren't aware of the difference between the C++
language and the C++ spoken by their specific compiler, end up writing
unportable code -- and that sentence is getting pretty unreadable :-/
> 3. it's hard to write effective and/or efficient lisp program,
Did you try?
As a beginner myself, I surely wouldn't dare to talk about advanced
Lisp ;-)
············@gmail.com wrote:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
...
> That's my opinion.
Your problem is that you do not understand Grammar. I do not mean Lisp
grammar, which is trivial, or English grammar, or the grammar of your
native tongue (which is evidently not English); I do not mean a
grammar, but the Grammar, the framework of all language, which is the
only medium of thought. The creation of Lisp was in large part an
attempt, and a very good one, to separate the flesh from the bones.
The skeleton is there for us to incarnate for our own creations, which
we do well or ill according as we have or haven't the guts and the
brains to do so.
Tim S.
·············@gmail.com" <············@gmail.com> writes:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
>
> 1, the syntax of the language is not intuitive enough, which would
> make people afraid of learning it.
The syntax of Lisp is *different*. It's actually more intuitive, in
the sense that it is more uniform, than other mainstream languages,
but the fact that it is not the same as they are provokes the caveman
response:
Ugh! Lisp different!! Me suspicious!!
--
Fred Gilham ······@csl.sri.com
Progressive (adj): Value-free; tolerant; non-judgemental.
E.g. traditional archery instruction methods spent tedious hours
teaching the archer to hit a bulls-eye. Progressive methods achieved
better results by telling the student archer to shoot in the manner he
or she found most comfortable, then calling whatever the arrow hit the
bulls-eye.
Fred Gilham wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
>
>>Hello:
>>
>> I am a beginner of Lisp, but from recent discussion it's not hard to
>>find the weakness of Lisp. That it,
>>
>> 1, the syntax of the language is not intuitive enough, which would
>>make people afraid of learning it.
>
>
> The syntax of Lisp is *different*. It's actually more intuitive, in
> the sense that it is more uniform, than other mainstream languages,
> but the fact that it is not the same as they are provokes the caveman
> response:
>
> Ugh! Lisp different!! Me suspicious!!
>
No shopping? :(
kenneth
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Fred Gilham wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
>
>>Hello:
>>
>> I am a beginner of Lisp, but from recent discussion it's not hard to
>>find the weakness of Lisp. That it,
>>
>> 1, the syntax of the language is not intuitive enough, which would
>>make people afraid of learning it.
>
>
> The syntax of Lisp is *different*. It's actually more intuitive, in
> the sense that it is more uniform, than other mainstream languages,
> but the fact that it is not the same as they are provokes the caveman
> response:
>
> Ugh! Lisp different!! Me suspicious!!
>
Lisp syntax is like mathematics: perfectly logical, but not really in
tune with the wirings of the average human brain.
--
The science of economics is the cleverest proof of free will yet
constructed.
> Lisp syntax is like mathematics: perfectly logical, but not really in
> tune with the wirings of the average human brain.
Ah! I see that your PhD in Cognitive Neuroscience comes from the same
place that graduated the brilliant commentators who gave us: "it fits
your brain..." and "only one obvious way..."
Eli Gottlieb <···········@gmail.com> wrote on Wed, 23 Aug 2006:
> Lisp syntax is like mathematics: perfectly logical, but not really in tune
> with the wirings of the average human brain.
The average human brain probably isn't well structured to do computer
programming at all.
Of those humans that have at least some affinity for programming computers,
it's far from obvious how Lisp syntax compares with the syntax of other
popular languages, in terms of being "in tune with the wirings" of
programmer brains.
For one thing, it's clear that most of comfort with all kinds of languages
is about familiarity, and the more you use something, the more "natural" it
seems to you.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
You have the intellect of dirt. You'll make a good MINION.
On Wed, 23 Aug 2006 09:45:37 -0700, Don Geddis <···@geddis.org>:
>For one thing, it's clear that most of comfort with all kinds of languages
>is about familiarity, and the more you use something, the more "natural" it
>seems to you.
And since there are lots of programming languages that have roughly
the same syntax as C, there's a huge probability that your first
language was one of those.
Le Wed, 23 Aug 2006 02:00:41 +0000, Eli Gottlieb a écrit :
>> Ugh! Lisp different!! Me suspicious!!
> Lisp syntax is like mathematics: perfectly logical, but not really in
> tune with the wirings of the average human brain.
I'm definitely not the average human. My brain has surely been wired
upside-down, because Lisp fits it way much than any other programming
language I ever tried.
Insanely,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Pierre THIERRY wrote:
> Le Wed, 23 Aug 2006 02:00:41 +0000, Eli Gottlieb a écrit :
>
>>>Ugh! Lisp different!! Me suspicious!!
>>
>>Lisp syntax is like mathematics: perfectly logical, but not really in
>>tune with the wirings of the average human brain.
>
>
> I'm definitely not the average human. My brain has surely been wired
> upside-down, because Lisp fits it way much than any other programming
> language I ever tried.
>
> Insanely,
> Nowhere man
Who said you were average? I'll bet you most people in this newsgroup
have brains better wired for math and Lisp than most of the population.
--
The science of economics is the cleverest proof of free will yet
constructed.
On Wed, 23 Aug 2006 16:18:03 +0200, Eli Gottlieb <···········@gmail.com>
wrote:
> Pierre THIERRY wrote:
>> Le Wed, 23 Aug 2006 02:00:41 +0000, Eli Gottlieb a �crit :
>>
>>>> Ugh! Lisp different!! Me suspicious!!
>>>
>>> Lisp syntax is like mathematics: perfectly logical, but not really in
>>> tune with the wirings of the average human brain.
>> I'm definitely not the average human. My brain has surely been wired
>> upside-down, because Lisp fits it way much than any other programming
>> language I ever tried.
>> Insanely,
>> Nowhere man
> Who said you were average? I'll bet you most people in this newsgroup
> have brains better wired for math and Lisp than most of the population.
>
Of cource!
Because we do both.
You don't get born with this you get it by doing..
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
On Tue, 22 Aug 2006 15:26:36 -0700, Fred Gilham:
>The syntax of Lisp is *different*. It's actually more intuitive
As a beginner, I find one thing rather confusing: the difference
between =, eq, eql, equal and equalp. That seems especially
complicated to the C++ programmer that I am.
In C++, whatever a and b might be, "a == b" always means "a and b have
the same value". If that doesn't make sense, you just get a compiler
error.
If you want to know whether a and b have the same address (which ain't
that frequent), it's the same:
"(the address of a) and (the address of b) have the same value"
(i.e. "&a == &b").
Fabien LE LEZ wrote:
> On Tue, 22 Aug 2006 15:26:36 -0700, Fred Gilham:
>
> >The syntax of Lisp is *different*. It's actually more intuitive
>
> As a beginner, I find one thing rather confusing: the difference
> between =, eq, eql, equal and equalp. That seems especially
> complicated to the C++ programmer that I am.
Here's the way I remember it. Think of the size of the word: eq, eql,
equalp. The smaller the word, the closer together the arguments
actually are. The smaller comparisons (eq, eql) are stricter, while
the longer words (equal, equalp) are looser. So if you are comparing
identity, like your 'same address' comparison in C/C++, use eq or eql.
Check the CLHS first. If you are comparing value of the objects, use
the larger words equal or equalp. Check the CLHS for them as well.
This helps me narrow down the choices when I have to pick one or the
other. Silly? Perhaps. Simple? I think so. Easy to remember?
Definitely.
On 26 Aug 2006 08:35:02 -0700, "jmckitrick" <···········@yahoo.com>:
>[...] Check the CLHS first. [...] Check the CLHS for them as well.
So simple that you have to check the manual, uh?
And the eq, eql, etc. entries in CLHS are rather long, too.
For my own functions, I have a rule: just by reading the name, you
know quite precisely what the function do.
If I fail, that means reading my programs will be more difficult, and
longer.
IMHO, the guy who invented =, eq, eql, equal and equalp failed.
>This helps me narrow down the choices when I have to pick one or the
>other. Silly? Perhaps. Simple? I think so. Easy to remember?
>Definitely.
Well, I know I'll get the hang of those eventually, since they're
heavily used.
But two predicates[*] named same-value and same-identity (or
same-variable) would definitely make things clearer.
[*] I don't know how/where to put an equivalent of equalp, since I've
never used such a predicate before.
(Note: I'm not trying to say that one language is better than another.
C++ also has its stupid function names, like a "remove" that doesn't
remove anything...)
Fabien LE LEZ wrote:
> On 26 Aug 2006 08:35:02 -0700, "jmckitrick" <···········@yahoo.com>:
>
> >[...] Check the CLHS first. [...] Check the CLHS for them as well.
>
> So simple that you have to check the manual, uh?
> And the eq, eql, etc. entries in CLHS are rather long, too.
>
> For my own functions, I have a rule: just by reading the name, you
> know quite precisely what the function do.
So, instead of ``equalp'', you would name this function
Returns-true-if-x-and-y-are-equal-or-if-they-have-components-that-are-of-the-same-type-as-each-other-and-if-those-components-are-equalp-specifically-equalp-returns-true-in-the-following-cases-Characters-If-two-characters-are-char-equal-Numbers-If-two-numbers-are-the-same-under-=-Conses-If-the-two-cars-in-the-conses-are-equalp-and-the-two-cdrs-in-the-conses-are-equalp-Arrays-If-two-arrays-have-the-same-number-of-dimensions-the-dimensions-match-and-the-corresponding-active-elements-are-equalp-The-types-for-which-the-arrays-are-specialized-need-not-match-for-example-a-string-and-a-general-array-that-happens-to-contain-the-same-characters-are-equalp-Because-equalp-performs-element-by-element-comparisons-of-strings-and-ignores-the-case-of-characters-case-distinctions-are-ignored-when-equalp-compares-strings-Structures-If-two-structures-S1-and-S2-have-the-same-class-and-the-value-of-each-slot-in-S1-is-the-same-under-equalp-as-the-value-of-the-corresponding-slot-in-S2-Hash-Tables-equalp-descends-hash-tables-by-first-comparing-the-count-of-entries-and-the-test-function-if-those-are-the-same-it-compares-the-keys-of-the-tables-using-the-test-function-and-then-the-values-of-the-matching-keys-using-equalp-recursively-equalp-does-not-descend-any-objects-other-than-the-ones-explicitly-specified-above-The-next-figure-summarizes-the-information-given-in-the-previous-list-In-addition-the-figure-specifies-the-priority-of-the-behavior-of-equalp-with-upper-entries-taking-priority-over-lower-ones
?
Tim S
On 26 Aug 2006 10:48:11 -0700, "numeromancer" <·······@sbcglobal.net>:
>So, instead of ``equalp'', you would name this function
>Returns-true-if-x-and-y-are-equal-or-if-they-have-components-that-are-of-the-same-type-as-each-other-and-if-those-components-are-equalp-specifically-equalp-returns-true-in-the-following-cases-Characters-If-two-characters-are-char-equal-Numbers-If-two-numbers-are-the-same-under-=-Conses-If-the-two-cars-in-the-conses-are-equalp-and-the-two-cdrs-in-the-conses-are-equalp-Arrays-If-two-arrays-have-the-same-number-of-dimensions-the-dimensions-match-and-the-corresponding-active-elements-are-equalp-The-types-for-which-the-arrays-are-specialized-need-not-match-for-example-a-string-and-a-general-array-that-happens-to-contain-the-same-characters-are-equalp-Because-equalp-performs-element-by-element-comparisons-of-strings-and-ignores-the-case-of-characters-case-distinctions-are-ignored-when-equalp-compares-strings-Structures-If-two-structures-S1-and-S2-have-the-same-class-and-the-value-of-each-slot-in-S1-is-the-same-under-equalp-as-the-value-of-the-corresponding-slot-in-S2-Hash-Tables-equalp-de
s
>cends-hash-tables-by-first-comparing-the-count-of-entries-and-the-test-function-if-those-are-the-same-it-compares-the-keys-of-the-tables-using-the-test-function-and-then-the-values-of-the-matching-keys-using-equalp-recursively-equalp-does-not-descend-any-objects-other-than-the-ones-explicitly-specified-above-The-next-figure-summarizes-the-information-given-in-the-previous-list-In-addition-the-figure-specifies-the-priority-of-the-behavior-of-equalp-with-upper-entries-taking-priority-over-lower-ones
>?
I wouldn't do such a function -- too complicated.
I've read that when comparing two strings, equalp ignores case.
So, what's the results of the following expressions?
(equalp "foo" "FOO")
(equalp "caf�" "CAF�")
(equalp "Stra�e" "STRASSE")
(Note that in each expression, the second word is the first word,
capitalized.)
Those five functions are nearly the very first a beginner has to
learn. And they seem to be, by far, the most complicated things I've
seen in Lisp.
Fabien LE LEZ wrote:
> On 26 Aug 2006 10:48:11 -0700, "numeromancer" <·······@sbcglobal.net>:
>
> >So, instead of ``equalp'', you would name this function
> >Returns-true-if-x-and-y-are-equal-or-if-they-have-components-that-are-of-the-same-type-as-each-other-and-if-those-components-are-equalp-specifically-equalp-returns-true-in-the-following-cases-Characters-If-two-characters-are-char-equal-Numbers-If-two-numbers-are-the-same-under-=-Conses-If-the-two-cars-in-the-conses-are-equalp-and-the-two-cdrs-in-the-conses-are-equalp-Arrays-If-two-arrays-have-the-same-number-of-dimensions-the-dimensions-match-and-the-corresponding-active-elements-are-equalp-The-types-for-which-the-arrays-are-specialized-need-not-match-for-example-a-string-and-a-general-array-that-happens-to-contain-the-same-characters-are-equalp-Because-equalp-performs-element-by-element-comparisons-of-strings-and-ignores-the-case-of-characters-case-distinctions-are-ignored-when-equalp-compares-strings-Structures-If-two-structures-S1-and-S2-have-the-same-class-and-the-value-of-each-slot-in-S1-is-the-same-under-equalp-as-the-value-of-the-corresponding-slot-in-S2-Hash-Tables-equalp-de
> s
> >cends-hash-tables-by-first-comparing-the-count-of-entries-and-the-test-function-if-those-are-the-same-it-compares-the-keys-of-the-tables-using-the-test-function-and-then-the-values-of-the-matching-keys-using-equalp-recursively-equalp-does-not-descend-any-objects-other-than-the-ones-explicitly-specified-above-The-next-figure-summarizes-the-information-given-in-the-previous-list-In-addition-the-figure-specifies-the-priority-of-the-behavior-of-equalp-with-upper-entries-taking-priority-over-lower-ones
> >?
>
> I wouldn't do such a function -- too complicated.
>
> I've read that when comparing two strings, equalp ignores case.
> So, what's the results of the following expressions?
>
> (equalp "foo" "FOO")
t
> (equalp "café" "CAFÉ")
t in clisp, which handles unicode well, nil in others which don't.
What says C++? Does ``=='' tell you what this operator does in C++,
precisely, without having to look in the standard? Could you guess
that it does not ignore case without knowing, or looking, or guessing
how these will probably be computed on a digital computer?
> (equalp "Straße" "STRASSE")
nil. Should (equalp "colour'" and "Color") evaluate to t? What about
(equalp "dog" "chien")?
>
> (Note that in each expression, the second word is the first word,
> capitalized.)
Except the last, sort of. A german would have to think to see the
difference, but a program must see the difference, because it cannot
handle generalities.
>
> Those five functions are nearly the very first a beginner has to
> learn. And they seem to be, by far, the most complicated things I've
> seen in Lisp.
``equalp'' is an emperor function; its will can usually be guessed by
its character, but if its will be known with certain precision for
every nook of its dominion, this will must be specified in long and
tedious specification, or precisely delegated. Ennuyeux, for certain,
but the nature of ``=='' in C++ was complicated with its
generalization, too. It is the nature of language: the meaning of
generalities must be guessed when pressed to detail, or be specified
with complication to tedium.
Tim S
"numeromancer" <·······@sbcglobal.net> writes:
>
>> (equalp "Straße" "STRASSE")
>
> nil. Should (equalp "colour'" and "Color") evaluate to t? What about
> (equalp "dog" "chien")?
Well, 'STRASSE' is the proper way to write 'straße' in capital letters.
The right thing to do would to include a 'SS' character, but no-one
seems to have gone there.
>> (Note that in each expression, the second word is the first word,
>> capitalized.)
>
> Except the last, sort of.
No, that's the proper capitalisation. And I don't think that the
Germans will soon be eliminating their 'ß.'
--
Robert Uhl <http://public.xdi.org/=ruhl>
The world would be a lot better off if more people knew a lot less
about HTML. --Kevin Buhr
On 26 Aug 2006 12:34:09 -0700, "numeromancer" <·······@sbcglobal.net>:
>> (equalp "foo" "FOO")
>t
>> (equalp "caf�" "CAF�")
>t in clisp, which handles unicode well, nil in others which don't.
nil with GCL (GNU Common Lisp) Version(2.5.0) under Windows.
>> (equalp "Stra�e" "STRASSE")
>nil.
So, when comparing strings, equalp sometimes ignores case.
The exact meaning of "sometimes" here depends on the implementation.
And "sometimes" becomes "always" if both strings contain only ASCII
characters (i.e. 32 to 127).
Right?
>Should (equalp "colour'" and "Color") evaluate to t? What about
>(equalp "dog" "chien")?
I don't know. All that is arbitrary, and for now, I don't intend to
modify the language -- I'm just trying to understand its basics.
Note that this is not just a theorical problem for the pleasure of
contradicting people. My next website will contain a search engine,
that must handle names containing such letters. E.g. "Karl Weierstra�"
or "Henri Poincar�".
Le Sat, 26 Aug 2006 22:04:46 +0200, Fabien LE LEZ a écrit :
>>> (equalp "Straße" "STRASSE")
>>nil.
> So, when comparing strings, equalp sometimes ignores case. The exact
> meaning of "sometimes" here depends on the implementation.
I'm not sure any current software would pass the test that comparing
Straße and STRASSE while ignoring case yields true. That's maybe even a
confusion. I'm not sure the case refers to capitalization of words, but
of letters.
Here equalp is meant to work on strings, not on sentences or words.
Sentences and words are a very narrow subset of all possible strings. If
equalp had been made to work sensibly on sentences and words
specifically, it would have been weird; IMHO.
Now if you care about typography, you could make up the following
functions: capitalize, which takes a string made only of words and
punctuation, and capitalizes every word in it, in a typorgraphically
correct way, and is-capitalized, which checks that it's first argument
is what you get when capitalizing the second one.
But is-capitalized would have very different uses than equalp...
Then we could talk about Unicode and the fact that different sequences
of characters can represent the same thing, like an accentuated letter
(e.g. an accentuated E versus an accent and a E...).
Identity indeed has many facets.
In a data structures and algorithm lecture, as some student was arguing
about identity of data ('when it has mutated, it's not identical'), the
teacher asked the wether he was identical to himself. 'Of course', he
answered. Then the teacher asked if he was identical to himself at the
age of 5 or 10...
Identically,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Pierre THIERRY <···········@levallois.eu.org> writes:
> I'm not sure any current software would pass the test that comparing
> Stra�e and STRASSE while ignoring case yields true.
Any software which correctly applies Unicode case folding rules does.
For example my language Kogut does.
> I'm not sure the case refers to capitalization of words, but of
> letters.
Changing case of words most of the time can be performed a character
at the time, but in some subtle combinations it's not sufficient.
http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
"numeromancer" <·······@sbcglobal.net> wrote in message
·····························@p79g2000cwp.googlegroups.com...
>
> Fabien LE LEZ wrote:
>> On 26 Aug 2006 08:35:02 -0700, "jmckitrick" <···········@yahoo.com>:
>>
>> >[...] Check the CLHS first. [...] Check the CLHS for them as well.
>>
>> So simple that you have to check the manual, uh?
>> And the eq, eql, etc. entries in CLHS are rather long, too.
>>
>> For my own functions, I have a rule: just by reading the name, you
>> know quite precisely what the function do.
>
> So, instead of ``equalp'', you would name this function
> Returns-true-if-x-and-y-are-equal-or-if-they-have-components-that-are-of-the-same-type-as-each-other-and-if-those-components-are-equalp-specifically-equalp-returns-true-in-the-following-cases-Characters-If-two-characters-are-char-equal-Numbers-If-two-numbers-are-the-same-under-=-Conses-If-the-two-cars-in-the-conses-are-equalp-and-the-two-cdrs-in-the-conses-are-equalp-Arrays-If-two-arrays-have-the-same-number-of-dimensions-the-dimensions-match-and-the-corresponding-active-elements-are-equalp-The-types-for-which-the-arrays-are-specialized-need-not-match-for-example-a-string-and-a-general-array-that-happens-to-contain-the-same-characters-are-equalp-Because-equalp-performs-element-by-element-comparisons-of-strings-and-ignores-the-case-of-characters-case-distinctions-are-ignored-when-equalp-compares-strings-Structures-If-two-structures-S1-and-S2-have-the-same-class-and-the-value-of-each-slot-in-S1-is-the-same-under-equalp-as-the-value-of-the-corresponding-slot-in-S2-Hash-Tables-equalp-descends-hash-tables-by-first-comparing-the-count-of-entries-and-the-test-function-if-those-are-the-same-it-compares-the-keys-of-the-tables-using-the-test-function-and-then-the-values-of-the-matching-keys-using-equalp-recursively-equalp-does-not-descend-any-objects-other-than-the-ones-explicitly-specified-above-The-next-figure-summarizes-the-information-given-in-the-previous-list-In-addition-the-figure-specifies-the-priority-of-the-behavior-of-equalp-with-upper-entries-taking-priority-over-lower-ones
> ?
>
> Tim S
Oh i see now why emacs wraps lines around.
Sacha
Fabien LE LEZ wrote:
> IMHO, the guy who invented =, eq, eql, equal and equalp failed.
Often comparisons with lisp and C++ are unfair because lisp is doing
more for you. So much more information is available to the programmer
at compile time and run time that of course you will have more ways of
comparing objects.
In C++ for example you cannot say "is A a function, is it a variable or
is it something else?". C++ has no built in concepts for string
comparison at all, whilst lisp can handle different text encoding
straight out of the box.
You have to read the manual, as is often the case in lisp, but it
doesn't take long to figure out that more flexibility and power comes
from having more options.
On 27 Aug 2006 08:59:09 -0700, "justinhj" <········@gmail.com>:
>In C++ for example you cannot say "is A a function, is it a variable or
>is it something else?".
I'm not sure I understand you.
In Lisp, a function called A and a variable called A can coexist.
(Well, of course, the variable A can be a pointer to a function, but
it's still a variable.)
C++ might be simpler here, since there are no "variables" in the Lisp
sense. There are just (named) objects, which have a type and keep it
their whole life.
> C++ has no built in concepts for string comparison at all,
What are you calling "built in"?
std::string is part of the ISO C++ standard.
So is std::wstring.
True, C++ has no build-in way to handle case comparison.
But Lisp is worse, since it has half a way to do it (see the
"Stra�e"/"STRASSE" example).
Fabien LE LEZ wrote:
> On 27 Aug 2006 08:59:09 -0700, "justinhj" <········@gmail.com>:
>
> >In C++ for example you cannot say "is A a function, is it a variable or
> >is it something else?".
> I'm not sure I understand you.
> In Lisp, a function called A and a variable called A can coexist.
> (Well, of course, the variable A can be a pointer to a function, but
> it's still a variable.)
I'm just trying to give a feel for the greater amount of runtime
information available to you. Given a symbol A I can find out if there
is a function or another type of object (or indeed both as you
mentioned).
> C++ might be simpler here, since there are no "variables" in the Lisp
> sense. There are just (named) objects, which have a type and keep it
> their whole life.
Simpler is not always better. Assembly language is simpler than C, and
C is simpler than Java. Yet there are certain applications you would
better write in assembler and others you would better write in Java.
>
> > C++ has no built in concepts for string comparison at all,
>
> What are you calling "built in"?
> std::string is part of the ISO C++ standard.
> So is std::wstring.
>
> True, C++ has no build-in way to handle case comparison.
> But Lisp is worse, since it has half a way to do it (see the
> "Straße"/"STRASSE" example).
That's an interesting problem, but one that is easily solved. lisp is
merely telling you that the characters making up the string are not the
same (regardless of how they are encoded). In this case the German
language has two letters for something that is only one letter when
lower case. I'm not sure how any program can be expected to determine
when you intended a SS and when you intended a capitalised sharp S. Not
without searching a dictionary to check the word.
Regardles you have the problem, and it's neither helped nor hindered by
having four levels of equality testing.
On 27 Aug 2006 10:45:17 -0700, "justinhj" <········@gmail.com>:
>> But Lisp is worse, since it has half a way to do it (see the
>> "Stra�e"/"STRASSE" example).
>I'm not sure how any program can be expected to determine
>when you intended a SS and when you intended a capitalised sharp S.
Since we're talking about comparison here, there is an algorithm that
works fine with English, French and German: put both strings in upper
case (with the rule "�" => "SS"), and then compare them.
Well, in fact, in French, the capitalised "�" is quite often
(incorrecly) written "E".
So a working algorithm (e.g. for a search engine) would be even more
complex. I suppose I'd use either Soundex or the Levenshtein distance
to get sensible results.
All that to say that EQUALP is quite deceptive, especially since what
it really does is implementation-defined.
>Not without searching a dictionary to check the word.
This would not help, since "Masse" and "Ma�e" are both written
"MASSE"[*] in upper case.
[*] Should be Ma�e -> MASZE, strictly speaking, but AFAIK this rule
isn't respected in everyday life.
"justinhj" <········@gmail.com> writes:
>
>> True, C++ has no build-in way to handle case comparison. But Lisp is
>> worse, since it has half a way to do it (see the "Straße"/"STRASSE"
>> example).
>
> That's an interesting problem, but one that is easily solved. lisp is
> merely telling you that the characters making up the string are not
> the same (regardless of how they are encoded). In this case the German
> language has two letters for something that is only one letter when
> lower case. I'm not sure how any program can be expected to determine
> when you intended a SS and when you intended a capitalised sharp
> S. Not without searching a dictionary to check the word.
If the Unicode guys hadn't denied it, there would have been a capital ß
(whose glyph should have been SS as a single letter), and then upcasing
straße and then downcasing that result would Do the Right Thing.
Instead they made IMHO a big mistake.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I still can't see a wasp without thinking '400K 1W.'
--Derek Potter, uk.misc
Fabien LE LEZ <········@gramster.com> writes:
>
>>If the Unicode guys hadn't denied it, there would have been a capital
>>ß (whose glyph should have been SS as a single letter), and then
>>upcasing straße and then downcasing that result would Do the Right
>>Thing. Instead they made IMHO a big mistake.
>
> Well... The thing is, if the user types "SS", you still don't know
> whether he meant "double S" or "capital ß".
That could be handled by a German input method--either shift+ß generates
the 'SS' glyph or smart software figures it out.
If the CL spec can assume the existence of a sufficiently smart
compiler, I can assume the existence of a sufficiently smart input
method:-)
--
Robert Uhl <http://public.xdi.org/=ruhl>
If I want to be challenged, to think, to grow or improve or any of
that kinda stuff I read a book. When I go to the movies I want
explosions, improbable one-liners, well configured women in proper
attire etc. --billy
On Tue, 29 Aug 2006 09:23:30 -0600, Robert Uhl
<·········@NOSPAMgmail.com>:
>That could be handled by a German input method--either shift+� generates
>the 'SS' glyph
>or smart software figures it out.
And if the user types "MASSE" in, say, a search engine, what then?
I have not programmed in C for a long time but i cannot
believe what you are claiming. If a and b are char arrays,
what does a == b do?
does it compare pointers or strings?
my memory is that a == b in that case tests whether
the strings are stored in the same memory location,
not whether their char contents are the same. Is this correct?
-jim
Fabien LE LEZ wrote:
> On Tue, 22 Aug 2006 15:26:36 -0700, Fred Gilham:
>
> >The syntax of Lisp is *different*. It's actually more intuitive
>
> As a beginner, I find one thing rather confusing: the difference
> between =, eq, eql, equal and equalp. That seems especially
> complicated to the C++ programmer that I am.
>
> In C++, whatever a and b might be, "a == b" always means "a and b have
> the same value". If that doesn't make sense, you just get a compiler
> error.
> If you want to know whether a and b have the same address (which ain't
> that frequent), it's the same:
> "(the address of a) and (the address of b) have the same value"
> (i.e. "&a == &b").
Jimka wrote:
> I have not programmed in C for a long time but i cannot
> believe what you are claiming. If a and b are char arrays,
> what does a == b do?
> does it compare pointers or strings?
>
> my memory is that a == b in that case tests whether
> the strings are stored in the same memory location,
> not whether their char contents are the same. Is this correct?
>
> -jim
Char arrays are pointers, so obviously the memory locations are
compared. This is why the function strcmp exists.
On the other hand, in C++, you could use std::string and the operator
== would act like strcmp and compare the strings.
On 26 Aug 2006 08:38:42 -0700, "Jimka" <·····@rdrop.com>:
>I have not programmed in C for a long time but i cannot
>believe what you are claiming. If a and b are char arrays,
>what does a == b do?
I don't know, I don't program in C.
I wrote "In C++", meaning that what I said is true in C++.
C is quite a different language.
In C++, you have two different kind of strings:
- litteral strings, i.e. strings that are typed directly in the source
code, and can't change during the execution;
- other strings, that can be created and change during the execution.
You'll usually use std::string, but in some case you may want to use
another (but similar) class.
Let a and b be two objects of class std::string.
a == b => comparison by value
a == "Hello world" => comparison by value
"Hello world" == b => comparison by value
"Hello world" == "Hello guy" => I don't know the result (I never
tried), but it doesn't make sense to compute that at runtime, since
the two strings are known at compile-time.
[Note: in C++, you can also use char* like in C, but it's considered
advanced programming, and used mainly to create the class std::string.
A beginner shouldn't bother with that kind of dark corners.]
Jimka schrieb:
> I have not programmed in C for a long time but i cannot
> believe what you are claiming. If a and b are char arrays,
> what does a == b do?
> does it compare pointers or strings?
>
> my memory is that a == b in that case tests whether
> the strings are stored in the same memory location,
> not whether their char contents are the same. Is this correct?
>
This is absolutely correct, BUT we are talking about a C-ism here. C++
has string, vector, valarray, etc.. Those have appropriatly defined
operator==() functions, which compare by value.
Whenever you use C-style programming in C++, you are on your own. You
can make const objects mutable via const_cast<>, and Lisp offers (safety
0), etc. etc. Own fault, not the language.
The problem in C++ is, whenever you see a pointer, you ask this little *
(star): are you a reference? an array? a valid optimization? or just
plain _wrong_?
I think, about 70% of problems people encounter in C++ programming (at
least in our project, which has to deal with tons of old code) would be
eliminated by using what C++ has to offer, instead of using such legacy
(sic!) constructs like raw pointers in user code (they can all be
efficiently and safely wrapped).
just my 2 euro cents.
-- Markus
> -jim
>
>
> Fabien LE LEZ wrote:
>> On Tue, 22 Aug 2006 15:26:36 -0700, Fred Gilham:
>>
>>> The syntax of Lisp is *different*. It's actually more intuitive
>> As a beginner, I find one thing rather confusing: the difference
>> between =, eq, eql, equal and equalp. That seems especially
>> complicated to the C++ programmer that I am.
>>
>> In C++, whatever a and b might be, "a == b" always means "a and b have
>> the same value". If that doesn't make sense, you just get a compiler
>> error.
>> If you want to know whether a and b have the same address (which ain't
>> that frequent), it's the same:
>> "(the address of a) and (the address of b) have the same value"
>> (i.e. "&a == &b").
>
On Sat, 26 Aug 2006 17:59:34 +0200, Markus Grueneis
<··········@gmx.net>:
>Whenever you use C-style programming in C++
... you program is a mess.
If you program in C++ like you'd program in C, it won't work -- but
it's not the language's fault.
[Note that even a program that works perfectly in C might not be
correct in C++, because of the exceptions mechanism.]
Well, OK, in some very tiny part of your program (typically, when you
want to implement your own intelligent pointer), you'll have to use
naked pointers and stuff like that. But then again, that's advanced
programming -- a beginner won't have to care about that, at least not
the first few months or so.
>I think, about 70% of problems people encounter in C++ programming (at
>least in our project, which has to deal with tons of old code) would be
>eliminated by using what C++ has to offer, instead of using such legacy
>(sic!) constructs like raw pointers in user code (they can all be
>efficiently and safely wrapped).
Yup. Like I said, C++ lets you do what you want. It's up to the
programmer to program properly, or not.
And when your C++ teacher knows only about C, the result is usually
quite awful.
Fabien LE LEZ wrote:
> On Tue, 22 Aug 2006 15:26:36 -0700, Fred Gilham:
>
> >The syntax of Lisp is *different*. It's actually more intuitive
>
> As a beginner, I find one thing rather confusing: the difference
> between =, eq, eql, equal and equalp. That seems especially
> complicated to the C++ programmer that I am.
>
> In C++, whatever a and b might be, "a == b" always means "a and b have
> the same value".
A transliteration of a notation into English is not the same thing as
an assignment of meaning. If the English sentence has a meaning, then
certainly, the transliteration connects the notation to that meaning.
But in this case, the English sentence does not have a meaning, by
itself. It has to be connected to some definition which explains how A
and B are considered to have the same value!
In C++, for user defined class types, the == operator, if defined, can
in fact mean anything whatsoever. It can even fail, mathematically, to
be an equivalence relation.
Also, when you can only have one equality operator, that can be a
problem, because there is more than way in which two things can be
considered equal.
You might recall that any symmetric, transitive and reflexive relation
over a domain can be considered to be a form of equality.
That is part of the reason why Lisp has more than one equality
function. For various types, they actually have different meanings
which are useful, and all of those meanings satisfy the definition of
an equivalence relation.
> If that doesn't make sense, you just get a compiler error.
> If you want to know whether a and b have the same address (which ain't
> that frequent), it's the same:
> "(the address of a) and (the address of b) have the same value"
> (i.e. "&a == &b").
It is quite frequent if you include the comparison of pointers. It's
not that frequent to compare the addresses of declared variables, since
unless one of them is a reference to the other, or some
implementation-defined trick was used to alias them to the same object
(e.g. alias symbols in the ELF specification) you already know they are
different.
However, C++ programs pass around objects using references and
pointers, and so these comparisons do arise.
For instance, in user-defined assignment oeprators, it's often
necessary to include a check for self-assignment, which is based
address: if (this != &right_hand_object) ...
Smart C++ programmers know about interning and take advantage of it.
On 26 Aug 2006 11:06:08 -0700, "Kaz Kylheku" <········@gmail.com>:
>In C++, for user defined class types, the == operator, if defined, can
>in fact mean anything whatsoever.
But if the operator == doesn't mean "equality of value", for a
sensible and canonical definition of "equality", then it's an abuse,
and you'd better not use the class.
True, C++ let you do anything you want -- it's up to you to write
sensible things.
Either the class has sensible operators (or no operators at all), or
it is bogus.
>Also, when you can only have one equality operator, that can be a
>problem, because there is more than way in which two things can be
>considered equal.
Either there's an evident canonical way of defining equality, and
that's what == means, or there's not (i.e. no way, or more than one),
and the class doesn't have a == operator.
But for "simple" objects (strings, numbers, arrays of strings, etc.),
there is usually a simple definition for ==.
>For instance, in user-defined assignment oeprators, it's often
>necessary to include a check for self-assignment, which is based
>address: if (this != &right_hand_object) ...
Nope. It might be used as an optimisation, but that's all.
If you need that trick to make your program correct, it means that
it's actually more subtly incorrect -- it's not exception-safe. See
for example "Exceptional C++" (Herb Sutter) for a detailed
explanation.
<even more OT>
The proper way of doing operator= is:
T& operator= (T const& src)
{
T new_value (src);
new_value.swap (*this);
}
(with a swap() member function that just swaps internal pointers, and
that's guaranteed not to throw).
</>
Fabien LE LEZ <········@gramster.com> writes:
> On Tue, 22 Aug 2006 15:26:36 -0700, Fred Gilham:
>
>>The syntax of Lisp is *different*. It's actually more intuitive
>
> As a beginner, I find one thing rather confusing: the difference
> between =, eq, eql, equal and equalp.
You could always use EQUALP.
> That seems especially
> complicated to the C++ programmer that I am.
Ah, if you're a C++ programmer you might prefer to always use EQL.
> In C++, whatever a and b might be, "a == b" always means "a and b have
> the same value". If that doesn't make sense, you just get a compiler
> error.
Oh oh! So you're expecting some overloading of operator==.
Try:
(defgeneric == (a b)
(:method ((a number) (b number)) (= a b))
(:method ((a character) (b character)) (char= a b))
(:method ((a string) (b string)) (string= a b))
(:method ((a array) (b array)) (equal a b))
(:method ((a symbol) (b symbol)) (eq a b))
(:method ((a t) (b t)) (eql a b)))
> If you want to know whether a and b have the same address (which ain't
> that frequent), it's the same:
> "(the address of a) and (the address of b) have the same value"
> (i.e. "&a == &b").
bool really(int* a,int* b){return((&a)==(&b));}
int main(void){
int a=1;
int b=2;
printf("%d\n",really(&a,&a));
printf("%d\n",really(&a,&b));
return(0);}
Serriously, go read this article: http://www.nhplace.com/kent/PS/EQUAL.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
On Sat, 26 Aug 2006 20:31:32 +0200, Pascal Bourguignon
<···@informatimago.com>:
>bool really(int* a,int* b){return((&a)==(&b));}
Since "a" and "b" means something completely different in this
function and in main(), I'd rather rename them, if you don't mean:
bool really (int * ptr1, int * ptr2)
{ return &ptr1 == &ptr2; }
So you like playing with pointers to pointers?
The function will always return false, because you're asking whether
ptr1 and ptr2 (which are local variables) have the same address.
>int main(void){
> int a=1;
> int b=2;
> printf("%d\n",really(&a,&a));
[Note: I'm not sure passing a bool where printf is waiting for an int,
works. I'm not fluent enough in C.]
But if you want to know if a and a are the same variable, by passing a
pointer to each to a function, you should at least compare the passed
pointers in the function.
Or, just do it the C++ way:
bool IsSameVariable (int& ref1, int& ref2)
{
return &ref1 == &ref2;
}
int main()
{
int a=1;
int b=2;
cerr << IsSameVariable (a, a) << endl;
cerr << IsSameVariable (a, b) << endl;
}
On Sat, 26 Aug 2006 20:31:32 +0200, Pascal Bourguignon
<···@informatimago.com>:
>Oh oh! So you're expecting some overloading of operator==.
>Try:
BTW, how would you do, in Lisp, the same as PHP's operators ==
and === ?
(a===b if a and b have the same type and value
a==b if a and b can have the same value after a conversion from one
to the other; e.g. "1"==1 and "nothing"==0)
Le Sat, 26 Aug 2006 20:57:08 +0200, Fabien LE LEZ a écrit :
> (a===b if a and b have the same type and value
(defun === (x y)
(and (equalp x y) (eql (type-of x) (type-of y))))
...maybe.
> a==b if a and b can have the same value after a conversion from one
> to the other; e.g. "1"==1 and "nothing"==0)
PHP is a very weakly typed language, to make things easy for web devs.
Essentially for them not to worry about input validation, which also
greatly helps crackers when they search for vulnerabilities.
But you could define some converting methods and have the == function or
method call them. I think it would not be that hard...
(defun == (x y)
(=== (canonical x) (canonical y)))
(defmethod canonical ((x number))
x)
(defmethod canonical ((x string))
(let ((maybe-number (read-from-string x)))
(if (numberp maybe-number) number x)))
Something like that, I suppose. Wether it would be desirable that
"nothing"==0, remains questionable... Then you should have == as a
method, and use multiple dispatch, I think.
Quickly,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
On Sat, 26 Aug 2006 23:03:15 +0200, Pierre THIERRY:
>(defun == (x y)
> (=== (canonical x) (canonical y)))
I'd say
(defun == (x y)
(if (eql (type-of x) (type-of y))
(=== x y)
(=== (canonical x) (canonical y))))
In order not to have "01"=="1"
Also, we'll have to add the usual int <-> bool equalities, that don't
seem to exist in Lisp:
1 == T (or true)
0 == nil (or false)
Might be a good exercise to completely implement that foreign operator
;-)
On Sat, 26 Aug 2006 20:31:32 +0200, Pascal Bourguignon:
>Serriously, go read this article: http://www.nhplace.com/kent/PS/EQUAL.html
"EQUAL and EQUALP are not in Common Lisp because they are uniquely
dictated by science--rather, these functions are present out of a
sense of tradition and conceptual (although in some cases not
functional) compatibility with older dialects."
>(defgeneric == (a b)
> (:method ((a number) (b number)) (= a b))
I'd love to just make my own functions to suit my tastes, and I
wouldn't hesitate to do so for more obscure functions.
But those five functions are kinda fundamental, if somehow arbitrary,
so I know I'll see lots of them everywhere -- I can't just overlook
them.
All that discussion is not about saying that List is bad; if was just
an answer to Fred Gilham saying "[The syntax of Lisp] is actually more
intuitive".
Fabien LE LEZ <········@gramster.com> writes:
>
> As a beginner, I find one thing rather confusing: the difference
> between =, eq, eql, equal and equalp. That seems especially
> complicated to the C++ programmer that I am.
>
> In C++, whatever a and b might be, "a == b" always means "a and b have
> the same value". If that doesn't make sense, you just get a compiler
> error.
In Common Lisp, that'd be equivalent to EQL. EQUAL & EQUALP do more
than C/C++ ==.
> If you want to know whether a and b have the same address (which ain't
> that frequent), it's the same: "(the address of a) and (the address of
> b) have the same value" (i.e. "&a == &b").
That's CL EQ.
The one problem is that in CL one cannot write one's own specialised
extension to EQUAL or EQUALP--OTOH this makes one think more about what
one's doing (e.g. with strings or characters: are you being
case-insensitive?). It's quite so low-level as C, but then that's Lisp
in a nutshell:-)
--
Robert Uhl <http://public.xdi.org/=ruhl>
European Ideal: Italian cook, English policeman, German engineer, French
lover. Everything organised by the Swiss.
European reality: English cook, German policeman, French engineer, Swiss
lover. Everything organised by the Italians.
On Sat, 26 Aug 2006 21:02:05 -0600, Robert Uhl
<·········@NOSPAMgmail.com>:
>> In C++, whatever a and b might be, "a == b" always means "a and b have
>> the same value". If that doesn't make sense, you just get a compiler
>> error.
>
>In Common Lisp, that'd be equivalent to EQL.
I don't think so:
(setf a "Hello")
(setf b "Hello")
(eql a b)
-> nil
(equal a b)
-> t
So, for strings at least, C++'s operator == seems to be equivalent to
equal.
For different types of arrays (lists, etc.), I think it's the same.
I won't talk about C, since C doesn't have strings. C just has
pointers, and the programmer can say to himself "this pointer points
to a part of the RAM that contains the characters I need, in the right
order" -- and it's a mess.
Fabien LE LEZ <········@gramster.com> writes:
> On Tue, 22 Aug 2006 15:26:36 -0700, Fred Gilham:
>
>>The syntax of Lisp is *different*. It's actually more intuitive
>
> As a beginner, I find one thing rather confusing: the difference
> between =, eq, eql, equal and equalp. That seems especially
> complicated to the C++ programmer that I am.
Well, then, here are some simple guidelines.
Only use `=' for numbers. (And if they're not integers,
I hope you know enough numerical analysis to know what you're
doing).
Otherwise, only ever use EQL.
Never use EQUALP. If you think you need EQUALP, you're comparing
things so high level that you should have some specialized function;
e.g. if you've got a bunch of FOOs, you use SAME-FOO-P (which you write).
By the time you know when to break these guidelines, you won't be confused
anymore.
Does that help?
--ap
On 2006-08-18 12:16:18 -0500, ·············@gmail.com"
<············@gmail.com> said:
> Hello:
>
> I am a beginner of Lisp, but from recent discussion it's not hard to
> find the weakness of Lisp. That it,
>
> 1, the syntax of the language is not intuitive enough, which would
> make people afraid of learning it.
That's an interesting point. I wrote my English essays back in high
school with tons of nested parenthetical comments because I couldn't
express myself clearly in linear text. After I discovered Lisp, I
realized why I hated English back in high school. Whoever invented the
essay wasn't a lisper.
2, the implementation decides too much, maybe it's because the
> standard specification is outdated or the Lisp language itself is
> heavily based on the implementation, and it's hard to find a decent
> implementation on Win 32 platform( at least for me ).
CLisp should be fine for a beginner. And if you're a student, ACL 8 is
only $99.
> 3. it's hard to write effective and/or efficient lisp program, I
> remember there are many advanced C++ or Java books, but even the
> simplest lisp book is difficult enough so I think it would be harder to
> find an advanced one.
why do you need more advanced lisp books if you haven't gotten the basics yet?
>
> Besides those obvious reasons, what really hurts Lisp is the lack of
> connection to the real world. The world is evolving, now we have SOA
> (Service Oriented Architecture), we have MDA( Model Driven
> Architecture? ), and Lisp's best weapon, the powerful macroes, can be
> replaced by simple code generators; dynamically typed is nice to
> develop in the beginning, but in the end I think these types are fixed,
> so that even with a better development speed, languages with static
> types would eventually catched up with better performance, and the RAD
> tool would really helps those static typed language more.
I admit the world is changing, and to be honest I've found some things
in lisp I don't like, such as the lack of static typing. But macros
aren't going to be replaced by simple code generators, because most
code generators don't have nearly the power of a full fledged
programming langauge, which Lisp macros have. BTW, you mention model
driven architecture and service oriented architecture, but do you
realize that they're just fancy names that marketing people cooked up
for a very old idea? It's called bottom up programming, or data driven
programming, which Lisp, and most functional programming languages
excel at. It's funny that you would consider Lisp of all languages to
not support model driven architecture, what better language to use to
implement data driven architecture than a language that has the same
exact syntax for code and data?
>
> That is,
>
> If a Lisp web application needs 3 months to develop, a Java web
> application might take 6 months, but with the help of development
> tools, Java web application can be shortened to maybe 4 months. Yes it
> still takes more time than the Lisp one, but either it's easier to
> extend with components that are ready, and it's easier to find people
> to maintain the code.
>
> From my own view, Lisp is a fun language with a steep learning curve,
> and it's not that practical, what Lisp needs I think are
>
> 1, better FFI. What makes Ruby's libraries grow that fast, one reason
> is the easiness to extend with C. I think currently it's hard to make
> lots of project in pure Lisp, but lending from other languages (like C)
> might be a shortcut.
>
> 2, syntax sugar. Though Lisp has a good macro system can define what
> language you need, but what most people need is a readable syntax. If
> there is a way to define some syntax with a more intuitive way, it
> might attract more people.
>
> 3. integration. What makes Ruby succeed is not only the language
> itself, but rubygems, ri, erb, drb, rdoc, rake, irb... all makes an
> important part. That's outside the language, but it really helps the
> language. Even with those tools, Ruby still needs a killer ap Rail to
> become popular, and Lisp I think lacks more in these aspects.
>
> That's my opinion.
Actually, I think FFIs are a bad idea. It makes debugging almost
impossible. It takes longer to find documentation for most functions
than it takes to just write your own. I do agree that library support
does speed up program development a lot, and I do like having RAD tools
at my disposal. But I find that the biggest obstacle to me developing
in Lisp is the lack of tools to organize large projects. I would like
to see more software development simulation tools, like databases that
keep track of your ideas and code snippets, documentation. I hate
having to organize code into separate files. That just distracts me and
eat up time.
On Thu, 24 Aug 2006 21:25:57 -0500, Jeffery Zhang wrote:
> Whoever invented the essay wasn't a lisper.
But the person who invented the ethay was. ;)
More interesting: Paul Graham, one of the most famous Lispers around these
days, is a prolific essayist, and has written an essay about essays past
and present called "The Age of the Essay". Read it here:
http://www.paulgraham.com/essay.html
>
> 2, the implementation decides too much, maybe it's because the
>> standard specification is outdated or the Lisp language itself is
>> heavily based on the implementation, and it's hard to find a decent
>> implementation on Win 32 platform( at least for me ).
>
> CLisp should be fine for a beginner. And if you're a student, ACL 8 is
> only $99.
Still too expensive. I like CMUCL, which is free as in beer, speech, and
"Get off my back, you vampiric lawyers!" ;)
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On Fri, 25 Aug 2006 01:34:35 -0600, Chris Barts
<··············@tznvy.pbz>:
>More interesting: Paul Graham, one of the most famous Lispers around these
>days, is a prolific essayist
And as a drawback of that, he always takes ages to come to the point.
I mean, I do like reading his essays, but each time I read one, I
think that he could have said the same thing in three times less
lines.
Fabien LE LEZ <········@edulang.com> wrote:
+---------------
| Chris Barts <··············@tznvy.pbz>:
| >More interesting: Paul Graham, one of the most famous Lispers
| >around these days, is a prolific essayist
|
| And as a drawback of that, he always takes ages to come to the point.
|
| I mean, I do like reading his essays, but each time I read one, I
| think that he could have said the same thing in three times less lines.
+---------------
Even this one?!? ;-} ;-}
http://paulgraham.com/writing44.html
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607