looking for a language with any of the following 4 charachteristics (all 4 would be nice).

9648 views
Skip to first unread message

zaphod

unread,
Feb 11, 2002, 8:48:16 PM2/11/02
to
My idea of the perfect language would be something like any of the
four following:

1)Logo that concentrated on lisp tricks and didn't even HAVE
turtle-graphics
2)Forth w/out all that OS STUFF, and stack STUFF.
3)lisp without so many parentheses
4)C without structured programming concepts

Anyone got a good candidate?

I'll even let you tell me how dumb I am for wanting what I want.
It seems that the common denominator of the four languages I like is
that they are all extensible, and I think all could be said to have
charachteristics of functional languages.

Someone could make me extraordinarilly happy by a real nice thorough
analysis of my essentially stupid and trivial thought(s) here.

Daniel Barlow

unread,
Feb 12, 2002, 4:57:53 AM2/12/02
to
Sla...@ureach.com (zaphod) writes:

> 1)Logo that concentrated on lisp tricks and didn't even HAVE
> turtle-graphics
> 2)Forth w/out all that OS STUFF, and stack STUFF.
> 3)lisp without so many parentheses
> 4)C without structured programming concepts

5) Assembler without all that addressing mode cruft

6) Plain txt fils without the lttr '', bcaus lts fac it, it's silly


-dan

--

http://ww.tlnt.net/cliki/ - Link farm for fr CL-on-Unix rsourcs

Raymond Wiker

unread,
Feb 12, 2002, 5:40:30 AM2/12/02
to
Daniel Barlow <d...@telent.net> writes:

> Sla...@ureach.com (zaphod) writes:
>
> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > turtle-graphics
> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > 3)lisp without so many parentheses
> > 4)C without structured programming concepts
>
> 5) Assembler without all that addressing mode cruft
>
> 6) Plain txt fils without the lttr '', bcaus lts fac it, it's silly

^ You missed one.

Of the original list, the three first items seemed to be about
removing a (the) "defining feature" of the language - seems like a
pretty pointless exercise.

--
Raymond Wiker Mail: Raymon...@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60

Try FAST Search: http://alltheweb.com/

Marco Antoniotti

unread,
Feb 12, 2002, 10:13:22 AM2/12/02
to

Sla...@ureach.com (zaphod) writes:

I think that by definition, INTERCAL (whose design goal was to remove
any feature known to any other programming language) fits the bill.

Cheers


--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.

Nils Goesche

unread,
Feb 12, 2002, 11:45:06 AM2/12/02
to
In article <y6cit92...@octagon.mrl.nyu.edu>, Marco Antoniotti wrote:
>
> Sla...@ureach.com (zaphod) writes:
>
>> My idea of the perfect language would be something like any of the
>> four following:
>>
>> 1)Logo that concentrated on lisp tricks and didn't even HAVE
>> turtle-graphics
>> 2)Forth w/out all that OS STUFF, and stack STUFF.
>> 3)lisp without so many parentheses
>> 4)C without structured programming concepts
>>
>> Anyone got a good candidate?
>>
>> I'll even let you tell me how dumb I am for wanting what I want.
>> It seems that the common denominator of the four languages I like is
>> that they are all extensible, and I think all could be said to have
>> charachteristics of functional languages.
>>
>> Someone could make me extraordinarilly happy by a real nice thorough
>> analysis of my essentially stupid and trivial thought(s) here.
>
> I think that by definition, INTERCAL (whose design goal was to remove
> any feature known to any other programming language) fits the bill.

No, he wants a functional language. So, I think this is closer:

http://www.eleves.ens.fr:8080/home/madore/programs/unlambda/

Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."

PGP key ID 0x42B32FC9

Eric Moss

unread,
Feb 12, 2002, 3:29:24 PM2/12/02
to
zaphod wrote:
>
> My idea of the perfect language would be something like any of the
> four following:
>
> 1)Logo that concentrated on lisp tricks and didn't even HAVE
> turtle-graphics
> 2)Forth w/out all that OS STUFF, and stack STUFF.
> 3)lisp without so many parentheses
> 4)C without structured programming concepts
>
> Anyone got a good candidate?

Yes.

Common Lisp comes closest for you, despite your loathing of
parentheses. First off, your dislikes wrt the other languages appear to
be structural and therefore unavoidable. Your beef with Lisp appears to
be cosmetic. That is least problematic when it comes to making a
working piece of code.

Addressing the parentheses phobia, which I see in other students in my
AI course, I say several things.

Firstly, parentheses are actually a necessity. You have to have *some*
delimiter in a language, after all, and it can't be just whitespace.

