off-topic: Why is lisp so weird?

N

nobody

Howdy, Mike!

I'm a C++ programmer, and have to use lisp because I want to use
emacs. I've gotten a book on lisp, and I must say lisp is the ugliest
looking language syntax wise. What is up with this: (defun(foo()).

(DEFUN FOO () NIL)
What were the lisp authors thinking? Why did Stallman use lisp in
emacs so extensively?

C and C++ did not exist at the time. Do you think he should have used
Fortran for this? *shudder*

If someone, although not RMS, admittedly, was writing a new extensible
editor today, a combination of C++ and Python would have probably be
chosen.
Why oh why does such a weird and strange
looking language end up in a major software package so now I have to
learn it?

You can use better editors than Emacs. I'll give you a hint: no
12-finger key combinations with right clicking
and waving of a rubber wildebeest are happening in my office.
My mind boggles at the craziness of lisp, and stallman's
decision to add so much of it to lisp.


(SETF THIS-PARAGRAPH
`(PARAGRAPH
"do not eval this inside omega-forms unless you know what you
are doing!"
(SENTENCE
(HOPE I
(CLAUSE
(FEEL YOU (ADJECTIVE GOOD)))))

(SENTENCE
(WHO-ME-P
(PAST-TENSE
(USE (MAKE-SYMBOL "LISP")
:WHEN (PERIOD :FROM (YEAR 1982)
:TO (YEAR 1991)))))
(CLAUSE
(FEEL I (BELONGS :SUBJECT YOU PAIN)))

(BUT-CLAUSE
(PAST-PERFECT
SEE YOU (ONLY (THE (CL::FIRST ICEBERG))))))

;; *shudder* is a special variable !

(SENTENCE
(CAN YOU (USED GET (TO (THE (MANY PAREN))))
:WHEN ,(LAMBDA (X) (> X (SEVERAL (MANY WEEK))))))

,(LET ((SURFACE T))
`(SENTENCE
((DOUBLE MUCHO) :CONTENT 'ATROCITY
:WHERE? ,(LOCATION :TYPE
'ABOVE-BELOW NIL SURFACE))))))




(PRINT (TRANSLATE-INTO-ENGLISH THIS-PARAGRAPH))

--> "I hope you feel better. As someone who used Lisp from 1982 to
1991, I feel your pain, but you have only seen the tip of the iceberg.
You can get used to the parens after a few weeks of using them a lot.
Larger atrocities are beneath the surface"

If someone can answer my questions, I will spend less time with the
emacs psychiatrist!

Just walk away and never look back, if you value whatever sanity you
have left in you, mate!

HTH
 
M

MSCHAEF.COM

(e-mail address removed) (Mike Cox) wrote in message


(DEFUN FOO () NIL)

The syntax of Lisp is that way primarily because of its regularity. Every
program is represented as a generalized list, with only a few concessions
to the more diverse syntax folks have come to expect from languages like
C, etc. As a result, Lisp is more dependant than many languages on tools
like auto-indenting editors that support paren-matching. Of course, since
I'd hate to read a un-indended C program, I think the indention argument
against Lisp is specious at best.

The brightest side of all this is that since Lisp programs are built using
a construct that's so fundamental to the language, it's much easier to
write higher level code transformations than in C. In C, the preprocessor
can at best work with sequences of characters in the source text. In Lisp,
the macro facility can manipulate code at the level of syntax trees.
Python is an example of a language that provides AST manipulation in an
infix language, and while I haven't used it myself, the code I've read
makes it obvious that it's far less convenient than Lisp-style macros.
C and C++ did not exist at the time. Do you think he should have used
Fortran for this? *shudder*

The first version of Emacs was written in Teco macros. (If you really
want to *shudder*, do some research on that... :) The modern GNU
Emacs and X Emacs are written with a layer of C that implements the Lisp
system and some editing primitives. Most of the higher level functionality
is written in Lisp.
You can use better editors than Emacs. I'll give you a hint: no
12-finger key combinations with right clicking
and waving of a rubber wildebeest are happening in my office.

I can't say that such things happen in my office, even when I use Emacs.
Just walk away and never look back, if you value whatever sanity you
have left in you, mate!

Lisp gets a bad rap for a lot of reasons. IMO, if you enjoy programming,
and you haven't worked through writing some significant Lisp code, then
you've missed out on something useful. Even if you spend most of your time
in environments that have done better in the commercial space.

Consider this: 10 years ago (and for some of these features 30-40), Lisp
had syntax tree manipulation, multi-method dispatch, a metaobject
protocol, multiple inheritance, garbage collection, anonymous functions, a
highly interactive development environment, and first-class closures.
_All_ of these features are slowly finding there way into more mainstream
languages, with more chances of commercial success. If there truly was no
value in these concepts, and no value in knowing Lisp, this would not be
happening.

-Mike
 
P

Phil Stripling

The syntax of Lisp is that way primarily because of its regularity. Every
program is represented as a generalized list, with only a few concessions
to the more diverse syntax folks have come to expect from languages like
C, etc.

From today's MOTD:
We don't need no indirection
We don't need no flow control
No data typing or declarations
Did you leave the lists alone?

Hey! Hacker! Leave those lists alone!

Chorus:
All in all, it's just a pure-LISP function call.
All in all, it's just a pure-LISP function call.
 
M

MSCHAEF.COM

Phil Stripling said:
From today's MOTD:
We don't need no indirection
We don't need no flow control
No data typing or declarations
Did you leave the lists alone?

Cute. Wrong, but cute. :)

-Mike
 
N

nobody

I like!

How about this?


We don't need no obfuscation
We don't need no FORM-CONTROL
No CADR CADAR in the classroom
Hackers, leave them lists alone
Hey! Hackers! Leave them LISPs alone!

Chorus:
All in all, it's just another missing FUNCALL
All in all, purge LISP once and for all!



=============================================
In the following, Lisp == Common Lisp (ANSI):
---------------------------------------------

1. The fastest Lisp implementations are slow
(See any third-party benchmark)

2. Nobody but a small clique of fanatics likes it
(Whose existence proves nothing: No matter how odd
or perverted the cause, there will be followers)

3. The vast majority of people who study Lisp in
school, never want to use it out of their free will
later on.

3. Lisp is the most complicated language in the world
(It has the biggest standard specification document)

4. However, threads and GUI are not defined by the standard

5. There is no open-source cross-platform native code compiler

6. There is no standard C interface.
 
C

Christian Lynbech

nobody> =============================================
nobody> In the following, Lisp == Common Lisp (ANSI):
nobody> ---------------------------------------------

nobody> 1. The fastest Lisp implementations are slow
nobody> (See any third-party benchmark)

Says who? Says nobody!

What is the definition of "slow"? What particular third-party
benchmark are we talking about?

One analysis suggests that with the best of Lisp implementations you
should not accept a speed penality much above 10% relative to C.

The analysis in question was the Pfannkuch benchmark that was
thoroughly analysed in the ACM lisp journal some years back. I haven't
a reference at hand but will hunt one down if properly bullied.

Do not forget: benchmarking is roughly as reliable as statistics, you
can generally "prove" anything you like.

nobody> 2. Nobody but a small clique of fanatics likes it
nobody> (Whose existence proves nothing: No matter how odd
nobody> or perverted the cause, there will be followers)

And in what sense is that a problem for Lisp? It is merely the joy of
having infrared-capable 20/20 1000 mile vision on a planet of the
blind and deaf.

Can you say "business opportunity"?

nobody> 3. The vast majority of people who study Lisp in
nobody> school, never want to use it out of their free will
nobody> later on.

I have yet to encounter somebody who has aquired any useful
understanding of what Lisp is, that is not lamenting the difficulties
in finding a Lisp related job.

nobody> 3. Lisp is the most complicated language in the world
nobody> (It has the biggest standard specification document)

In what way did you arrive to "complicated language" from "big
standard document"?

C has more keywords than Lisp; the large part of the ANSI Lisp spec is
made up of library functions. My linux box has almost 4000 entries in
man3, how much do you think that would amount to if printed out on
paper?

This is not to dispute that Lisp is a big language but you probably
need to be a C programmer to consider that a problem. We Lisp
programmers prefer to have a large language in order to be able to
write small programs.

nobody> 4. However, threads and GUI are not defined by the standard

True, I am however curious about what examples of languages specifications,
including GUI and Threads, you are thinking about and what size these
specifications would be.

nobody> 5. There is no open-source cross-platform native code compiler

For what interesting definitions of "open-source", "cross-platform"
and "native code" do you use to make the above a valid statement?

It is true that the open-source implementations doesn't support
Windows well but they do cover the rest of the pack.

nobody> 6. There is no standard C interface.

As part of the standard no, as a separate open-source library yes.


------------------------+-----------------------------------------------------
Christian Lynbech | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- (e-mail address removed) (Michael A. Petonic)
 
C

Christian Lynbech

I apologize for not specifying a followup.

Follow-up set to comp.lang.lisp.

------------------------+-----------------------------------------------------
Christian Lynbech | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- (e-mail address removed) (Michael A. Petonic)
 
J

Joe Marshall

=============================================
In the following, Lisp == Common Lisp (ANSI):

Must be because it is interpreted. That and the fact that everything
is a list.
2. Nobody but a small clique of fanatics likes it
(Whose existence proves nothing: No matter how odd
or perverted the cause, there will be followers)

I don't understand why anyone would design a language without
putting emphasis on acceptance by the masses. Visual Basic is what we
all should be programming in! There are literally *millions* of
professional programmers who use it. That and Perl.
3. The vast majority of people who study Lisp in
school, never want to use it out of their free will
later on.

Exactly! Same as algebra or biology.
3. Lisp is the most complicated language in the world
(It has the biggest standard specification document)

Commmon Lisp about 1400 pages
C++ (1998) 776 pages
Perl about 600 pages
Java Language Specification, second edition, 544 pages

Intercal - about 40 pages
 
M

Michael Wojcik

[Followups restricted to comp.programming. Remember, kids, crossposting
leads to new aggressive malign retroviruses and excess nose hair.]


Odd. I've used emacs without having to use LISP. It's not as much
fun as using LISP without emacs, but it works.

This is, of course, entirely subjective, but I can't imagine on what
aesthetic basis LISP would be the ugliest programming language in
existence.

I can't say for sure what McCarthy was thinking when he created LISP,
but I'd guess it was something along the lines of "I think I'll create
a computer language which emphasizes function application rather than
procedural steps, which provides an easy-to-use list structure as a
generic data collection, and which sort of models Alonzo Church's
lambda calculus".
If someone, although not RMS, admittedly, was writing a new extensible
editor today, a combination of C++ and Python would have probably be
chosen.

That's one possibility, but I'm not sure I'd label it "probable".
There are other choices. vile, for example, is written in C.
Eclipse is written in Java. MS Visual Studio .NET is, what, C#?
Probably no Python in it, anyway.

What's "weird and strange[-]looking" about LISP? Maybe your
experience is just limited.

C++ looks pretty weird to programmers who only know COBOL. SML looks
weird to kids who've grown up on a diet of Java. APL looks weird to
pretty much everyone who doesn't write APL programs. The various
evil languages (Intercal, Brainfuck, and the lot) generally look weird
to anyone who isn't perversely devoted to such things. LISP isn't
even in the running with that crowd.
 
C

Corey Murtagh

Christian said:
nobody> =============================================
nobody> In the following, Lisp == Common Lisp (ANSI):
nobody> ---------------------------------------------

nobody> 1. The fastest Lisp implementations are slow
nobody> (See any third-party benchmark)

Says who? Says nobody!

What is the definition of "slow"? What particular third-party
benchmark are we talking about?

One analysis suggests that with the best of Lisp implementations you
should not accept a speed penality much above 10% relative to C.

....which proves that it is slow, no?
The analysis in question was the Pfannkuch benchmark that was
thoroughly analysed in the ACM lisp journal some years back. I haven't
a reference at hand but will hunt one down if properly bullied.

Since it helps to prove that Lisp is slow it's hardly vital information.
Feel free to pull it out if you want though.
Do not forget: benchmarking is roughly as reliable as statistics, you
can generally "prove" anything you like.

If you'd like we can all get together and write code in our language of
choice to perform a variety of common algos, find some sucker to run all
the samples sequentially on one computer, and see which languages excell
at which tasks. If Lisp comes out faster than the 'main-stream'
languages in any of those tests, we'll reconsider your objection.
nobody> 2. Nobody but a small clique of fanatics likes it
nobody> (Whose existence proves nothing: No matter how odd
nobody> or perverted the cause, there will be followers)

And in what sense is that a problem for Lisp? It is merely the joy of
having infrared-capable 20/20 1000 mile vision on a planet of the
blind and deaf.

Translation: I can see that Lisp is great, and all the rest of you are
morons. Sounds like a fanatic to me.
Can you say "business opportunity"?

When was the last time you found a niche market screaming out for a Lisp
solution? A solution that could /only/ be implemented in Lisp?
nobody> 3. The vast majority of people who study Lisp in
nobody> school, never want to use it out of their free will
nobody> later on.

I have yet to encounter somebody who has aquired any useful
understanding of what Lisp is, that is not lamenting the difficulties
in finding a Lisp related job.

This could be because there aren't many Lisp-related jobs. Wonder why
that is?
nobody> 3. Lisp is the most complicated language in the world
nobody> (It has the biggest standard specification document)

In what way did you arrive to "complicated language" from "big
standard document"?

Actually I kind of agree with you here. A much better test would be to
measure the time taken to learn to /use/ the language. Hard to get
those kinds of stats in a usable fasion however.
C has more keywords than Lisp; the large part of the ANSI Lisp spec is
made up of library functions. My linux box has almost 4000 entries in
man3, how much do you think that would amount to if printed out on
paper?

Brainf*ck has fewer keywords... are you saying that it's a simple
language? Wow. There's a bold statement for you.

Also failing to see how 4000 man pages on a Linux box relates to
language complexity *shrug*
This is not to dispute that Lisp is a big language but you probably
need to be a C programmer to consider that a problem. We Lisp
programmers prefer to have a large language in order to be able to
write small programs.

....that don't run very fast :>
nobody> 4. However, threads and GUI are not defined by the standard

True, I am however curious about what examples of languages specifications,
including GUI and Threads, you are thinking about and what size these
specifications would be.

Agreed, most languages don't touch on GUI in their standards docs. A
couple do touch on threads though.
nobody> 5. There is no open-source cross-platform native code compiler

For what interesting definitions of "open-source", "cross-platform"
and "native code" do you use to make the above a valid statement?

Find me an open-source Lisp compiler that produces native executables
that works on Windows, Linux and Mac... maybe Solaris too, just for fun.
It is true that the open-source implementations doesn't support
Windows well but they do cover the rest of the pack.


nobody> 6. There is no standard C interface.

As part of the standard no, as a separate open-source library yes.

This is a null point either way. The two languages should be kept
separate :>
------------------------+-----------------------------------------------------
Christian Lynbech | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- (e-mail address removed) (Michael A. Petonic)

I refer you to point #3 :>
 
T

Tom Plunket

Corey said:
...which proves that it is slow, no?

If "slower than C" is equivalent to "slow," then, yeah, most
languages are "slow".
If you'd like we can all get together and write code in our language of
choice to perform a variety of common algos, find some sucker to run all
the samples sequentially on one computer, and see which languages excell
at which tasks. If Lisp comes out faster than the 'main-stream'
languages in any of those tests, we'll reconsider your objection.

It's already been done. Doug Bagley has a project that tests a
bunch of languages beside one another in a variety of benchmarks.
(Some of his C++ samples could use some work, but I couldn't get
the benchmark to run on any of my machines because I'm dumb.) In
any event, Common Lisp performs admirably, coming in as "better"
than Python, Perl, and Java in the default benchmarks.

http://www.bagley.org/~doug/shootout/craps.shtml

Feel free to play with the numbers, though, to get the results
you're looking for. :)

-tom!
 
T

Tim Haynes

Corey Murtagh said:
If you'd like we can all get together and write code in our language of
choice to perform a variety of common algos, find some sucker to run all
the samples sequentially on one computer, and see which languages excell
at which tasks. If Lisp comes out faster than the 'main-stream' languages
in any of those tests, we'll reconsider your objection.

<http://www.bagley.org/~doug/shootout/craps.shtml> is one possible site of
interest.

HTH.

~Tim
 
J

Jeremy Yallop

Joe said:
Commmon Lisp about 1400 pages
C++ (1998) 776 pages
Perl about 600 pages
Java Language Specification, second edition, 544 pages

SQL (2003; draft?): more than 3000 pages.

Jeremy.
 
C

Corey Murtagh

Tom said:
If "slower than C" is equivalent to "slow," then, yeah, most
languages are "slow".

Well, I guess it kind of depends on your definitions. Comparison
against machine code is probably more useful, since that should give us
a baseline value to work against. Since C is closest to that, it's the
best baseline we have until something better comes along.
It's already been done. Doug Bagley has a project that tests a
bunch of languages beside one another in a variety of benchmarks.
(Some of his C++ samples could use some work, but I couldn't get
the benchmark to run on any of my machines because I'm dumb.) In
any event, Common Lisp performs admirably, coming in as "better"
than Python, Perl, and Java in the default benchmarks.

http://www.bagley.org/~doug/shootout/craps.shtml

Feel free to play with the numbers, though, to get the results
you're looking for. :)

It's close, but it enforces certain rules which I think are unrealistic.
For instance, some languages are much better with recursive algos than
the iterative equivalent.

I was more thinking that we produce the most optimal solution in our
chosen language rather than trying to find a common method and forcing
the language to work with that. After a few iterations of "oh, that's a
nice trick that'd work just as well in <language-of-choice>" the results
should stabilize somewhat... assuming roughly equivalent skill levels in
our chosen languages ;)

Oh, and let's get rid of the startup times to give Java a chance to
catch up, otherwise all the Java fans out there will bleat :>
 
M

Matthias

Corey Murtagh said:
If you'd like we can all get together and write code in our language
of choice to perform a variety of common algos, find some sucker to
run all the samples sequentially on one computer, and see which
languages excell at which tasks. If Lisp comes out faster than the
'main-stream' languages in any of those tests, we'll reconsider your
objection.

I had this stupid benchmark lying around anyway:

http://www.cvgpr.uni-mannheim.de/heiler/microbench/

It clearly shows that Lisp outperforms C++ in times of execution speed
in one test. Happy?

Matthias
 
C

Corey Murtagh

Joe said:
Fortran isn't.

I've always wondered about that. I've been hearing for years how
Fortran is faster than - or as fast as - C, and it seems strange. As
fast as, I'm not concerned about. Faster than... I'd be interested in
how and why, from a purely academic perspective.
 
C

Christian Lynbech

Corey" == Corey Murtagh said:
One analysis suggests that with the best of Lisp implementations you
should not accept a speed penality much above 10% relative to C.

Corey> ...which proves that it is slow, no?

No it doesn't, it only proves that it is a little slower than C which
is fast enough. And when it isn't you put the critical part of the
code into C or assembly or microcode, just as a C programmer would.
Can you say "business opportunity"?

Corey> When was the last time you found a niche market screaming out for a
Corey> Lisp solution? A solution that could /only/ be implemented in Lisp?

Ah, but there obviously is no such thing as "could /only/ be implemented in".
Turing has assured us that there is a formal equivalence between the
expressiveness power of all programming languages, so from a
theoretical standpoint there is no difference.

However, experience tells us that in practice there is a huge
difference in the *productivity* of deriving a correct solution to a
problem. There is a reason why very few people today write whole
applications in assembly or Turing Machines.

Lisp just happens to be the most productive language around.
C has more keywords than Lisp; the large part of the ANSI Lisp spec
is made up of library functions. My linux box has almost 4000
entries in man3, how much do you think that would amount to if
printed out on paper?

Corey> Brainf*ck has fewer keywords... are you saying that it's a simple
Corey> language? Wow. There's a bold statement for you.

Not that I know Brainf*ck or that it matters, but I was merely
challenging the thinking that the size of the language translates to
the complexity of it. If there was such a causality, you could claim
Lisp to be simpler than C which probably wasn't what nobody was trying
to say.

Corey> Also failing to see how 4000 man pages on a Linux box relates to
Corey> language complexity *shrug*

Agreed, it should however attest to the size of UNIX (ie. C+libs).


(And I never said that I wasn't a fanatic, but at least I am a fanatic
with a superior language)

------------------------+-----------------------------------------------------
Christian Lynbech | christian #\@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- (e-mail address removed) (Michael A. Petonic)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top