Why learn Lisp
Mr. Neutron
I don't want to start a religious war. I am on my travels through
learning computing, and wanting to explore the universe of Computer
Science. This is just my opinions of Lisp so far.
I have learned the very basics of Lisp. It is in my opinion a weird
language. It uses strange named operators (car...) and lots of (() ).
I am left witha very superficial look at what appears to be a retro
language, a throwback to a time when computers were the size of
buildings. It is hard to think in Lisp or what I can use it for.
I can not imagine why I should keep trying to program in this language when I have
better, easier modern languages with a cleaner syntax and operators with
names that make sense to me. SO far everything I understand I can do in
Lisp I can just as well do in another language I know. I know not the
ways of Lisp or what it is about that has enabled it survive this long.
So far the only thing I have learned to do with Lisp is make a stack
using a very strange syntax. I could easily code this same problem in
Python or C or Java much faster and easier to read (to me).
What oh what makes Lisp or Scheme useful? Are they just hacker languages
that a hacker must know to be accepted by the hacker community? Or is
there really something about Lisp (or Scheme) that makes them stand apart
from the easier (IMO) to understand languages like Python, Java or C/C++?
How has Lisp survived through the years? I have come across many many
computer languages in my studies, and the majority of them died before
they were even conceived. Yet Lisp, Fortran, and C survived. I know C and
Fortran. They are not too hard to understand. But Lisp is IMO very hard to
understand (first, everything is literally backwards in it...).
I would like to learn how to program in Lisp, so I can appreciate
something of the history of Computer Science. I am also interested
in understanding Lisp, because I have read that it teaches you to think
about problems recursively. But I am still struggling to figure out how
to write an interesting program in the language.
If you can explain to a neophyte Computer Scientist why learning to code
in Lisp will enlighten me and will be worth the pain of getting
acquainted with it, I'd like to know!
Also are there any free e-books on programming in Lisp or Scheme?
Are there any places I can get Lisp (or Scheme) code so I can look at to
learn how to think in these languages?
I am still interested in the way of Lisp and Scheme so I am not closed to
learning about it. But my only experience with it is a funny taste. It is
completely opposite of how I think and I can not think at all in this
language. I just stare at the clisp prompt wondering what I should do
next. I can write simple programs that process a list, but it is a toy.
There must be more to it than just making toys.
hehe.
Thanks
Wojciech Sobczuk
answered many times already.
Greetings,
Wojtek
Edi Weitz
> I can not imagine why I should keep trying to program in this
> language when I have better, easier modern languages with a cleaner
> syntax [...]
The very reason why Lisp might look silly to you on first encounter is
that it has a _very_ clean syntax as opposed to other languages like
C, Java or Perl (!!) which have things like curly braces, parentheses,
brackets, semicolons, commas and more all over the place and use it
pretty arbitrarily.
Most people here won't agree with you that other (more "modern")
languages are better than Lisp. Maybe they seem easier to learn, yes,
but it's also easier to drive a Toyota than to drive a Ferrari.
You might want to read a text that another Lisp newbie has written
some days ago. It also includes some useful links for further reading
at the end:
<http://www.cs.uni-bonn.de/~costanza/lisp/guide.html>
Edi.
Mr. Neutron
>
> Most people here won't agree with you that other (more "modern")
> languages are better than Lisp. Maybe they seem easier to learn, yes,
> but it's also easier to drive a Toyota than to drive a Ferrari.
>
Hi sorry, I am not trying to aggravate Lispers. The real problem is I
I have only 1 book on Lisp that was written over twenty years ago. You
have to understand that so far my only introduction to Lisp has been
through a book that is almost as old as I am. I am stumped imagining how
to use Lisp for anything useful (like maybe downloading files from an FTP
site, or accessing a database..). I am very anxious to see what makes
Lisp an AI language. But all I have is a dumb book that talks about
making a stack or two and moving items around on a list. You have to
understand from my perspective, I can accomplish the same thing in just
about any language i know and without any learning curve.
Now this is the kind of statement that makes me interested in Lisp! Why
is it considered a Ferrari? It looks like a VW beetle when I play with
it.
Where do I find the archives and other ****modern**** resources on
Lisp that will help me in my understanding of why Lisp is cool!
> You might want to read a text that another Lisp newbie has written some
> days ago. It also includes some useful links for further reading at the
> end:
>
> <http://www.cs.uni-bonn.de/~costanza/lisp/guide.html>
>
I am finding this introduction useful thanks.
Alexey Dejneka
> Where do I find the archives and other ****modern**** resources on
> Lisp that will help me in my understanding of why Lisp is cool!
Take a look at Document -> "Common Lisp, Typing and Mathematics".
--
Regards,
Alexey Dejneka
---
CMUCL-specific packages:
C: Python compiler
...
cr88192
> "Mr. Neutron" <nickts...@charter.net> writes:
>
>> I can not imagine why I should keep trying to program in this
>> language when I have better, easier modern languages with a cleaner
>> syntax [...]
>
> The very reason why Lisp might look silly to you on first encounter is
> that it has a _very_ clean syntax as opposed to other languages like
> C, Java or Perl (!!) which have things like curly braces, parentheses,
> brackets, semicolons, commas and more all over the place and use it
> pretty arbitrarily.
>
yes, this is one good point. even though I have been using scheme (not so
much cl) for a while now I still do not like the abundance of parenthesis
around, though the syntax pointed out in my spec has a few bad points for
many things I would still rather use it.
at present my plans also include keeping an s-expr parser around so people
could code in that if they wanted, and display will still continue to
output s-exprs (likely anyways, I have not gotten as far as defining
structured/console input/output yet though, or much of any io...).
> Most people here won't agree with you that other (more "modern")
> languages are better than Lisp. Maybe they seem easier to learn, yes,
> but it's also easier to drive a Toyota than to drive a Ferrari.
>
yep. besides lisp I consider python a possible alternative (if I need
something more popular), though I still have plenty of reasons to use the
lisps.
personally I still feel that room for improvement exists (though I can not
argue that mine is any better...). mine at present, like scheme, still
holds the ideal of keeping the core language small and consistent.
my idea is to try to develop an effective module system and try to promote
this as a major means of extending the language. unlike modules in many
other languages, the ones in mine are also conceptually capable of
extending/altering the syntax as well (though this has yet to be
specified...).
from experience it seems though that very few people are actually willing
to contribute ideas though. a problem is that language design leaves
problems in that there may be plenty of issues for which I am not aware,
and language design pushes my language knowlege limits at present...
> You might want to read a text that another Lisp newbie has written
> some days ago. It also includes some useful links for further reading
> at the end:
>
> <http://www.cs.uni-bonn.de/~costanza/lisp/guide.html>
>
> Edi.
--
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
Wade Humeniuk
"Mr. Neutron" <nickts...@charter.net> wrote in message
news:pan.2002.08.25.09....@charter.net...
> On Sun, 25 Aug 2002 08:18:35 -0400, Edi Weitz wrote:
> Hi sorry, I am not trying to aggravate Lispers. The real problem is I
> I have only 1 book on Lisp that was written over twenty years ago. You
> have to understand that so far my only introduction to Lisp has been
You can download a better book for free,
see http://www.paulgraham.com/onlisp.html
Also see http://www.norvig.com
When I started to learn Lisp, I started very simply, simple interactions with the Lisp
Listener, stuff like (+ 3 4), (list 1 2 3 4). I worked through my text's chapters
systematically, doing all the examples, until I understood the the simple syntax of what I
was doing. Doing it this way with no preconceived notions of what is "right" allows the
brain to catch on to what is going on. Its like learning a foreign language, it just
looks like nonsense at the beginning, but then suddenly you begin to see letters, then
words and then sentences. But you have to give yourself time to understand, it does not
happen instantly (especially when one is used to C-like-syntax languages).
Wade
Edi Weitz
> > On Sun, 25 Aug 2002 08:18:35 -0400, Edi Weitz wrote:
> > Hi sorry, I am not trying to aggravate Lispers. The real problem is I
> > I have only 1 book on Lisp that was written over twenty years ago. You
> > have to understand that so far my only introduction to Lisp has been
This quote looks as if I had written the above paragraphy. I haven't.
Edi.
Wade Humeniuk
through it in combination with the Common Lisp Hyperspec.
http://www.lispworks.com/reference/HyperSpec/Front/index.htm
See attached file. It is fairly limited in the CL functionality used but it may push you
into exploring aspects of CL. (things like multiple-value-bind, macrolet (macros),
funcall, structs, vectors, types, format,...)
Wade
Wade Humeniuk
Friedrich Dominicus
> On Sun, 25 Aug 2002 08:18:35 -0400, Edi Weitz wrote:
>
> >
> > Most people here won't agree with you that other (more "modern")
> > languages are better than Lisp. Maybe they seem easier to learn, yes,
> > but it's also easier to drive a Toyota than to drive a Ferrari.
> >
> Hi sorry, I am not trying to aggravate Lispers. The real problem is I
> I have only 1 book on Lisp that was written over twenty years ago.
Than get a more decent book.
And get the Hyperspec
http://www.lispworks.com/reference/HyperSpec/index.html
> You
> have to understand that so far my only introduction to Lisp has been
> through a book that is almost as old as I am. I am stumped imagining how
> to use Lisp for anything useful (like maybe downloading files from an FTP
> site, or accessing a database..). I am very anxious to see what makes
> Lisp an AI language.
See Paradigms or Artificial Intelligence Programming. And you got a
good ide on how Lisp programming could look
>But all I have is a dumb book that talks about
> making a stack or two and moving items around on a list. You have to
> understand from my perspective, I can accomplish the same thing in just
> about any language i know and without any learning curve.
Can you really? So please write such thing in C, without knowing any C
of course.
Friedrich
Erik Naggum
| I don't want to start a religious war.
Do /not/ feed the trolls.
--
Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder.
Act from faith, and failure makes you blame someone and push harder.
Fred Gilham
> I have learned the very basics of Lisp. It is in my opinion a weird
> language. It uses strange named operators (car...) and lots of (()).
> I am left witha very superficial look at what appears to be a
> retro language, a throwback to a time when computers were the size
> of buildings. It is hard to think in Lisp or what I can use it for.
One comment about `car' and `cdr' and the like. This is one where
people disagree, but I still like them. The way I think about them is
like `x' and `y' in a coordinate system. Why do you call it `x'? How
about `horizontal'? Wouldn't that make more sense? But that misses
the point --- `x' and `y' are abstractions. So are `car' and `cdr'.
The other thing is that you can do `cadr', `caar' and so on. Some
people hate this but I think it's kind of neat.
> I can not imagine why I should keep trying to program in this
> language when I have better, easier modern languages with a cleaner
> syntax and operators with names that make sense to me. SO far
> everything I understand I can do in Lisp I can just as well do in
> another language I know. I know not the ways of Lisp or what it is
> about that has enabled it survive this long.
You didn't give examples. So I'm not sure which languages you prefer
as having cleaner syntax etc.
If you are unhappy with prefix --- that is, the way lisp does (+ 2 3)
as opposed to 2 + 3 --- then I can only say that you'll get used to
it, and you'll be happy when you find yourself doing (+ 2 3 4 5) or
(= x y z) or things like that.
Lisp uses a `regular' syntax, with parentheses as its primary
structure-creating mechanism. For this reason, it's easy to read
Lisp. You always know what's going on. Almost all the semantics is
pushed into named operators.
For example, instead of
a[4]
you say
(aref a 4)
Instead of
for(i = 0; i < 5; i++) {
...do something....
}
you say
(dotimes (i 5)
(...do something))
Note in the examples from C you see braces, brackets, semicolons and
parentheses to indicate structure of one kind or another. In Lisp you
see parentheses. (Lisp programs are `line noise free zones'!)
> So far the only thing I have learned to do with Lisp is make a stack
> using a very strange syntax. I could easily code this same problem
> in Python or C or Java much faster and easier to read (to me).
I guess you must have been writing a stack using the Common Lisp
Object System? Otherwise, in Lisp, stacks are trivial:
(defvar *my-stack* nil)
(push 3 *my-stack*)
(push 4 *my-stack*)
(push 12 *my-stack*)
(push 7 *my-stack*)
(pop *my-stack*)
(pop *my-stack*)
(etc.)
Of course, this isn't an `information-hiding' version of a stack, but
it's easy enough to do that in Lisp too using closures.
(let ((my-stack nil))
(defun my-push (e)
(push e my-stack))
(defun my-pop ()
(if my-stack
(pop my-stack)
(error "Stack empty!"))))
> What oh what makes Lisp or Scheme useful? Are they just hacker
> languages that a hacker must know to be accepted by the hacker
> community? Or is there really something about Lisp (or Scheme) that
> makes them stand apart from the easier (IMO) to understand languages
> like Python, Java or C/C++?
I like the distinction people make with regard to GUIs: easy to learn
vs. easy to use. Some people call a GUI "easy to use" when they mean
"easy to learn", or easy to get started with. Lisp really isn't THAT
hard to learn, but some people find languages like Java or C++ more
familiar (at first). But after a while you find that Lisp is easer to
use. That's because as time goes on, in C++ or Java you start getting
bogged down in language-induced complexity. Things become harder to
do because the language makes them harder to do. In Lisp, there isn't
as much language-induced complexity; things become harder because of
problem-induced complexity (that is, because the problem itself is
harder).
An example of language-induced complexity that someone posted in this
newsgroup some time ago can be found in the following paper:
http://www.oonumerics.org/tmpw00/eisenecker.html
I am not sure I understand this paper, but it seems to me that in Lisp
the problem doesn't arise at all.
For example, here's my Lisp code that does what I think they were
trying to do in the paper:
;;;;
(defclass customer ()
((first-name :initarg :first-name)
(last-name :initarg :last-name)))
(defmethod print-it ((cust customer))
(with-slots (first-name last-name) cust
(format t "~&First name: ~A~%Last name: ~A~%" first-name last-name)))
(defclass phone-contact (customer)
((phone-number :initarg :phone-number)))
(defmethod print-it ((phone phone-contact))
(with-slots (phone-number) phone
(call-next-method)
(format t "~&Phone number: ~A~%" phone-number)))
(defclass email-contact (customer)
((email-address :initarg :email-address)))
(defmethod print-it ((email email-contact))
(with-slots (email-address) email
(call-next-method)
(format t "~&Email address: ~A~%" email-address)))
(defclass postal-address (customer)
((postal-address :initarg :postal-address)))
(defmethod print-it ((address postal-address))
(with-slots (postal-address) address
(call-next-method)
(format t "~&Postal address: ~A~%" postal-address)))
(defclass customer-info (phone-contact email-contact postal-address)
())
(setf *my-info*
(make-instance 'customer-info
:first-name "Foo" :last-name "Bar"
:phone-number "555-1212"
:email-address "f...@bar.com"
:postal-address "1234 Main. St. Anytown, CA"))
(print-it *my-info*)
;;;
It all works as it is. (I think I'd write it a little differently,
though.)
The working code at the end of the paper contains a lot of extra
mechanism and complexity, and I claim that this is all
language-induced, that is, necessary to work around shortcomings in
the language.
To put it somewhat hyperbolically, Lisp lets you solve problems, while
other languages let you solve problems AFTER you've solved the
problems presented by using that language in the first place.
> I would like to learn how to program in Lisp, so I can appreciate
> something of the history of Computer Science. I am also interested
> in understanding Lisp, because I have read that it teaches you to
> think about problems recursively. But I am still struggling to
> figure out how to write an interesting program in the language.
Just take an interesting program that you want to write, and write it
in Lisp. You'll find it pretty hard at first, but if you persist,
one day you'll reach enlightenment.
One thing to realize. If Lisp is really snake-oil, it will seem weird
and quirky because it is just a collection of poorly thought-out hacks
and frauds. But if Lisp really is a serious alternative, it will also
seem weird and quirky because it doesn't follow various fundamental
assumptions about how things must be done. That's the very thing that
makes it a serious alternative.
The only way to find out which is true (snake oil or serious
alternative) is to take Lisp on its own terms, and NOT impose those
fundamental assumptions on it. Don't expect anything in Lisp to work
the way it does in any other language and you'll get it faster.
--
Fred Gilham gil...@csl.sri.com
Lisp has jokingly been called "the most intelligent way to misuse a
computer". I think that description is a great compliment because it
transmits the full flavor of liberation: it has assisted a number of
our most gifted fellow humans in thinking previously impossible
thoughts. E. Dijkstra
Kaz Kylheku
wrote:
> language. I just stare at the clisp prompt wondering what I should do
> next. I can write simple programs that process a list, but it is a toy.
> There must be more to it than just making toys.
This is your personal problem that has nothing to do with any programming
language. If you can't think of what to do, it can only be because you have
reached your wit's end.
You should go back to one of those programming languages that you cited; these
will give you enough impedance so that you can push against them and dissipate
your energy to create the feeling that you are accomplishing something.
C is great for this; you can start with no idea at all, and starting writing
thousands of lines of supporting code in hopes that the idea will materialize
in the meanwhile.
``Gee, I don't know what I will write, but I bet it will need a linked list, a
better malloc routine, some binary trees and reference-counted strings,
a buffer management module, ...''
Kaz Kylheku
>> The very reason why Lisp might look silly to you on first encounter is
>> that it has a _very_ clean syntax as opposed to other languages like
>> C, Java or Perl (!!) which have things like curly braces, parentheses,
>> brackets, semicolons, commas and more all over the place and use it
>> pretty arbitrarily.
>>
> yes, this is one good point. even though I have been using scheme (not so
> much cl) for a while now I still do not like the abundance of parenthesis
> around, though the syntax pointed out in my spec has a few bad points for
> many things I would still rather use it.
Nobody cares about the braindamaged spec for your nonexistent language, so stop
bringing it up, you lunatic. It's not topical here. Maybe try the patience of
comp.compilers for a change.
Christopher Browne
>> I have learned the very basics of Lisp. It is in my opinion a weird
>> language. It uses strange named operators (car...) and lots of (()).
>> I am left witha very superficial look at what appears to be a
>> retro language, a throwback to a time when computers were the size
>> of buildings. It is hard to think in Lisp or what I can use it for.
>
> One comment about `car' and `cdr' and the like. This is one where
> people disagree, but I still like them. The way I think about them is
> like `x' and `y' in a coordinate system. Why do you call it `x'? How
> about `horizontal'? Wouldn't that make more sense? But that misses
> the point --- `x' and `y' are abstractions. So are `car' and `cdr'.
>
> The other thing is that you can do `cadr', `caar' and so on. Some
> people hate this but I think it's kind of neat.
.. And if your code is filled with this stuff, it _usually_
demonstrates that you're not making particularly good use of the rest
of the language.
It is really painful to read "cadaverous" code; not unlike fiddling
with assembler, or FORTH code that's full of ROT, -ROT, SWAP, and
ROLL.
If you're using Lisp _well_, you'll have a nice set of defuns,
defmethods, perhaps some macros, and such, that make it largely
unnecessary to fill your code with rubbish looking like
(cons (cdddadar a) (cddar (car b)))
When I finish working on some Lisp code, I usually do a read through
it to see where there are references to CAR and CDR, with a view to
seeing if they couldn't be replaced with something a little more
elegant.
> Instead of
> for(i = 0; i < 5; i++) {
> ...do something....
> }
>
> you say
>
> (dotimes (i 5)
> (...do something))
And you do _that_ instead of
(do ((i 0 (incf i)))
((= i 5))
(format t "Value: ~A~%" i))
It's pretty likely that the introductory texts on Lisp mention DO, and
say little, if anything, about the other alternatives. The only place
I _ever_ use DO is if I'm building an iteration macro, and even _that_
is rare. DO is almost perfectly analagous to the C "for(;;) {}" loop,
with the difference that the order of the three statements changes a
bit.
> Note in the examples from C you see braces, brackets, semicolons and
> parentheses to indicate structure of one kind or another. In Lisp
> you see parentheses. (Lisp programs are `line noise free zones'!)
Mind you, the DO example is filled with somewhat non-obvious sets of
list structure:
(do ((variable initial-value update-form))
(termination-test)
(body-of-loop))
The only piece of that which is expressly identified as what it is is
the DO at the start. And I downright _hate_ looking at DO loops,
pretty much as a result of that.
One thing that I kind of like about the syntax of ML is that it puts
fairly sensible names to the pieces.
The similarly-not-overly-obvious LET statement
(let ((a b) (c d)) (foo a) (bar c))
in ML would look something like:
let
a = b and
c = d
in
foo(a);
bar(c);
And while I wouldn't argue that it's worth leaping to ML _just_
because of that, I _would_ argue that it's likely to be more
"intuitive," initially, than the Lisp way of expressing it, and that
the ML representation is a pretty nice way of _explaining_ what is
going on to the beginner.
--
(reverse (concatenate 'string "moc.enworbbc@" "sirhc"))
http://www3.sympatico.ca/cbbrowne/oses.html
"What you end up with, after running an operating system concept
through these many marketing coffee filters, is something not unlike
plain hot water." -- Matt Welsh
cr88192
hell, at least this is some feedback.
if others feel similar I guess it explains the lack of reply.
if I write a compiler will this topic be more acceptable?...
Thien-Thi Nguyen
> If you can't think of what to do, it can only be because you have
> reached your wit's end.
OP needs inspiration. OP: maybe a good idea to take a step back, look
at yourself, see what is your personality, then try to express yourself
somehow. some humble suggestions:
if you are artistic, write programs that are artistic (and produce art,
bonus!).
if you rage against the machine, write simulation programs, and build a
better society.
if you are lazy, write screensavers.
if you are curious, write virii.
if you are a slave, convince your fellows that lisp is no good and talk
amongst yourselves.
if you are kind, learn what you can learn and teach what you can teach.
if you are whiny, write programs that filter spam (please).
if you want to cash in on the programming "profession", hire lisp
programmers and give them some slack.
thi
Thomas Stegen CES2000
news:umi9336...@corp.supernews.com...
> if I write a compiler will this topic be more acceptable?...
His point if more than likely that in this newsgroup lisp is the
topic. If your language is not a Lisp then it is off topic here.
--
Thomas.
Approaching singularity.
Kaz Kylheku
> Kaz Kylheku wrote:
>> Nobody cares about the braindamaged spec for your nonexistent language, so
>> stop
>> bringing it up, you lunatic. It's not topical here. Maybe try the
>> patience of comp.compilers for a change.
>
> hell, at least this is some feedback.
> if others feel similar I guess it explains the lack of reply.
>
> if I write a compiler will this topic be more acceptable?...
Not in this forum unless it is a compiler for the language ANSI Common Lisp.
Not in comp.lang.scheme, unless it contains an implementation of an RnRS spec.
cr88192
my last compiler was scheme.
no one in comp.lang.misc seemed to care either when I had posted there.
Erik Naggum
| no one in comp.lang.misc seemed to care either when I had posted there.
Why does it matter to you whether people on Usenet care? Usenet is a good
place to people who already care about the same things; they congregate in
newsgroups according to what they care about. When people in a newsgroup do
not care about what you care about, they are extremely unlikely to /start/ if
you somehow imply that they /ought/ to.
If you feel that people /should/ care about what you care about, you have only
set out to become a nuisance to others in their eyes. They will want you to
go away more than anything else. If even this conducive to your personal
needs, you should really talk to someone who already cares about /you/.
Mr. Neutron
>> making a stack or two and moving items around on a list. You have to
>> understand from my perspective, I can accomplish the same thing in just
>> about any language i know and without any learning curve.
> Can you really? So please write such thing in C, without knowing any C
> of course.
>
do.
I am just experiencing a problem in learning a new language. You could
imagine that I am fluent in a certain type of language. Lisp and Scheme
are a very different type of language.
I can not see in my mind how to translate my ideas from my native tongue
to my new language. All I can do in my new language is make toys. While
that is an interesting career, I want to build rocket ships.
I can build rocket ships in my native tongue (C). Translating my rocket
ship into Lisp results in a broken machine. I am missing doors, windows,
glass, steering controls, landing gear, wings, and fuel. I have a
complete toolbox in C. In Lisp, I just have a screwdriver.
That is my frustration with Lisp so far. I can build rockets. But in Lisp
I am starting all over again. It is sort of intimidating. I am actually
kind of interested in the challenge. But I need a guide to teach me.
I just can't find a guide. It would be nice if there was a Lisp for C
programmers book around.
That's why I am griping. It's not that I think Lisp sucks. It is that I
can not communicate in it at all. I am a stranger in a strange land in
Lisp.
Bye
Jacek Podkanski
Because everybody seems to love to discuss this subject
--
Jacek Podkanski
cr88192
> * cr88192 <cr8...@hotmail.nospam.com>
> | no one in comp.lang.misc seemed to care either when I had posted there.
>
> Why does it matter to you whether people on Usenet care? Usenet is a
> good place to people who already care about the same things; they
> congregate in
> newsgroups according to what they care about. When people in a
> newsgroup do not care about what you care about, they are extremely
> unlikely to /start/ if you somehow imply that they /ought/ to.
>
> If you feel that people /should/ care about what you care about, you
> have only
> set out to become a nuisance to others in their eyes. They will want
> you to
> go away more than anything else. If even this conducive to your
> personal needs, you should really talk to someone who already cares
> about /you/.
>
I have not really found any real language design groups which have very
many people in them. I could try again on comp.lang.misc, but it would
probably be more of the same.
in life I have no freinds, and I am alone. I guess I wanted people to talk
to about something so that I am not in more isolation...
before I could talk to my ex about stuff, then she left me. since then I
have made little progress on anything, everything now seems to be in the
past. I still do not really understand why she left, just at the end she
said she did not care about me anymore. that was 2 months ago...
all my life has been like that, people get bored with me then they leave.
everyone else avoids me altogether...
being online has been an attempt to escape that, hoping somewhere somehow
what I said would mean something. due to my lack of productivity this is
too large of a goal, thus I continue to be worthless...
Christopher Browne
Why would you _expect_ them to care?
There is a sizable population of people in these newsgroups that are
much more interested in figuring out ways of using the "industrial
grade" systems that they have than they are in hearing about the
latest techniques you just heard about (that they likely knew of ten
years ago) that you added, then took out because it didn't turn out
well.
In comp.lang.scheme, there are _barrels_ of free implementations out
there that are likely a whole lot more featureful than your language
is at this point. There are _largely disused_ implementations that
are likely of wider interest.
On comp.lang.lisp, the main dialect of Lisp under discussion is one
that has been fairly well specified since the 1980s, and your language
doesn't hold a candle to it in terms of overall functionality. Why
SHOULD people on comp.lang.lisp be interested in something that's not
compatible with their favored language, and which lacks a whole lot of
the functionality that they expect and demand.
If you need for people to "care" about your language design
discussion, then perhaps you need to work on a language implementation
that _will_ seem consequential to them. If you were to add a few
features to CLISP, _that_ would be of some interest to people. Ditto
for SBCL or CMUCL. A while back you were looking into Yale T; if you
were to resurrect the code base, and get a compiler running on a
modern Linux or FreeBSD system, I'm _sure_ that would attract some
interest. (Albeit from a different direction.)
But when what you're essentially doing is to fiddle with your own
private language implementation, why WOULD other people find this of
immense interest?
--
(reverse (concatenate 'string "moc.enworbbc@" "enworbbc"))
http://www3.sympatico.ca/cbbrowne/sgml.html
"I support Microsoft's right to innovate. I just wish they would make
use of that right." - Steve Shaw
Hartmann Schaffer
"Mr. Neutron" <nickts...@charter.net> writes:
> Hi,
> I don't want to start a religious war. I am on my travels through
> learning computing, and wanting to explore the universe of Computer
> Science. This is just my opinions of Lisp so far.
>
> I have learned the very basics of Lisp. It is in my opinion a weird
> language. It uses strange named operators (car...) and lots of (() ).
> I am left witha very superficial look at what appears to be a retro
> language, a throwback to a time when computers were the size of
> buildings. It is hard to think in Lisp or what I can use it for.
anything new can be hard to learn if you don't have the right
tutorial. unfortunately, you don't mention which book you are using
as an introduction
your impression of lisp's syntax seems to be solely based on it being
deviating from the syntax of the languages you used. in fact, it is
amazingly simple, using only very few rules. the languages you
mentioned use an algebraic syntax, which is well established for
numeric problems, but tends to become pretty complex once you go
beyond the normal arithmetic operations (how many C programmers do you
know who don't use superfluous parantheses because they have problems
remembering the precedence rules once shift and logical operators
become involved). once you have become used to the unfamiliar syntax,
you most likely will appreciate its simplicity and consistency.
parantheses are only a problem if you use the wrong editor. most
editors that are meant for programmers now support lisp and eliminate
the parenthesis problem. after a while you won't even notice the
parentheses, esp. if you format your code logically.
depending on what examples you have tried so far, the advantages of
lisp might not be that obvious, esp. if you limit yourself to simply
transcribing programs you have written in familiar languages. i wold
suggest you have a look at books like "paradigms of artificial
intelligence - case studies in common lisp" (norvig) or "the structure
and implementation of computer programs" (abelson/sussman) to get an
appreciation of how simple problems can be expressed in lisp like
languages.
yes, function names carry a lot of historical baggage that often is
troublesome for newcomers, but this is simply something you have to
get used to. scheme, a language of the lisp family, has made an
attempt to remove some of this historical baggage, i.e. introduced
more consistent naming conventions for the standard functions. most
people in this newsgroup think that think that this is not enough of
an advantage to give up the advantages common lisp has over scheme.
hs
--
don't use malice as an explanation when stupidity suffices
Wade Humeniuk
Windows), download
http://www3.telus.net/public/whumeniu/runnerslog-140.exe
Its a self-installing application (shaken at delivery level 5).
Manual is:
http://www3.telus.net/public/whumeniu/Manual.html
I have also posted the source code. Maybe if you stare at it long enough it will make
some sense and you will get the idea of how to get your ideas down in Lisp. (Hint: Just
like in C, a Lisp app is built up of functions and expressions). Load defs.lisp first and
then see run.lisp for the main functionality. The main entry function is make-running-log
http://www3.telus.net/public/whumeniu/running-140-src.zip
In theory this all runs on LispWorks for Linux, though I have not tried.
Wade
Steven T Abell
> in Lisp will enlighten me and will be worth the pain of getting
> acquainted with it, I'd like to know!
It will definitely be worth it,
but things will look really strange to you for a while.
Part of the problem is that you seem to be trying to build things
using the mental tools you developed for other languages.
You can write C in Lisp, but you won't be happy about it.
Since you already know several traditional procedural languages,
you've noticed that they're all about the same under their skins.
Smalltalk is not like that.
APL is not like that.
Lisp is *definitely* not like that.
The skills you've developed elsewhere will still be useful to you,
but you have an entirely different outlook to acquire
before you can turn those skills to your benefit in Lisp.
Traditional procedural languages
are concerned with managing the memory field of a VonNeumann machine.
Lisp is concerned with construction using some very general ideas,
memory field be damned,
and the realm of what you can construct is considerably larger
that what you're used to thinking about in a traditional language.
Yes, you can do these things in C,
but some of them hurt so much that you'd never think to do them,
and those are often the things that are most useful in real programs.
Higher-order functions are a case in point.
A lot of people complain about it,
but I think the Abelson & Sussman book is a decent piece of work,
and you'll learn some other good stuff along the way.
Here's a guideline you can use in this matter,
regardless of how you pursue it:
as long as you're inclined to complain about all those silly parentheses
and CARs and CDRs and lack of significant syntax,
you haven't yet understood what Lisp is about.
Once you get it, you'll never think the same way about programming again.
I wish I could be more specific,
but there's a change that has to happen in your head,
and the only way I know to make that happen
is to look at some good examples and keep trying to make your own.
It's worth doing.
Steve
--
Steven T Abell
Software Designer
http://www.brising.com
In software, nothing is more concrete than a good abstraction.
larry
>> It uses strange named operators (car...) and lots of (() ).
Why do people coming to lisp complain about all the parenthesis?
Take c code, change { } to parenthesis and move the position a little and
you get something like
(for (i=0;i<10;i++)
(for (j=0;j<10;j++)
(if i == j
(printf "i =j\n");
(printf "i not j\n");
)
)
)
That looks just like lisp, but nobody notices it because they're used to seeing
it. What about all the damn semi-colons in c-- weird.
Adam Warner
> yes, function names carry a lot of historical baggage that often is
> troublesome for newcomers, but this is simply something you have to get
> used to.
Not in my limited experience. For example I've been using first, second,
rest, last, etc. in my code. There's no historical baggage associated with
those terms. There isn't a car or cdr in sight.
Sure you might come across mapcar etc. but they are such powerful
operators that many people will be learning them for the first time
anyway.
> scheme, a language of the lisp family, has made an attempt to remove
> some of this historical baggage, i.e. introduced more consistent naming
> conventions for the standard functions. most people in this newsgroup
> think that think that this is not enough of an advantage to give up the
> advantages common lisp has over scheme.
I found it to be the other way around Hartmann. Scheme forces you to use
more historical baggage (at least initially before you define new
functions) since you must use function names like car, cdr, etc.
But defining new functions with common names doesn't help because the
single namespace forces you to avoid those names in variables (along with
remembering to avoid all the common built in names such as list and
string). The more obvious the function name, the more likely it's going to
bite you.
CLISP:
[1]> (setf list '(this is a list))
(THIS IS A LIST)
[2]> (list "a" "b" "c")
("a" "b" "c")
MZScheme:
> (set! list '(this is a list))
> (list "a" "b" "c")
procedure application: expected procedure, given: (this is a list);
arguments were: "a" "b" "c"
You don't have to know any of the function names in Common Lisp to avoid
redefining them as variables. While it's a big language it doesn't get in
your way.
Given Common Lisp's long history the level of historical baggage is
remarkably low. And the more I learn about the language the more I
appreciate the skill of all its designers over the decades.
Regards,
Adam
Software Scavenger
> Now this is the kind of statement that makes me interested in Lisp! Why
> is it considered a Ferrari? It looks like a VW beetle when I play with
> it.
As an electric drill looks like an awkward hammer. It doesn't even do
a very good job of driving nails. And what's that wire thing sticking
out of it, with the plug on the end? Is that some kind of
compatibility adaptor or something? The whole thing seems awkward and
backward. And it's too heavy to be handy.
The electricity you need to make Lisp come alive is available if you
know where to look for it. It's simply learning. The more Lisp you
learn, the more power you have, and the closer you are to making it
spin.
cr88192
> But when what you're essentially doing is to fiddle with your own
> private language implementation, why WOULD other people find this of
> immense interest?
not sure, I could just continue where I left off and add everything I was
thinking to my scheme implementation, this would save having to redesign
and reimplement everything...
the only possible relavence in any case will be that it will be the
language I use for my projects.
it does not matter, I had just wondered if anyone would be interested...
Luis Guillermo RESTREPO RIVAS
on LISP) is somewhat illuminating:
http://www.paulgraham.com/lib/paulgraham/acl1.txt
As the language best suited, for example, to work on Genetic
Programming, see section 4.3, pages 71-72 of "Genetic Programming" by
John R. KOZA: "Reasons for choosing LISP".
As a language to explore fundamental things of math and computer
science, see the book by Grogory J. CHAITIN:
"The limits of Mathematics", pages 31-44
"Whay I love (pure) LISP" and
"Proving LISP Programs are elegant")
"The Unknowable".
It have bee said that LISP is a "programmable programing language",
where the programmer has power to define his/her own language for the
problem at hand.
Also, think that the languge has been actively used and developed by a
community of computer scientists, mathmeticians, researches solving
difficult problems, and exploring the challenges of AI, so the time
past from the begginings of LISP doesn't mean obsolescence but
maturity, compared with new languages as Java, even in the Object
Oriented trend, with te power of CLOS.
Best regards,
Luis G. RESTREPO
http://LuisGuillermo.com
Erik Naggum
| if people don't care I have little reason to implement it...
That kind of attitude is just so /stupid/ I could scream. Well, let me
scream. THAT ATTITUDE IS SO GODDAMN STUPID! (Thank you.)
What you do with your time should be /completely/ unaffected by what other
people find valuable. You could not possibly attract anyone with some half-
assed non-implementation of an idea, so just give that part of the task up
right now. What you /can/ do, however, is prove to yourself first, and then
to others, that you can accomplish something worth accomplishing. Some
people prove this with degrees in educational institutions. Others start
small companies in their garage with the proceeds of their past successes.
If you are starting out in life and treat creating a language as a means to
learn something, which I do not even consider a worthwhile task if you are
into compiler design, you should not even /ask/ people to care. You have
set out to learn something by explicitly rejecting everything that other
people have done before you. Create your own language and be on your own.
Frank A. Adrian
> in life I have no freinds, and I am alone. I guess I wanted people to talk
> to about something so that I am not in more isolation...
So go to a local bar and quit bothering us.
> all my life has been like that, people get bored with me then they leave.
> everyone else avoids me altogether...
Yup, people tend to get that way around a whiney little troll like you. Go
away.
faa
Fred Gilham
> if people don't care I have little reason to implement it...
You have to do some `supply-side' thinking --- `build it and they will
come'. Of course, you are taking the risk that you will build it and
they'll stay away in droves. But if you win, you win really big.
If you decided to revive the T implementation, personally I'd
definitely comment on it, and one part of my comment would be `thank
you very much'.
But I found your language design really frustrating. You seemed to
want to combine some aspects of Python, Scheme and Common Lisp. It
didn't seem at all promising to me and I thought silence would be the
most charitable response.
You should realize that good self-image comes from accomplishment. If
you do something good, you WILL become world famous. I kid you not.
That's just the way the Internet is. You will get messages from all
over the world either praising you or asking for free upgrades. :-)
So you've got a lot of time on you hands: pick a project and see it
through. Then put it out there. Repeat until satisfied.
--
Fred Gilham gil...@csl.sri.com
Do remember you're there to fuddle him. From the way some of you
young fiends talk, anyone would suppose it was our job to teach!
-- The Screwtape Letters, C. S. Lewis
Charlton Wilbur
EN> If you are starting out in life and treat creating a language
EN> as a means to learn something, which I do not even consider a
EN> worthwhile task if you are into compiler design, you should
EN> not even /ask/ people to care. You have set out to learn
EN> something by explicitly rejecting everything that other people
EN> have done before you. Create your own language and be on your
EN> own.
On the contrary, I think this is a valuable exercise -- but its end is
not producing a useful language, especially not one that will be
useful to other people, but in learning about why things are done the
way they are in a particular language. When I was an undergraduate, I
looked at the dozen languages I had been exposed to, and decided that
I didn't like any of them completely, and that I could do a lot better
if I designed a language on my own. I was wrong; my pet language
wound up looking a lot like Objective-C, but I learned an enormous
amount about language design in the process.
All computer languages -- indeed, all engineering decisions -- involve
choices among various sets of tradeoffs. Sometimes the best way to
understand this principle, as well as to see it in action, is to
explicitly reject all existing solutions and to design one from the
ground up. The ancients were wise, but they were also foolish or
short-sighted; how many things in computer languages are there because
of historical precedent? If we were designing LISP today, would we
have functions named car and cdr? If we were designing C++ today,
would we put such immense importance on avoiding run-time typing
decisions?
And even then, designing a new language does not necessarily mean
rejecting all that has gone before. Did Bertrand Meyer discard what
he had learned from other languages when he designed Eiffel? Did
Bjarne Stroustrup discard what he had learned from other languages
when he started down the path that led to C++? Did Kernighan,
Ritchie, and Thompson discard what they had learned when they created
C? Of course not. All of them saw deficiencies in the existing
languages, and created a new language with what they considered
strengths and with as few weaknesses as possible.
Still, it's hardly surprising that comp.lang.lisp doesn't care. I
wouldn't expect it to; the language is neither LISP nor LISP-like, and
it doesn't seem to address any need I might have that isn't already
addressed by a more mature language.
Charlton
Erik Naggum
| And even then, designing a new language does not necessarily mean rejecting
| all that has gone before.
After you know what has gone before, you can be more intelligently creative
than when you start out from scratch.
| Did Bertrand Meyer discard what he had learned from other languages when he
| designed Eiffel? Did Bjarne Stroustrup discard what he had learned from
| other languages when he started down the path that led to C++? Did
| Kernighan, Ritchie, and Thompson discard what they had learned when they
| created C? Of course not.
Of course not. Were they 18-year-old whining loners who craved attention
for their inventions created in a vacuum? Of course not. Do you know
anything worth beans to anyone else when you are 18? Of course not.
| Still, it's hardly surprising that comp.lang.lisp doesn't care.
So far, the willingness to listen does not even extend to Paul Graham's Arc.
Novices with a desire to reinvent the world before they know what it is like
should take notice of this. Improving on Common Lisp is /very/ hard. And
most of the "improvements" on Scheme are neither improvements nor Scheme.
Friedrich Dominicus
> >>But all I have is a dumb book that talks about
> >> making a stack or two and moving items around on a list. You have to
> >> understand from my perspective, I can accomplish the same thing in just
> >> about any language i know and without any learning curve.
> > Can you really? So please write such thing in C, without knowing any C
> > of course.
> >
> I *do* know C. If I *didn't* know C, obviously it would be hard to
> do.
Well why don't you expect the same for Lisp? How can you expect that
learning is *not* necessary?
>
> I am just experiencing a problem in learning a new language. You could
> imagine that I am fluent in a certain type of language. Lisp and Scheme
> are a very different type of language.
You're right they are different. But there are other "foreign"
languages for users of C, Pascal and how they are all named. Look at
Haskell, OCaml, Forth etc.
>
> I can not see in my mind how to translate my ideas from my native tongue
> to my new language. All I can do in my new language is make toys. While
> that is an interesting career, I want to build rocket ships.
Well I would expect to start small and grow with the tasks at
hand. But you could write Lisp simular to C and it would work. This is
one of the difference to other languages.
>
> I can build rocket ships in my native tongue (C). Translating my rocket
> ship into Lisp results in a broken machine. I am missing doors, windows,
> glass, steering controls, landing gear, wings, and fuel. I have a
> complete toolbox in C.
What does this toolbox contain?
> In Lisp, I just have a screwdriver.
Lisp is you toolbox. And you can translitereate C code nearly to Lisp
and it will work why should anything get lost?
>
> That is my frustration with Lisp so far. I can build rockets. But in Lisp
> I am starting all over again. It is sort of intimidating.
This is the usualy feeling one have while starting something new. You
even get this feeling while beeing perfectly fluent in one language
but while starting at a topic which you never have touched before. At
the moment you got a problem because you entry no-where land for
you.
> I am actually
> kind of interested in the challenge. But I need a guide to teach me.
> I just can't find a guide. It would be nice if there was a Lisp for C
> programmers book around.
Well the problem can be that C has certain kind of world-view. One
thing differently in Lisp is it's functional side. I suggest looking
at a "pure" functional language and see how programming works
there. Than you understand the "functional" side from Lisp much
better.
And then you can check out
http://www.bagley.org/~doug/shootout/
Well and got and idea that a Lisp solution must not look much
different from a C solution.
>
> That's why I am griping. It's not that I think Lisp sucks. It is that I
> can not communicate in it at all. I am a stranger in a strange land in
> Lisp.
You can't expect to learn a language without that feelings. And you
need patience, write some code in Lisp polish it, tackle it from
different angles and you will feel much more comfortable soon.
Just an very simple example. Write down different ways to "sum up
elements". Write it C-ish, write it a functional way, and and
Regards
Friedrich
Bruce Hoult
"Adam Warner" <use...@consulting.net.nz> wrote:
> But defining new functions with common names doesn't help because the
> single namespace forces you to avoid those names in variables (along with
> remembering to avoid all the common built in names such as list and
> string). The more obvious the function name, the more likely it's going to
> bite you.
>
> CLISP:
> [1]> (setf list '(this is a list))
> (THIS IS A LIST)
> [2]> (list "a" "b" "c")
> ("a" "b" "c")
>
> MZScheme:
> > (set! list '(this is a list))
> > (list "a" "b" "c")
> procedure application: expected procedure, given: (this is a list);
> arguments were: "a" "b" "c"
>
> You don't have to know any of the function names in Common Lisp to avoid
> redefining them as variables. While it's a big language it doesn't get in
> your way.
This is a point I hadn't seen before. However:
- avoiding shadowing a function name is only of importance if
you're intending to use that function (in a lexically enclosed
scope).
- if you don't know some function exists then you're not likely
use it, or care if it gets shadowed.
I gusss the exception to this is if you use some macro that expands to a
function you don't know about, and accidentally shadowed. Which would
be a problem in CL (butfor the two namespaces), but isn't in a language
with hygienic macros, such as Scheme or Dylan.
-- Bruce
Duane Rettig
> >>But all I have is a dumb book that talks about
> >> making a stack or two and moving items around on a list. You have to
> >> understand from my perspective, I can accomplish the same thing in just
> >> about any language i know and without any learning curve.
> > Can you really? So please write such thing in C, without knowing any C
> > of course.
> >
> I *do* know C. If I *didn't* know C, obviously it would be hard to
> do.
Precisely. So don't assume any different for Lisp.
> I am just experiencing a problem in learning a new language. You could
> imagine that I am fluent in a certain type of language. Lisp and Scheme
> are a very different type of language.
>
> I can not see in my mind how to translate my ideas from my native tongue
> to my new language. All I can do in my new language is make toys. While
> that is an interesting career, I want to build rocket ships.
>
> I can build rocket ships in my native tongue (C). Translating my rocket
> ship into Lisp results in a broken machine. I am missing doors, windows,
> glass, steering controls, landing gear, wings, and fuel. I have a
> complete toolbox in C. In Lisp, I just have a screwdriver.
Translating to _any_ language you do not know will result in brokenness.
Take a look at http://www.engrish.com/recentdiscoveries.html for
some examples of broken translations to English by people who never
bothered to really learn the language.
> That is my frustration with Lisp so far. I can build rockets. But in Lisp
> I am starting all over again. It is sort of intimidating. I am actually
> kind of interested in the challenge. But I need a guide to teach me.
> I just can't find a guide. It would be nice if there was a Lisp for C
> programmers book around.
But Lisp is not for C programmers; Lisp is for Lisp programmers. You
can be both, but you must decide that you will learn to be a Lisp
programmer, or it will never happen. Just decide to do it and start
learning. Others have already given you plenty of material to start
working with.
> That's why I am griping. It's not that I think Lisp sucks. It is that I
> can not communicate in it at all. I am a stranger in a strange land in
> Lisp.
The strangeness will only disappear when you start becoming familiar
with it, rather than relating it to your own C experience.
--
Duane Rettig du...@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
Adam Warner
It's a point I discovered in my learning. And I don't think it is best
practice for programmers to be generating unintended side effects such as
shadowing core functions and relying upon lexical scope to protect them.
Your comment that "if you don't know some function exists then you're not
likely use it, or care if it gets shadowed" still means that as you gain
understand of the language you may start to care about rewriting your code
to avoid those side effects. You may even add one of those newly learned
functions into your code and then witness it break.
> I guess the exception to this is if you use some macro that expands to a
> function you don't know about, and accidentally shadowed. Which would
> be a problem in CL (butfor the two namespaces), but isn't in a language
> with hygienic macros, such as Scheme or Dylan.
Common Lisp certainly doesn't need hygienic macros. Why does Dylan? (Sorry
Bruce I'm pretty ignorant about Dylan. Does it have a single namespace?)
By the way, I've come to realise that my initial emphasis of a few months
ago that Lisp symbols should be case sensitive was misplaced. There's also
a nice discussion about case sensitivity in Ian Joyner's C++ Critique:
http://www.elj.com/cppcv3/s4/#s04-12
Still it would be nice if the information wasn't just thrown away but was
instead available as some aspect of a symbol's property.
Regards,
Adam
Alain Picard
> By the way, I've come to realise that my initial emphasis of a few months
> ago that Lisp symbols should be case sensitive was misplaced.
>
> Still it would be nice if the information wasn't just thrown away but was
> instead available as some aspect of a symbol's property.
Where did you get the idea that lisp symbols are case insensitive?
Adam Warner
I don't have that idea but the sentence was very sloppy. The Lisp Reader
throws away the case information by default (that is it converts all
symbols to uppercase).
As I understand it symbols have a number of properties associated with
them. It would be nice if one of those properties was information about
the original case of the symbol (e.g. it may be helpful when trying to
generate case sensitive markup such as XML or be especially helpful when
trying to make foreign interface calls that require the use of
StudlyCaps).
It would seem to be a modest and compatible addition to the language that
would not break any existing code. The drawback would be the manipulation
and storage of extra strings.
I am aware that the read table can be set to case sensitive and the
inplications for existing code and development environments breaking.
Regards,
Adam
Pascal Costanza
>
> Hi,
[...]
> I have lear