Secondly, parentheses are an *advantage* over other delimiters. Note
that C uses {} and ; and " " and ",", so it only *appears* to not be
full of delimiters. Lisp is far more elegant, separating tokens with
whitespace and expressions with ().

Thirdly, with a good editor, the parentheses become minor blips on your
screen, and the indentation (which is orthogonal to what makes parsing
easy for the compiler) can be your guide. If you wanted, you could even
customize the indentation, although lots of experience indicates that
emacs does just fine.

To summarize, Lisp appears to have everything you want except for its
cosmetic "flaw", which isn't really a flaw. That can be gotten past
with experience or editor-tinkering. All the other languages have major
structural issues that can't be avoided.


Or something like that...

Eric

Thomas F. Burdick

unread,
Feb 12, 2002, 4:42:58 PM2/12/02
to
Eric Moss <eric...@alltel.net> writes:

> zaphod wrote:
> >
> > My idea of the perfect language would be something like any of the
> > four following:
> >
> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > turtle-graphics
> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > 3)lisp without so many parentheses
> > 4)C without structured programming concepts
> >
> > Anyone got a good candidate?
>
> Yes.
>
> Common Lisp comes closest for you, despite your loathing of
> parentheses. First off, your dislikes wrt the other languages appear to
> be structural and therefore unavoidable. Your beef with Lisp appears to
> be cosmetic. That is least problematic when it comes to making a
> working piece of code.
>
> Addressing the parentheses phobia, which I see in other students in my
> AI course, I say several things.
>
> Firstly, parentheses are actually a necessity. You have to have *some*
> delimiter in a language, after all, and it can't be just whitespace.

Hell, since the parens are just the textual way of representing the
structure of the code, you could use a structure editor and never see
another paren again. Writing said editor is left as an exercise to
the reader.

--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'

Erik Naggum

unread,
Feb 12, 2002, 5:16:14 PM2/12/02
to
* Eric Moss <eric...@alltel.net>

| Addressing the parentheses phobia, which I see in other students in my AI
| course, I say several things.

I wonder if it is the parentheses or the enclosing delimiter. For some
time, now, I have been trying to understand how people react to Lisp, and
something occurred to me some tima ago that was recently reinforced. In
almost all other programming languages, parentheses are actually painful,
or symptoms of something painful. E.g., in those stupid infix syntaxes,
you need parentheses when the precedences of the operators you want to
combine are not related the way you want them to be. So the parentheses
become a means of resolving a conflict between the language and your
needs. In C-style languages, where type casts are necessary due to the
retarded type system, parentheses are used to resolve a conflict between
what the language thinks should be the type of something and what you
want it to be. The number of parentheses thus correlate with the level
of complexity, and the level of complexity with how hard it is to grasp.
The only "neutral" parentheses are those used in function calls. The
rest of the delimiters serve different purposes and also look different.

However, in (Common) Lisp, parentheses are the only game in town (well,
this is not true, but to the extent they are, bear with me), and all the
emotionsl responses to parentheses-as-pain-indicators from languages that
the programmer may have been previously exposed to come right back at him
at a very low level of consciousness. Any thinking person would observe
his reaction and think about it, but thinking peopla are never a problem.
Those who only react and feel that something must be wrong with all the
parentheses, may have a very particular reaction to parentheses. I have
had occasion to exploit this recently to test the hypothesis.

< and > are accetable delimiters these days, so I changed the reader and
printer to use them instead of ( and ). (The only practical problem was
that symbols with < and > in them needed to have that character escaped.)
Presented to two people who had previously been negative to Lisp, one of
them thought it was OK, now, the other went "you can't trick me into
liking Lisp". Presented to three people who were predicted to have a
strong dislike of parentheses, but had not had prior exposure to Lisp,
all three found it interesting, and one thought the parentheses of the
original code looked silly when presented with it -- the others quickly
figured out what the point of the exercise was, but did not react with
hostility to the parentheses. I found only one person whom I thought
would not be hostile to parentheses, but he was hostile to all the HTML
crap, instead, effectively being more annoyed with <> than with ().
This, of course, serves no useful statistical purposes, but I do not want
to run a research project on this. I would like to experiment with
working with this syntax for a while just to see how I think it works,
however. It might actually be the easiest way to get around the
parenthesis "perception problem".

/// 2002-02-12
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.

Software Scavenger

unread,
Feb 13, 2002, 1:41:34 AM2/13/02
to
Erik Naggum <er...@naggum.net> wrote in message news:<32225409...@naggum.net>...

> I wonder if it is the parentheses or the enclosing delimiter. For some
> time, now, I have been trying to understand how people react to Lisp, and

