From
<http://spyced.blogspot.com/2005/10/why-i-never-got-into-lisp.html>
Funny reading:
1) This is a chosing special-case-verifying-i-want-to-prove. I mean i
can find code where LISP is more terse.
2) My math miserable fails, 33%?
3) Use == and = instead zerop and setq. Future LISP?
4) You could omit indentation in LISP because code is small
(if (or (> x y) (== a)) (= a1 (+ (* m x) b) (= a2 (- (/ m x) b))
you cannot in Python: 6.7%
5) Side effects. If x = 4 Python is okay, but if x = 2 + 2 precedence
will be wrong. In LISP (+ 2 2) or 4 both are correct.
On Thu, 07 Dec 2006 01:38:26 -0800, Juan R. wrote:
> From
> <http://spyced.blogspot.com/2005/10/why-i-never-got-into-lisp.html>
>
> Funny reading:
>
> 1) This is a chosing special-case-verifying-i-want-to-prove. I mean i
> can find code where LISP is more terse.
I bet an ultra-competent macro head could have shrunk code considerably
over the course of the whole program. But in small blocks, Lisp tends to
look flabby compared to Huffman-coded languages like Perl.
This statement from the link represents the disconnect we're up against:
> But Lisp syntax was designed 50 years ago to make it easy to parse! We
> don't have to optimize for this anymore -- it's time to optimize for the
> programmer!
Macros, man. Macros! Mutate the language into whatever it is you want.
>
> 2) My math miserable fails, 33%?
Floating-point math is hard! ;)
>
> 3) Use == and = instead zerop and setq. Future LISP?
Indeed. Arc, the perpetual vaporware project, is going in this direction.
>
> 4) You could omit indentation in LISP because code is small
Except experienced Lisp-heads read indentation more than parens.
>
> (if (or (> x y) (== a)) (= a1 (+ (* m x) b) (= a2 (- (/ m x) b))
I have to count parens to read that. Not fun.
>
> you cannot in Python: 6.7%
There are ways to obfuscate Python.
>
> 5) Side effects. If x = 4 Python is okay, but if x = 2 + 2 precedence
> will be wrong. In LISP (+ 2 2) or 4 both are correct.
Python has odd ideas about what constructs are statements and which are
expressions. Lisp has no concept of a statement: Everything returns a
value, so everything is an expression.
(Lisp also never has precedence screws.)
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Chris Barts <··············@tznvy.pbz> writes:
> I bet an ultra-competent macro head could have shrunk code considerably
> over the course of the whole program. But in small blocks, Lisp tends to
> look flabby compared to Huffman-coded languages like Perl.
I think this has a detrimental effect in how you think about solutions
in languages like Perl. Since certain solution styles have optimized
syntax baked right into the language, going outside those styles
suddenly feels like a lot of hassle and not worth the trouble. I think
that's why a lot of solutions converge tweaking strings with regular
expressions and sticking them into hash tables.
If you can accept Lisp's notion that most constructs (including method
calls, control structures, array references, etc) look somewhat like a
function call, it doesn't feel like you're really going outside the
preferred realm of solutions by simply adding more features that look
somewhat like function calls. Code that uses a specialized forms of
table storage or arrays doesn't look unnatural simply for not being
able to take advantage of a compressed syntax using {} or [].
Zach
Zach Beane <····@xach.com> writes:
> Chris Barts <··············@tznvy.pbz> writes:
>
>> I bet an ultra-competent macro head could have shrunk code considerably
>> over the course of the whole program. But in small blocks, Lisp tends to
>> look flabby compared to Huffman-coded languages like Perl.
>
> I think this has a detrimental effect in how you think about solutions
> in languages like Perl. Since certain solution styles have optimized
> syntax baked right into the language, going outside those styles
> suddenly feels like a lot of hassle and not worth the trouble. I think
> that's why a lot of solutions converge tweaking strings with regular
> expressions and sticking them into hash tables.
>
> If you can accept Lisp's notion that most constructs (including method
> calls, control structures, array references, etc) look somewhat like a
> function call, it doesn't feel like you're really going outside the
> preferred realm of solutions by simply adding more features that look
> somewhat like function calls. Code that uses a specialized forms of
> table storage or arrays doesn't look unnatural simply for not being
> able to take advantage of a compressed syntax using {} or [].
>
I think I agree....
I recently had to write some fairly simple scripts to analyse some
data files. At work, they have a very poor grasp of programming and
language issues - its one of those places where they waste far too
much time writing poorly thought out specs and demand you use their
"supported" language, which unfortunatley is Oracle's PL/SQL - yep,
thats right, we are supposed to use this for everything, even tasks
with no database requirements.
Obviously, I have ignored that requirement because its stupid and
mainly because nobody will ever see the code - its only the
output/reports they are interested in. As there has been some perl
used in the past, I figured that would be the most acceptable solution
should it become known what I was doing. I consider myself a fairly OK
perl programmer having used it on and off for about 10 years.
I wrote the script and started refining it as I got a clearer
understanding of the large data sets being processed (I had no
documentation, no real description of the data and have had to
discover it). As the script developed, I began to feel more and more
uncomfortable about it as it felt very clunky and I wasn't confident
my results were what I thought they were and the number of probable
bugs concerned me. It struck me at the time that some of my problem
was due to difficulty in mapping my conceptual ideas/solutions into
perl. I decided to try some other languages and see how this real
world task might change.
I decided to try a solution in CL. I'm not yet as confident regarding
the language as I am with Perl and spend considerably more time
searching the hyperspec for appropriate functions or refreshing my
memory regarding arguements and return values etc. Despite this, the
whole process was almost instantly more rewarding and progress was
much faster. The resulting code was also much easier to understand and
I had increased confidence that the reports were actually reporting
what I intended etc. The whole repl interaction was also much more
rewarding for this type of explorational programming.
This got me thinking about other languages. I've recently being
looking at Ruby, which I have to say seems on the surface to be the
nicest OO language I've used since smaltalk at Uni. Using it makes me
shudder when I remember the years in the wilderness programming Java.
I found the solution I developed in Ruby also mapped more readily wrt
how I thought of the problem conceptually.
In the end, I found that for this particular problem, the easiest
language to use was CL, then Ruby and finally Perl (keeping in mind
that Perl is actually the language I have the most experience with).
The CL and Perl appear to have similar execution times, but given my
inexperience with CL, I suspect the CL solution could be faster if
optimised. I found both the CL and Ruby solutions used considerably
more memory and the Ruby solution was considerably slower than the
perl one. Again, this could be due to my lack of Ruby experience as
this is my first Ruby script.
However, the most interesting observation for me was that both CL and
Ruby made the task simpler mainly because the way I was thinking about
the problem maps to those languages with a lot less effort than
with Perl.
Tim
--
tcross (at) rapttech dot com dot au
On 2006-12-08, Tim X <····@nospam.dev.null> wrote:
> Zach Beane <····@xach.com> writes:
>> Chris Barts <··············@tznvy.pbz> writes:
>>> I bet an ultra-competent macro head could have shrunk code
>>> considerably over the course of the whole program. But in small
>>> blocks, Lisp tends to look flabby compared to Huffman-coded
>>> languages like Perl.
>>
>> I think this has a detrimental effect in how you think about
>> solutions in languages like Perl. Since certain solution styles
>> have optimized syntax baked right into the language, going outside
>> those styles suddenly feels like a lot of hassle and not worth the
>> trouble. I think that's why a lot of solutions converge tweaking
>> strings with regular expressions and sticking them into hash
>> tables.
>>
>> If you can accept Lisp's notion that most constructs (including
>> method calls, control structures, array references, etc) look
>> somewhat like a function call, it doesn't feel like you're really
>> going outside the preferred realm of solutions by simply adding
>> more features that look somewhat like function calls. Code that
>> uses a specialized forms of table storage or arrays doesn't look
>> unnatural simply for not being able to take advantage of a
>> compressed syntax using {} or [].
>>
>
> I think I agree....
>
> I recently had to write some fairly simple scripts to analyse some
> data files.
[ cool story snipped ]
I enjoyed reading that and would be interested in hearing more about
the specifics of the problem, e.g. what concepts you tried in Perl,
and what you tried in Lisp, and how Lisp mapped better, for you. I'd
like to put a pointer to your story in the FAQ
(http://www.lispniks.com/faq/faq.html) in the "Toto -- I've a feeling
we're not in Kansas anymore" section (or somewhere in there, anyway).
Regardless, thanks again!
-- Larry
Larry Clapp <·····@theclapp.org> writes:
> On 2006-12-08, Tim X <····@nospam.dev.null> wrote:
>> Zach Beane <····@xach.com> writes:
>>> Chris Barts <··············@tznvy.pbz> writes:
>>>> I bet an ultra-competent macro head could have shrunk code
>>>> considerably over the course of the whole program. But in small
>>>> blocks, Lisp tends to look flabby compared to Huffman-coded
>>>> languages like Perl.
>>>
>>> I think this has a detrimental effect in how you think about
>>> solutions in languages like Perl. Since certain solution styles
>>> have optimized syntax baked right into the language, going outside
>>> those styles suddenly feels like a lot of hassle and not worth the
>>> trouble. I think that's why a lot of solutions converge tweaking
>>> strings with regular expressions and sticking them into hash
>>> tables.
>>>
>>> If you can accept Lisp's notion that most constructs (including
>>> method calls, control structures, array references, etc) look
>>> somewhat like a function call, it doesn't feel like you're really
>>> going outside the preferred realm of solutions by simply adding
>>> more features that look somewhat like function calls. Code that
>>> uses a specialized forms of table storage or arrays doesn't look
>>> unnatural simply for not being able to take advantage of a
>>> compressed syntax using {} or [].
>>>
>>
>> I think I agree....
>>
>> I recently had to write some fairly simple scripts to analyse some
>> data files.
> [ cool story snipped ]
>
> I enjoyed reading that and would be interested in hearing more about
> the specifics of the problem, e.g. what concepts you tried in Perl,
> and what you tried in Lisp, and how Lisp mapped better, for you. I'd
> like to put a pointer to your story in the FAQ
> (http://www.lispniks.com/faq/faq.html) in the "Toto -- I've a feeling
> we're not in Kansas anymore" section (or somewhere in there, anyway).
>
I'll see if I can expand a bit.
The Problem
===========
- The application generates "event logs" which are similar in style to
syslog records, but its not done through syslog and unfortunatley
there is some inconsistency in record formats, which muddy the
waters a bit (need quite a lot of error checking an alternative
parsing formats)
- There is no documentation. The application is in binary and was
written in the early 90s. We have source code - actually, we have
lots of source code, but it has not been managed well and we can't
determine which source code was used to create the binary (some of
it won't compile anymore without considerable changes - its early
C++).
- The system is Tru64 on a server with approx 30,000 user accounts.
However, only approx 10k - 15k of the users use the application.
Usage frequency varies greatly. Log records average around 150Mb per
month. Initially, we want to process 1 years data. We have data
going back around 7 years.
- Records have a "session" relationship, but the only information
linking a session is the process id, which is not unique due to both
normal pid rotation and the way the application's server is
implemented. There is no documentation regarding record formats,
possible values or even meaning of some values etc.
- We want to get a "picture" of user interaction with the system, so
we need to try and tie together the records making up individual
sessions. Although there is a record which indicates the end of the
session, it seems that the existance of this record depends on how
the user exits the app, plus there seems to be frequent 'drop outs'
or possibly records being lost (i.e. race condition writing to log
files or something similar).
I think one of the main things that made lisp so useful in addressing
this problem was the level of data exploration that was needed to get
to understand the event logs. When developing the first version in
perl, it was a slightly annoying process of add a bit of code, try
parsing a section of a data file, tweak the code, try again, tweak ,
try, tweak, try - each time, starting from scratch. With lisp, the
exploration was a joy. I just entered code into the repl and refined
it in the repl while being able to keep variables and other data
structures. Essentially it was faster and less intrusive with respect
to concentration.
This problem was really well suited to an iterative style
of development where you incrementally refined what the program did.
While this can be done to some extent in any language, lisp seems to
suit this approach more than perl. The lisp code ended up looking a
lot clearer, while the perl code got less elegant and more muddy.
Adjusting data structures seemed easier with lisp than perl as well,
but that might be a reflection of how quickly I forget how to do
nested structures in perl - for example, if I wanted to create a hash
in perl with elements that were lists of lists, I always have trouble
trying to remember the syntax unless I've been working fairly
constantly in the language. With lisp, I don't seem to have this
problem.
As the code developed, in lisp, I was able to simplify some bits with
some really simple macros. To simplify the code in perl, I had to
write a new subroutine and either stick with global variables or deal
with yet another different referencing/dereferencing syntax and make
decisions on whether to use prototypes or not etc.
When I decided to try Ruby (mainly because I had been looking for a
real problem to try it out on), I had a better understanding of the
event records and the level of variation. I took a different approach
and created record objects and session objects to represent the main
data structures. I was actually quite shocked at how fast and
productive I was with this langauge given that it was my first ever
attempt to program with it. I found it had many of the features I
liked in both smaltalk and CLOS. Above all, I liked the fact it did
not have the overhead and verbosity of Java or clumsiness of C++. I
liked the fact that Ruby, like lisp, seems to have sensible defaults
for most things. Unlike lisp, I found the naming convention a lot more
familiar, which made finding built-in objects, methods etc easier to
find (for me, the hardest part of CL has been identifying the
appropriate functions and getting familiar with nameing conventions).
I didn't bother trying an OO perl based solution. although I've done
OO perl some time ago, I do remember there were a couple of "gotchas"
to watch out for (which I've forgotten the details of) and you pretty
much have to define everything in your object - there is no sensible
default accessors like there is in CL or Ruby (though from memory, I
didn't mind OO perl when I did it, which was a reflection of my
distaste for Java and C++).
The results I ended up with from Ruby look quite good. The code seems
easy to follow and logical, but this could be a reflection of my
better understadning of the problem than in any particular stremgth of
the language. Using objects certaily made refinement simpler and kept
the code cleaner than in perl - for example, in Ruby, defining to_s
(to string) methods in my objects made report generation very easy and
when I refined the object, a simple tweak of the to_s method updated
everything. In perl, I defined a subroutine to print out the data
structures to make the report. frequently, I would update the data
structure and forget to update the printing subroutine - running the
file would either crash or not report correctly and I'd have to switch
back to the editor and fix that before trying again - not a big issue,
but it added to my frustration.
I got similar positive results with CLOS and in some ways, found
things did what I expected more often. There were a couple of gotchas
with Ruby, but again, these could be just due to my lack of experience
with the language. For example, I was surprised that a line like
puts "My object is "+object
didn't work, but
puts "My object is "+object.to_s
did. I would have thought it would have been able to determine the need to
call the to_s method due to the context of being referenced in a puts
statement. I actually still think this is probably just something I've
overlooked rather than alimitation of the language.
As a big part of this problem involved parsing records and breaking
them up into tokens and interpreting some action from the set of
toekns, I also think it is the sort of problem which either suits lisp
or at least is the type of problem I think of in terms whih suit lisp.
Given that the main "selling point" of perl is its text processing
abilities, I had expected this sort of problem to fall out quite
naturally with perl. However, either the specifics of this problem
didn't map well onto perl, or more likely, the way I thought about the
problem and solution resulted in a conceptual model which didn't map
to perl as cleanly as it mapped to lisp and/or Ruby.
For me, the main thing I think I learned was that while the languages
may be functionally equivalent in a turing sense and while they all
possessed the necessary built-in features (though I did use cl-pcre),
one language may suit an individual better than another because it has
a better mapping from how the programmer thinks to how this is
translated into code. It is also likely that the way you think about a
problem could be significantly affected by what language was used to
introduce you to programming. This would explain why some people love
C++ and java. On the other hand, my first language was basic on a
TRS-80 in c1977, followed later by logo, pascal and C (in that order)
and yet it was lisp which re-inspired me wrt programming.
I'm now going to continue to try nd refine my program some more, but
have given up the perl version completely. The main version is likely
to be ruby (because its something new), but my exploration of the
problem domain will continue to be done in lisp (because thats easy
and allows me to concentrate on the problem rather than the language).
In conclusion, I really like lisp, but suspect Ruby is going to
continue to grow in popularity. It is interesting that although I
spent more time looking at python than I have with Ruby, I have
already achieved more with Ruby than I ever did in Python. It wouldn't
be a shock to find in five years time, Ruby is more popular than
Python and people will be saying things like "Oh Python, yeah, I
remember - that was that language with the weird whitespace thing that
couldn't decide exactly what type of language it was."
Of course if it was a really fair and balanced world, in five years
time people would also be saying "PHP? What's that?"
Tim
--
tcross (at) rapttech dot com dot au
On 2006-12-08, Tim X <····@nospam.dev.null> wrote:
> I'll see if I can expand a bit.
>
> The Problem
>===========
[ snip cool writeup ]
Thanks, Tim!
-- Larry
From: Holger Schauer
Subject: Re: Why I never got into Lisp
Date:
Message-ID: <yxzu006g5vx.fsf@gmx.de>
On 4846 September 1993, Tim X. wrote:
> In the end, I found that for this particular problem, the easiest
> language to use was CL, then Ruby and finally Perl (keeping in mind
> that Perl is actually the language I have the most experience with).
> The CL and Perl appear to have similar execution times, but given my
> inexperience with CL, I suspect the CL solution could be faster if
> optimised. I found both the CL and Ruby solutions used considerably
> more memory and the Ruby solution was considerably slower than the
> perl one. Again, this could be due to my lack of Ruby experience as
> this is my first Ruby script.
I recently also had a stab at Ruby (for similar reasons) and had a
quite similar experience. But I had two different sets of data to
analyze. After writing a Ruby script much the Perl way, I found that
Ruby was about as fast as a Perl solution I had come up with (the Perl
didn't solve several issues which I found could only be grossly solved
in Perl, which drove me to Ruby in the first place). For the second
data set, I went all OO with Ruby and used a lot of abstractions. I
think this is the main reason why the resulting solution is a lot
slower and consumes more memory than the (in reality not so)
straight-forward Perl hack. On the benefit side, however, is the clear
structure that allows for very local modifications in case they're
needed, greater reusability. That in turn fitted in nicely with
test-driven development, so as another benefit all parts can easily be
tested (whereas the hackish solution is just a tightly integrated mess
where most part of the constraints of the problem domain are left
implicit in assumptions the code makes, so that for every unexpected
input I would start digging through it all).
Now, coming back to Lisp, as we all know, CL similarly allows several
styles to solve a problem. From what you've written, I would assume
that you took a very structured approach to solving the problem in
Lisp. But just like I did with my first Ruby approach, a much more
messy approach would be possible as well: forget about abstractions,
use global variables to store state, etc. Hence, I would expect that
it would be to achieve at least a similar resource behaviour with a CL
solution as with Perl, because that is what Perl is usually all about:
use what it provides without thinking to much about code design. To
sum it up: highly structured solutions may come with a price,
regardless of the language you use.
The question then is what are you willing to pay for? For speed or
memory usage? Or for readability and re-usability? Or perhaps, as you
suggest, it would even be possible to optimize the clean CL code to be
as fast as, well, that other solution. I think that's not possible
with Ruby (there is no way to declare types and there is no optimizing
compiler, etc.). On the other hand, if the structured code is
considerably slower than the unstructured approach, this might hint at
a deeper problem, i.e. that over all that structure one has forgotten
to choose the right algorithmic approach.
Holger
--
--- http://hillview.bugwriter.net/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
89: PSD
Damit die Schriften nicht aussehen, als w�ren sie mit der
Laubs�ge bearbeitet. (Meikel Katzengreis)
Chris Barts wrote:
>
> This statement from the link represents the disconnect we're up against:
> > But Lisp syntax was designed 50 years ago to make it easy to parse! We
> > don't have to optimize for this anymore -- it's time to optimize for the
> > programmer!
>
> Macros, man. Macros! Mutate the language into whatever it is you want.
Yeah, the problem is that LISP is different and too many people do not
notice that.
> >
> > 2) My math miserable fails, 33%?
>
> Floating-point math is hard! ;)
More hard may be he counted spaces added where were not needed.
> >
> > 3) Use == and = instead zerop and setq. Future LISP?
>
> Indeed. Arc, the perpetual vaporware project, is going in this direction.
And is not good? Lisp already was from early PLUS, TIMES... to modern
+, *...
Other ideas i read are fn instead lambda, hd and tl instead car and
cdr, etc.
> >
> > 4) You could omit indentation in LISP because code is small
>
> Except experienced Lisp-heads read indentation more than parens.
I know lispers prefer to write linearly for small code, e.g. (* 2 (+ 4
8))
> >
> > (if (or (> x y) (== a)) (= a1 (+ (* m x) b) (= a2 (- (/ m x) b))
>
> I have to count parens to read that. Not fun.
Some fun with a simple (there is several for free) highligt syntax
editor, wich automatically match parens.
> >
> > you cannot in Python: 6.7%
>
> There are ways to obfuscate Python.
Sure, but he focused on terseness and claimed that 33% was too much for
the example he choosed. The 33% is not correct and with above points,
you could obtain more power than Python but with less than a 7% more
typping even in a simple text editor.
>
> > >
> > > 3) Use == and = instead zerop and setq. Future LISP?
> >
> > Indeed. Arc, the perpetual vaporware project, is going in this direction.
>
> And is not good? Lisp already was from early PLUS, TIMES... to modern
> +, *...
>
> Other ideas i read are fn instead lambda, hd and tl instead car and
> cdr, etc.
I can't believe that someone is actually proposing == and = in this
day and age. Just the other day we found some code here where the
programmer had typed == instead of =.
Anyway, you can already use = to test for numeric equality. And = is
not the same as zerop, which the above seems to imply.
hd and tl as replacements for car and cdr are also misguided because
car and cdr don't operate on lists, but rather on conses, and conses
don't have a head and a tail. They have a car and a cdr, and these
are different from a head and a tail.
If you want to operate on lists, there's already first and rest.
To me this fizz about changing Lisp's syntax is so misguided. It's a
mistake to think that the reason people don't use Lisp is that there's
something wrong with Lisp syntax.
The reason Lisp is not more popular is that Lisp is not fashionable.
It's not the hot new thing that is coming down the 'pike.
All this trying to fix the syntax of Lisp is as if some movie director
saw a modern Audrey Hepburn and sent her off to get a boob job.
--
Fred Gilham ······@csl.sri.com
The great Irish satirist Jonathan Swift once exposed an astrologer by
prophesying his death on a certain date. When the date passed and the
astrologer protested that he was still alive, Swift, refusing to take
his word for it, puckishly accused his survivors of perpetrating a
hoax. --- Joseph Sobran
Fred Gilham wrote:
> >
> > > >
> > > > 3) Use == and = instead zerop and setq. Future LISP?
> > >
> > > Indeed. Arc, the perpetual vaporware project, is going in this direction.
> >
> > And is not good? Lisp already was from early PLUS, TIMES... to modern
> > +, *...
> >
> > Other ideas i read are fn instead lambda, hd and tl instead car and
> > cdr, etc.
>
> I can't believe that someone is actually proposing == and = in this
> day and age. Just the other day we found some code here where the
> programmer had typed == instead of =.
For instance, D. Moon call for using = for declaration, := for
assignment, and == for equality for next lisp.
It appears that Graham want = for assignments.
> hd and tl as replacements for car and cdr are also misguided because
> car and cdr don't operate on lists, but rather on conses, and conses
> don't have a head and a tail. They have a car and a cdr, and these
> are different from a head and a tail.
The suggestion to use hd and tl instead car and cdr on next lisp
becomes from Peter Norvig. Why do not explain to him conses are? :)
I personally will implement head and tail on cnml expressions.
> To me this fizz about changing Lisp's syntax is so misguided. It's a
> mistake to think that the reason people don't use Lisp is that there's
> something wrong with Lisp syntax.
Some statistics supporting your point?
Informal searchs over the internet suggest most people hate about LISP
is not functional approach, dinamical typing, nested lists or others
characteristics but syntax; specially critics are about excessive
number of parentheses and prefix. XML people said me that fiasco of
DSSSL ('nobody' uses) regarding relative popularity of XSLT is because
of syntax. DSSSL uses LISP-like syntax, XSLT is almost an angle
bracketed non prefix version.
They can be either correct or wrong, i am simply noticing people says.
In several internal statistics we detect that nobody want to use prefix
notation but are permissive about parentheses, noticing many of people
prefer [ ] or { } rather than ( ).
> The reason Lisp is not more popular is that Lisp is not fashionable.
> It's not the hot new thing that is coming down the 'pike.
Then Graham -and colleagues- may be in the correct way because Arc is
one "hot new thing" when compared to 'ancient' CL.
Juan R. wrote:
> I personally will implement head and tail on cnml expressions.
Let me clarify -if you did not read me before- that cnml expressions
are not based in LISP conses neither in Moon proposed Arc conses.
Fred Gilham wrote:
>
> I can't believe that someone is actually proposing == and = in this
> day and age. Just the other day we found some code here where the
> programmer had typed == instead of =.
sorry today i am a bit dense. I forget to say you that already exist
very modern [*] dialects of lisp using == for equality and = for
asignment. For instance,
(= factorial (fn (n)
(if (== n 1)
1
(* n (factorial (- n 1))))))
I am not saying that was a good thing or not, simply noticing existence
for you.
[*] http://p-cos.net/lisp-ecoop05/submission/19605.html
"Juan R." <··············@canonicalscience.com> writes:
> Fred Gilham wrote:
>>
>> I can't believe that someone is actually proposing == and = in this
>> day and age. Just the other day we found some code here where the
>> programmer had typed == instead of =.
>
> sorry today i am a bit dense. I forget to say you that already exist
> very modern [*] dialects of lisp using == for equality and = for
> asignment. For instance,
>
> (= factorial (fn (n)
> (if (== n 1)
> 1
> (* n (factorial (- n 1))))))
>
> I am not saying that was a good thing or not, simply noticing existence
> for you.
>
> [*] http://p-cos.net/lisp-ecoop05/submission/19605.html
>
Audrey Hepburn with a boob job. How sad.
--
Fred Gilham ······@csl.sri.com
...every candid Reader will easily understand my Discourse to be
intended only in Defence of *nominal* Christianity, the other having
been for some time wholly laid aside by general Consent, as utterly
inconsistent with all our present Schemes of Wealth and Power.
--- Jonathan Swift
Fred Gilham <······@snapdragon.csl.sri.com> writes:
>
> I can't believe that someone is actually proposing == and = in this
> day and age. Just the other day we found some code here where the
> programmer had typed == instead of =.
In a sane language it doesn't matter: == returns a Boolean; in Python
it's an error to write if x = 0. Now, this would have to be tweaked for
Lisp (Python expressions don't return values, so for Python it's as
simple as if not receiving a Boolean), but the principle stands.
As does the principle that typing (setf var val) is a _lot_ more painful
than var = val, and still more painful than (= var val).
--
Robert Uhl <http://public.xdi.org/=ruhl>
I won't insult your intelligence by suggesting that you really believe
what you just said. --William F. Buckley, Jr.
On Fri, 08 Dec 2006 05:20:19 -0800, Juan R. wrote:
>
> Chris Barts wrote:
>>
>> This statement from the link represents the disconnect we're up against:
>> > But Lisp syntax was designed 50 years ago to make it easy to parse! We
>> > don't have to optimize for this anymore -- it's time to optimize for the
>> > programmer!
>>
>> Macros, man. Macros! Mutate the language into whatever it is you want.
>
> Yeah, the problem is that LISP is different and too many people do not
> notice that.
Indeed. Something else about Lisp that it's difficult to notice from the
outside is that it natively recognizes many different types of equality
and thus has what seems like an embarrassing amount of equality tests.
When I was first learning the language, I was confused about why we need
equal, equalp, eq, and eql.
>> >
>> > 3) Use == and = instead zerop and setq. Future LISP?
>>
>> Indeed. Arc, the perpetual vaporware project, is going in this direction.
>
> And is not good? Lisp already was from early PLUS, TIMES... to modern
> +, *...
I think it is good to some extent. I also think having both = and == in
the same language is the Wrong Thing, and that if you have = for equality
then =: should be used for assignment.
(Of course, the above issue about equality comes up. =: is naturally made
a synonym for setf because setf always Does The Right Thing, even when
faced with complex objects. What function should be shortened to =?)
>
> Other ideas i read are fn instead lambda, hd and tl instead car and
> cdr, etc.
Shortening lambda to fn is uncontroversial and I think the CL standards
committee should have done it. But, as has been said elsewhere, a list
is made of cons cells and car and cdr are functions that work with cons
cells. Plus, experienced programmers can compose car and cdr into
functions with short descriptive names (cadar, cadr, caddr, etc.).
>
>> >
>> > 4) You could omit indentation in LISP because code is small
>>
>> Except experienced Lisp-heads read indentation more than parens.
>
> I know lispers prefer to write linearly for small code, e.g. (* 2 (+ 4
> 8))
This is true, but I, at least, still don't really read parens in that case.
>
>> >
>> > (if (or (> x y) (== a)) (= a1 (+ (* m x) b) (= a2 (- (/ m x) b))
>>
>> I have to count parens to read that. Not fun.
>
> Some fun with a simple (there is several for free) highligt syntax
> editor, wich automatically match parens.
True. Emacs does this and a whole lot of other Lisp-friendly things. But
it's so cheap to correctly indent Lisp code it's simply asocial not to.
>
>> >
>> > you cannot in Python: 6.7%
>>
>> There are ways to obfuscate Python.
>
> Sure, but he focused on terseness and claimed that 33% was too much for
> the example he choosed. The 33% is not correct and with above points,
> you could obtain more power than Python but with less than a 7% more
> typping even in a simple text editor.
Indeed. Especially if you count all of CL's standard functions you have to
import in libraries in Python and all of the functions you have to write
yourself.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Chris Barts <··············@tznvy.pbz> wrote:
+---------------
| Juan R. wrote:
| > Yeah, the problem is that LISP is different and too many people do not
| > notice that.
|
| Indeed. Something else about Lisp that it's difficult to notice from the
| outside is that it natively recognizes many different types of equality
| and thus has what seems like an embarrassing amount of equality tests.
| When I was first learning the language, I was confused about why we need
| equal, equalp, eq, and eql.
+---------------
The best [IMHO] commentary on why the Common Lisp standard does not
provide only one equality test is here:
http://www.nhplace.com/kent/PS/EQUAL.html
It starts by discussing why the Common Lisp standard does not
provide a generic COPY function, and then uses that lemma in
the discussion of EQUAL:
The design issues here are pretty much the same as they are for
COPY. If COPY can't be done properly, then neither can EQUAL. And,
in fact, that's the case. There is no uniquely determined equality
function for complex structures--there are only arbitrary ones.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Chris Barts wrote:
> I think it is good to some extent. I also think having both = and == in
> the same language is the Wrong Thing, and that if you have = for equality
> then =: should be used for assignment.
I think that i agree with you about reusing. Also i consider that usage
for symbols would be close to typical mathematical usage.
> (Of course, the above issue about equality comes up. =: is naturally made
> a synonym for setf because setf always Does The Right Thing, even when
> faced with complex objects. What function should be shortened to =?)
I do not know
>
> Shortening lambda to fn is uncontroversial and I think the CL standards
> committee should have done it. But, as has been said elsewhere, a list
> is made of cons cells and car and cdr are functions that work with cons
> cells.
Would i remark again that hd and tl were proposed by Peter Norvig? I
simply noticed.
> Plus, experienced programmers can compose car and cdr into
> functions with short descriptive names (cadar, cadr, caddr, etc.).
This is a good point. Not sure if contractions like hdtlhd, hdtl,
hdtltl, etc. are more descriptive.
Chris Barts <··············@tznvy.pbz> writes:
>
> Indeed. Especially if you count all of CL's standard functions you
> have to import in libraries in Python and all of the functions you
> have to write yourself.
*boggle*
Which functions, exactly? The standard criticism is that Perl, Python,
Ruby and friends provide functionality that in Lisp one must write for
oneself.
I'll grant that Lisp-the-language is far more powerful than Python (it'd
be pretty daft not to), but Lisp-the-library can't even compare.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Thesaurus: ancient reptile with an excellent vocabulary.
On Tue, 12 Dec 2006 08:40:09 -0700, Robert Uhl wrote:
> Chris Barts <··············@tznvy.pbz> writes:
>>
>> Indeed. Especially if you count all of CL's standard functions you
>> have to import in libraries in Python and all of the functions you
>> have to write yourself.
>
> *boggle*
>
> Which functions, exactly? The standard criticism is that Perl, Python,
> Ruby and friends provide functionality that in Lisp one must write for
> oneself.
Off the top of my head: Most of the MOP (if not all of it), much of the
rest of CLOS, a lot of the list processing functions (mapcars, mapcan,
etc.), and, of course, the entire concept of macros.
>
> I'll grant that Lisp-the-language is far more powerful than Python (it'd
> be pretty daft not to), but Lisp-the-library can't even compare.
Lisp-the-language is pretty much the eval function, the special forms, and
some basic I/O. Everything else is library.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
On 8 Dec 2006 05:20:19 -0800,
"Juan R." <··············@canonicalscience.com> wrote:
>Chris Barts wrote:
>>>
>>> 3) Use == and = instead zerop and setq. Future LISP?
>>
>> Indeed. Arc, the perpetual vaporware project, is going in this direction.
>
> And is not good? Lisp already was from early PLUS, TIMES... to modern
> +, *...
>
> Other ideas i read are fn instead lambda, hd and tl instead car and
> cdr, etc.
Hmmm, short names are ok, but why do we need a new language for that,
since we can already use Lisp?
CL-USER> (defmacro fn (lambda-list &rest body)
`(lambda ,lambda-list ,@body))
FN
CL-USER> (mapcar (fn (x) (+ x 1)) '(1 2 3))
(2 3 4)
Implementing HD and TL as macro-wrappers around CAR and CDR is equally
easy, today, with Lisp.