I've got a problem, I've tried several times to learn lisp, and all of
them I've succeeded, sort of. My background is C, perl, python, and
Java. I have absolutely no problem understanding the syntax and the way
programs are put together in lisp. What I have a problem with is
understanding "lispishness" and how to write in a functional way.
I've read several books, and one of the things that they seem to
criticize most is "writing C in lisp", which to the best of my knowledge
means using all of the old imperative tricks in a functional world where
they're not appropriate. The reason I've been so frustrated with lisp
is that all of my programs appear to me to be in this style, and I'm not
sure how to grok the functional style. I figure that if I'm going to
write C in lisp, then I may as well stick to C and not bother with lisp.
But through some functional things that I have used, I am very anxious
to really understand the core of how lispers do things.
Pretty much the only core "lispish" type of thing that I understand and
use a lot in my programming is map() in perl and python. There are
many, many situations where I want a list of results from a list of
operations, and it just makes more sense than looping over the list with
'for'. And as I understand, this embodies what I'd call lispishness
because it's using the idea of applying functions to values to produce
other values, rather than using the idea of sequential statements and
regular manipulation of data structures, which while simple, seems like
it's at a lower level than it needs to be. So in python for example,
rather than writing:
mylist = [1,2,3,4,5,6,7]
newlist = []
for item in mylist:
newlist.append(item*item)
I write:
def fn(x):
return(x*x)
newlist = map(fn, [1,2,3,4,5,6,7])
I am not interested in fewer lines of code. I am also not interested in
"go ahead, you can write C in lisp, because lisp is powerful enough to
allow you to do that". I'm interested in really understanding the new
paradigm.
I've read books on lisp, and they give code examples, but my core
problem is this. When I sit down and start thinking about a problem, my
mind immediately comes up with a solution that looks great and runs
great in C perl or python. What I need help with is either (1) learning
how to appropriately "translate" that idea or (2) learning how to think
the idea in the functional langauge to start with.
One of the comments that I've heard before was "many an imperative
program was hidden in the let statement" By this I guess they mean that
let is often used as a C prop of "defining all your variables before you
use them" and thus maybe violating the idea that you should have
storage? Is this right?
Does anybody know of any place maybe that has simple programs written in
"C in lisp" and written in "lisp" which could illustrate the difference?
Any help would be appreciated.
Sent via Deja.com
http://www.deja.com/
In article <············@nnrp1.deja.com>, ···········@my-deja.com wrote:
>I've got a problem, I've tried several times to learn lisp, and all of
>them I've succeeded, sort of. My background is C, perl, python, and
>Java. I have absolutely no problem understanding the syntax and the way
>programs are put together in lisp. What I have a problem with is
>understanding "lispishness" and how to write in a functional way.
[snip]
>Does anybody know of any place maybe that has simple programs written in
>"C in lisp" and written in "lisp" which could illustrate the difference?
i don't know of any books that have this parallel structure.
what books have you been using in your study of lisp?
my guess is that you have been using intermediate introductions, i.e.,
books intended for people familiar with other programming languages.
there is a pressure in such books to skip rather quickly to somewhat
"advanced" topics (like iteration and structures) because the author
knows that the reader is probably wondering "when am i gonna see the
lisp way to do the stuff i know how to do in other langauges". in
doing so, these books often skimp on the pages pointing out the
deliciousness of lisp for mundane things -- the anchor for the sense
of lisp style you seek.
my advice would be to start with an absolute beginner's book like
touretzky's "Common Lisp: A Gentle Introduction to Symbolic Computation".
if you start at the beginning and pay attention to the seemingly trivial
subject matter presented first, you will get the subtle instruction you
seek: why there are different equality predictes, the relationship
between EVAL and APPLY, disciplines like dynamic scope that you've
probably not seen before, etc. these discussions are up front, well
before traditional constructs like loops and structures are introduced.
hell, side effects aren't introduced until 130 pages in.
hennessey's "Common Lisp" is also good in this regard. i've not really
looked at winston and horn or "The Little *er" books, but these
might suffice as well.
in general, i would say start with a beginning book and be on the lookout
for differences in topics and order of presentation from analogous books
that introduce procedural programming languages. these differences are
your clues to "the lisp way".
good luck.
sashank
In article <······························@129.59.212.53>,
·············@vanderbilt.edu wrote:
> In article <············@nnrp1.deja.com>, ···········@my-deja.com wrote:
>
>>I've got a problem, I've tried several times to learn lisp, and all of
>>them I've succeeded, sort of. My background is C, perl, python, and
>>Java. I have absolutely no problem understanding the syntax and the way
>>programs are put together in lisp. What I have a problem with is
>>understanding "lispishness" and how to write in a functional way.
> [snip]
>>Does anybody know of any place maybe that has simple programs written in
>>"C in lisp" and written in "lisp" which could illustrate the difference?
>
> i don't know of any books that have this parallel structure.
>
> what books have you been using in your study of lisp?
Cltl2, which is a great reference, but sucks for learning
the language
"Looking at Lisp" by Tony Hasemer
"On Lisp" by Paul Graham
The Harlequin Hyperspec, which suffers the same problem
as Cltl2
> my guess is that you have been using intermediate introductions, i.e.,
> books intended for people familiar with other programming languages.
> there is a pressure in such books to skip rather quickly to somewhat
> "advanced" topics (like iteration and structures) because the author
> knows that the reader is probably wondering "when am i gonna see the
> lisp way to do the stuff i know how to do in other langauges". in doing
> so, these books often skimp on the pages pointing out the deliciousness
> of lisp for mundane things -- the anchor for the sense of lisp style you
> seek.
This is quite possible. I've been programming for
several years, and I'm not sure I want to go back
to "hello world" and madlib type programs in order
to learn a language. So I do tend to say to myself,
"What's the equivalent of fopen() in lisp? How does
the GUI toolkit work?" which may be flying before
I can walk...
> my advice would be to start with an absolute beginner's book like
> touretzky's "Common Lisp: A Gentle Introduction to Symbolic
> Computation". if you start at the beginning and pay attention to the
> seemingly trivial subject matter presented first, you will get the
> subtle instruction you seek: why there are different equality predictes,
> the relationship between EVAL and APPLY, disciplines like dynamic scope
> that you've probably not seen before, etc. these discussions are up
> front, well before traditional constructs like loops and structures are
> introduced. hell, side effects aren't introduced until 130 pages in.
>
> hennessey's "Common Lisp" is also good in this regard. i've not really
> looked at winston and horn or "The Little *er" books, but these might
> suffice as well.
>
> in general, i would say start with a beginning book and be on the
> lookout for differences in topics and order of presentation from
> analogous books that introduce procedural programming languages. these
> differences are your clues to "the lisp way".
Thanks for the suggestions, I will check out these
books. It looks like I may be going back to "hello
world" and madlib type programs after all. :)
How did you learn lisp? Well, actually I shouldn't
ask how you learned it, but how did you come to understand
the way of doing things?
--
David Allen
http://opop.nols.com/
----------------------------------------
People are like onions -- you cut them up, and they make you cry.
In article <·····················@typhoon2.ba-dsg.net>, "David Allen"
<········@titan.vcu.edu> wrote:
[snip]
>Thanks for the suggestions, I will check out these
>books. It looks like I may be going back to "hello
>world" and madlib type programs after all. :)
>
>How did you learn lisp? Well, actually I shouldn't
>ask how you learned it, but how did you come to understand
>the way of doing things?
i learned the wrong way. common lisp was the language used in a computer
science class i took in college called "fundamental structures of computer
science II". the explicit purpose of the class was to continue teaching
data structures and algorithms; the implicit purpose was exposure to a
non-procedural programming language. we were never really taught lisp,
just assigned CLtL along with the algorithms/data structures text.
you think i'm joking? i'm not.
i knew immediately that i loved lisp, so i guess i didn't really mind the
macho bullshit way i initially learned the language. of course, i imported
all of my assumptions about pascal and modula-2 into lisp. my first
programming job was in college, working on an existing franz lisp
application. there were all sorts of arcana involved, and my model of
how common lisp works was further polluted from this experience.
coming out of college, then, my knowledge of lisp was a mixture of what
i had gleaned from CLtL (essentially, an interactive procedural language
with a kick-ass library) and the bag of tricks of a franz lisp junkie.
it was then that i got my first job programming common lisp. there was
a programmer there who clued me into the richness of the lisp way in
generally and common lisp in particular. he was the first guy i saw
write real macros to extend the syntax. he knew CLOS cold (this was
in 1991) and seemed to derive great power from it. (or was that power
inherited?) he would often use sequences where i would use lists...i
began to wonder why.
aware there was stuff i needed to know, i decided to take a step
back. i read touretzky's book. i was shocked to find that while i
had mastered the stuff in the later chapters (e.g., the various forms
of DO for iteration, hash tables), i never really grokked the implications
of the variuous scope disciplines, the differences between EVAL and APPLY,
etc. i then read hennessey's book, which is faster-paced and includes
nice chapters on lisp style (e.g., data-driven programming) and compilation.
this remedial work made it all come together for me. i went on to
devour keene's book on CLOS and SICP next, and then PAIP and graham's
"on lisp" after they were published. now, don't get me wrong -- there's
a lot i don't know. the posts of kent, erik, barry, pierre, tim, joe,
duane, rainer, etc., in this forum constantly reveal stuff i didn't know.
but the foundation i built when putting in the remedial work has so far
been general enough that i can follow their thoughts.
so, if you're anything like me, this grunt work may be what it takes
for you as well.
sashank
In article <················@naggum.net>, "Erik Naggum" <····@naggum.net>
wrote:
> * "David Allen" <········@titan.vcu.edu>
> | Cltl2, which is a great reference, but sucks for learning the language
>
> I disagree. Some people learn quickly and correctly from references
> and languages specifications material, and they will find both CLtL
> and CLtL2 and CLtS (Standard) truly excellent. Some people do not
> seem able to read a specification even when they supposedly know the
> material well, and they may need hand-holding tutorials. Recognizing
> this difference between people is quite important when giving advice
> about literature.
Well, what I mean by "learn the language" is not strictly
how to program lisp. I'm talking about how to think
in lisp. I learned perl and python from reference
materials, but reference materials (or the way I
seem to use them) do not encourage learning how to
think in the language in question, they encourage
finding language equivalents. (Like "what's fopen()
in lisp?") If I had come into reading Cltl2 as a
fuctional programmer, I would have been much more happy
with it. Reading it, I felt like I was learning
lisp, but that I was learning how to write C in lisp.
> | So I do tend to say to myself, "What's the equivalent of fopen() in
> lisp?
> | How does the GUI toolkit work?" which may be flying before I can
> walk...
>
> Worse, you never learn a new language if you do this, unfortunately.
> It is quite common among pragmatically inclined people to build their
> knowledge in one area slowly and with great effort, only to turn
> around and expect the next area to be basically free, that they can
> use all their extant concepts directly in whatever new language they
> are using. But whence did those concepts come? Clearly, they were not
> innate! I compare this approach to languages to walking into a
> grocery store in a foreign country expecting to find exactly the same
> products as you're used to at home, only with different brand names.
> (If you have not been abroad, this analogy may not work for you, but
> then you'll get all the more surprised when you do.)
I can agree with this. I think a lot of people
get a false feeling for exactly what percentage of
their knowledge is portable from one area of application
to the next.
> | It looks like I may be going back to "hello world" and madlib type
> | programs after all. :)
>
> I think it would be useful to find books for experienced programmers
> in language X who wish to learn language Y. It is incredibly annoying
> to have to work through hundreds of pages of trivia to get the basics
> when it could be explained in a few pages.
That's what I was referring to when I said that I'd
love to have a book that wrote a few programs in
C or java, and then said "Now here's how we might
approach this in lisp..." There are some immediate
things that pop out in code that I've seen, like
the extensive use of cover procedures rather than
iterators. (i.e. rather than providing functions
to get the next item in some conglomeration, you pass
a function and the module that owns the data does
the iteration (or recursion as the (case (may) be)) for
you)
--
David Allen
http://opop.nols.com/
----------------------------------------
I don't know half of you half as well as I should like; and I like less
than half of you half as well as you deserve.
-- J. R. R. Tolkien
>>>>> "David" == David Allen <········@titan.vcu.edu> writes:
David> In article <······························@129.59.212.53>,
David> ·············@vanderbilt.edu wrote:
>> In article <············@nnrp1.deja.com>,
>> ···········@my-deja.com wrote:
>> what books have you been using in your study of lisp?
David> Cltl2, which is a great reference, but sucks for learning the
David> language
David> "Looking at Lisp" by Tony Hasemer
David> "On Lisp" by Paul Graham
David> The Harlequin Hyperspec, which suffers the same problem as
David> Cltl2
Of these, I'm not familiar with "Looking at Lisp."
There is a parallel to be drawn; CLTL2 and the HyperSpec are somewhat
like the traditional Unix manual pages: They're sometimes terse,
aren't particularly directed to the task of presenting the system in a
"pedagogical" way, and don't have all the examples people might want.
[And have bits of quirky humour here and there...] People "bash" them
as being inappropriate to try to learn from.
And those that become "gurus" in Lisp and Unix realms probably _did_
use them as their primary learning references :-).
You almost certainly should add to the list of options Peter Norvig's
"Paradigms of Artificial Intelligence Programming: Case Studies in
Common Lisp" <http://www.norvig.com/paip.html>. It focuses _largely_
on AI applications, which may not necessarily be your cup of tea; the
crucial/unique value of it is in presenting Common Lisp programs of
significant size and complexity.
--
(reverse (concatenate 'string ····················@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
Attention Spam: The amount of time it takes to determine that a piece
of email is not worth reading.
···········@my-deja.com writes:
>I've got a problem, I've tried several times to learn lisp, and all of
>them I've succeeded, sort of. My background is C, perl, python, and
>Java. I have absolutely no problem understanding the syntax and the way
>programs are put together in lisp. What I have a problem with is
>understanding "lispishness" and how to write in a functional way.
The last sentense seems to show the problem: it is not typical for a
Lisp program to be written following a more or less "purely
functional" paradigm.
In fact, most big Lisp systems are Object-Oriented and Lisp also has a
larger followship of people writing in a "memory-oriented" way (in
lack of a better term).
If there's anything typical for a person approaching a problem in
Lisp, then it is that comparably few consideration is given to
paradigms at all.
>I've read several books, and one of the things that they seem to
>criticize most is "writing C in lisp", which to the best of my knowledge
>means using all of the old imperative tricks in a functional world where
>they're not appropriate.
You can use Lisp to program in a memory-oriented way with preallocated
buffers and all.
This is not "bad" as such. Such a programming style can and will be
neccessary for performance. Still, if you use this brute-force style
in Lisp, you can use Lisp constructs to make it safer and easier to
maintain than in C.
>The reason I've been so frustrated with lisp
>is that all of my programs appear to me to be in this style, and I'm not
>sure how to grok the functional style. I figure that if I'm going to
>write C in lisp, then I may as well stick to C and not bother with lisp.
> But through some functional things that I have used, I am very anxious
>to really understand the core of how lispers do things.
As I said, your assumptions are wrong and there the confusion is not
surprising.
[...]
>I've read books on lisp, and they give code examples, but my core
>problem is this. When I sit down and start thinking about a problem, my
>mind immediately comes up with a solution that looks great and runs
>great in C perl or python. What I need help with is either (1) learning
>how to appropriately "translate" that idea or (2) learning how to think
>the idea in the functional langauge to start with.
If you really want a functional style very seperate from C, work
through SICP. It's Scheme-based, though.
In you think of a solution, they why do you care that it looks like a
"C" solution? Is there anything in it that makes it a "bad" solution?
That's the question. If it is a very direct solution or oriented
around data manipulation, it may very well be a good solution and you
can use Lisp to implement is cleaner, without having a mental problem
with not following paradigm X.
It is always a good idea to widen your mind by reading SICP and the
other Lisp classics, but don't expect your mental way of approaching
programming solutions to turn backwards. Expect tuning.
Besides, if you are already an experienced programmer, there is a good
chance that your way of thinking just fits the tasks you have to do.
>One of the comments that I've heard before was "many an imperative
>program was hidden in the let statement" By this I guess they mean that
>let is often used as a C prop of "defining all your variables before you
>use them" and thus maybe violating the idea that you should have
>storage? Is this right?
No, I think it's nonsense.
>Does anybody know of any place maybe that has simple programs written in
>"C in lisp" and written in "lisp" which could illustrate the difference?
I can't. Since many of my Lisp programs would not fit your apparent
definition of "Lispy" programs.
Or maybe you would consider my C programs to be lisp-like. Function
pointers, dynamically loaded (and sometimes compiled) code and macros
expanding abstract definitions to structs and struct manipulating
functions are common in my C programs as well.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Martin Cracauer <········@counter.bik-gmbh.de> wrote
>
> If you really want a functional style very seperate from C, work
> through SICP. It's Scheme-based, though.
I've been working with SICP. I find it interesting, but I also keep drawing
parallels to what
I am familiar with. The dispatch mechanism reminds me of a C++ vtable, and
some of the
techniques to store data in lists strikes me as clumsy.
I'm enjoying the different perspectives, but I would have to admit I haven't
seen a compelling
reason to use Lisp, Scheme, ML etc. I can justify Forth, another language I
am familiar with,
as I can use that with everything from an 8051 on up. Perhaps if I had been
exposed to a
functional language earlier, it would be easier.
"bowman" <······@montana.com> writes:
> I'm enjoying the different perspectives, but I would have to admit I
> haven't seen a compelling reason to use Lisp, Scheme, ML etc. I can
> justify Forth, another language I am familiar with, as I can use
> that with everything from an 8051 on up. Perhaps if I had been
> exposed to a functional language earlier, it would be easier.
If you're only looking at Lisp's "functional" aspect, I think you're missing
most of it. If it's functional you want, you should use Scheme. But I
don't recommend that approach.
The main reason I come back to Lisp over and over is its syntactic flexibility.
All the other stuff I can get in other languages, but the one thing I can't
easily get is the ability to make the language look like what I'm programming
about rather than having it look like yet another program in the same old fixed
syntax offered by most languages.
Scheme has a macro facility, but because it is pattern-matcher driven I don't
see it used to do the kind of really complex rewrites that Lisp is famous
for. And mostly Scheme people don't use macros heavily.
An example of what I mean by being able to change the "look" of the language
is the stupid little foothold piece of code you have to incant in just about
every language when you want to talk CORBA or RMI or any similar thing.
There's a standard 5 line incantation that involves getting ahold of a server,
making a thing that gets you back a general purpose object, after getting back
the object of general kind, casting it to a more specific kind and then finally
putting it into a typed variable of the appropriate kind. It can't be
contracted to anything much smaller in Java because there is no macro facility.
In C or C++, it could be contracted but often is not done that way.
In Lisp, things you get tired of routinely get macrofied for easier use, and
when you get tired of those, you macrofy those, and so on up the ladder,
always keeping the focus on what you want to be programming.
If you're focused on making it look "lispy", IMO, you're off track. The
real lisp programs I have any respect for look like their "application
domain", not like other programs in the language--unless those programs
happen to be about the same domain.
Lisp is a language for the efficient creation and use of jargon. Not
just nouns but jargon-syntax.
Functional programming is only a tiny corner of Lisp.
Kent M Pitman <······@world.std.com> wrote:
+---------------
| Scheme has a macro facility, but because it is pattern-matcher driven I
| don't see it used to do the kind of really complex rewrites that Lisp is
| famous for. And mostly Scheme people don't use macros heavily.
+---------------
Well, I do, but *not* the syntax-rules macros, I'm afraid. (*blush*)
I stubbornly continue to use plain ol' defmacro, which exists (or can
be defined trivially) in every Scheme implementation I care about.
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Kent M Pitman <······@world.std.com> wrote:
> +---------------
> | Scheme has a macro facility, but because it is pattern-matcher driven I
> | don't see it used to do the kind of really complex rewrites that Lisp is
> | famous for. And mostly Scheme people don't use macros heavily.
> +---------------
>
> Well, I do, but *not* the syntax-rules macros, I'm afraid. (*blush*)
> I stubbornly continue to use plain ol' defmacro, which exists (or can
> be defined trivially) in every Scheme implementation I care about.
But it ain't in R^nRS :) I'm not Naggum, but I can be Naggin' :)
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Kent M Pitman <······@world.std.com> wrote:
> +---------------
> | Scheme has a macro facility, but because it is pattern-matcher driven I
> | don't see it used to do the kind of really complex rewrites that Lisp is
> | famous for. And mostly Scheme people don't use macros heavily.
> +---------------
>
> Well, I do, but *not* the syntax-rules macros, I'm afraid. (*blush*)
> I stubbornly continue to use plain ol' defmacro, which exists (or can
> be defined trivially) in every Scheme implementation I care about.
Actually, I invented (but never published) and then later someone else
(Alan Bawden?) re-invented a paradigm for doing defmacro-style macros in
Scheme in a way that was both hygeinic and powerful. But for some reason
the other mechanism (Kohlbecker's?) involving mere substitution was adopted
by the Scheme community. I never understood how this happened, even though
I was there to watch it. Bleah. I believe the competing theory was called
"syntactic closures", btw.
Kent M Pitman <······@world.std.com> wrote:
+---------------
| Actually, I invented (but never published) and then later someone else
| (Alan Bawden?) re-invented a paradigm for doing defmacro-style macros in
| Scheme in a way that was both hygeinic and powerful. ... I believe the
| competing theory [competing with Kohlbecker/syntax-rules] was called
| "syntactic closures", btw.
+---------------
Are you thinking of Chris Hanson maybe? If so, there's an implementation
in SLIB (incl. documentation and comparison/contrast with syntax-rules):
<URL:http://www-swiss.ai.mit.edu/~jaffer/slib_2.html#SEC23>
-Rob
-----
Rob Warnock, 31-2-510 ····@sgi.com
SGI Network Engineering http://reality.sgi.com/rpw3/
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
····@rigden.engr.sgi.com (Rob Warnock) writes:
> Kent M Pitman <······@world.std.com> wrote:
> +---------------
> | Actually, I invented (but never published) and then later someone else
> | (Alan Bawden?) re-invented a paradigm for doing defmacro-style macros in
> | Scheme in a way that was both hygeinic and powerful. ... I believe the
> | competing theory [competing with Kohlbecker/syntax-rules] was called
> | "syntactic closures", btw.
> +---------------
>
> Are you thinking of Chris Hanson maybe? If so, there's an implementation
> in SLIB (incl. documentation and comparison/contrast with syntax-rules):
>
> <URL:http://www-swiss.ai.mit.edu/~jaffer/slib_2.html#SEC23>
>
>
> -Rob
From the end of that cited section:
Acknowledgements
The syntactic closures facility was invented by Alan Bawden and
Jonathan Rees. The use of aliases to implement syntax-rules was
invented by Alan Bawden (who prefers to call them synthetic
names). Much of this proposal is derived from an earlier proposal by
Alan Bawden.
Nicolas.
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> "bowman" <······@montana.com> writes:
>
> > I'm enjoying the different perspectives, but I would have to admit I
> > haven't seen a compelling reason to use Lisp, Scheme, ML etc. I can
> > justify Forth, another language I am familiar with, as I can use
> > that with everything from an 8051 on up. Perhaps if I had been
> > exposed to a functional language earlier, it would be easier.
>
> If you're only looking at Lisp's "functional" aspect, I think you're missing
> most of it. If it's functional you want, you should use Scheme. But I
> don't recommend that approach.
I disagree. The functional approach is cool. CL should support
tail-recursion elimination, curry (or was it sch�nfinkel?), etc.
> Scheme has a macro facility, but because it is pattern-matcher driven I don't
> see it used to do the kind of really complex rewrites that Lisp is famous
> for. And mostly Scheme people don't use macros heavily.
I agree. Standard Scheme macros are mostly useless. Common Lisp macros
are much more power- and useful.
> Functional programming is only a tiny corner of Lisp.
(defun bar (stream) something...)
As much as I agree, I don't see a reason to prefer
(with-open-file (foo "pathname")
(bar foo))
over
(invoke-with-open-file "pathname" bar)
Do you?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <···············@world.std.com>, Kent M Pitman
> <······@world.std.com> wrote:
> > If you're only looking at Lisp's "functional" aspect, I think
> > you're missing most of it. If it's functional you want, you
> > should use Scheme. But I don't recommend that approach.
>
> I disagree. The functional approach is cool. CL should support
> tail-recursion elimination, curry (or was it sch�nfinkel?), etc.
To clarify, I wasn't saying that any functional capability of Scheme shouldn't
be supported. What I was saying is that the purpose of Scheme is to support
functional programming, while the purpose of CL is not. The purpose of CL --
that is, the political constituency to which CL caters -- is the community of
people who want to integrate various styles, or who want to work with people
who have different styles. The Scheme political constituency appears to me
to eschew people with a different mindset than their own, for better or worse.
Anyone who wants to make Functional Programming their religious way of life is,
IMO, better among the Scheme community. Anyone who merely wants to sometimes
use functional programming, but wants to reserve the right to use other styles
or to interoperate casually with people who use other styles, is, IMO, better
off in CL. Obviously, reasonable people can differ on my claim about CL.
That only confirms my point--we're a community of people who differ. For the
most part, I don't think most people disagree with my characterization of
Scheme, and I think mostly because that community attracts/produces/tolerates
a more homogenous mindset.
> > [...] Functional programming is only a tiny corner of Lisp.
>
> (defun bar (stream) something...)
>
> As much as I agree, I don't see a reason to prefer
>
> (with-open-file (foo "pathname")
> (bar foo))
> over
>
> (invoke-with-open-file "pathname" bar)
>
> Do you?
Yes, I do. Indentation. This is another place that I think Scheme seriously
loses. They worry to death about functional aesthetics and care not a bit
about syntactic aesthetics. with-open-file has the important characteristic
that it increases the indentation level only two spaces. invoke-with-open-file
increases it enormously. Even if you imagined (falsely) that people routinely
customized the indenter to indent things like
(invoke-with-open-file "pathname"
bar)
You still have the problem that if you want to open up bar inline, you end
up with
(invoke-with-open-file "pathname"
(lambda (stream)
...))
and a minimum of 1 wasted horizontal line and 2 wasted columns.
Individually, these little things might seem to matter very little, but
collectively they add up to a lot more code per screen in perfectly legible
form. I find that Scheme wastes my time a lot, much like Java, in terms of
requiring me to write useless syntax to accomplish basic primitive operations.
Yes, I could write macros to get around that, but my point about Lisp is
that the language primitively accomodates this notion of aesthetics.
And I do so tire of being beaten up by Scheme folks on the issue of aesthetics,
as if it's a lemma that Scheme always trumps CL on aesthetics. It does not.
It merely adopts an overly simplistic notion of what is aesthetic and then
proceeds to "win" arguments by shamelessly insisting that others should
believe the same impoverished aesthetic model.
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
> functional programming, while the purpose of CL is not.
I was under the impression that CL should atleast
**support** Functional Programming - but not
enforce it. That's how I see it.
> > (defun bar (stream) something...)
> >
> > As much as I agree, I don't see a reason to prefer
> >
> > (with-open-file (foo "pathname")
> > (bar foo))
> > over
> >
> > (invoke-with-open-file "pathname" bar)
> >
> > Do you?
>
> Yes, I do. Indentation.
This is a minor point for me in this case.
(invoke-with-open-file
"pathname"
bar)
Is fine for me.
> form. I find that Scheme wastes my time a lot, much like Java, in terms of
> requiring me to write useless syntax to accomplish basic primitive operations.
Hmm, I really can't follow this. Actually I think FP
saves me time a lot, just because the basic building blocks
are easily combinable.
The macro approach to WITH-OPEN-FILE seems to have some negative
side points:
- it's a macro, so it can't be FUNCALLed
- it makes debugging harder. Compiled code won't show
WITH-OPEN-FILE in the debugger
- it duplicates code (if you want that you could use
INLINEd functions)
I'm open to the non-FP side of Lisp (I'm also guilty of writing
some Macro-generating Macros sometimes). But the FP side
gives me:
- building blocks. A function is a building block with defined
INPUT (parameters) and OUTPUT (results).
- recombination of building blocks (function
application, composition, higher order functions, closures, ...)
- a relatively clean mental model to understand the
relationship between written and running code
Sent via Deja.com
http://www.deja.com/
Hello!
In article <············@nnrp1.deja.com>,
<······@corporate-world.lisp.de> wrote:
>[...]
>This is a minor point for me in this case.
>(invoke-with-open-file
> "pathname"
> bar)
>Is fine for me.
Okay.
(defun invoke-with-open-file (filename func)
(with-open-file (handle filename) (funcall func handle)))
>[...]
Kind regards,
Hannah.
······@schlund.de (Hannah Schroeter) writes:
> Hello!
>
> In article <············@nnrp1.deja.com>,
> <······@corporate-world.lisp.de> wrote:
> >[...]
>
> >This is a minor point for me in this case.
>
> >(invoke-with-open-file
> > "pathname"
> > bar)
>
> >Is fine for me.
>
> Okay.
>
> (defun invoke-with-open-file (filename func)
> (with-open-file (handle filename) (funcall func handle)))
I usually do it the other way around. Almost all WITH-xxx macros I write
look like:
(defmacro with-whatever ((quality1 quality2 ...) &body forms)
`(call-with-whatever ,quality1 ,quality2 ... #'(lambda () ,@forms)))
(defun call-with-whatever (quality1 quality2 ... fn)
(bind-some-state (...quality1 quality2 ...)
(funcall fn)))
In this way, the thing is on the stack. I think having the pair of the
function and macro accessible at once is good, but I still 99% of the time
prefer to use the macro.
- - - - -
Btw, if I get *really* ambitious, I write
(defmacro with-whatever ((quality1 quality2 ...) &body forms)
(let ((temp (gensym)))
`(flet ((,temp () ,@forms))
(declare (dynamic-extent #',temp))
(call-with-whatever ,quality1 ,quality2 ... ,temp))))
but mostly I don't find this cons savings is worth the time it takes
to write except for things in inner loops. Once in a while I've macrofied
this trick to avoid my need to write it out longhand.
- - - - -
But on the point of functional vs not, it's important to understand that
whether call-with-whatever or with-whatever is primitive is just a matter
of conceptual perspective, or sometimes an accident of implementation.
One ought not fight over whether either of these ought be the only one present
or whether some system is too weak to have both. Both Scheme and Lisp can
accomodate both, but as a matter of practice Lisp doesn't export the
call-with-xxx primitives and Scheme doesn't export the with-xxx primitives.
(Then, Scheme confusingly renames the call-with-xxx primitives to with-xxx,
which I find to be an English grammatical error because the function itself,
but that's another story.) It's plain that the Scheme style is defaultly
functional and the Lisp style is not, even though both can accomodate either
style. The question "which is better?" can't be taken as a question of
"computational power" since both are turing equivalent. The question
"which is better?" has to mean "which is the most convenient notation to
use a priori, regardless of other issues, since those "other issues" always
have answers". Personally, for me, and it is a personal decision, the
with-xxx macros are just 100% superior. Going down Rainer's list of
"negatives":
RJ> - it's a macro, so it can't be FUNCALLed
but it can be inlined. and 99% of the time I don't need to funcall it.
I almost always produce that call-with-xxx function just in case and yet I
have never found occasion to use it (other than implicitly I do use the fact
that it makes it easier to patch the macro atomically by simply replacing the
call-with-xxx function, but that would happen even if the name were not
exported).
RJ> - it makes debugging harder. Compiled code won't show
RJ> WITH-OPEN-FILE in the debugger
compiled code shows the call-with-xxx function in many cases. But I just
can't ever remember the absence of such a thing on the stack being an
impediment, so I don't recall debugging ever having been harder. Just
personal experience, though; your mileage may vary.
RJ> - it duplicates code (if you want that you could use
RJ> INLINEd functions)
It only duplicates code if you don't use the call-with-xxx strategy. But
for a lot of cases, the duplicated code cost is negligible.
RJ> I'm open to the non-FP side of Lisp (I'm also guilty of writing
RJ> some Macro-generating Macros sometimes). But the FP side
RJ> gives me:
RJ>
RJ> - building blocks. A function is a building block with defined
RJ> INPUT (parameters) and OUTPUT (results).
RJ> - recombination of building blocks (function
RJ> application, composition, higher order functions, closures, ...)
Just as a statistical observation, I don't find that I ever build much out
of the things that I write with-xxx macros such that this distinction
matters. Probably because of the other dataflow issues, I don't find
myself ever mapping such functions, for example.
RJ> - a relatively clean mental model to understand the
RJ> relationship between written and running code
I don't find anything unclean about understanding with-xxx macros.
Kent M Pitman <······@world.std.com> writes:
> I usually do it the other way around. Almost all WITH-xxx macros I write
> look like:
>
> (defmacro with-whatever ((quality1 quality2 ...) &body forms)
> `(call-with-whatever ,quality1 ,quality2 ... #'(lambda () ,@forms)))
>
> (defun call-with-whatever (quality1 quality2 ... fn)
> (bind-some-state (...quality1 quality2 ...)
> (funcall fn)))
>
> In this way, the thing is on the stack. I think having the pair of the
> function and macro accessible at once is good, but I still 99% of the time
> prefer to use the macro.
Having the function is useful if you wish add advice, trace, or
redefine the macro. If it is used extensively, you can save a lot of
recompilation time when you change it.
It also allows you to have `conditional wrappers', which on the very
rare occasion come in handy:
(funcall
(if (need-wrapper-p)
#'call-with-wrapper
#'funcall)
#'(lambda ()
...some sort of body...))
For example, suppose you have a `single threaded' and `multi
threaded' mode. Your need-whatever-p would determine which mode is
selected, and the call-with-whatever would spawn a thread for
evaluating the thunk. But if you switched to single threaded, you
would simply funcall the thunk in the current thread.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Joe Marshall <···@content-integrity.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > I usually do it the other way around. Almost all WITH-xxx macros I write
> > look like:
> >
> > (defmacro with-whatever ((quality1 quality2 ...) &body forms)
> > `(call-with-whatever ,quality1 ,quality2 ... #'(lambda () ,@forms)))
> >
> > (defun call-with-whatever (quality1 quality2 ... fn)
> > (bind-some-state (...quality1 quality2 ...)
> > (funcall fn)))
> >
> > In this way, the thing is on the stack. I think having the pair of the
> > function and macro accessible at once is good, but I still 99% of the time
> > prefer to use the macro.
>
> Having the function is useful if you wish add advice, trace, or
> redefine the macro. If it is used extensively, you can save a lot of
> recompilation time when you change it.
Yes... but...
Now you have INVOKE-WITH-OPEN-FILE
(invoke-with-open-file filename (lambda (stream) <stuff>))
What happens if the file does not exist? Well you can write a new
function
(define (invoke-with-checked-open-file file forms if-does-not-exist-form)
...)
Of course, you have to decide whether you are opening the file for
writing or reading, so you have
(define (invoke-with-checked-open-file-for-reading file forms if-does-not-exist-form)
...)
Suppose you call the function to write a file and then ask yourself
what to do if the file already exists.
Shall I go on?
The bottom line is that WITH-OPEN-FILE does pretty much the right
thing here. Even better than
FileReader r;
try {
r = new FileReader(...);
...
} catch (java.io.IOException ioe) {
r.close();
}
while in Scheme (we are talking about that, aren't we?) you do not
even have keywords arguments to help you out in writing a decent
functional interface.
(defun invoke-with-open-file (file handler
&key
(if-exists :supersede)
(if-does-not-exist :create)
(:direction :input)
...)
(with-open-file (f file #| you know what goes here |#)
(funcall handler f)))
For every problem there is a solution that is pretty, simple, fast and
wrong.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Joe Marshall <···@content-integrity.com> writes:
> > Having the function is useful if you wish add advice, trace, or
> > redefine the macro. If it is used extensively, you can save a lot of
> > recompilation time when you change it.
>
> Yes... but...
>
[various variations on invoke-with-open-file elided]
> while in Scheme (we are talking about that, aren't we?) ...
Actually I wasn't talking about Scheme. I was just mentioning that
having WITH-MUMBLE-FROTZ macros expand into a call to
CALL-WITH-MUMBLE-FROTZ has certain benefits in a Common Lisp program.
> you do not even have keywords arguments to help you out in writing a
> decent functional interface.
Keyword args are a good example of one of those things that are
`unclean' but really nice to have.
> For every problem there is a solution that is pretty, simple, fast and
> wrong.
As in `pretty simple', or `pretty fast', or `simply wrong'?
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Joe Marshall <···@content-integrity.com> writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
>
> > For every problem there is a solution that is pretty, simple, fast and
> > wrong.
>
> As in `pretty simple', or `pretty fast', or `simply wrong'?
>
Pretty as in "Cute" :)
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Hello!
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
>······@schlund.de (Hannah Schroeter) writes:
>[...]
>> (defun invoke-with-open-file (filename func)
>> (with-open-file (handle filename) (funcall func handle)))
>I usually do it the other way around. Almost all WITH-xxx macros I write
>look like:
> (defmacro with-whatever ((quality1 quality2 ...) &body forms)
> `(call-with-whatever ,quality1 ,quality2 ... #'(lambda () ,@forms)))
> (defun call-with-whatever (quality1 quality2 ... fn)
> (bind-some-state (...quality1 quality2 ...)
> (funcall fn)))
>In this way, the thing is on the stack. I think having the pair of the
>function and macro accessible at once is good, but I still 99% of the time
>prefer to use the macro.
It seems the difference between with-foo as primitive vs call-with-foo
as primitive is a matter of taste. However, the original poster
complained about the absense of (concretely!) call-with-open-file.
In that case, I'd just pragmatically choose with-open-file as primitive,
as it's provided by the CL standard and the implementations thereof.
Kind regards,
Hannah.
PS: As I learnt to know more purely functional languages such as Haskell,
I tend to place both Scheme and Lisp into other places. Scheme
is (matter of taste) either combined functional/imperative or
impure functional; CL is definitely multiparadigm imperative/OO/functional/
metaprogramming. Scheme culture seems to emphasize the functional part
of Scheme's nature a bit more than CL culture does to the functional
part of CL's nature.
In article <············@c3po.schlund.de>,
······@schlund.de (Hannah Schroeter) writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
>>······@schlund.de (Hannah Schroeter) writes:
>>I usually do it the other way around. Almost all WITH-xxx macros I write
>>look like:
>
>> (defmacro with-whatever ((quality1 quality2 ...) &body forms)
>> `(call-with-whatever ,quality1 ,quality2 ... #'(lambda () ,@forms)))
>
>> (defun call-with-whatever (quality1 quality2 ... fn)
>> (bind-some-state (...quality1 quality2 ...)
>> (funcall fn)))
>
>>In this way, the thing is on the stack. I think having the pair of the
>>function and macro accessible at once is good, but I still 99% of the time
>>prefer to use the macro.
>
> It seems the difference between with-foo as primitive vs call-with-foo
> as primitive is a matter of taste.
To me, the whole point of having a primitive call-with-whatever is to make
it a generic function. Then people can do :before and :after on it. I could
never figure out what having a plain function call-with-whatever bought you.
Mike McDonald
·······@mikemac.com
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> I usually do it the other way around. Almost all WITH-xxx macros I write
> look like:
>
> (defmacro with-whatever ((quality1 quality2 ...) &body forms)
> `(call-with-whatever ,quality1 ,quality2 ... #'(lambda () ,@forms)))
>
> (defun call-with-whatever (quality1 quality2 ... fn)
> (bind-some-state (...quality1 quality2 ...)
> (funcall fn)))
Something like that usually makes sense. The CALL-WITH-WHATEVER
provides the implementation and the WITH-WHATEVER supports
the most used usage patterns.
> RJ> - it's a macro, so it can't be FUNCALLed
>
> but it can be inlined.
And it will be inlined. Which makes patching and redefinition
hard.
> RJ> - it makes debugging harder. Compiled code won't show
> RJ> WITH-OPEN-FILE in the debugger
>
> compiled code shows the call-with-xxx function in many cases. But I just
> can't ever remember the absence of such a thing on the stack being an
> impediment, so I don't recall debugging ever having been harder. Just
> personal experience, though; your mileage may vary.
If you have the right tool, debugging is possible. But I've
seen some really large macros (with symbol-macros, local
macrolets and the like) that are hard to debug for
the unexperienced - additionally some people writing
macros are barely checking the input to the macro.
My horror macro is CLIM:DEFINE-APPLICATION-FRAME .
> RJ> - it duplicates code (if you want that you could use
> RJ> INLINEd functions)
>
> It only duplicates code if you don't use the call-with-xxx strategy. But
> for a lot of cases, the duplicated code cost is negligible.
I'm not sure about that. If you use such a style system-wide, it
adds up. For many task (say a UI lib) the function call
may save code size and processor cache space.
> RJ> - a relatively clean mental model to understand the
> RJ> relationship between written and running code
>
> I don't find anything unclean about understanding with-xxx macros.
Not understanding the macros, but the mapping from macros
to code. One needs to understand the transformation
process and the generated code.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> > RJ> - a relatively clean mental model to understand the
> > RJ> relationship between written and running code
> >
> > I don't find anything unclean about understanding with-xxx macros.
>
> Not understanding the macros, but the mapping from macros
> to code. One needs to understand the transformation
> process and the generated code.
I'm not sure I understand what you're saying without an example. Can
you provide one for the sake of conversational context?
On Thu, 11 Jan 2001 19:40:10 GMT, Kent M Pitman <······@world.std.com>
wrote:
> or whether some system is too weak to have both. Both Scheme and Lisp can
> accomodate both, but as a matter of practice Lisp doesn't export the
> call-with-xxx primitives and Scheme doesn't export the with-xxx primitives.
If understand things right, CLIM is among the exceptions with its WITH-XXX
and INVOKE-WITH-XXX. I specifically refer to the convention illustrated in
section 2.9 "Macros that Expand into Calls to Advertised Functions" of the
CLIM II specification (May 10, 1994). Here is the example mentioned in that
section:
(defgeneric invoke-with-drawing-options (medium continuation &key)
(declare (dynamic-extent continuation)))
(defmacro with-drawing-options ((medium &rest drawing-options) &body body)
`(flet ((with-drawing-options-body (,medium) ,@body))
(declare (dynamic-extent #'with-drawing-options-body))
(invoke-with-drawing-options
,medium #'with-drawing-options-body ,@drawing-options)))
(defmethod invoke-with-drawing-options
((medium clx-display-medium) continuation &rest drawing-options)
(with-drawing-options-merged-into-medium (medium drawing-options)
(funcall continuation medium)))
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
In article <············@c3po.schlund.de>, ······@schlund.de (Hannah
Schroeter) wrote:
> Hello!
>
> In article <············@nnrp1.deja.com>,
> <······@corporate-world.lisp.de> wrote:
> >[...]
>
> >This is a minor point for me in this case.
>
> >(invoke-with-open-file
> > "pathname"
> > bar)
>
> >Is fine for me.
>
> Okay.
>
> (defun invoke-with-open-file (filename func)
> (with-open-file (handle filename) (funcall func handle)))
Sure, but them I'd like also the options to appear
in INVOKE-WITH-OPEN-FILE. It is not that I'm
too stupid to write it - it is a library design
issue.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
>>>>> "joswig" == joswig <······@corporate-world.lisp.de> writes:
joswig> In article <···············@world.std.com>, Kent M Pitman
joswig> <······@world.std.com> wrote:
>> functional programming, while the purpose of CL is not.
joswig> I was under the impression that CL should atleast
joswig> **support** Functional Programming - but not enforce
joswig> it. That's how I see it.
>>> (defun bar (stream) something...) As much as I agree, I don't see
>>> a reason to prefer (with-open-file (foo "pathname") (bar foo))
>>> over (invoke-with-open-file "pathname" bar) Do you?
joswig> (invoke-with-open-file "pathname" bar) is fine for me.
joswig> The macro approach to WITH-OPEN-FILE seems to have some
joswig> negative side points:
joswig> - it's a macro, so it can't be FUNCALLed
Indeed.
I find myself in a situation where I'd like to open a bunch of files
and
(apply #'MAKE-CONCATENATED-STREAM list-of-file-descriptors)
to essentially give myself "one big virtual file" to work with.
I'd _like_ to do this via opening all the files using something like
WITH-OPEN-FILE so that the operations (and auto-closing when done)
would be protected via the implicit UNWIND-PROTECT.
As a macro, using WITH-OPEN-FILE requires coding via macros. (Or at
least seems to do so; perhaps I'm wrong?)
In contrast, an "invoke-with-open-file" would make it pretty easy to
stack up the set of streams. I'm fine with recursing to get the job
done...
--
(reverse (concatenate 'string ····················@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
Random hacker: Oz needs to be booted.
RMS: Ok, I'll break open a window.
Kent M Pitman <······@world.std.com> wrote in message
>
> All the other stuff I can get in other languages, but the one thing I
can't
> easily get is the ability to make the language look like what I'm
programming
> about rather than having it look like yet another program in the same old
fixed
> syntax offered by most languages.
As an observation on my personal taste, no an argument one way or the other,
this is
a feature I've always regarded with mixed emotions, whether it involves the
extensive
use of macros in an assembler or C, or a language like Forth.
For the pluses, I've used Forth to build very specialized 'languages' for
hardware testing,
robot control, and so on, where the end user was blissfully unaware of what
langauge the
were actually using. I've found this approach to be much faster, and easier
to modify and
adapt than writing an interpreter to implement to same sort of
functionality.
otoh, after a relatively small percentage of the final app, I'm essentially
writing in a hitherto
unknow language, with perhaps only ':' and ';' still recognizable as Forth.
Other people do
the same. This means if I look at your code, or vice versa, I have to grasp
the entire metaphor
and learn the usages of this new language before I can make any changes or
debug.
C certainly can be as opaque if one just looks at the function calls from
main(), but I've
found that in practice, in tracing through a function, there are many fewer
layers before I
get to the 'same old fixed syntax' that is recognizable.
This is more important to me if I'm trying to maintain a piece of unfamiliar
code. If the code isn't broke, I certainly agree that working at a level of
abstraction that maps to the problem at hand
is much nicer. For instance, after about 25 years or so of C, writing yet
another linked list
doesn't thrill me; in the same period, I've also seen too many failed
attempts to do the job. At
this point, the container classes from the STL make a great deal of sense.
This leads to the discussion that's been going on in another thread --
Scheme is small and
simple, but one has to re-invent every wheel; Clisp is a much larger animal
when confronted
for the first time, but there are well known functions available to do the
things that must be
done in anything but a toy language. To me, this implies another's Scheme
app is more likely
to require digging deeper to unravel the adhoc constructs than looking at a
fragment of CLisp
and saying ,"oh, yeah, thats doing this or that".
"bowman" <······@montana.com> writes:
> Kent M Pitman <······@world.std.com> wrote in message
> > All the other stuff I can get in other languages, but the one
> > thing I can't easily get is the ability to make the language look
> > like what I'm programming about rather than having it look like
> > yet another program in the same old fixed syntax offered by most
> > languages.
>
> As an observation on my personal taste, no an argument one way or
> the other, this is a feature I've always regarded with mixed
> emotions [...] For the pluses, I've used Forth to build very
> specialized 'languages' [...] I've found this approach to be much
> faster, and easier to modify and adapt than writing an interpreter
> to implement to same sort of functionality.
>
> otoh, after a relatively small percentage of the final app, I'm
> essentially writing in a hitherto unknow language, with perhaps only
> ':' and ';' still recognizable as Forth.
One thing a lot of people will recommend to you is that you *read* a
lot of Lisp programs in order to learn the language. I think you
will find that there is some unspoken discipline to how this is
done. Note, for example, that although it's possible to redefine
the "character syntax" of the language, few good programmers do this
heavily. And those who do mostly are careful to make sure
read/print invertibility is maintained. That is, if you change the
printer to print something differently, you also change the reader
to read it back in, so that it can be modularly inserted into other
code. That yields less variability and more predictability than in
other languages, I'd bet. Also, a lot of the syntax changes are at the
"expression macro" level, and are often done in various standard pattern
ways that encourage uniformity rather than avoiding it. For example,
someone will observe that they want to make a with-open-device macro
because it's like with-open-file, not because it's different than
something in the core system. This ends up adding predictability, not
removing it. It just keeps the focus on the domain language.
Also, most lisp systems, because of their built-in reflectivity, provide
easy access to arglist information so that even someone unfamiliar with the
code can easily inspect the syntax of a macro pretty easily, or can ask to
see it interactively expanded to find out what it does. Such features
change how "scary" some syntactic options are.
I think the truth is that in C there is no overriding sense of "taste"
that dominates design, while in Lisp there really is a community sense
of style that leads to some pretty nice design through macros.
> This leads to the discussion that's been going on in another thread
> -- Scheme is small and simple, but one has to re-invent every wheel;
> Clisp is a much larger animal when confronted for the first time,
> but there are well known functions available to do the things that
> must be done in anything but a toy language. To me, this implies
> another's Scheme app is more likely to require digging deeper to
> unravel the adhoc constructs than looking at a fragment of CLisp and
> saying ,"oh, yeah, thats doing this or that".
Yes. CL arose out of observing that the first several hundred lines of
every Maclisp or Zetalisp program (the dialects preceding CL) were always
the same or similar--just establishing a common foundation of "obvious
lifesupport". I had teco macros in my editor environment which inserted
those "obvious" lines of Lisp code just to speed things up, but it was
still nutty, since other people's setup stuff differed gratuitously from
mine. The real power of CL isn't that it picked the right answer to the
myriad stupid little design questions that had to be answered to standardize
that wealth of functionality, but rather the power is that it blundered past
a bunch of arbitrary decisions, saving a large community from endless
bickering over whose way was better, and moving that community on to
better discussions. Mostly. Every now and then we descend back into some
of the old, supposedly-settled disputes. It's nearly always a waste of
time, I think. The Java community has independently discovered this same
power. It puts out lots of more-or-less standard libraries that might or might
not be right, but that are enough right to get people on to thinking about
the next problem beyond. For all Java as a language sucks, IMO, its force
of will in confronting the arbitrary head-on is commendable, and is the most
severe threat to CL in many years.
Kent M Pitman <······@world.std.com> writes:
> time, I think. The Java community has independently discovered this
> same power. It puts out lots of more-or-less standard libraries that
> might or might not be right, but that are enough right to get people
> on to thinking about the next problem beyond. For all Java as a
> language sucks, IMO, its force of will in confronting the arbitrary
> head-on is commendable, and is the most severe threat to CL in many
> years.
I always thought this was one of the worse aspects of the Java
Community, so I'm curious as to why you see it as an advantage. I
think the result of this fast-forward standardization is a set of
standard libraries that are bloated, largely useless, and not
distilled from experience by committee, but outright designed by
committee. Am I right in understanding that what you see as the
threat is not the execution of this process, but the recognition by
the Java community that it need be done?
What allowed the CL standard to avoid this pitfall, and is it possible
for CL to move forward with this same strategy at the present time in
attempts to add such things as sockets, FFIs, user-defined streams,
and multi-processing? Do you still see any evidence of this force of
will in the CL community?
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
>>>>> "Craig" == Craig Brozefsky <·····@red-bean.com> writes:
Craig> What allowed the CL standard to avoid this pitfall, and is it
Craig> possible for CL to move forward with this same strategy at the
Craig> present time in attempts to add such things as sockets, FFIs,
Craig> user-defined streams, and multi-processing? Do you still see
Craig> any evidence of this force of will in the CL community?
The "sockets thing" [to camp out on one item] may be waiting for
someone to try to build a unified scheme, and _that_ may be waiting
for the "would-be-killer-app" to make it useful.
A thought for case in point would be the "currently Corman-only"
XML-RPC package:
<http://www.double.co.nz/cl/#xmlrpc>
I've started looking at how to make that work with CLISP; it only
references socket calls in 3 places, which ought to mean that the
package could be made useful without needing to do _vast_ amounts of
integration work.
So far, replacement of its calls with CLISP "apparent equivalents" is
just resulting in crashes; hopefully it can head to actually working
soon.
In reviewing socket options, I see:
http://ww.telent.net/lisp/sockets.html - for CMUCL/SBCL
http://mit.edu/cadet/www/socket.lisp - for LispWorks
http://www.double.co.nz/cl#sockets - for Corman Lisp
Perhaps also useful in the interests of unification would be:
http://www.chez.com/emarsden/downloads/pg.lisp
which works with CLISP, CMUCL, and ACL, providing socket-based access
to PostgreSQL.
I guess the critical thing is to have some application(s) that use
sockets that are implemented to run atop all of:
CLISP, CMUCL, SBCL, ACL, LispWorks, Corman Lisp
which probably provides a sufficiently large grouping to encourage
stragglers to take the same approach(es?).
--
(reverse (concatenate 'string ····················@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
What's another word for synonym?
>>>>> "cbb" == cbbrowne <········@hex.net> writes:
cbb> I've started looking at how to make [XMLRPC] work with CLISP; it only
cbb> references socket calls in 3 places, which ought to mean that the
cbb> package could be made useful without needing to do _vast_ amounts of
cbb> integration work.
cbb>
cbb> So far, replacement of its calls with CLISP "apparent equivalents" is
cbb> just resulting in crashes; hopefully it can head to actually working
cbb> soon.
it works with CMUCL and CLISP with a few minor modifications; see the
patch at
<URL:http://www.laas.fr/~emarsden/etc/xmlrpc.diff>
cbb> Perhaps also useful in the interests of unification would be:
cbb> http://www.chez.com/emarsden/downloads/pg.lisp which works with
cbb> CLISP, CMUCL, and ACL, providing socket-based access to
cbb> PostgreSQL.
that library only uses very basic socket functionality. A useful
unified interface would need to address issues such as exceptions,
UDP, out of band data, non blocking input.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
········@hex.net writes:
> The "sockets thing" [to camp out on one item] may be waiting for
> someone to try to build a unified scheme, and _that_ may be waiting
> for the "would-be-killer-app" to make it useful.
IMHO the thing that is "preventing" a standardised socket layer from
emerging is that ~90% of all applications that use sockets do so in a
trivial form, so that only 3 or 4 abstracted-out functions need
trivial changes to port to another implementation. Case in point:
Our in-house HTTP/1.0+ server library contains slightly more than 3
KLOC totally portable ANSI CL code (all dealing with HTTP only, the
server framework is totally content-agnostic, i.e. this is not wedded
to some HTML-generation stuff). For each supported CL implementation
it needs exactly 2 files, which together contain around 40-50 LOC
platform dependent code, dealing with sockets, processes and locking.
The server currently runs on CMU CL (both MP and event-server), ACL,
and LispWorks Linux/Windows, and it is trivial to port to other
sufficiently standards-adhering CLs which support sockets as streams.
Under these circumstances, why invest the time needed to implement or
even learn to use a platform-independent interface?
And then there are the 10% of applications that need the full power of
TCP/IP sockets. Designing and implementing a truly portable socket
layer for all CLs and TCP/IP-stacks out there that will satisfy those
seems like very hard work, indeed, and I think someone with very deep
pockets would be needed to fund the work that would be necessary to
create and _maintain_ said interface...
Similar stuff seems to apply to stuff such as MP, FFIs, etc. It seems
to me that standardisation in these areas is not being undertaken
because the suffering caused by not having standardised solutions in
place is still below the threshold necessary to prompt the commitment
of funds and resources towards creating said standards.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
"Pierre R. Mai" <····@acm.org> writes:
> And then there are the 10% of applications that need the full power of
> TCP/IP sockets. Designing and implementing a truly portable socket
> layer for all CLs and TCP/IP-stacks out there that will satisfy those
> seems like very hard work, indeed, and I think someone with very deep
> pockets would be needed to fund the work that would be necessary to
> create and _maintain_ said interface...
>
Further proof of that is that there doesn't exist such an interface
even for Unix/C which is the native platform for the socket
concept. The archive of the ISC DHCPD mailing list is a very long
example of the differences in behaviour of much of the Unix API
between platforms. Getting dhcpd to work on some platforms at all (AIX
comes to mind) is a major undertaking.
--
Lieven Marchand <···@village.uunet.be>
Gla�r ok reifr skyli gumna hverr, unz sinn b��r bana.
Craig Brozefsky <·····@red-bean.com> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > time, I think. The Java community has independently discovered this
> > same power. It puts out lots of more-or-less standard libraries that
> > might or might not be right, but that are enough right to get people
> > on to thinking about the next problem beyond. For all Java as a
> > language sucks, IMO, its force of will in confronting the arbitrary
> > head-on is commendable, and is the most severe threat to CL in many
> > years.
>
> I always thought this was one of the worse aspects of the Java
> Community, so I'm curious as to why you see it as an advantage. I
> think the result of this fast-forward standardization is a set of
> standard libraries that are bloated, largely useless, and not
> distilled from experience by committee, but outright designed by
> committee. Am I right in understanding that what you see as the
> threat is not the execution of this process, but the recognition by
> the Java community that it need be done?
I believe you are right, yes. Except that I'm not saying that their
committees, if that's what they use, are needed. What I'm saying would
be unchanged if a single individual designed their "standards". I'm saying
the salient aspect of a successful standard is not "consensus" but rather
its "canonical nature". The success criterion is that it is "good enough"
to build on, not that it is best.
We've seen this in numerous other industries. VHS vs Betamax, for example.
The industry didn't care to sustain a long protracted debate over which had
the best quality. I'm told Betamax was technically better, but the consumer
market as a whole thought every store being half-full of video formats any
given consumer didn't want was a bigger waste than was picking the wrong brand.
The world rejoiced, more or less, when VHS was the winner not because VHS was
better but because the fight was over and new fights could occur on layered
products that needed to depend on this decision being a settled thing.
I've said this many times: it's more important to be standard than right.
This is not a statement against good design, careful planning, etc. It's
just to say that if you want to do any such thing, you have to do it quick,
because external pressures to proceed ahead are strong and you can't fight
them.
> What allowed the CL standard to avoid this pitfall,
CL was designed before what I call the democratization of computer science.
In the days of CL design, the competition was C and C was designed by its
designers. Both were socialist states, and CL was enough superior to hold
its own and sustain a good design presence. I don't think CL could be
designed with the care it required on modern budgets and cash flows. It was
a once in a lifetime chance, I think. I think to move forward, CL must learn
to embrace a democratic/capitalist world, where the power comes from the
users and not the designers.
> and is it possible
> for CL to move forward with this same strategy at the present time in
> attempts to add such things as sockets, FFIs, user-defined streams,
> and multi-processing?
My guess is no. I'd be happy to be surprised. But I've seen sveral
abortive attempts to move forward using the mechanisms of the past and
they have gone nowhere. My personal perception, and that's all it is
so no doubt some others will disagree, is that vendors simply don't
have it in them to make standards on these. The vendors who are not
"leaders" don't have the resources to engage in standards--it's all
they can do to make product. The vendors who are the "leaders" don't
need to engage in standards because they are the leaders. That's
oversimplifying, but the point is that it's different than long ago,
when people joined standards groups "because it was the thing to do".
I remember we used to have secretarial staff that did typing and
copying for us and that filled out our expense vouchers for us after
trips, and then one day it vanished. I remember we used to plan time
into schedules for people to get sick or take vacations, so that when
you went away, someone else picked up the slack. Now vacation is just
something they owe you until you take it and then all the same work is
there when you get back and you're responsible for getting caught back
up as if you'd never had vacation--you have twice as much work now but
now they don't owe you vacation time. Bleah. All of these things are
the market squeezing excesses out of a system, and I think standards
were an excess. They are about fairness and cooperation, but the
market doesn't need fairness and cooperation--it's arguably either
counterproductive to advances, or too long-range for a market to
fairly evaluate as positive. (It's possible that free markets are subject
to "hill climbing" problems and that standards processes helped to fight
that... But the market doesn't care if people get stuck on hills. If
they're really stuck, someone will move non-linearly and some companies
may die, but that hurts only the company, not the market. Markets are
callous. And again it doesn't need standards to accomplish this.)
Sorry for the stream of consciousness sentence. If I had more time I'd
edit it up. But this is my third attempt to send this message, and on the
first two I had a long answer but my machine crashed. I just wanted to
get ANY answer out on this because I think it's an important point and
worth debating. Hopefully my answer will make at least one person excited
or angry or something enough to fuel more discussion. I think people
need to have their eyes open to these things.
> Do you still see any evidence of this force of
> will in the CL community?
Nope.
That's not to say I am pessimistic about the CL community per se. I'm kind
of middling on that. I think it's possible for there to be a rosy outlook
but I don't think a rosy outlook comes for free.
I mostly just think the burden today is on the USERS, not the VENDORS.
I think the users are used to looking to the vendors, but it's time
for it to be the other way around. I think it's a crying shame that
the ALU is so passive. I think it's a crying shame they let the
vendors run their show because I think user activism and consolidation
and users telling vendors what they will and won't stand for is the
only way to move forward. Vendors will probably say they are moving
forward and that user activism won't help because users can't see the
big picture. I'm dubious, but who knows. I'm just one person. I
could be wrong.
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> I mostly just think the burden today is on the USERS, not the VENDORS.
> I think the users are used to looking to the vendors, but it's time
> for it to be the other way around.
Yes.
There is only one active (in terms of presence, marketing,
new products, new code, ...) vendor left and this situation
is unhealthy for the Lisp community in general. Additionally
old existing stuff is not accessible (Examples: CLIM sources,
Lispm sources, KEE, ...) and can't be used.
The largest target of a user base is on INTEL/Windows/Unix - but
exactly there are not the best Lisp environments (based on
user friendlyness, sophistication, productivity,
sexyness, source code, smallness, deployability,
...).
My example usually is (I haven't really counted, these are
my estimates):
- three messages per day on the MCL mailing list
- two messages per week on the ACL mailing list
- one message per week on the SLUG mailing list
- three messages per year on the LispWorks mailing list
Then I look at the MCL ftp site
(<ftp://ftp.digitool.com/pub/mcl/contrib/>
for contributed code: quite a lot MCL-specific code
(lot's of user interface stuff, ...) and demo
applications.
But for the "standard" platforms (Windows/Unix) there
isn't that much more to be seen. It should be atleast ten
times as much (polished and quality) stuff. Every
provider of a Lisp system needs to make sure that
their users are finding each other, finding code,
learning about the system, are encouraged to share,
having a place to share, ... Sometimes it might
be necessary to ask them to put contributions together
for a new release - they might not have the idea
that others would be interested in their stuff.
Users currently are largely "unorganized", unorganizing,
inactive, not able to spend money and time, not well
connected, ... with the usual exceptions. New users are
not really taught to use Lisp effectively - they learn slowly their
way by trial and error.
Progress may be seen when new applications appear or
old ones get renovated. Sometimes I fear new Lisp users
are overwhelmed by some of the complexities and
it get's worse with a poor programming environment...
Hmm, is it time to reread "Worse is better" and what
RPG recommended?
Let's wait and see. Maybe at some point there is reaction
to pain or it just stays at a low level of activity.
The ALU is not to blaim for their inactivity - the
ALU is just a part of the community.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> There is only one active (in terms of presence, marketing,
> new products, new code, ...) vendor left and this situation
> is unhealthy for the Lisp community in general.
Uh, to my knowledge, both Franz and Harlequin are commercially active.
Saying otherwise portrays, I think, a falsehood that is unnecessarily
daunting to people reading this who don't know what's afoot.
Also, I don't know that I think the vendor situation is that unhealthy
in the sense that an increase in its health would not change much in
the market. As I said, I think there is a limit to what vendors can
do. If each vendor had tenfold the money, I think they could still
not keep up with Java because what makes Java strong is its user
community, not its vendors. (I also think there are advantages to not
having so much money; the last time a vendor had tons of money, it was
Symbolics and it bled it all away on things that were cool but that
were ultimately not targeting the markets it needed to target. Being
slim on cash leaves one focused on the need for doing things the
market will pay for, and that's not always a bad thing.) If I were
Harlequin or Franz and had tons of extra money, I would do like Sun
and pour infinite money into the non-profit-making activity of
building the user community. But Sun could afford to do that because
it had OTHER products to make revenue on while it did this with Java.
It's hard to compete with a company that has an infinite supply of
money the spending of which doesn't have to yield direct profit...
I think the vendors are doing all they can reasonably be expected to do.
If anyone, it is the users who are screwing up. (I didn't used to get to
say stuff like that back when I worked for a vendor, so I have to say
such things now while I'm an independent and no company has to take
responsibility for my chiding the users...)
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > There is only one active (in terms of presence, marketing,
> > new products, new code, ...) vendor left and this situation
> > is unhealthy for the Lisp community in general.
>
> Uh, to my knowledge, both Franz and Harlequin are commercially active.
Commercially active, meaning somehow selling something - that's right.
But there's more to that:
- marketing: whose advertisements did you see lately?
- education: who offered/provided training classes lately?
- updates: when was the last major update?
- meetings: who was lately active organizing meetings?
- presence: who is visible outside the Lisp community?
- selling: whose sales person called you lately?
- press announcements: whose news did you read on cnet, zdnet, ...?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
>>>>> "Kent" == Kent M Pitman <······@world.std.com> writes:
Kent> Rainer Joswig <······@corporate-world.lisp.de> writes:
>> There is only one active (in terms of presence, marketing, new
>> products, new code, ...) vendor left and this situation is
>> unhealthy for the Lisp community in general.
Kent> Uh, to my knowledge, both Franz and Harlequin are commercially
Kent> active. Saying otherwise portrays, I think, a falsehood that is
Kent> unnecessarily daunting to people reading this who don't know
Kent> what's afoot.
Harlequin is "dead;" long live Xanalys.
More interestingly, Franz is _much_ more active in advertising than
Xanalys. I see ACL "banner ads" quite a bit at web sites, and seem to
recall seeing Franz as a sponsor of [something I can't remember] just
in the last couple days.
In contrast, if I didn't see mention on comp.lang.lisp, I'm quite sure
that Xanalys would be a company I would be _utterly_ unaware of.
Kent> I think the vendors are doing all they can reasonably be
Kent> expected to do. If anyone, it is the users who are screwing up.
Kent> (I didn't used to get to say stuff like that back when I worked
Kent> for a vendor, so I have to say such things now while I'm an
Kent> independent and no company has to take responsibility for my
Kent> chiding the users...)
I don't disagree with such comments; I'm quite sure that Xanalys has
the significant challenge of digging themselves out of "obscurity" as
a new company that is trying to keep credible with the existing set of
customers. Unfortunately that leaves them limited resources for:
a) Spending money on "more public" sorts of marketing;
b) Spending _time_ on that publicity.
Throw in that, based on their web site, Lisp seems more likely a
secondary or even tertiary part of their "sales strategy" than it
being primary, and that suggests that getting resources for promoting
or improving it is liable to be dicey.
--
(reverse (concatenate 'string ····················@" "454aa"))
<http://www.ntlug.org/~cbbrowne/>
In a world without fences, who needs Gates?
* Kent M Pitman wrote:
> If I were Harlequin or Franz and had tons of extra money, I would do
> like Sun and pour infinite money into the non-profit-making activity
> of building the user community. But Sun could afford to do that
> because it had OTHER products to make revenue on while it did this
> with Java. It's hard to compete with a company that has an infinite
> supply of money the spending of which doesn't have to yield direct
> profit...
I think this is a really important, and often-forgotten, point. I'd
be quite interested to know if Sun make, or expect to make, any money
directly out of Java. I have a suspicion that they might not -- they
make their money basically out of things like E10k, and Java is just a
loss-leader to get people to buy big Sun boxes. It's probably been
rather successful at doing that, too. One could go further and wonder
whether Sun or Microsoft make significant money out of their
development environments at all, or if they use them as tools to sell
the things that do make money -- in Sun's case big hardware (they
probably still make money on workstations, but these, too, are a way
to pull people into the big boxes nowadays), and in Microsoft's case
Windows and Office.
So it's not surprising that companies who expect to make their money
out of selling a development environment behave very differently. In
particular they need to charge for it, and they don't have huge
amounts of money washing around from their main product to throw at
non-profit activities.
Actually, it's my belief that you don't get rich selling a development
environment, you need to sell something else -- something much more
profitable either by virtue of huge volume (MS) or huge cost (Sun) --
and then give the development environment away. This is the tragedy
of Lisp vendors in a way -- none of them have worked out what else to
sell so they can give Lisp away. Fortunately for us, I guess, it
seems that you can stay in business selling a development environment.
> I think the vendors are doing all they can reasonably be expected to
> do. If anyone, it is the users who are screwing up.
well said.
--tim
Tim Bradshaw <···@cley.com> wrote in
>
> One could go further and wonder
> whether Sun or Microsoft make significant money out of their
> development environments at all, or if they use them as tools to sell
> the things that do make money
Microsoft certainly seems to try. While the Learning Editions are
inexpensive, and the Academic versions carry high discounts, the full blown
professional level packages are quite pricy . Plus the various subscriptions
to get enough documentation to effectively use the products.
I think it makes some sort of statement that a whole industry , of benefit
to both MS and third parties, has sprung up around training and certifying
people to use their products. The 'net has made the information more
available; prior to that, being a MS developer required a significant
contribution to MS's coffers. Always thought it strange they would place the
bar high enough to discourage apps that would help sell their OS (referring
of course to the time period before they had conquered the desktop market
completely)
* bowman wrote:
> Tim Bradshaw <···@cley.com> wrote in
>>
>> One could go further and wonder
>> whether Sun or Microsoft make significant money out of their
>> development environments at all, or if they use them as tools to sell
>> the things that do make money
> Microsoft certainly seems to try. While the Learning Editions are
> inexpensive, and the Academic versions carry high discounts, the full blown
> professional level packages are quite pricy . Plus the various subscriptions
> to get enough documentation to effectively use the products.
I had a very brief search and I found visual studio Enterprise with no
discounts at around L1000 which I suppose is $1xxx depending on
exchange rate. Visual C++ enterprise seemed only slightly cheaper.
I should think that's not a hugely money-losing price, but rather
doubt a lot of profit is being made.
--tim
Tim wrote:
> I had a very brief search and I found visual studio Enterprise with no
> discounts at around L1000 which I suppose is $1xxx depending on
> exchange rate. Visual C++ enterprise seemed only slightly cheaper.
The equivalent for Sun (Forte C++ Enterprise was Sun Visual WorkShop(tm)
C++) $3495 or ~ �2380.
;)w
"Rainer Joswig" <······@corporate-world.lisp.de> wrote in message
·································@news.is-europe.net...
>
> Progress may be seen when new applications appear or
> old ones get renovated. Sometimes I fear new Lisp users
> are overwhelmed by some of the complexities and
> it get's worse with a poor programming environment...
> Hmm, is it time to reread "Worse is better" and what
> RPG recommended?
>
> Let's wait and see. [...]
Has anybody been thinking about the implications of .NET for Lisp (or Lisp
for .NET)?
- It will provide a set of services that software needs to please "modern"
users.
- Built in support for comms, gui, web development and database access.
- Designed for language interoperability.
- Not a technically unpleasant environment to work in (surprisingly).
- Guaranteed a wide audience.
These are strong enough incentives to invest time, money and energy. The
question is whether the disincentives are strong enough to preclude it, and
I guess that's why I'm donning the old asbestos suit to find out your
attitudes.
Those who are concerned for Lisp's "survival", and those who keep an open
mind about the implications of "Worse is Better" for survival, might want to
keep an open mind about .NET too. This seems like an environment in which a
highly adaptable life form like Lisp could thrive, without sacrificing
anything technically indispensable - as far as I can see.
Does anybody know of a project to coerce Clisp to compile to the .NET IL? Or
any similar project?
"Patrick W" <······@my-deja.com> writes:
[...]
> Has anybody been thinking about the implications of .NET for Lisp (or Lisp
> for .NET)?
Oh yes! Such a promising idea -- with such unfortunate provenance. ;-)
> - It will provide a set of services that software needs to please "modern"
> users.
> - Built in support for comms, gui, web development and database access.
> - Designed for language interoperability.
Hmmm, but not without some legacy restrictions, true? The "object
model" of .NET is rigidly single-argument dispatch, is it not?
> - Not a technically unpleasant environment to work in (surprisingly).
Oh? You don't have to use Windows? ;-)
But seriously, how much of .NET is real and available today? The
material I last read (admittedly all several months ago, when C# was
first announced) was pretty forward-looking.
> - Guaranteed a wide audience.
>
> These are strong enough incentives to invest time, money and energy. The
> question is whether the disincentives are strong enough to preclude it, and
> I guess that's why I'm donning the old asbestos suit to find out your
> attitudes.
>
> Those who are concerned for Lisp's "survival", and those who keep an open
> mind about the implications of "Worse is Better" for survival, might want to
> keep an open mind about .NET too. This seems like an environment in which a
> highly adaptable life form like Lisp could thrive, without sacrificing
> anything technically indispensable - as far as I can see.
>
> Does anybody know of a project to coerce Clisp to compile to the .NET IL? Or
> any similar project?
Is the .NET intermediate language even publicly documented yet?
-- Kaelin
"Kaelin Colclasure" <······@everest.com> wrote in message
···················@soyuz.arslogica.com...
> "Patrick W" <······@my-deja.com> writes:
>
> [...]
> > Has anybody been thinking about the implications of .NET for Lisp
> > (or Lisp for .NET)?
>
> Oh yes! Such a promising idea -- with such unfortunate provenance. ;-)
Indeed!
To all but the Microsoft toadies, that's the general attitude.
> > - It will provide a set of services that software needs to please
"modern"
> > users.
> > - Built in support for comms, gui, web development and database access.
> > - Designed for language interoperability.
>
> Hmmm, but not without some legacy restrictions, true? The "object
> model" of .NET is rigidly single-argument dispatch, is it not?
That's right. I believe so, anyway.
> > - Not a technically unpleasant environment to work in (surprisingly).
>
> Oh? You don't have to use Windows? ;-)
Hopefully not for long ;-)
When I first heard about it I thought it was another grotesque hack built on
top of COM - which I loathe. But that's apparently not the case. Building a
runtime architecture on other platforms that conforms to the CLI (which I
believe they've either submitted, or will be submitting, to ECMA for
standardisation), is a real possibility - unless I'm missing something.
> But seriously, how much of .NET is real and available today?
Well ... all of it
(In Beta form - liable to change - but surprisingly feature-rich and usable)
http://msdn.microsoft.com/net
> Is the .NET intermediate language even publicly documented yet?
Yep.
There's a set of documents and specs for tool developers at:
http://msdn.microsoft.com/msdn-files/027/001/520/nettdg.exe
"Patrick W" <······@my-deja.com> writes:
[...]
> > Is the .NET intermediate language even publicly documented yet?
>
> Yep.
> There's a set of documents and specs for tool developers at:
> http://msdn.microsoft.com/msdn-files/027/001/520/nettdg.exe
Hmmm, anything you can look at *without* installing Windows on your
machine? :-)
-- Kaelin
Patrick W wrote:
>> Hmmm, but not without some legacy restrictions, true? The "object
>> model" of .NET is rigidly single-argument dispatch, is it not?
>
> That's right. I believe so, anyway.
No I think they have implemented multiple Inheritage but it is built above
the "IL" Layer as I remember....
Regards
Jochen
I've got a Lisp interpreter (dotLisp) up and running under .NET. It's
terrific fun dealing with .NET interactively w/Lisp. dotLisp is not CL, and
never will be, and I'm skeptical of the idea of a port of an existing CL to
.Net, in terms of such a port yielding a language that has suitable
integration with the environment.
It is (IMHO) vital to separate the language/library/runtime when bringing a
language to a platform such as .NET. CL provides for services in all these
areas, but in doing so it dictates much that makes it difficult to integrate
into an environment with considerable overlap in services. I understand the
value of CL's broad spec in allowing rich programs to be written portably,
but I want a Lisp that is a first class citizen in .NET, able to leverage
the libraries and runtime without any wrappers/bridges/FFI etc.
Here are some of the characteristics of dotLisp:
Adopts the .NET type system:
(type-of 5) -> Int32
(type-of #(1 2 3)) -> System.Object[]
Extends Lisp syntax to allow for member access in a Lisp-like manner.
;Hashtable has an indexed default property, so should behave like an
array
;in the consuming language
(def ht (new Hashtable.)) -> System.Collections.Hashtable
(set (aref ht "a") 5) -> 5 ;indexed property access
(aref ht "a") -> 5
(.Count ht) -> 1 ;property access
(.Contains ht "a") -> true ;method invocation
(.Contains ht "b") -> false
;member accessors (both properties and methods) behave like functions
(mapcar .Length '("a" "bc" "def")) -> (1 2 3)
(mapcar .ToUpper '("a" "bc" "def")) -> ("A" "BC" "DEF")
Leverages .NET CLR (Common Language Runtime) services for GC, object
instantiation, reflection, runtime type-safety, boxing, exceptions etc
Supports generic functions, with multiple dispatch, but not CLOS
Nothing about supporting the class-scoped polymorphism of the type
system precludes generic functions - having both is quite useful
I built upon the work of Norvig et al's SILK, a Scheme interpreter written
in Java for the JVM, ported it to C# and the .NET CLR, migrated from Scheme
towards more of CL - dotLisp has support for macros, optional, keyword and
rest params, unified nil/()/logical-false, multidimensional arrays, a
simplified notion of place, multiple-place set, lots more library (where it
doesn't overlap with the .NET framework). It is case-sensitive and a Lisp-1.
The result is a non-standard Lisp, sitting between Scheme and CL, portable
only to environments that support the CLR (Windows flavors, but possibly
others later), with a huge predefined library and transparent access to any
components (defined by anyone, in any language) for .NET. I find it
incredibly useful and productive - but is there a market for it? I'm having
fun but I'm not sure what to do with it ;-)
Anyway, I think there is great potential for Lisp in .NET, but probably not
CL.
"Patrick W" <······@my-deja.com> wrote in message
························@ozemail.com.au...
> Has anybody been thinking about the implications of .NET for Lisp (or Lisp
> for .NET)?
>
> - It will provide a set of services that software needs to please "modern"
> users.
> - Built in support for comms, gui, web development and database access.
> - Designed for language interoperability.
> - Not a technically unpleasant environment to work in (surprisingly).
> - Guaranteed a wide audience.
>
> These are strong enough incentives to invest time, money and energy. The
> question is whether the disincentives are strong enough to preclude it,
and
> I guess that's why I'm donning the old asbestos suit to find out your
> attitudes.
>
> Those who are concerned for Lisp's "survival", and those who keep an open
> mind about the implications of "Worse is Better" for survival, might want
to
> keep an open mind about .NET too. This seems like an environment in which
a
> highly adaptable life form like Lisp could thrive, without sacrificing
> anything technically indispensable - as far as I can see.
>
> Does anybody know of a project to coerce Clisp to compile to the .NET IL?
Or
> any similar project?
>
>
>
"Rich Hickey" <····@nospamagentradio.com> writes:
> I've got a Lisp interpreter (dotLisp) up and running under .NET. It's
...
> The result is a non-standard Lisp, sitting between Scheme and CL, portable
> only to environments that support the CLR (Windows flavors, but possibly
> others later), with a huge predefined library and transparent access to any
> components (defined by anyone, in any language) for .NET. I find it
> incredibly useful and productive - but is there a market for it? I'm having
> fun but I'm not sure what to do with it ;-)
>
> Anyway, I think there is great potential for Lisp in .NET, but probably not
> CL.
Why not? The fact that you choose to do somthing different from CL is
not a good argument.
Can you be more specific about it?
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Well, I think when you approach .NET you have to embrace a couple of things:
1) It's a platform with a language-independent runtime, type system, and
library.
2) The primary benefit of targeting it, transparent interoperability,
derives from the above.
How often do we read in this ng and others "language x is better than
language y because x has libraries for doing z". Or "Lisp would have more
appeal if it had libraries for ___"
Language-independent component libraries and language interoperability are
very good ideas, IMO. Why should every language have to wait for someone (in
its possibly small community) to write a sockets/DB/GUI/HTTP/XML/regexp
library for it? How much time does the development community waste
reinventing various wheels?
But supporting language-independent component libraries means solving some
problems globally, like types, objects and lifetime management. Doing it
transparently means solving those problems in a runtime environment, and
with a certain amount of cooperation from participating languages, as well
as acceptance of the limitations of the runtime-supplied solutions. Anyone
who has used CORBA or COM and then .NET can testify to the quantum
difference between 'bridging' approaches and an integrated approach. And you
only get that transparency when language types are runtime types, and you
let the runtime environment take over those areas in which it provides
services. Otherwise it's more bridges, mismatches, lifetime issues,
conversion issues etc. Yes, Lisp is a programmable programming language, and
one could probably build the infrastructure and macrology to make it >seem<
like things are integrated, but you are either in the environment or you're
not, and if you're not, you're just a non-citizen left wondering when your
visa is going to expire. Every language brought to .NET must deal with the
fact that primitive types are no longer the provenance of the language -
they are defined by the runtime, and the notion of transparently consuming
components defined outside of the language as if they were language-native.
I understand that, for many, Lisp is a runtime environment and a library,
not just a language, and they derive much power from the rich environment CL
defines, and has to define, since environments like .NET are not widely
available. I am not arguing with that, I accept the benefits. CL was
designed to serve a community and it does that extremely well. And yes, that
same community might embrace a compliant CL port to .NET (at least the few
that don't despise MS or Windows ;-). I guess I should qualify what I said:
IMO, CL on .NET would likely have appeal limited to its existing community,
while a Lisp designed for .NET could have far greater potential. To the
extent that Lisp/CL is an environment it is always going to be an island,
requiring bridges and ferries to the rest of the world. That's not to take
away from the excellent bridges to CORBA/COM/Java from the CL vendors. But
it ain't the same as being there.
Perhaps a vendor will chime in with their perspective on taking CL to .NET?
Maybe I'm wrong about the difficulties of bringing spec-compliant CL to .NET
and achieving transparent interoperability.
To answer your question with a question: If one were starting from scratch,
and supplied a platform like .NET, would one define Lisp the way CL is
defined?
I would hope the answer is 'most definitely not'. For instance, .NET
provides for numbers, characters, strings, arrays, hashtables, exceptions,
namespaces, files, streams, user-defined types, a type hierarchy and
inheritance, I/O, object creation and initialization, reflection etc. Should
a language define its own incompatible versions of these things in such an
environment?
Yet Lisp, the language, has so much to offer developers on .NET, even with
the tradeoffs inherent in adopting a platform-specified type system, object
system and runtime. The Microsoft supplied languages (C#, VB.Net, and
JScript.Net) are practically identical, and offer nothing interesting to
those who have experienced the power of Lisp. But is Lisp the CL spec, or is
it its approach to programming - dynamic, flexible, expressive, powerful and
extensible? You need lose none of these things when you bring Lisp, the
language, to .NET, the environment. I think there is a real opportunity for
Lisp here.
"Marco Antoniotti" <·······@cs.nyu.edu> wrote in message
····················@octagon.mrl.nyu.edu...
>
> "Rich Hickey" <····@nospamagentradio.com> writes:
>
> > I've got a Lisp interpreter (dotLisp) up and running under .NET. It's
>
> ...
> > Anyway, I think there is great potential for Lisp in .NET, but probably
not
> > CL.
>
> Why not? The fact that you choose to do somthing different from CL is
> not a good argument.
>
> Can you be more specific about it?
"bowman" <······@montana.com> writes:
> Martin Cracauer <········@counter.bik-gmbh.de> wrote
> >
> > If you really want a functional style very seperate from C, work
> > through SICP. It's Scheme-based, though.
>
> I've been working with SICP. I find it interesting, but I also keep
> drawing parallels to what I am familiar with.
Good! You're supposed to.
> The dispatch mechanism reminds me of a C++ vtable,
Yes, it is very similar.
> and some of the techniques to store data in lists strikes me as
> clumsy.
They are, but the point is to illustrate a general technique. Take
for example the simple `generic arithmetic' package. The underlying
concrete data are formed by lists with symbols marking them, so a
rational number might be represented as '(rational 2 3) and a complex
as '(complex (rational 2 3) 4)
This representation *is* clumsy, and it will not perform well at all,
but that isn't the point. The point is that in order to do
data-directed programming you need to be able to recognize arbitrary
data, and manifest tags are needed if you don't know the data
beforehand. Whether the tags are lisp symbols, the bottom 3 bits in
a 32-bit quantity, or an enum stored in the first byte of a struct is
just an implementation detail.
One of the reasons the authors chose to use Scheme is that it is
relatively easy to demonstrate general techniques without getting
bogged down in the details of a particular implementation.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
"bowman" <······@montana.com> writes:
>Martin Cracauer <········@counter.bik-gmbh.de> wrote
>>
>> If you really want a functional style very seperate from C, work
>> through SICP. It's Scheme-based, though.
>I've been working with SICP. I find it interesting, but I also keep drawing
>parallels to what
>I am familiar with. The dispatch mechanism reminds me of a C++ vtable, and
>some of the
>techniques to store data in lists strikes me as clumsy.
>I'm enjoying the different perspectives, but I would have to admit I haven't
>seen a compelling
>reason to use Lisp, Scheme, ML etc. I can justify Forth, another language I
>am familiar with,
>as I can use that with everything from an 8051 on up. Perhaps if I had been
>exposed to a
>functional language earlier, it would be easier.
You really didn't understand a word from the things I told you about
Lisp and functional programming being only very loosely coupled, did
you?
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Martin Cracauer <········@counter.bik-gmbh.de> wrote in
>
> You really didn't understand a word from the things I told you about
> Lisp and functional programming being only very loosely coupled, did
> you?
Yes, I did. From my perspective, 'functional programming' is an ill defined
academic
concept that is interesting primarily from a historical standpoint. Those
languages
with 'functional' roots seem to be useful in real world programming only to
the
extent they have become 'imperative', 'procedural' or whatever term one
uses.
I've got a whole toolbox full of 'procedural' languages; I really don't need
another
one that differs only by textual oddity.
"bowman" <······@montana.com> writes:
> Martin Cracauer <········@counter.bik-gmbh.de> wrote in
> >
> > You really didn't understand a word from the things I told you about
> > Lisp and functional programming being only very loosely coupled, did
> > you?
>
> Yes, I did. From my perspective, 'functional programming' is an ill defined
> academic
> concept that is interesting primarily from a historical standpoint. Those
> languages
> with 'functional' roots seem to be useful in real world programming only to
> the
> extent they have become 'imperative', 'procedural' or whatever term one
> uses.
Well, sometime the academicians did something good. The authors of
the Dragon book and SICP are mostly in Academia, are they not?
> I've got a whole toolbox full of 'procedural' languages; I really don't need
> another
> one that differs only by textual oddity.
Bu you need one that is more powerful that what you have in your
toolbox. E.g. one that does not break on factorial(20) (like Python)
and that has multiple method dispatch (unlike any other language
around).
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Bu[t] you need one that is more powerful that what you have in your
> toolbox. E.g. one [...] that has multiple method dispatch
> (unlike any other language
> around).
Cecil?
--
T. Kurt Bond, ···@tkb.mpl.com
···@tkb.mpl.com (T. Kurt Bond) writes:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> > Bu[t] you need one that is more powerful that what you have in your
> > toolbox. E.g. one [...] that has multiple method dispatch
> > (unlike any other language
> > around).
>
> Cecil?
Why not? I do not know anything about it. Time to fire up a search
engine.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Marco Antoniotti <·······@cs.nyu.edu> writes:
> ···@tkb.mpl.com (T. Kurt Bond) writes:
> > Marco Antoniotti <·······@cs.nyu.edu> writes:
> > > Bu[t] you need one that is more powerful that what you have in your
> > > toolbox. E.g. one [...] that has multiple method dispatch
> > > (unlike any other language
> > > around).
> > Cecil?
> Why not? I do not know anything about it. Time to fire up a search
> engine.
I'm not saying that it's a language that you'll like, but does have
multi-methods. It seems like the predicate dispatching that they have
come up with (not implemented in Cecil, last time I looked) is also
interesting.
[I could have said "Dylan", too, but Cecil somes from farther way from
Lisp.]
--
T. Kurt Bond, ···@tkb.mpl.com
In article <··············@tkb.mpl.com>, ···@tkb.mpl.com (T. Kurt Bond)
wrote:
> Marco Antoniotti <·······@cs.nyu.edu> writes:
> > Bu[t] you need one that is more powerful that what you have in your
> > toolbox. E.g. one [...] that has multiple method dispatch
> > (unlike any other language
> > around).
>
> Cecil?
is it "around"?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
"bowman" <······@montana.com> writes:
> Yes, I did. From my perspective, 'functional programming' is an ill
> defined academic concept that is interesting primarily from a
> historical standpoint. Those languages with 'functional' roots seem
> to be useful in real world programming only to the extent they have
> become 'imperative', 'procedural' or whatever term one uses.
May I kindly submit that you have not given sufficient attention to
the functional languages. I'm no advocate of pure functional
programming, but I think it's ludicrous to suggest that functional
languages are only useful to the extent that they are procedural. I
believe that the ML "family" of languages offer alot of things to
learn from; list comprehensions, pattern matching, currying, monadic
I/O, lazy evaluation etc... Many real world projects, including
operating systems, network layers, ATM switches, and web servers have
been created using these functional languages.
> I've got a whole toolbox full of 'procedural' languages; I really
> don't need another one that differs only by textual oddity.
One of my favorite things about lisp is that I can take things I've
learned from other languages and programming styles and transplant
them back into lisp. In the process of implementing it in my lisp
environment, I learn much more about the new tactic.
"bowman" <······@montana.com> writes:
> From my perspective, 'functional programming' is an ill defined
> academic concept that is interesting primarily from a historical
> standpoint.
I can't argue that this is not your perspective, but I will point out
that it is wrong on several points. Functional programming is not
ill-defined: It is a way of programming that places emphasis on
functional composition. It is inspired by Church's lambda calculi,
which grew out of his efforts to come up with a formal notion of what
is computable.
I suppose that it is `academic', but more so than many other concepts
that are related to computing.
There is quite a bit of active research into functional programming,
and there are several money making products that are based on
functional programming. It is hardly a historical footnote.
> Those languages with 'functional' roots seem to be useful in real
> world programming only to the extent they have become 'imperative',
> 'procedural' or whatever term one uses.
This is simply not true. You might argue that `pure' functional
programming is impractical (and I'd be inclined to agree), but the
necessary sprinkling of imperative code is usually an adjunct to the
functional core, not a replacement. In these `mostly functional'
languages, you would find that the bulk of the program is `pure', and
that the imperative parts are used to print the results, or save to a
file, (two rather useful things).
> I've got a whole toolbox full of 'procedural' languages; I really
> don't need another one that differs only by textual oddity.
I'm not trying to sell you anything.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
bowman wrote:
>
> From my perspective, 'functional programming' is an ill defined
> academic
> concept that is interesting primarily from a historical standpoint.
What an odd perspective you have.
> I've got a whole toolbox full of 'procedural' languages; I really don't need
> another
> one that differs only by textual oddity.
Does that mean "I've learned Algol-60 in ten different disguises
so that's all I'm prepared to see"?
Ian Wild <···@cfmu.eurocontrol.be> wrote in message
>
> Does that mean "I've learned Algol-60 in ten different disguises
> so that's all I'm prepared to see"?
probably more than I really want to admit. I started with Fortran IV
and assembler, moving to C. Other than Forth, most of the
other languages I use regularly are C-like.
I am not adverse to learning new techniques. I just haven't come
upon the problem that compels me to use a functional approach.
If and when I do, I will inderstand the appeal.
"bowman" <······@montana.com> writes:
>Martin Cracauer <········@counter.bik-gmbh.de> wrote in
>>
>> You really didn't understand a word from the things I told you about
>> Lisp and functional programming being only very loosely coupled, did
>> you?
>Yes, I did. From my perspective, 'functional programming' is an ill defined
>academic
>concept that is interesting primarily from a historical standpoint. Those
>languages
>with 'functional' roots seem to be useful in real world programming only to
>the
>extent they have become 'imperative', 'procedural' or whatever term one
>uses.
That is wrong as well.
>I've got a whole toolbox full of 'procedural' languages; I really don't need
>another
>one that differs only by textual oddity.
You should really give up the idea that there is such a strong
connection between languages and paradigms. There are languages more
or less suited to multiple paradigms (the "more" are usually much more
sucessful), and as long as you try to put each language in its own
single paradigm corner first, you will never find a language you are
satisfied with.
And languages for the same paradigm differ in much more than textual
representation.
If you are really searching for paradigm - not language - experiments,
then say so.
[Could you please fix your line wrapping? thanks]
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
···········@my-deja.com writes:
> I've got a problem, I've tried several times to learn lisp, and all of
> them I've succeeded, sort of. My background is C, perl, python, and
> Java. I have absolutely no problem understanding the syntax and the way
> programs are put together in lisp. What I have a problem with is
> understanding "lispishness" and how to write in a functional way.
As others have said, "lispishness" is not equivalent to "functional".
If you want to learn pure functional style, you should use a pure
functional language like Prolog. However, I don't think that's really
what you want; functional style is just a buzzword that sometimes
gets attached to lisp, because it is so hard otherwise to understand
what "lispishness" is.
> I've read several books, and one of the things that they seem to
> criticize most is "writing C in lisp", which to the best of my knowledge
> means using all of the old imperative tricks in a functional world where
> they're not appropriate. The reason I've been so frustrated with lisp
> is that all of my programs appear to me to be in this style, and I'm not
> sure how to grok the functional style. I figure that if I'm going to
> write C in lisp, then I may as well stick to C and not bother with lisp.
> But through some functional things that I have used, I am very anxious
> to really understand the core of how lispers do things.
The whole problem of "writing C in lisp" (which I understand to mean
writing lisp code that looks like a C programmer wrote it rather than
a lisp programmer) is not due to "lispishness", but rather to "Cishness".
For example, the requirement in C that all types and data structures be
pre-determined and allocated before testing any operations on them causes
one to try to do the same in lisp, even though it is not necessary.
Another example is memory management. Consideration of who "owns" a
data object that has been allocated causes many design cycles to be
used up, wheras in lisp the garbage collector takes care of disposal
of objects for you and you don't have to think about that problem
while programming in lisp.
Now, C is not the only language that has these kinds of limitations, and
lisp is not the only language to have some of these absesnces of the same
limitations, so it is really not fair to either trash C more than some
other languages, nor is it fair to some other languages to put lisp
above them (though usually we tend to say that such languages have a
particular "lispish" feature). So I would tend to say rather that it is
useful to learn what limitations you have habitually put up with in
the more limited languages, and to thus unlearn them when programming
in less limited languages. This is of course a hard thing to do,
and it usually takes a good book or two, or better yet, a mentor who
can see your bad habits. Many times if you post something to this
newsgroup and ask for a more lispy solution you will get an answer
or two or ten.
Finally, I view "lispishness" as a growing thing. One of the more
lispish things that lisp does is to facilitate writing other languages,
by reason of its extensibility. Because of this, any new programming
concept that might be invented (and probably manifested in a new
whiz-bang language) can easily be incorporated into a lisp system
(if not already there), thus reducing the limitations which even
lisp has and thereby extending lispishness.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>, "Duane Rettig" <·····@franz.com>
wrote:
> Now, C is not the only language that has these kinds of limitations, and
> lisp is not the only language to have some of these absesnces of the same
> limitations, so it is really not fair to either trash C more than some other
> languages, nor is it fair to some other languages to put lisp above them
> (though usually we tend to say that such languages have a particular
> "lispish" feature). So I would tend to say rather that it is useful to
> learn what limitations you have habitually put up with in the more limited
> languages, and to thus unlearn them when programming in less limited
> languages. This is of course a hard thing to do, and it usually takes a
> good book or two, or better yet, a mentor who can see your bad habits. Many
> times if you post something to this newsgroup and ask for a more lispy
> solution you will get an answer or two or ten.
Well, I'm not trying to trash C or glorify lisp. What
this is more about is that as I've progressed as a
programmer, I've learned the C way of doing things,
the OOP way of doing things, and some mixed approaches,
but one thing that I feel is a major gap in my
understanding of programming is the functional approach.
So it's not really that I want to learn the functional
approach because I think it's better than anything
else, but I want to add another tool to my toolbox.
I figure the more tools I have in my toolbox, the
better equipped I'll be for things down the road.
As for writing C in lisp, practically everybody's
heard the quote "Any language that doesn't teach you
something new about programming isn't worth learning"
(paraphrased). Well for my purposes, writing C in
lisp is of course an option, but just doesn't make
much sense since I'm not learning anything new.
What you said is right - I'm looking for the things
that lisp can do that other languages can't do. Perl
and python tought me not to be a BDSM programmer and
not to worry about who owns things or who has a reference
to them, since they take care of themselves. They
also taught me about map(). It's when I found out
that this idea had been borrowed from languages like
lisp that I showed up here.
--
David Allen
http://opop.nols.com/
"David Allen" <········@titan.vcu.edu> writes:
> Well, I'm not trying to trash C or glorify lisp. What
> this is more about is that as I've progressed as a
> programmer, I've learned the C way of doing things,
> the OOP way of doing things, and some mixed approaches,
> but one thing that I feel is a major gap in my
> understanding of programming is the functional approach.
> So it's not really that I want to learn the functional
> approach because I think it's better than anything
> else, but I want to add another tool to my toolbox.
> I figure the more tools I have in my toolbox, the
> better equipped I'll be for things down the road.
An exercise that I found useful at an earlier point in my career was
learning Prolog by implementing a small, yet non-trivial system with
it. It's very, very difficult to write C (e.g. imperative) code in
Prolog. You are essentially *forced* to reformulate your
conceptualization of the problem space. It's absolutely maddening --
and ultimately enlightening, just as I dimly recall my earliest
experiences with BASIC being.
I certainly wouldn't claim that I now grok the functional paradigm,
but I do have a working understanding of it and a basic appreciation
of its strengths and the trade-offs it entails. And I don't think I'd
have quite gotten there with Common Lisp -- because the bits that were
really hard to me to conceptualize in Prolog would have been too easy
to knock out using side-effects in Lisp.
[Just as an aside, the system I wrote was the core of a mediator for
the board game Diplomacy. It's a fairly popular game for
Internet-based play, with the games conducted by email and mediated by
a software package called simply the "judge". Diplomacy's rules allow
for convoy orders (moving armies via ships) to specify redundant
routes in case enemy movements interfere at some point in the convoy
chain. However, I was annoyed to find during the course of one of my
early Internet games that the judge software can't handle redundant
convoy routes -- so they're dissallowed by a "house rule" in Internet
play. The mediator I wrote, of course, did "properly" implement the
Diplomacy convoy rules.
What I had the hardest time wrapping my head around in Prolog was how
to represent the state of the map as it evolved during the course of
mediation. The answer, of course, was that each predicate needed an
auxilliary argument for passing in the graph structure representing
the map -- but I started out trying to use assert and retract to keep
the map state as part of the predicate database...
And no, I never completed a replacement for the judge. Things got busy
at work, etc. But I did pick up at least a fundamental appreciation
of declarative / functional style.]
-- Kaelin
"David Allen" <········@titan.vcu.edu> writes:
> In article <·············@beta.franz.com>, "Duane Rettig" <·····@franz.com>
> wrote:
> > Now, C is not the only language that has these kinds of limitations, and
> > lisp is not the only language to have some of these absesnces of the same
> > limitations, so it is really not fair to either trash C more than some other
> > languages, nor is it fair to some other languages to put lisp above them
[ ...]
> Well, I'm not trying to trash C or glorify lisp.
Please understand that the statement I made about fairness to C and lisp
was not about what you or anybody else has said, but about what _I_ said in
the immediately preceding paragraph in the above article. Those elided
statements were intended to draw a contrast between C and lisp, and the
above was intended to generalize it to all "C-like" and "lisp-like"
languages, rather than focussing specifically on C or lisp.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
Hello!
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
>···········@my-deja.com writes:
>[...]
>As others have said, "lispishness" is not equivalent to "functional".
>If you want to learn pure functional style, you should use a pure
>functional language like Prolog.
This isn't true. Prolog is an impure logical language.
Try Haskell for a change (non-strict purely functional).
>However, I don't think that's really
>what you want; functional style is just a buzzword that sometimes
>gets attached to lisp, because it is so hard otherwise to understand
>what "lispishness" is.
For me, lispish is:
- multi-paradigm programming
- language extension (macros, sometimes even reader-macros)
- nice views on OOP, quite different from the often more
popular single dispatch models
But don't take that as gospel, I don't have too much Lisp experience
till now.
So "functional" is only slightly covered in my enumeration
(multi-paradigm which includes using functional aspects when appropriate).
>[...]
Kind regards,
Hannah.
······@schlund.de (Hannah Schroeter) writes:
> Hello!
>
> In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> wrote:
> >···········@my-deja.com writes:
>
> >[...]
>
> >As others have said, "lispishness" is not equivalent to "functional".
> >If you want to learn pure functional style, you should use a pure
> >functional language like Prolog.
>
> This isn't true. Prolog is an impure logical language.
Yep. Sorry; brain-fart. I had meant Scheme. Although I hadn't
thought that Prolog programmers considered it to be impure. By
purity, I mean that the thought process is strongly guided by the
language, not that it has aspects that are not purely logic
programming. Scheme also fits this description for functional
programming, though I don't think it is strictly pure.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
From: Friedrich Dominicus
Subject: Re: Understanding lispishness
Date:
Message-ID: <87y9wnu5ny.fsf@frown.here>
···········@my-deja.com writes:
> I've got a problem, I've tried several times to learn lisp, and all of
> them I've succeeded, sort of. My background is C, perl, python, and
> Java. I have absolutely no problem understanding the syntax and the way
> programs are put together in lisp. What I have a problem with is
> understanding "lispishness" and how to write in a functional way.
You got a lot of good answers. But anyway because I do think I was in
the same situation I allow me to add my experience.
I looked into a "pure" langauge before I started looking into
Lisp. Lisp is one of the few languages which do not drive you in a
particular way of solving your problem. This is a major disadvantage
and major advantage of it. It is not obvious when what approach is
probably "better" (the "" around better should indicate that this is
not to taken as is sounds). So you may look into Haskell, ML or the
like and look into their ways of doing things. There are very good
books available on Haskell which really stress the functional way. If
you do some excersices in those languages you probably will see that
you can write them (totally) simular to those solutions and then you
got the "functional" way.
Just an example (which is used very often) Implement a map in Haskell
and/or Common Lisp you'll how simular they are. The are a bit easier
to understand in Haskell IMHO because in Common Lisp you have to
remember that there are differen namespaces and that you may have to
use funcall which is not necessary in Haskell and/or Scheme.
Here the example written in Haskell
my_map :: (a -> b) -> [a] -> [b]
my_map f [] = []
my_map f (x:xs) = f x:my_map f xs
And this is the same in Lisp
(defun my-map (fn lis)
(if (null lis) '()
(cons (funcall fn (first lis))
(my-map fn (rest lis)))))
Lisp is an older language and takes some of it's history with it,
this is neither good nor bad. Just in some points the age show whereas
in some points other langauges simply can'f follow.
No other language I tried to learn give you as much freedom and
flexibility as Lisp
does. Lisp is IMHo the total counterpart to languages like Eiffel,
Pascal, Modula and/or Ada. This flexibility comes IMHO with a
price. To really learn "doing it the Lispway" takes time, maybe more
time than people are willing to spend. But you get so much back for it
that IMHO everyone should (if not must) learn Lisp.
Regards
Friedrich
In article <············@nnrp1.deja.com>, ···········@my-deja.com wrote:
>Any help would be appreciated.
by the way, since you're getting a bunch of good suggestions, how about
doing us a favor and giving us a product report on your progress in due
time?
sashank
In article <······························@129.59.212.53>,
·············@vanderbilt.edu wrote:
> In article <············@nnrp1.deja.com>, ···········@my-deja.com wrote:
>
>>Any help would be appreciated.
>
> by the way, since you're getting a bunch of good suggestions, how about
> doing us a favor and giving us a product report on your progress in due
> time?
>
> sashank
That shouldn't be a problem...
--
David Allen
http://opop.nols.com/
You might also post some code you consider to be non-Lispish to make things a
little more concrete.
t
David Allen wrote:
> In article <······························@129.59.212.53>,
> ·············@vanderbilt.edu wrote:
>
> > In article <············@nnrp1.deja.com>, ···········@my-deja.com wrote:
> >
> >>Any help would be appreciated.
> >
> > by the way, since you're getting a bunch of good suggestions, how about
> > doing us a favor and giving us a product report on your progress in due
> > time?
> >
> > sashank
>
> That shouldn't be a problem...
>
> --
> David Allen
> http://opop.nols.com/
On Sat, 06 Jan 2001 18:22:34 GMT, ···········@my-deja.com wrote:
> programs are put together in lisp. What I have a problem with is
> understanding "lispishness" and how to write in a functional way.
[...]
> great in C perl or python. What I need help with is either (1) learning
> how to appropriately "translate" that idea or (2) learning how to think
> the idea in the functional langauge to start with.
It has been pointed out elsewhere in this thread that it is limiting to
view Lisp as a single-paradigm language. This quote from Paul Graham's "On
Lisp" also seems relevant:
Efforts to sum up Lisp in a single phrase are probably doomed to failure,
because the power of Lisp arises from the combination of at least five or
six features. Perhaps we should resign ourselves to the fact that the
only accurate name for what Lisp offers is _Lisp_.
Since you said that you have read the book, I suggest that you read the
context from which the above quote is taken. Check note 349 on page 398.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
In article <············@nnrp1.deja.com>,
···········@my-deja.com wrote:
> I've got a problem, I've tried several times to learn lisp, and all of
> them I've succeeded, sort of. My background is C, perl, python, and
> Java. I have absolutely no problem understanding the syntax and the way
> programs are put together in lisp. What I have a problem with is
> understanding "lispishness" and how to write in a functional way.
[...]
If you want to learn Lisp, i recommend Paul Graham's book: "ANSI Common Lisp"
(ISBN - 0-13-370875-6.
I had the same problem; i succeeded in my third try (many years after my
first attempt).
Get the book, get a Lisp system to play with (e.g.: CLISP). Check
http://www.alu.org for free and cheap systems.
Have fun!
g
--
Glauber Ribeiro
··········@my-deja.com http://www.myvehiclehistoryreport.com
"Opinions stated are my own and not representative of Experian"
Sent via Deja.com
http://www.deja.com/