My first reaction to Lisp parentheses before I started learning Lisp
was that there were three main reasons why I didn't like them. First,
I saw long strings of them in Lisp and wondered if I was expected to
count them every time I saw them, or how I could be sure they were
right without counting them. Second, parentheses are awkward on most
keyboards. They're more likely to be fumbled more often, because of
the combination of the shift key, the distance to the parentheses
keys, and the awkward combination of fingers used to type them.
Third, it seemed to me that infix syntax was making compilers do more
work to reduce the amount of work done by the programmer, and that
therefore the non-infix parentheses-based syntax was a way of taking
some of the work load off the compiler and putting it on the
programmer.

Holger Schauer

unread,
Feb 13, 2002, 5:33:27 AM2/13/02
to
On 12 Feb 2002, Software Scavenger wrote:
> Erik Naggum <er...@naggum.net> wrote in (some) message:

>> I wonder if it is the parentheses or the enclosing delimiter.
>> For some time, now, I have been trying to understand how people
>> react to Lisp, and
> First, I saw long strings of them in Lisp and wondered if I was
> expected to count them every time I saw them, or how I could be sure
> they were right without counting them.

That was the one thing I really hated in the intro-course on Lisp that
I have taken. Once I learned the joys of Emacs (some five years
later), the parentheses "problem" disappeared without a trace. Hence,
the first thing I actually showed my students this year was a really
awkward and painful written peace of Lisp code. Next, I showed them
what it would look like to write it in Emacs. I then turned to show
them the same code with parens removed and told them not to count
parens but to use the structure of the code. Now that the course is
done, most of the code they've written actually looks pretty lispy.

> Second, parentheses are awkward on most keyboards. They're more
> likely to be fumbled more often, because of the combination of the
> shift key, the distance to the parentheses keys, and the awkward
> combination of fingers used to type them.

You should take a look at a German keyboard and try the key
combinations necessary to insert curly braces. Alt-Gr-7 and 8. Now
that's awkward (and the reason why German programmers sometimes prefer
using qwerty keyboards over German qwerty ones).

Holger

--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
Fachbegriffe der Informatik - Einfach erklärt
49: Version x.0
Kostenpflichtiger Preview als Bestandteil unserer Beta-Tests
(Kristian Köhntopp)

Brian Campbell

unread,
Feb 13, 2002, 10:25:41 AM2/13/02
to
In article <42e37222.02021...@posting.google.com>,
Sla...@ureach.com (zaphod) wrote:

> My idea of the perfect language would be something like any of the
> four following:
>
> 1)Logo that concentrated on lisp tricks and didn't even HAVE
> turtle-graphics
> 2)Forth w/out all that OS STUFF, and stack STUFF.
> 3)lisp without so many parentheses
> 4)C without structured programming concepts
>
> Anyone got a good candidate?

Well, to respond to exactly what you've asked for, I'd recommend Dylan
(which is a descendant of lisp with infix syntax) or ML (which is a
functional programming language with infix syntax, although it may seem
more weird to you than Dylan).

For Dylan, see the pages of the two implementations:
http://www.gwydiondylan.org (the open source implementation)
http://www.fun-o.com (the commercial implementation)

A web search should suffice for finding out stuff about ML (I've found
that when doing web searches about Dylan, I find lots of out of date
pages, so you have to know where to look to find the decent information).

>
> I'll even let you tell me how dumb I am for wanting what I want.
> It seems that the common denominator of the four languages I like is
> that they are all extensible, and I think all could be said to have
> charachteristics of functional languages.

Other languages you might want to consider but I can't say much about
are Oz/Mozart, Erlang, Haskell, Mercury, Smalltalk, or Self.

Of course, as plenty of other people have pointed out, the parentheses
in lisp really aren't that much of a problem, and lisp is far more
mature and complete than any of these other languages I've pointed out.
I've found that as I look at the newest features people are adding to
other languages and the problems people are encountering, they all seem
to have been solved in Lisp 20 years ago (that may be a slight
exaggeration, but not much of one).

Actually, though it makes me shudder to recommend it, the feature set of
perl seems to be slowly converging on an infix lisp, but perl is not a
language I'd recommend for anyone who wants anything close to resembling
elegance


>
> Someone could make me extraordinarilly happy by a real nice thorough
> analysis of my essentially stupid and trivial thought(s) here.

--
Brian Campbell
Real email: lambda (at) cs (dot) dartmouth (dot) edu

Ed L Cashin

unread,
Feb 13, 2002, 9:04:45 PM2/13/02
to
Erik Naggum <er...@naggum.net> writes:

...


> I would like to experiment with
> working with this syntax for a while just to see how I think it works,
> however. It might actually be the easiest way to get around the
> parenthesis "perception problem".

I don't know. Holger Schauer has a point: emacs makes it easy to edit
lisp, but many people don't use emacs. If I didn't already feel
confident that emacs will keep track of the parens and the indentation
for me on first encountering lisp, the nesting might appear
overwhelming.

Also, I remember thinking that lisp looked like "text vomit" compared
to languages whose structure lexically mirrors what's going on.
Here's an example in ruby:

{
"foo" => "bar",
"baz" => "burfle",
}.each { |i|
puts i
}

Which, once you're used to it, looks at a glance like a hash table
followed by some code to do for each thing in it. More importantly,
even before you're used to it, the structure suggests that there's
some structured data on top and some code on the bottom.

Lisp is more verbose, and at a glance always looks like text and
parentheses:

(let ((h (make-hash-table)))
(setf (gethash "foo" h) "bar")
(setf (gethash "foo" h) "bar")
(maphash
#'(lambda (k v)
(format t "~A~%" k)
(format t "~A~%" v)) h))

I know that an experienced lisper could create a read macro to support
a syntax like in the first example, but someone encountering lisp for
the first time might not know that.

My first time seeing a large amount of lisp code was in the emacs
sources.

--
--Ed L Cashin | PGP public key:
eca...@uga.edu | http://noserose.net/e/pgp/

zaphod

unread,
Feb 13, 2002, 10:06:23 PM2/13/02
to
Raymond Wiker <Raymon...@fast.no> wrote in message news:<86pu3br...@raw.grenland.fast.no>...

> Daniel Barlow <d...@telent.net> writes:
>
> > Sla...@ureach.com (zaphod) writes:
> >
> > > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > > turtle-graphics
> > > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > > 3)lisp without so many parentheses
> > > 4)C without structured programming concepts
> >
> > 5) Assembler without all that addressing mode cruft
> >
> > 6) Plain txt fils without the lttr '', bcaus lts fac it, it's silly
>
> ^ You missed one.
>
> Of the original list, the three first items seemed to be about
> removing a (the) "defining feature" of the language - seems like a
> pretty pointless exercise.


I think I mentioned that! I covered all that junk. You probably read
the meat and ignored my side dishes! Don't eat ever eat in the
restaurant I want to own, or I might put a little surprise in the
secret sauce!
Thank you for replying!

zaphod

unread,
Feb 13, 2002, 10:08:06 PM2/13/02
to
Marco Antoniotti <mar...@cs.nyu.edu> wrote in message news:<y6cit92...@octagon.mrl.nyu.edu>...

> Sla...@ureach.com (zaphod) writes:
>
> > My idea of the perfect language would be something like any of the
> > four following:
> >
> > 1)Logo that concentrated on lisp tricks and didn't even HAVE
> > turtle-graphics
> > 2)Forth w/out all that OS STUFF, and stack STUFF.
> > 3)lisp without so many parentheses
> > 4)C without structured programming concepts
> >
> > Anyone got a good candidate?
> >
> > I'll even let you tell me how dumb I am for wanting what I want.
> > It seems that the common denominator of the four languages I like is
> > that they are all extensible, and I think all could be said to have
> > charachteristics of functional languages.
> >
> > Someone could make me extraordinarilly happy by a real nice thorough
> > analysis of my essentially stupid and trivial thought(s) here.
>
> I think that by definition, INTERCAL (whose design goal was to remove
> any feature known to any other programming language) fits the bill.
>
> Cheers

Intercal is a joke. I'm very stupid; but I'm just smart enough to know that!

Wade Humeniuk

unread,
Feb 13, 2002, 10:11:56 PM2/13/02
to

"Ed L Cashin" <eca...@uga.edu> wrote in message
news:863d04e...@cs.uga.edu...

>
> Also, I remember thinking that lisp looked like "text vomit" compared
> to languages whose structure lexically mirrors what's going on.
> Here's an example in ruby:
>
> {
> "foo" => "bar",
> "baz" => "burfle",
> }.each { |i|
> puts i
> }
>
> Which, once you're used to it, looks at a glance like a hash table
> followed by some code to do for each thing in it. More importantly,
> even before you're used to it, the structure suggests that there's
> some structured data on top and some code on the bottom.
>

I have a dumb question, but of what use is the preceding Ruby code? I do
not even see the hash table in that code, where is it and how do you refer
to it outside the code fragment? Overloading of {??

> Lisp is more verbose, and at a glance always looks like text and
> parentheses:
>
> (let ((h (make-hash-table)))
> (setf (gethash "foo" h) "bar")
> (setf (gethash "foo" h) "bar")
> (maphash
> #'(lambda (k v)
> (format t "~A~%" k)
> (format t "~A~%" v)) h))
>

All your ruby code above seems to do is

(write '((foo bar) (baz burfle)))

or more tersely

'((foo bar) (baz burfle))

Wade


zaphod

unread,
Feb 13, 2002, 10:16:06 PM2/13/02
to
Eric Moss <eric...@alltel.net> wrote in message news:<3C697B24...@alltel.net>...


From experience (very little, but it don't take more)it is not just
cosmetic to me! If it were just a matter of making sure you close all
of your parentheses; that would be fine (i've figured that out, just
close with a zero, on a count-down from all open parentheses), but the
problem is, I think you have to know the whole damned kit-and kaboodle
to know WHEN to open, and WHEN to close; either that or I have yet to
find anything that adresses the idea behind the opening and closing of
them.

Ed L Cashin

unread,
Feb 13, 2002, 10:20:55 PM2/13/02
to
"Wade Humeniuk" <hume...@cadvision.com> writes:

> "Ed L Cashin" <eca...@uga.edu> wrote in message
> news:863d04e...@cs.uga.edu...
> >
> > Also, I remember thinking that lisp looked like "text vomit" compared
> > to languages whose structure lexically mirrors what's going on.
> > Here's an example in ruby:
> >
> > {
> > "foo" => "bar",
> > "baz" => "burfle",
> > }.each { |i|
> > puts i
> > }

...


> I have a dumb question, but of what use is the preceding Ruby code? I do
> not even see the hash table in that code, where is it and how do you refer
> to it outside the code fragment? Overloading of {??

It simply illustrates that the code that creates a hash tables is
visually reminiscent of the relationships that the hash table
represents. To keep track of the variable for later you'd just use a
variable:

h = {


"foo" => "bar",
"baz" => "burfle",
}.each { |i|
puts i
}

h.each { |i| puts i } # or whatever you want to do with h


The lisp example did the same thing as the ruby example -- creating a
hash table and printing its contents. But my point was the visual
impact of the syntax and had nothing to do with the use of the example
code.

> > Lisp is more verbose, and at a glance always looks like text and
> > parentheses:
> >
> > (let ((h (make-hash-table)))
> > (setf (gethash "foo" h) "bar")
> > (setf (gethash "foo" h) "bar")
> > (maphash
> > #'(lambda (k v)
> > (format t "~A~%" k)
> > (format t "~A~%" v)) h))
> >
>
> All your ruby code above seems to do is
>
> (write '((foo bar) (baz burfle)))
>
> or more tersely
>
> '((foo bar) (baz burfle))

True.

zaphod

unread,
Feb 13, 2002, 10:23:28 PM2/13/02
to
Erik Naggum <er...@naggum.net> wrote in message news:<32225409...@naggum.net>...

Not with me. I have no problem with parentheses, except that I don't
know all the rules to their use, and I don't want to learn the entire
common-lisp language to find out; either. I may do so, but I WILL
find a better way, if I can!

zaphod

unread,
Feb 13, 2002, 10:31:37 PM2/13/02
to
Brian Campbell <lambd...@yahoo.com> wrote in message news:<lambda2000-0F772...@merrimack.dartmouth.edu>...


Thank You very much. I'm quite pleased. Have you checked out python, by the way?

Ed L Cashin

unread,
Feb 13, 2002, 11:09:56 PM2/13/02
to
Sla...@ureach.com (zaphod) writes:

...


> Not with me. I have no problem with parentheses, except that I
> don't know all the rules to their use, and I don't want to learn the
> entire common-lisp language to find out; either. I may do so, but I
> WILL find a better way, if I can!

As far as this lisp beginner can tell, it's pretty simple:

* parentheses go around a list

* when a list is evaluated the first thing is treated as a function
and the following things in the list are the function arguments.

There are abbreviations (like the single quote character) and special
cases (special forms), and extensions (like read macrose), but that
seems to be the general idea. Add the fact that lists can be elements
a list, and you're off!

Marc Spitzer

unread,
Feb 13, 2002, 11:36:40 PM2/13/02
to

Here are the rules that work for me, a begining lisper working on small
stuff, probably not the real reason but it has worked so far:

name ; it gets evaled no parens
(function_name ; it get evaled as a function, because it is the first
; thing that lisp sees after a open paren

Some thing like cond conditions or let apear different, they start with 2
parens, but that is because there is some stuff going on behind the seens.
With cond I think the first form is just checked for a boolena return value
so you need to scope what is checlked by wrapping it in a set of parens,
unless you are checking the value of a varable then you can just type it.
There I have contradicted my self, it is time to shut up now.

so the short answer is when you need a function use a paren and when it is
done close it.

good luck

marc

Tim Bradshaw

unread,
Feb 14, 2002, 6:58:57 AM2/14/02
to
* Ed L Cashin wrote:

> It simply illustrates that the code that creates a hash tables is
> visually reminiscent of the relationships that the hash table
> represents. To keep track of the variable for later you'd just use a
> variable:

> h = {
> "foo" => "bar",
> "baz" => "burfle",
> }.each { |i|
> puts i
> }

> h.each { |i| puts i } # or whatever you want to do with h


> The lisp example did the same thing as the ruby example -- creating a
> hash table and printing its contents. But my point was the visual
> impact of the syntax and had nothing to do with the use of the example
> code.

Yes, I think this is what Lisp is about. Languages like Perl or Ruby
(or C) have decided that one sort of thing is interesting, and have a
syntax which has been greatly optimized for that single thing. Perl
is *really good* at string-bashing code with regexps, C is really good
at very terse OS code that both runs and can be compiled in reasonable
time on a PDP11-class machine, and so on.

Lisp has decided not to decide. Rather than provide a great mass of
syntactic tricks to support some particular style or programming
technique, Lisp provides a minimalist syntax which is just adequate to
express nested structures of various kinds without making any
commitment as to their meaning. The programmer then decides what this
syntax means in any instance.

Lisp is a toolkit for language design not a toolkit for solving
problems in particular domain. Of course, people will typically
evolve special languages in Lisp if they need to spend enough time in
any one domain to make it worth while, but since those languages are
usually application specific and not well-known, it's always easy to
demonstrate that any given language has a better syntax for any given
application than Lisp does.

--tim

Erik Naggum

unread,
Feb 14, 2002, 8:12:00 AM2/14/02
to
* Ed L Cashin <eca...@uga.edu>

| Also, I remember thinking that lisp looked like "text vomit" compared
| to languages whose structure lexically mirrors what's going on.

It appears warranted by the various reactions people have posted and told
of elsewhere to conclude that Common Lisp is a language that is better
suited for those who are more verbal than visual in how they remember and
learn. Those who are more visual, tend to be thrown off by the lack of
visual clues and the preponderance of words they need to recognize in
order to "see" the structure. The verbal, who recognize words the way
the visual see pictures and figures, have no such problem.

However, since XML and the like is not the disaster it should have been,
I guess that either those who use it are completely clueless verbally as
well as visually (95% chance of being true) or people can learn to be
more verbal even if they are "naturally" visual (5% chance of being true).

This is not to imply that those who are more verbal than visual are
superior beings, but they are clearly more suited to certain tasks than
those who are more visual.

///

Erik Naggum

unread,
Feb 14, 2002, 8:15:22 AM2/14/02
to
* Sla...@ureach.com (zaphod)

| Not with me. I have no problem with parentheses, except that I don't
| know all the rules to their use, and I don't want to learn the entire
| common-lisp language to find out; either. I may do so, but I WILL
| find a better way, if I can!

Quite amazing. It is obviously superfluous to answer any of your
questions with technical answers. This is good to know.

///

Tim Bradshaw

unread,
Feb 14, 2002, 8:33:29 AM2/14/02
to
* Erik Naggum wrote:

> It appears warranted by the various reactions people have posted and told
> of elsewhere to conclude that Common Lisp is a language that is better
> suited for those who are more verbal than visual in how they remember and
> learn. Those who are more visual, tend to be thrown off by the lack of
> visual clues and the preponderance of words they need to recognize in
> order to "see" the structure. The verbal, who recognize words the way
> the visual see pictures and figures, have no such problem.

I think this is an interesting point. However I'm not sure it's right
or at least not uniquely right. I think I'm a terribly visual person
(although I also can read). Whenever I write systems in Lisp (or any
other language, but my only recent experience of non-trivial systems
is Lisp), I end up with a huge mass of throwaway `browser'-type tools
which show me pictures of the various structures in the system. I
find it fairly hard to work without these tools. One of the beauties
of Lisp, for me, is that it's so good at talking about complex data
structures, and that typically it's easy to get pictures of these
things of various kinds.

--tim

Holger Schauer

unread,
Feb 14, 2002, 8:43:10 AM2/14/02
to
On Thu, 14 Feb 2002, Erik Naggum wrote:
> * Ed L Cashin <eca...@uga.edu>
>| Also, I remember thinking that lisp looked like "text vomit"
>| compared to languages whose structure lexically mirrors what's
>| going on.

I think the structure of Lisp does mirror what's going on.



> It appears warranted by the various reactions people have posted
> and told of elsewhere to conclude that Common Lisp is a language
> that is better suited for those who are more verbal than visual in
> how they remember and learn. Those who are more visual, tend to
> be thrown off by the lack of visual clues and the preponderance of
> words they need to recognize in order to "see" the structure. The
> verbal, who recognize words the way the visual see pictures and
> figures, have no such problem.

I wonder on what basis you draw the conclusion that the distinction is
between verbal and visual and wonder even more about the possible
implications. For instance, a verbal learner should not be thrown off
by code like (member (car (list (do-something here (based on another
complicated computation) ... <bunch of further arguments elided>)))).
This seems counterintuitive to me, I think even experienced Lisp
programmers tend to have (reading) problems with such gross code. [1]

With respect to the more visual oriented, I think what helped me most
was to recognize that there is structure but that parentheses are not
an issue one needs to care about, as long as you do follow it. I think
Graham has an example in his "Ansi CL" book in which he presents some
Lisp code with and without the parens. It's getting the structure that
matters, not the parens. I think, a claim somebody made is likely to
be true across most programming languages, which is that it does not
really matter what style you're following, it's following the style
that matters [2].

But then again, I may be one of those who you would classify as a
visual oriented person, although I tend to see myself as being verbal
oriented. Come to think of it, I'm a very unlikely candidate for
participating in an obfuscated code contest, although I am uncertain
whether that tells a story or doesn't.

Holger

Footnotes:
[1] Some time ago, I made some whitespace modifications to some old
and very ugly looking code. I was not the only one feeling that the
result was much more readable afterwards.

[2] Of course, when you have to follow some style guideline enforced
by external forces, this may throw you off when its totally against
your personal preferences.

"/home/moehwald > echo "the quick brown fox jumps over the lazy dog" |
tr -d aeiou"
"Jetzt weiss ich endlich, wie ein gewisser A.K. seine Postings erstellt."
-- Sven Geggus in de.comp.os.unix.linux.misc

Marco Antoniotti

unread,
Feb 14, 2002, 8:58:25 AM2/14/02
to

Sla...@ureach.com (zaphod) writes:

> Marco Antoniotti <mar...@cs.nyu.edu> wrote in message news:<y6cit92...@octagon.mrl.nyu.edu>...

...

> > I think that by definition, INTERCAL (whose design goal was to remove
> > any feature known to any other programming language) fits the bill.
> >
> > Cheers
>
> Intercal is a joke. I'm very stupid; but I'm just smart enough to
> know that!

Given your username.... :)

42

Ed L Cashin

unread,
Feb 14, 2002, 9:03:09 AM2/14/02
to
Tim Bradshaw <t...@cley.com> writes:

...


> Yes, I think this is what Lisp is about. Languages like Perl or
> Ruby (or C) have decided that one sort of thing is interesting, and
> have a syntax which has been greatly optimized for that single
> thing. Perl is *really good* at string-bashing code with regexps, C
> is really good at very terse OS code that both runs and can be
> compiled in reasonable time on a PDP11-class machine, and so on.
>
> Lisp has decided not to decide. Rather than provide a great mass of
> syntactic tricks to support some particular style or programming
> technique, Lisp provides a minimalist syntax which is just adequate
> to express nested structures of various kinds without making any
> commitment as to their meaning. The programmer then decides what
> this syntax means in any instance.

Yes, and I think that's why it often requires a little bit of
experience with several programming that are good in a more limited
domain before lisp's generality can be recognized as a boon.

Marco Antoniotti

unread,
Feb 14, 2002, 9:10:19 AM2/14/02
to

Ed L Cashin <eca...@uga.edu> writes:

> Erik Naggum <er...@naggum.net> writes:
>
> ...
> > I would like to experiment with
> > working with this syntax for a while just to see how I think it works,
> > however. It might actually be the easiest way to get around the
> > parenthesis "perception problem".
>
> I don't know. Holger Schauer has a point: emacs makes it easy to edit
> lisp, but many people don't use emacs. If I didn't already feel
> confident that emacs will keep track of the parens and the indentation
> for me on first encountering lisp, the nesting might appear
> overwhelming.
>
> Also, I remember thinking that lisp looked like "text vomit" compared
> to languages whose structure lexically mirrors what's going on.
> Here's an example in ruby:
>
> {
> "foo" => "bar",
> "baz" => "burfle",
> }.each { |i|
> puts i
> }

(map* #'print
(make-hash-table* '(("foo" => "bar")
("baz" => "bar"))))

Hello!!!!!!

The point being that in CL you can modify the language, and make it
look like CL or something else.

Here is one of my favourite `primes' in conforming CL.

(in-package "SETL-USER")

(defun primes (max)
[n in (range 3 max 2)
/ (not (exist m in (range 3 (min (1- n) (+ 2 (sqrt n))) 2)
/ (= (mod n m) 0)))])

> I know that an experienced lisper could create a read macro to support
> a syntax like in the first example, but someone encountering lisp for
> the first time might not know that.

So? Does that warrant the application of Greenspun's Tenth? :)

> My first time seeing a large amount of lisp code was in the emacs
> sources.

A lot of ELisp code is not all that nice looking. Especially because
a lot of ELisp code does not (require 'cl) :)

Cheers

Christophe Rhodes

unread,
Feb 14, 2002, 9:17:32 AM2/14/02
to
Marco Antoniotti <mar...@cs.nyu.edu> writes:

> Here is one of my favourite `primes' in conforming CL.
>
> (in-package "SETL-USER")
>
> (defun primes (max)
> [n in (range 3 max 2)
> / (not (exist m in (range 3 (min (1- n) (+ 2 (sqrt n))) 2)
> / (= (mod n m) 0)))])

I appreciate the point, but I thought that we decided that "conforming
CL" programmes needed to include their macros and reader-macros to be
properly conforming... :-)

Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)

Erik Naggum

unread,
Feb 14, 2002, 9:20:22 AM2/14/02
to
* Holger Schauer <Holger....@gmx.de>

| I wonder on what basis you draw the conclusion that the distinction is
| between verbal and visual and wonder even more about the possible
| implications.

Sigh. I wrote:

It appears warranted by the various reactions people have posted and
told of elsewhere to conclude that Common Lisp is a language that is
better suited for those who are more verbal than visual in how they
remember and learn.

| For instance, a verbal learner should not be thrown off by code like


| (member (car (list (do-something here (based on another complicated
| computation) ... <bunch of further arguments elided>)))). This seems
| counterintuitive to me, I think even experienced Lisp programmers tend to
| have (reading) problems with such gross code. [1]

On what basis do you conclude something about what a "verbal learner"
should or should not be thrown off by?

| But then again, I may be one of those who you would classify as a
| visual oriented person

Why do you think this is an either-or issue? When I write "more verbal
than visual" and try to be very clear that we are talking about a point
on a line between two extrama, please do not waste my time by assuming
that only the extrema are worth talking about. Nobody is "classified" as
a visual-oriented person, it is a matter of what you are more comfortable
with, not some one-bit flag in your personality.

Thom Goodsell

unread,
Feb 14, 2002, 9:32:23 AM2/14/02
to
Holger Schauer <Holger....@gmx.de> writes:
>
> I wonder on what basis you draw the conclusion that the distinction is
> between verbal and visual and wonder even more about the possible
> implications. For instance, a verbal learner should not be thrown off
> by code like (member (car (list (do-something here (based on another
> complicated computation) ... <bunch of further arguments elided>)))).
> This seems counterintuitive to me, I think even experienced Lisp
> programmers tend to have (reading) problems with such gross code. [1]
>
> With respect to the more visual oriented, I think what helped me most
> was to recognize that there is structure but that parentheses are not
> an issue one needs to care about, as long as you do follow it. I think
> Graham has an example in his "Ansi CL" book in which he presents some
> Lisp code with and without the parens. It's getting the structure that
> matters, not the parens. I think, a claim somebody made is likely to
> be true across most programming languages, which is that it does not
> really matter what style you're following, it's following the style
> that matters [2].
>

I don't believe Erik intended to suggest that verbal people can easliy
read poorly formatted code. Rather, lisp code is more about words than
about granting special meaning to every non-text character on your
keyboard. As a simple example, consider array access in Lisp and
C/C++/Java:

(aref *some-array* 10)
vs.
some_array[10];

In C, the braces take the place of "aref" and are easily spotted, even
by someone who has trouble spotting "aref" in a mass of text. Thus,
discounting syntactic characters (parens, semi-colons, and braces), C
code has a lot more non-character symbols than Lisp. The structure is
still important in both cases.

I show the extreme example of a visually-oriented language, but I've
so far managed to avoid learning any Perl.

Thom

--
(map 'string #'(lambda (char) (let ((char-code (char-code char)))
(code-char (if (< 64 char-code 123) (+ (mod (+ 13 char-code) 52) 65)
char-code)))) "Z...@IXG.IUS")

Julian Stecklina

unread,
Feb 14, 2002, 10:15:35 AM2/14/02
to
Sla...@ureach.com (zaphod) writes:

[...]

> Intercal is a joke. I'm very stupid; but I'm just smart enough to know that!

But it's nevertheless interesting. I got headache after the first few
pages of the "specification". :)

Regards,
Julian

--
Um meinen oeffentlichen Schluessel zu erhalten:
To get my public key:
http://math-www.uni-paderborn.de/pgp/

Dorai Sitaram

unread,
Feb 14, 2002, 10:26:39 AM2/14/02
to

I am inclined to agree, but just yesterday a coupla
posts here were praising special tools over
general tools. That also sounded somewhat agreeable
with at the time, except that their argument put CL
firmly on the side of the specializers, not
generalizers as the above seems to be doing (unless
Lisp is not being equated with CL).

--d

Holger Schauer

unread,
Feb 14, 2002, 10:05:08 AM2/14/02