The first of two parts of my Slashdot interview is posted at slashdot.org
Feel free to contribute comments or to answer the comments of non-believers.
Let's make the Lisp community look alive, folks.
So far from reading the responses to your interview I have gleaned a couple
of points.
1) People are interested in Lisp but they would like Lisp to be more
mainstream. Sounds like lots have people have used Lisp and no longer use
Lisp or they would like to learn it but consider it duanting. I am curious
as to why that has happened. It is almost like people are intimidated by
the language. Maybe when it was taught the teachers espoused that it had
such great powers that people thought it could not be used for everyday
little things (like Word Processors ;)). This kind of fits with the guy who
said that Lispers are arrogant and insist that they have the BEST and the
most POWERFUL language.
Then people diss Lisp for all sorts of small details like, too many parans,
can't embed comments (????), slow execution (though lots of people use
Python, etc.). Can people be SCARED of Lisp?? Looking back to when I
started to learn Lisp I had some of those feelings. It was daunting to
learn, but good things take time and effort.
2) The expressed desire to have a more expressive GUI (someone mentioned
SWING). Better FLI support. Here again it seems to be a plea for Lisp to
become more mainstream (integrated) and that here should be less grunt work
to interface to other languages and toolkits. Does anyone know if those
graphical tools developed in the early Lisp implementations (3D engine,
image processing and such) could be brought back into the open for wider
spread use? Where has all the code gone? Is it in the Symbolics/Open
Genera distribution?
3) That Lisp really suffered because of the AI winter.
Wade
"Kent M Pitman" <······@shell01.TheWorld.com> wrote in message
····················@shell01.TheWorld.com...
> The first of two parts of my Slashdot interview is posted at slashdot.org
>
> Feel free to contribute comments or to answer the comments of
non-believers.
> Let's make the Lisp community look alive, folks.
"Wade Humeniuk" <········@cadvision.com> writes:
I'm going to give a lot my opinions. They're largely based on
introducing Lisp to a couple of professional programmers in a company
I interned for last summer (I fear I'm gonna be looking back on it as
my only period has a professional Common Lisp programmer... :(). I'm
obviously writing with far less experience and background then most of
the regulars on this newsgroup, so please bear with me....
> Then people diss Lisp for all sorts of small details like, too many parans,
> can't embed comments (????), slow execution (though lots of people use
> Python, etc.). Can people be SCARED of Lisp?? Looking back to when I
I agree that people are scared of Lisp. This past summer I convinced
by boss to let me use Common Lisp. I prototyped an application that
they were trying to get off the ground; my prototype ran an order of
magnitude faster on hardware that was an order of magnitude cheaper
(the increase didn't have as much to do with the language as with
using less naive algorithms). I then got the opportunity to
demonstrate Common Lisp to the group, both in a presentation and
one-on-one with a couple of the programmers. Here are a few of the
things I noticed they had a hard time with:
1.) The syntax. This is trivial to someone whose been exposed to a lot
of languages, but to some people, especially those who've only been
exposed to languages in one family (Pascal, for example), the syntax
becomes inextricably linked to the semantics of the language. It
seemed very bizarre to them.
2.) The development cycle. I think for a lot of people programming
gets reduced to "write, try to compile, fix syntax errors,
compile (optional with some languages), run, coredump (or watch
errors accumulate), repeat". Even languages that could be
developed in interactively (Python, for example) are often
used with the above idiom. The dynamic nature of the language
can be very hard to grasp.
3.) The reliance on the editor. With Lisp, learning the development
environment right off the bat is more critical then with other
languages. Notepad or vi just doesn't cut it.
4.) The efficiency model. This could be a book. :) A quick point:
to someone used to having to either declare the type of
everything or declare the type of nothing Common Lisp's
optional type declarations can seem confusing.
5.) Having never heard of the language.
6.) Being compiled and interpreted.
7.) The lack of books. Yes, there are some really great books on
Common Lisp. PAIP is superb. I've heard good things about
Graham's Lisp book. However, in general the people that tried
them had a hard time with them. Is there a book *in print* about
Common Lisp that doesn't emphasize recursion at all, doesn't
emphasizes the List data structure to the exclusion of hash
tables, vectors with fill pointers, etc., and doesn't mention
anything AI'ish? They'd go (yes, they actually went and
looked) looking for Lisp books in a book store and not find any
amid bookcases full of 33 thousand mostly horrid C++ and Java
books. It does give one a certain impression of the language.
8.) The lack of courses. One of the first questions my boss asked
was where it was taught. The typical places a professional
programmer might look to take a course (Community Colleges,
local state schools, etc.) don't even mention the language.
There are also some "new" misconceptions that I've noticed as a
(graduating this semester) CS undergrad at Berkeley. A lot of the
students here, both grads and undergrads, have an impression of Lisp
heavily tainted by Scheme, which is the only exposure most get. They
can't even conceive of a fast compiled Lisp with iterative constructs
and a huge library of useful functions.
> 2) The expressed desire to have a more expressive GUI (someone mentioned
> SWING). Better FLI support. Here again it seems to be a plea for Lisp to
> become more mainstream (integrated) and that here should be less grunt work
These criticisms I have a really hard time disagreeing with. :/ I
really would like to see stuff like multiprocessing, GUI (although
CLIM seems to the de facto standard for the last two), FFI, defsystem,
possibly POSIX interfaces, SQL interfaces, etc. standardized. I don't
necessarily mean "included in the standard for ANSI Common Lisp."
I just think that many different vendors providing a variety of
different interfaces to the same functionality is exactly the kind of
thing that standardization was invented for. Yes, it's possible to
write wrappers like CLOCC graciously provides. But having to use
wrappers to write portable code seems like a cry for standardization.
Incidently, CAPI and CLIM were both viewed *very* positively by the
people I showed them to this summer. Having a GUI that's source code
compatible between Windows and Unix was *huge* to them. Common Lisp's
portability is one of its many great strengths.
Gabe Garza
ObDisclaimer: I truly love Common Lisp. I'm not trying to bash it.
Let me be the first to acknowledge I don't know nearly as much about
it or its circumstances as many of the people here....
Gabe Garza <·······@ix.netcom.com> writes:
> "Wade Humeniuk" <········@cadvision.com> writes:
>
> I'm going to give a lot my opinions. They're largely based on
> introducing Lisp to a couple of professional programmers in a company
> I interned for last summer (I fear I'm gonna be looking back on it as
> my only period has a professional Common Lisp programmer... :(). I'm
> obviously writing with far less experience and background then most of
> the regulars on this newsgroup, so please bear with me....
>
> > Then people diss Lisp for all sorts of small details like, too many parans,
> > can't embed comments (????), slow execution (though lots of people use
> > Python, etc.). Can people be SCARED of Lisp?? Looking back to when I
>
> I agree that people are scared of Lisp. This past summer I convinced
> by boss to let me use Common Lisp. I prototyped an application that
> they were trying to get off the ground; my prototype ran an order of
> magnitude faster on hardware that was an order of magnitude cheaper
> (the increase didn't have as much to do with the language as with
> using less naive algorithms).
Heh. I once had a boss-free month (well, sort of -- a layer of
management was missing so we were more or less on our own). "You
wrote what? Cool, wow, we'll use that right away. ... You wrote it
in WHAT?!?!" It took nearly a month to rewrite a 4-day CL project in
C++. *sigh* I never did get the C++ version running as fast, either.
So what I'm saying is, I'm jealous :).
> I then got the opportunity to demonstrate Common Lisp to the group,
> both in a presentation and one-on-one with a couple of the
> programmers. Here are a few of the things I noticed they had a hard
> time with:
>
> 1.) The syntax. This is trivial to someone whose been exposed to a lot
> of languages, but to some people, especially those who've only been
> exposed to languages in one family (Pascal, for example), the syntax
> becomes inextricably linked to the semantics of the language. It
> seemed very bizarre to them.
This is definately something I've noticed as well, and it points out a
serious hole in the education of American CS/EECS undergrads: how can
there be so many of them who literally have *never*, not even lightly,
used a non-Alogol-like language??? These people have CS degrees, for
godsakes, and have never even seen something that looks like Lisp, or
Forth, or PostScript, or SmallTalk, or ...
> 2.) The development cycle. I think for a lot of people programming
> gets reduced to "write, try to compile, fix syntax errors,
> compile (optional with some languages), run, coredump (or watch
> errors accumulate), repeat". Even languages that could be
> developed in interactively (Python, for example) are often
> used with the above idiom. The dynamic nature of the language
> can be very hard to grasp.
>
> 3.) The reliance on the editor. With Lisp, learning the development
> environment right off the bat is more critical then with other
> languages. Notepad or vi just doesn't cut it.
These are both things where Emacs is a lifesaver. Sort of like how if
someone has even lightly used PostScript, they'll have a lot easier of
a time with Lisp syntax. Emacs users I've tried to introduce to Lisp
are fine with these pieces (or can cope, anyhow). Interestingly, VB
people seem to be fine with it too. I've never used it, but I'm
guessing it's a very (development) tool-oriented language?
[...]
> 7.) The lack of books. Yes, there are some really great books on
> Common Lisp. PAIP is superb. I've heard good things about
> Graham's Lisp book. However, in general the people that tried
> them had a hard time with them. Is there a book *in print* about
> Common Lisp that doesn't emphasize recursion at all, doesn't
> emphasizes the List data structure to the exclusion of hash
> tables, vectors with fill pointers, etc., and doesn't mention
> anything AI'ish? They'd go (yes, they actually went and
> looked) looking for Lisp books in a book store and not find any
> amid bookcases full of 33 thousand mostly horrid C++ and Java
> books. It does give one a certain impression of the language.
Oh, no kidding. "Object Oriented Common Lisp" (I think that's the one
I'm thinking of) has done a good job of convincing the hardcore
OO-heads I've pointed towards it, of how cool Lisp is. AI people tend
to be open-minded enough (in my experience) that you can convince them
that their previous problem with Lisp was because they were writing
C-in-Lisp (I know quite a few people whose professors never commented
on their Lisp style, or bothered to help them -- and looking at their
code, I'm amazed they were as productive as they were. It's so much
easier to write C in C, than to try to force Lisp to be C. How did
their profs not mention this???).
Cons cells are cool, and you can hack up all kinds of useful ad-hoc
data structures with them. But they're not the most exciting part of
the language. I mean, there's so much to pick from, and when I see a
Lisp book's contents, I tend to cringe at the way all the other data
types are put off to the end of the book, and are so under-treated.
Smae thing with recursion -- it's cool and all, but so is dynamic
scoping. Imagine a Lisp book that didn't mention that not all
variables had to be declared special, until the second half of the
book. I'm trying to reccomend a book to someone who doesn't know how
to program, who wants to learn, and to someone who only knows C, C++,
and Java, and wants to learn something different. DO, DOLIST, LOOP,
etc, would be really good things for these people to learn, lest they
only write weird, unnecessary recursive code and think that's Lisp's
fault.
Kent, you said you're writing a book/books? PLEASE have the code in
the books look like actual Lisp code that people use. Please please
please.
[...]
> There are also some "new" misconceptions that I've noticed as a
> (graduating this semester) CS undergrad at Berkeley. A lot of the
> students here, both grads and undergrads, have an impression of Lisp
> heavily tainted by Scheme, which is the only exposure most get. They
> can't even conceive of a fast compiled Lisp with iterative constructs
> and a huge library of useful functions.
Yeah, the first thing I show to people after saying "Scheme is not
Common Lisp" is LOOP. Then, you know, you can go into some of the
cool features and explain how big the language is. But LOOP is about
the most un-Schemely thing I can think of, and it seems to get the
message across that these two are *very* different. Oh yeah, that and
some nice type-declared code and the CMUCL disassembly :-)
> ObDisclaimer: I truly love Common Lisp. I'm not trying to bash it.
> Let me be the first to acknowledge I don't know nearly as much about
> it or its circumstances as many of the people here....
Didn't sound at all like bashing, more like loving criticism of the
state of afairs.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@conquest.OCF.Berkeley.EDU>,
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>Gabe Garza <·······@ix.netcom.com> writes:
>> 1.) The syntax. This is trivial to someone whose been exposed to a lot
>> of languages, but to some people, especially those who've only been
>> exposed to languages in one family (Pascal, for example), the syntax
>> becomes inextricably linked to the semantics of the language. It
>> seemed very bizarre to them.
>
>This is definately something I've noticed as well, and it points out a
>serious hole in the education of American CS/EECS undergrads: how can
>there be so many of them who literally have *never*, not even lightly,
>used a non-Alogol-like language??? These people have CS degrees, for
>godsakes, and have never even seen something that looks like Lisp, or
>Forth, or PostScript, or SmallTalk, or ...
algol notation:lisp notation::
newton's calculus notation:leibniz's calculus notation
i've heard it said that english mathematics lost a centry by adopting
newton's inferior notation for nationalistic reasons. one wonders how
much time the computer science world is throwing down the drain ;-)
>>>>> "Sashank" == Sashank Varma <·············@vanderbilt.edu> writes:
Sashank> In article <···············@conquest.OCF.Berkeley.EDU>,
Sashank> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>> Gabe Garza <·······@ix.netcom.com> writes:
>>> 1.) The syntax. This is trivial to someone whose been exposed to a lot
>>> of languages, but to some people, especially those who've only been
>>> exposed to languages in one family (Pascal, for example), the syntax
>>> becomes inextricably linked to the semantics of the language. It
>>> seemed very bizarre to them.
>>
>> This is definately something I've noticed as well, and it points out a
>> serious hole in the education of American CS/EECS undergrads: how can
>> there be so many of them who literally have *never*, not even lightly,
>> used a non-Alogol-like language??? These people have CS degrees, for
>> godsakes, and have never even seen something that looks like Lisp, or
>> Forth, or PostScript, or SmallTalk, or ...
Sashank> algol notation:lisp notation::
Sashank> newton's calculus notation:leibniz's calculus notation
Do you have a pointer to what the notation looked like? Just curious.
Ray
In article <··············@rtp.ericsson.se>, Raymond Toy
<···@rtp.ericsson.se> wrote:
>Do you have a pointer to what the notation looked like? Just curious.
my references didn't turn up much. newton's calculus worked via
something called 'fluxions', which seem to resemble the writing
of nth derivatives with n dots on top of a variable. sorry,
that's all i got out of them. i'll look in my copy of bell's
"men of mathematics" at home tonight.
* Sashank Varma wrote:
> my references didn't turn up much. newton's calculus worked via
> something called 'fluxions', which seem to resemble the writing
> of nth derivatives with n dots on top of a variable. sorry,
> that's all i got out of them. i'll look in my copy of bell's
> "men of mathematics" at home tonight.
Newton had some whole elaborate mechanism of `infinitessimals' which
were numbers smaller than any actual number but not zero. I don't
think he had the idea of limits &c which is important in Leibnitz's
approach. So I think the difference was more than notational.
--tim
In article <···············@cley.com>, "Tim Bradshaw" <···@cley.com>
wrote:
> * Sashank Varma wrote:
>> my references didn't turn up much. newton's calculus worked via
>> something called 'fluxions', which seem to resemble the writing of nth
>> derivatives with n dots on top of a variable. sorry, that's all i got
>> out of them. i'll look in my copy of bell's "men of mathematics" at
>> home tonight.
>
> Newton had some whole elaborate mechanism of `infinitessimals' which
> were numbers smaller than any actual number but not zero. I don't think
> he had the idea of limits &c which is important in Leibnitz's approach.
> So I think the difference was more than notational.
Actually I think the differences were entirely notational. Leibniz had
the same infinitesimal idea, it wasn't until Cauchy that limits were
developed. I could be wrong though.
I think basically newton's notation was ever more "dots" or "primes"
above a derivative... whereas lebiniz had the df/dx notation.
In article <································@sil-no.spam-con.com>, "Daniel
Lakeland" <········@sil-no.spam-con.com> wrote:
>In article <···············@cley.com>, "Tim Bradshaw" <···@cley.com>
>wrote:
>> Newton had some whole elaborate mechanism of `infinitessimals' which
>> were numbers smaller than any actual number but not zero. I don't think
>> he had the idea of limits &c which is important in Leibnitz's approach.
>> So I think the difference was more than notational.
>
>
>Actually I think the differences were entirely notational. Leibniz had
>the same infinitesimal idea, it wasn't until Cauchy that limits were
>developed. I could be wrong though.
the idea of quantities that are infinitesmally small was attacked
by bishop berkeley. his book "the analyst" is dedicated to "an
infidel mathematician" (guess whom?). berkeley was not amused
that edmund halley, a friend of newton's who financed the
publication of "principia", had persuaded a mutual friend to
abandon christianity in the face of newton's achievemnet.
berkeley argued that newton's assumptions were just as tenuous as
those in theology. in particular, he attacked the assumption of
the infinitesmal: quantities with magnitudes greater than 0 that
could not, even with repeated multiplication, be increased to
possess measurable size.
though for the wrong reasons, berkeley was correct in his
criticism of infinitesmals, and calculus was not really secured
until cauchy's definition of the limit concept and the analysts
of the mid-nineteenth century (e.g., weierstrass).
In article <······························@129.59.212.53>, "Sashank Varma"
<·············@vanderbilt.edu> wrote:
> In article <································@sil-no.spam-con.com>,
> "Daniel Lakeland" <········@sil-no.spam-con.com> wrote:
>
>>In article <···············@cley.com>, "Tim Bradshaw" <···@cley.com>
>>wrote:
>>> Newton had some whole elaborate mechanism of `infinitessimals' which
>>> were numbers smaller than any actual number but not zero. I don't
>>> think he had the idea of limits &c which is important in Leibnitz's
>>> approach. So I think the difference was more than notational.
>>
>>
>>Actually I think the differences were entirely notational. Leibniz had
>>the same infinitesimal idea, it wasn't until Cauchy that limits were
>>developed. I could be wrong though.
>
> the idea of quantities that are infinitesmally small was attacked by
> bishop berkeley. his book "the analyst" is dedicated to "an infidel
> mathematician" (guess whom?). berkeley was not amused that edmund
> halley, a friend of newton's who financed the publication of
> "principia", had persuaded a mutual friend to abandon christianity in
> the face of newton's achievemnet. berkeley argued that newton's
> assumptions were just as tenuous as those in theology. in particular,
> he attacked the assumption of the infinitesmal: quantities with
> magnitudes greater than 0 that could not, even with repeated
> multiplication, be increased to possess measurable size.
>
> though for the wrong reasons, berkeley was correct in his criticism of
> infinitesmals, and calculus was not really secured until cauchy's
> definition of the limit concept and the analysts of the mid-nineteenth
> century (e.g., weierstrass).
Abraham Robinson proved that Newton's infinitesemals (Berkeley's "ghosts
of departed quantities" ) actually exist and form an algebraic field if I
remember correctly. I've tried to read Robinson but got lost in the
ultrafilters....
Basically all of what Newton and Leibniz were doing with infinitesemals
turns out to be perfectly valid algebra. Limits are nice, but not
necessary.
the field is called "non-standard analysis" and is an entirely algebraic
treatment of calculus.
On Mon, 12 Nov 2001, Daniel Lakeland wrote:
> Abraham Robinson proved that Newton's infinitesemals (Berkeley's "ghosts
> of departed quantities" ) actually exist and form an algebraic field if I
> remember correctly. I've tried to read Robinson but got lost in the
> ultrafilters....
>
> Basically all of what Newton and Leibniz were doing with infinitesemals
> turns out to be perfectly valid algebra. Limits are nice, but not
> necessary.
>
> the field is called "non-standard analysis" and is an entirely algebraic
> treatment of calculus.
>
Non-standard analysis is really amazing in some ways. Some really ugly,
hard proofs of calculus theorems become immediately clear and intuitive.
Learning calculus, the way I understood things was using infinitesimals.
Of course the book had all the proofs and theory using limits, but I would
only really understand things when thinking of dx as an infinitesimal.
Here's one example: Given dy/dx, calculate dx/dy by inverting.
y(x) = x^3, so x(y) = y^(1/3)
dy / dx = 3x^2
dx / dy = 1 / 3x^2 = 1 / (3 y^(1/3)^2 ) = y^(-2/3) / 3
This trick works, but why? Using infinitesimals it is just a calculation.
I'm still not sure why it works using standard analysis.
--
Nathan
·············@vanderbilt.edu (Sashank Varma) writes:
> In article <································@sil-no.spam-con.com>, "Daniel
> Lakeland" <········@sil-no.spam-con.com> wrote:
>
> >In article <···············@cley.com>, "Tim Bradshaw" <···@cley.com>
> >wrote:
> >> Newton had some whole elaborate mechanism of `infinitessimals' which
> >> were numbers smaller than any actual number but not zero. I don't think
> >> he had the idea of limits &c which is important in Leibnitz's approach.
> >> So I think the difference was more than notational.
> >
> >
> >Actually I think the differences were entirely notational. Leibniz had
> >the same infinitesimal idea, it wasn't until Cauchy that limits were
> >developed. I could be wrong though.
>
> the idea of quantities that are infinitesmally small was attacked
> by bishop berkeley. his book "the analyst" is dedicated to "an
> infidel mathematician" (guess whom?). berkeley was not amused
> that edmund halley, a friend of newton's who financed the
> publication of "principia", had persuaded a mutual friend to
> abandon christianity in the face of newton's achievemnet.
> berkeley argued that newton's assumptions were just as tenuous as
> those in theology. in particular, he attacked the assumption of
> the infinitesmal: quantities with magnitudes greater than 0 that
> could not, even with repeated multiplication, be increased to
> possess measurable size.
>
> though for the wrong reasons, berkeley was correct in his
> criticism of infinitesmals, and calculus was not really secured
> until cauchy's definition of the limit concept and the analysts
> of the mid-nineteenth century (e.g., weierstrass).
robinson's _non-standard analysis_ puts infinitesimals onto a rigorous
footing. he shows that a calculous of infinitesimals can be made
equally powerful with the cauchy epsilon delta style. robinson goes
on to assert that some proofs are easier to derive using
infinitesimals. the infinitesimal style seems pretty straightforward
although there are a few points you need to be careful about.
the basic idea is to posit the existence of inifinitely large natural
numbers. these numbers follow the same rules of arithmetic as the
normal finite variety. all regular rules about natural numbers carry
over to the extended set of naturals.
he creates a set of extended reals from these extended naturals in the
usual way. an infinitesmial is a finite number divided by some
infinite number. the ordinary reals are a quotient set of
the extended reals where extended reals differing by at most an
infinitesimal are considered the same.
the catch seems to be that statements about whether a certain number
is finite or infinite have to be made with extra care. these do not
"just carry over" from ordinary maths.
you are correct that cauchy secured calculus. however, infinitesimals
can be used to secure the exact same calculus just as well. after
briefly looking at them, they seem to me to be reasonably easy to
grasp. it is maybe just an accident of history that cauchy's style
came first. or maybe the infinitesimal style required getting more
used to working with sets and infinities which occurred late in the
19th century and bled over into the early 20th.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
sysengr
·············@vanderbilt.edu (Sashank Varma) writes:
> though for the wrong reasons, berkeley was correct in his
> criticism of infinitesmals, and calculus was not really secured
> until cauchy's definition of the limit concept and the analysts
> of the mid-nineteenth century (e.g., weierstrass).
Infinitesimals can be made rigorous, but this is a 20th century
achievement known as "non-standard analysis". It's primarily used in
logic to show independence of certain axioms and to get different
models than the standard ones. It's not harder than the usual
epsilon-delta way and there has been one college level calculus text
using this approach, but it hasn't caught on.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
In article <··············@localhost.localdomain>, Lieven Marchand
<···@wyrd.be> wrote:
>·············@vanderbilt.edu (Sashank Varma) writes:
>
>> though for the wrong reasons, berkeley was correct in his
>> criticism of infinitesmals, and calculus was not really secured
>> until cauchy's definition of the limit concept and the analysts
>> of the mid-nineteenth century (e.g., weierstrass).
>
>Infinitesimals can be made rigorous, but this is a 20th century
>achievement known as "non-standard analysis". It's primarily used in
>logic to show independence of certain axioms and to get different
>models than the standard ones.
this is what i get for trying to remember mathematics i haven't
touched in over a decade. now if you'll excuse me, i have some
proofs-by-contradiction that i have to finish up...
·············@vanderbilt.edu (Sashank Varma) writes:
> though for the wrong reasons, berkeley was correct in his
> criticism of infinitesmals, and calculus was not really secured
There's nothing intrinsically wrong with infinitesimals. The trouble
is, you need 20th century logic to show this.
Andras
"Tim Bradshaw" <···@cley.com> wrote in message
····················@cley.com...
> * Sashank Varma wrote:
> > my references didn't turn up much. newton's calculus worked via
> > something called 'fluxions', which seem to resemble the writing
> > of nth derivatives with n dots on top of a variable. sorry,
> > that's all i got out of them. i'll look in my copy of bell's
> > "men of mathematics" at home tonight.
>
> Newton had some whole elaborate mechanism of `infinitessimals' which
> were numbers smaller than any actual number but not zero. I don't
> think he had the idea of limits &c which is important in Leibnitz's
> approach. So I think the difference was more than notational.
This is way off topic, but WTH...
There's a newish book called "Where Mathematics Comes From", by
Lakoff and Nunez, which I highly recommend. It describes the "tower
of metaphors" that lead to the equation (= (+ (^ $e (* $pi $i)) 1) 0),
which requires a pretty lengthy discussion of infinity and infinitesimals.
The story of these concepts is, honestly, really fascinating.
* "Scott McKay" <···@mediaone.net>
| There's a newish book called "Where Mathematics Comes From", by
| Lakoff and Nunez, which I highly recommend. It describes the "tower
| of metaphors" that lead to the equation (= (+ (^ $e (* $pi $i)) 1) 0),
| which requires a pretty lengthy discussion of infinity and infinitesimals.
| The story of these concepts is, honestly, really fascinating.
Is that (zerop (1+ (exp (complex 0 pi)))) in Common Lisp? :)
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
In article <················@naggum.net>, Erik Naggum wrote:
> Is that (zerop (1+ (exp (complex 0 pi)))) in Common Lisp? :)
Yep, that's it in Common Lisp.
Unfortunately, besides leaving out if* (sorry!), the ANSI standard
forgot to require infinite precision real arithmetic ;-)
Euler might be surprised that (1+ (exp (complex 0 pi))) evaluates
to #c(0.0d0 1.2246063538223773d-16) in modern times.
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
In article <····················@boa.b9.com>, Kevin Rosenberg wrote:
> Unfortunately, besides leaving out if* (sorry!), the ANSI standard
> forgot to require infinite precision real arithmetic ;-)
Oops, I need to retract that thought. If the standard did require
infinite precision arithmetic, implementations of ANSI CL may fit the
myth of Lisp being "slow".
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
Kevin Rosenberg <·····@rosenberg.net> writes:
> In article <····················@boa.b9.com>, Kevin Rosenberg wrote:
> > Unfortunately, besides leaving out if* (sorry!), the ANSI standard
> > forgot to require infinite precision real arithmetic ;-)
>
> Oops, I need to retract that thought. If the standard did require
> infinite precision arithmetic, implementations of ANSI CL may fit the
> myth of Lisp being "slow".
Don't forget arbitrary-precision rationals. Once you're not in a machine
word any more, the only difference between rationals and floats is that
floats have gaps in their space and rationals don't...
Kevin Rosenberg <·····@rosenberg.net> writes:
> Bruce Hoult wrote:
> > Kent M Pitman <······@world.std.com> wrote:
> >> Don't forget arbitrary-precision rationals. Once you're not in a machine
> >> word any more, the only difference between rationals and floats is that
> >> floats have gaps in their space and rationals don't..
> >
> > And also lazy continued-fractions. You can have a representation of the
> > exact result which is only ever evaluated as far as necessary to produce
> > the digits that are actually printed.
>
> Right you two are. I meant to say in hyperbole "infinite precision
> irrational constants and functions." The (zerop ...) test in the
> Common Lisp version of Euler's formula will only be numerically true
> with infinite calculations.
Isn't that what Bruce is suggesting? Lazy as in returning a "future" (a
promise for a result that's still being computed, as in the Star Trek
Classic episode "A Wolf In the Fold").
In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
> Isn't that what Bruce is suggesting? Lazy as in returning a "future" (a
> promise for a result that's still being computed, as in the Star Trek
> Classic episode "A Wolf In the Fold").
I don't recall that episode by name, but yes, a lazy result as in
"pipes" in PAIP and "streams" in SICP. I can see how lazy
continued-fractions can be used for arbitrary precision arithmetic. So,
if one wrote their own (exp) and (return-pi) functions using continued
fractions [cf], one could get a T result for
(zerop (1+ (my-cf-exp (complex 0 (my-cf-pi-generator)))))
"after" calculating infinitely .
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
Kevin Rosenberg <·····@rosenberg.net> writes:
> In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
> > Isn't that what Bruce is suggesting? Lazy as in returning a "future" (a
> > promise for a result that's still being computed, as in the Star Trek
> > Classic episode "A Wolf In the Fold").
>
> I don't recall that episode by name,
The immortal spirit of Jack the Ripper gets into the computer, and
Spock tells the computer to "compute to the last digit, the value of
pi"... He made it a class 1 priority directive to assure that the
the computer would turn bank after bank to the problem, squeezing out
the bad guy, who is presumably not smart enough to hide in the area
that has life support and will (hopefully) be last to go.
> but yes, a lazy result as in
> "pipes" in PAIP and "streams" in SICP. I can see how lazy
> continued-fractions can be used for arbitrary precision arithmetic. So,
> if one wrote their own (exp) and (return-pi) functions using continued
> fractions [cf], one could get a T result for
> (zerop (1+ (my-cf-exp (complex 0 (my-cf-pi-generator)))))
> "after" calculating infinitely .
Exactly.
In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
> The immortal spirit of Jack the Ripper gets into the computer, and
> Spock tells the computer to "compute to the last digit, the value of
> pi"... He made it a class 1 priority directive to assure that the
> the computer would turn bank after bank to the problem, squeezing out
> the bad guy, who is presumably not smart enough to hide in the area
> that has life support and will (hopefully) be last to go.
Thanks for refreshing my memory. Yes, it makes plots much easier to manipulate
if characters don't always act "reasonably."
>> (zerop (1+ (my-cf-exp (complex 0 (my-cf-pi-generator)))))
>> "after" calculating infinitely .
I understand that Lisp can support arbitrary precision. My initial post about
lack of infinite precision irrational functions was sparked in the gap be
evaluation
(zerop (1+ (exp (complex 0 pi))))
and getting NIL and then me realizing precision limitations.
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> The immortal spirit of Jack the Ripper gets into the computer, and
> Spock tells the computer to "compute to the last digit, the value of
> pi"... He made it a class 1 priority directive to assure that the
> the computer would turn bank after bank to the problem, squeezing out
> the bad guy, who is presumably not smart enough to hide in the area
> that has life support and will (hopefully) be last to go.
Surely by the time of star trek people will have worked out that
having the life-support fail in the absence of the (single) central
computer is kind of dumb?
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> > The immortal spirit of Jack the Ripper gets into the computer, and
> > Spock tells the computer to "compute to the last digit, the value
> > of pi"... He made it a class 1 priority directive to assure that
> > the the computer would turn bank after bank to the problem,
> > squeezing out the bad guy, who is presumably not smart enough to
> > hide in the area that has life support and will (hopefully) be
> > last to go.
> Surely by the time of star trek people will have worked out that
> having the life-support fail in the absence of the (single) central
> computer is kind of dumb?
Ah, but that would prevent this sort of facile plot device.
[And presumably the Lisp variation on it would involve Kirk typing in
(GC) at a critical moment to cause their systems to crash...]
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www.ntlug.org/~cbbrowne/xwindows.html
For a good prime call:
391581 * 2^216193 - 1
-- ····@cornell.edu (Szymon Rusinkiewicz)
In article <···············@shell01.TheWorld.com>, "Kent M Pitman"
<······@world.std.com> wrote:
> Kevin Rosenberg <·····@rosenberg.net> writes:
>
>> In article <····················@boa.b9.com>, Kevin Rosenberg wrote:
>> > Unfortunately, besides leaving out if* (sorry!), the ANSI standard
>> > forgot to require infinite precision real arithmetic ;-)
>>
>> Oops, I need to retract that thought. If the standard did require
>> infinite precision arithmetic, implementations of ANSI CL may fit the
>> myth of Lisp being "slow".
>
> Don't forget arbitrary-precision rationals. Once you're not in a
> machine word any more, the only difference between rationals and floats
> is that floats have gaps in their space and rationals don't...
Yeah like that rational that you can square to equal 2.
;-)
Kevin Rosenberg <·····@rosenberg.net> writes:
> Thanks for refreshing my memory. Yes, it makes plots much easier to
> manipulate if characters don't always act "reasonably."
>
> >> (zerop (1+ (my-cf-exp (complex 0 (my-cf-pi-generator)))))
> >> "after" calculating infinitely .
>
> I understand that Lisp can support arbitrary precision. My initial post about
> lack of infinite precision irrational functions was sparked in the gap be
> evaluation
> (zerop (1+ (exp (complex 0 pi))))
> and getting NIL and then me realizing precision limitations.
I believe Macsyma and other such systems employ some sort of fuzz
parameter that is used for fixing this according to advice from users.
MACLISP for the PDP10 (but not Multics, sigh--typical of MACLISP) even
did some of this (not for complexes, but for floats) primitively
through a variable called ZFUZZ (default NIL) defined as: "If this
variable's value is not NIL, then PLUS and DIFFERENCE perform a
special fuzz check on floating point numbers. If x and y are the
numbers to be added (possibly after contagious conversion to floating
point), then if x + y < y * ZFUZZ then the result is forced to zero."
I'm not sure what the success rate was with this; perhaps the fact that
it got left behind in MACLISP and not moved along into CL says it
was a failure. (JonL White's not out there lurking is he? He'd
probably know.)
In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
> I believe Macsyma and other such systems employ some sort of fuzz
> parameter that is used for fixing this according to advice from users.
> MACLISP for the PDP10 (but not Multics, sigh--typical of MACLISP) even
> did some of this (not for complexes, but for floats) primitively
> through a variable called ZFUZZ (default NIL) defined as: "If this
> variable's value is not NIL, then PLUS and DIFFERENCE perform a
> special fuzz check on floating point numbers. If x and y are the
> numbers to be added (possibly after contagious conversion to floating
> point), then if x + y < y * ZFUZZ then the result is forced to zero."
> I'm not sure what the success rate was with this; perhaps the fact that
> it got left behind in MACLISP and not moved along into CL says it
> was a failure. (JonL White's not out there lurking is he? He'd
> probably know.)
As always, I appreciate your insight steeped with experience and history.
For a persistent Lisp database that I am writing under contract, I
need to compare two double-floats for equality. In a testing section,
I compare a double-float after storage in a 8-byte floating point SQL
field with the original Lisp double-float.
I found that
(< (/ (abs (- f1 f2)) f1) (* 10 double-float-epsilon))
as test of equality works well in this application.
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
Kent M Pitman:
KMP> I believe Macsyma and other such systems employ some sort of fuzz
KMP> parameter that is used for fixing this according to advice from users.
(AND (= x y) (= y z)) implies (= x z)
How many of your programs rely on this property? (Memoisation,
caching, etc.)
In my case, the answer is ``I don't know.'' Which means that I
implicitly rely on this property all the time, and don't even notice
when I use it.
KMP> I'm not sure what the success rate was with this; perhaps the
KMP> fact that it got left behind in MACLISP and not moved along into
KMP> CL says it was a failure.
I can't say I'm surprised.
Juliusz
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> Kent M Pitman:
>
> KMP> I believe Macsyma and other such systems employ some sort of fuzz
> KMP> parameter that is used for fixing this according to advice from users.
>
> (AND (= x y) (= y z)) implies (= x z)
>
> How many of your programs rely on this property? (Memoisation,
> caching, etc.)
>
> In my case, the answer is ``I don't know.'' Which means that I
> implicitly rely on this property all the time, and don't even notice
> when I use it.
Kent was talking about Macsyma in numerical mode. Numerical analysts
are aware of those subtleties, and similar ones.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
Kent M Pitman:
KMP> I believe Macsyma and other such systems employ some sort of fuzz
KMP> parameter that is used for fixing this according to advice from users.
>> (AND (= x y) (= y z)) implies (= x z)
>> How many of your programs rely on this property?
Lieven Marchand:
LM> Kent was talking about Macsyma in numerical mode.
I was actually reacting to Kent's comment that this feature was
present in late MacLisp, and that it hasn't caught up in later Lisp
dialects. I am glad it hasn't, as it breaks a number of assumptions
that people routinely rely on in their code.
I would never dare comment on formal algebra systems, about which I
know next to nothing.
LM> Numerical analysts are aware of those subtleties, and similar
LM> ones.
Or perhaps they avoid using equality on floats in the first place?
Juliusz
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> Kent M Pitman:
>
> KMP> I believe Macsyma and other such systems employ some sort of fuzz
> KMP> parameter that is used for fixing this according to advice from users.
>
> >> (AND (= x y) (= y z)) implies (= x z)
>
> >> How many of your programs rely on this property?
>
> Lieven Marchand:
>
> LM> Kent was talking about Macsyma in numerical mode.
>
> I was actually reacting to Kent's comment that this feature was
> present in late MacLisp
but disabled by default; something, that like all features of the language,
could be enabled by competent people under competent circumstances
> , and that it hasn't caught up in later Lisp
> dialects. I am glad it hasn't, as it breaks a number of assumptions
> that people routinely rely on in their code.
Not by default.
But you're right that it could be an "attractive nuisance" (term of
art in the legal domain for something that confusingly let people
access and perhaps even conspicuously advertise the presence of, but
then get mad when they do access ...like leaving an outdoor shopping
mall open and lit for people to browse at night and then disclaiming
responsibility for injuries due to your failure to de-ice its
sidewalks by saying the mall was closed and people shouldn't have been
there) that people would try to set without understanding it and then
would confuse themselves. Then again, you can't really protect people
from themselves in all cases where they can hurt themselves and the
question, at least in my mind, is always: does the system/language
having a first-class understanding of this enable it to give better
support (efficiency or control) than the user would have trying to
simulate it. I'm not lobbying for any particular answer in that
point, just observing the issue. I've done a lot of work around the
periphery of numerical analysts over my career, having worked almost a
decade of it on Macsyma, but I more or less believe all floating point
issues should be decided by numerical analysts and that users should
mostly stay clear of them for all but the simplest of applications.
Floats themselves are the *real* attractive nuisances, IMO, but people
insist on using them as if they were precise, as if they were a
uniform space, etc. We might be better off with a money datatype, for
example. Understanding how floats really work (not what the
operations are but what the significance of the operations are in the
general case) is very hard.
This is also probably a case, though, where lexical rather than
dynamic control is probably safer, since having this quality vary
dynamically compounds the complexity of testing.
> I would never dare comment on formal algebra systems, about which I
> know next to nothing.
I feel somewhat similar.
> LM> Numerical analysts are aware of those subtleties, and similar
> LM> ones.
>
> Or perhaps they avoid using equality on floats in the first place?
I'd strike "equality on" here. ;-)
Kent M Pitman <······@world.std.com> writes:
> I've done a lot of work around the periphery of numerical analysts
> over my career, having worked almost a decade of it on Macsyma, but
> I more or less believe all floating point issues should be decided
> by numerical analysts and that users should mostly stay clear of
> them for all but the simplest of applications.
I wish.
> Understanding how floats really work (not what the operations are
> but what the significance of the operations are in the general case)
> is very hard.
It's not that bad. Making Goldberg's paper "What every computer
scientist should know about floating point" required reading for CS
courses would do a great deal to get the basics through.
> > LM> Numerical analysts are aware of those subtleties, and similar
> > LM> ones.
> >
> > Or perhaps they avoid using equality on floats in the first place?
>
> I'd strike "equality on" here. ;-)
Numerical analysts definitely use floats. They try to avoid
cancellation, naive algorithms to sum a sequence of numbers and other
stuff. But on occasion, even equality on floats gets used. If you
implement Newton's algorithm for square roots correctly with an IEEE
float model in mind, you can iterate with a (eql difference 0.0)
condition.
--
Lieven Marchand <···@wyrd.be>
She says, "Honey, you're a Bastard of great proportion."
He says, "Darling, I plead guilty to that sin."
Cowboy Junkies -- A few simple words
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
> Kevin Rosenberg <·····@rosenberg.net> writes:
>
> > In article <····················@boa.b9.com>, Kevin Rosenberg wrote:
> > > Unfortunately, besides leaving out if* (sorry!), the ANSI standard
> > > forgot to require infinite precision real arithmetic ;-)
> >
> > Oops, I need to retract that thought. If the standard did require
> > infinite precision arithmetic, implementations of ANSI CL may fit the
> > myth of Lisp being "slow".
>
> Don't forget arbitrary-precision rationals. Once you're not in a machine
> word any more, the only difference between rationals and floats is that
> floats have gaps in their space and rationals don't..
And also lazy continued-fractions. You can have a representation of the
exact result which is only ever evaluated as far as necessary to produce
the digits that are actually printed.
-- Bruce
Bruce Hoult wrote:
> Kent M Pitman <······@world.std.com> wrote:
>> Don't forget arbitrary-precision rationals. Once you're not in a machine
>> word any more, the only difference between rationals and floats is that
>> floats have gaps in their space and rationals don't..
>
> And also lazy continued-fractions. You can have a representation of the
> exact result which is only ever evaluated as far as necessary to produce
> the digits that are actually printed.
Right you two are. I meant to say in hyperbole "infinite precision
irrational constants and functions." The (zerop ...) test in the
Common Lisp version of Euler's formula will only be numerically true
with infinite calculations.
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
"Daniel Lakeland" <········@sil-no.spam-con.com> writes:
> In article <···············@shell01.TheWorld.com>, "Kent M Pitman"
> <······@world.std.com> wrote:
>
> > Don't forget arbitrary-precision rationals. Once you're not in a
> > machine word any more, the only difference between rationals and floats
> > is that floats have gaps in their space and rationals don't...
>
> Yeah like that rational that you can square to equal 2. ;-)
I know this was said with a smiley, but...
Arbitrary precision floats are going to fix this?
The secret truth is that floats ARE rationals. They are not reals.
They have a numerator and a denominator (sort of) but the number of bits
of precision in the numerator is irregular, leading to an oddly shaped
space. The real rational space, by which I mean the authentic
rational space, is better than this irregularly shaped space
where the FLOAT type doesn't have room to represent something. Floats'
primary value is for machine word computations, as I understand it, and
their value goes down a lot after that.
Macsyma has something called bigfloats that are similar to bignums, except
they are maintained to a specified precision (rather than growing to
different precision as computations progress). They're represented by
some integers that include numerator/denominator information plus hidden
bits and also some explicit precision information.
I remember about 20 years ago, at some Symbolic Algebra conference I
went to, back when I did that kind of thing, the guys at the Soft
Warehouse (Al Rich, who did MuLisp and David Stoutemeyer, who did
MuMath) were talking about making an actual "real" datatype, different
from rationals, for use in MuMath, their symbolic algebra tool. I
don't know if they ever did this, but it might be fun for someone to
find out. (Not me, I'm too busy with other things...)
Kent M Pitman <······@world.std.com> writes:
...
> The secret truth is that floats ARE rationals. They are not reals.
> They have a numerator and a denominator (sort of) but the number of bits
> of precision in the numerator is irregular, leading to an oddly shaped
> space. The real rational space, by which I mean the authentic
> rational space, is better than this irregularly shaped space
> where the FLOAT type doesn't have room to represent something. Floats'
> primary value is for machine word computations, as I understand it, and
> their value goes down a lot after that.
This is an interesting thread. Could you explain what you mean by
machine word computations?
--
--Ed Cashin integrit file-verification system:
·······@terry.uga.edu http://integrit.sourceforge.net/
Note: If you want me to send you email, don't munge your address.
Ed L Cashin <·······@terry.uga.edu> writes:
> Kent M Pitman <······@world.std.com> writes:
> ....
> > The secret truth is that floats ARE rationals. They are not
> > reals. They have a numerator and a denominator (sort of) but the
> > number of bits of precision in the numerator is irregular, leading
> > to an oddly shaped space. The real rational space, by which I
> > mean the authentic rational space, is better than this irregularly
> > shaped space where the FLOAT type doesn't have room to represent
> > something. Floats' primary value is for machine word
> > computations, as I understand it, and their value goes down a lot
> > after that.
> This is an interesting thread. Could you explain what you mean by
> machine word computations?
Presumably this is about the notion that you can use instructions
similar to FADD, FMUL, FSUB, FDIV to do floating point operations as
single FPU instructions.
It is common for CPUs to have special instructions to deal with the
sorts of rational numbers expressed as FLOATS, so that:
a) Relevant operations are atomic;
b) The operations are pretty fast;
c) There tend to be language features to conveniently support
loading, calculating, displaying, and storing FLOAT;
d) There are commonly well-understood linear algebra and calculus
libraries to work with 'em.
There may be various ways in which a FLOAT is ugly, but the above
four things make them _convenient_ for lots of purposes...
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www.cbbrowne.com/info/languages.html
Rules of the Evil Overlord #224. "I will build machines which simply
fail when overloaded, rather than wipe out all nearby henchmen in an
explosion or worse yet set off a chain reaction. I will do this by
using devices known as "surge protectors"."
<http://www.eviloverlord.com/>
In article <···············@shell01.TheWorld.com>, Kent M Pitman
<······@world.std.com> wrote:
>I remember about 20 years ago, at some Symbolic Algebra conference I
>went to, back when I did that kind of thing, the guys at the Soft
>Warehouse (Al Rich, who did MuLisp and David Stoutemeyer, who did
>MuMath) were talking about making an actual "real" datatype, different
>from rationals, for use in MuMath, their symbolic algebra tool. I
>don't know if they ever did this, but it might be fun for someone to
>find out. (Not me, I'm too busy with other things...)
Two vague memories:
(1) I think that Bill Gosper advocates the use of continued fraction
representations for real numbers because they can be used to
relatively efficiently maintain arbitrarily good precision.
(2) Gareth McGoughan (sp) posted here several years ago about a set
of routines he was developing that also supported arbitrarily
good precision for better approximating real numbers.
My recollection is that both schemes were like the infinite streams
idiom, computing additional digits of precision only when needed.
Sashank Varma:
SV> (1) I think that Bill Gosper advocates the use of continued fraction
SV> representations for real numbers because they can be used to
SV> relatively efficiently maintain arbitrarily good precision.
I know of some work using ``triadic'' expansions, base 2 expansions
but using the digits -1, 0 and 1. This way, a function may update its
current estimate of the result both up and downwards (unlike in usual
base 2 notation, where it can only update it upwards).
Programming with these systems is a little tricky. In particular,
- ZEROP is not computable (requires infinite work at 0);
- neither (lambda (x) (>= x 0)) nor (lambda (x) (> x 0)) are
computable (require infinite work in the limit case) [1];
- more generally, no total map from reals to any discrete set is
computable (and every computable total map from reals to reals is
continuous in the usual sense.)
(Of course, these systems don't actually give you infinite expansions;
I rather see them as giving finite expansions but with a reliable
estimate of the error, unlike usual floating-point arithmetic which
may very well give a result with 42 digits, none of which are
significant.)
I can dig for some bibliography if people are interested. Martin
Escardo's homepage at St. Andrews University may be a good starting
point.
Juliusz
[1] One nice thing about c.l.l. is that you can use lambda notation
without people staring blankly at you.
Sashank Varma wrote:
> (2) Gareth McGoughan (sp) posted here several years ago about a set
> of routines he was developing that also supported arbitrarily
> good precision for better approximating real numbers.
>
> My recollection is that both schemes were like the infinite streams
> idiom, computing additional digits of precision only when needed.
Well, that was a fairly decent approximation to my name,
which fortunately is only finitely long :-). My REAL package
(about 440 non-comment non-blank lines) represents a real
number x as a function which maps any number N to something
within 1/2 of Nx. <pedant>Actually, the "function" can
change with time.</pedant> It's rather a mess, and I have
trouble imagining any situation in which it would actually
be useful, especially as the REAL version of (zerop (- 1 1))
never terminates.
I think it would be possible to make an honest REAL type
with fairly decent performance. The ingredients would be:
- representing some particular sorts of number
in a canonical form. Rationals, obviously;
possibly algebraic numbers as well. Maybe some
special cases (rational multiples of pi, which
could be treated specially by trigonometric
functions? rational powers of e? that sort of
thing) too.
- maintaining for each REAL number a "good" (but size-limited)
approximation to its value; say, an integer and two double-floats
such that the number is known to be between
(* x0 (ash 1 n)) and (* x1 (ash 1 n)).
Since most of the time you only need fairly low
precision, this would enable most of the things
you'd want to do with REALs to be within, say,
an order of magnitude of double-float performance
(unless limited by, e.g., the performance of the
object system). Keep the integer zero whenever
possible, and special-case that in the calculations.
- a better choice than mine of the representation
for "real" REALs. I suggest (tentatively): a "function"
(see the caveat above) which maps N to an integer
within 1 of (* x (ash 1 n)).
- aggressive use of memoization, with some sort of
strategy for throwing away little-used mappings.
I think LEDA (a "Library of Efficient Data structures
and Algorithms" for C++) has something of this kind
for use in geometrical algorithms, where horrible precision
loss can occur when (e.g.) you have nearly parallel lines.
They claim that (since the limited-precision calculations
are usually good enough) they get performance within a
factor of 2 or 3 of double-floats.
Doing this properly would be a lot of fun, but also a lot
of work. If I were implementing a symbolic mathematics
system then I'd seriously consider doing numbers this way.
Perhaps it's just as well that I'm not implementing a
symbolic mathematics package.
--
Gareth McCaughan ················@pobox.com
.sig under construc
In article <···············@shell01.TheWorld.com>, "Kent M Pitman"
<······@world.std.com> wrote:
> "Daniel Lakeland" <········@sil-no.spam-con.com> writes:
>
>> In article <···············@shell01.TheWorld.com>, "Kent M Pitman"
>> <······@world.std.com> wrote:
>>
>> > Don't forget arbitrary-precision rationals. Once you're not in a
>> > machine word any more, the only difference between rationals and
>> > floats is that floats have gaps in their space and rationals don't...
>>
>> Yeah like that rational that you can square to equal 2. ;-)
>
> I know this was said with a smiley, but...
>
> Arbitrary precision floats are going to fix this?
You're right, the rational datatype is "dense" in the real line (to the
limit of available RAM), the float datatype is discrete and irregular.
Most floats won't represent 10^-(10000) for example.
basically the rational datatype *is* an arbitrary precision float
(abstractly).
But the smiley was there because I knew you knew.
Kent M Pitman <······@world.std.com> writes:
> The secret truth is that floats ARE rationals. They are not reals.
> They have a numerator and a denominator (sort of) but the number of bits
> of precision in the numerator is irregular, leading to an oddly shaped
> space.
..not to mention that the denominator is always a power of a fixed
base (usually 2 these days...) - resulting in another set of holes
wrt the full space of rational numbers.
Ole
"ROHNE Ole" <······@suntrt2.cern.ch> wrote in message
····················@suntrt2.cern.ch...
> Kent M Pitman <······@world.std.com> writes:
>
> > The secret truth is that floats ARE rationals. They are not reals.
> > They have a numerator and a denominator (sort of) but the number of bits
> > of precision in the numerator is irregular, leading to an oddly shaped
> > space.
>
> ..not to mention that the denominator is always a power of a fixed
> base (usually 2 these days...) - resulting in another set of holes
> wrt the full space of rational numbers.
It's ironic, isn't it, that US stock markets now use decimals
because we're in the computer age, and decimals are more
accurate than those silly old 1/8's. Oops.
In article <······················@typhoon.ne.mediaone.net>, "Scott McKay"
<···@mediaone.net> wrote:
> "ROHNE Ole" <······@suntrt2.cern.ch> wrote in message
> ····················@suntrt2.cern.ch...
>> Kent M Pitman <······@world.std.com> writes:
>>
>> > The secret truth is that floats ARE rationals. They are not reals.
>> > They have a numerator and a denominator (sort of) but the number of
>> > bits of precision in the numerator is irregular, leading to an oddly
>> > shaped space.
>>
>> ..not to mention that the denominator is always a power of a fixed base
>> (usually 2 these days...) - resulting in another set of holes wrt the
>> full space of rational numbers.
>
> It's ironic, isn't it, that US stock markets now use decimals because
> we're in the computer age, and decimals are more accurate than those
> silly old 1/8's. Oops.
I thought that was funny too.
but I think the real reason is because our monetary system is decimal,
and people have an easier time understanding the difference between say
.13 and .19 vs 1/8 and 3/16
"Daniel Lakeland" <········@sil-no.spam-con.com> writes:
> In article <······················@typhoon.ne.mediaone.net>, "Scott McKay"
> <···@mediaone.net> wrote:
> > It's ironic, isn't it, that US stock markets now use decimals because
> > we're in the computer age, and decimals are more accurate than those
> > silly old 1/8's. Oops.
>
> I thought that was funny too.
That one irritated me big-time; it's a representation that makes it
_dead easy_ to do exact arithmetic. And these clowns expect that
moving to FP is NOT going to give them a lot of new headaches?
> but I think the real reason is because our monetary system is
> decimal, and people have an easier time understanding the difference
> between say ..13 and .19 vs 1/8 and 3/16
If they wanted more accuracy, going from /8ths to /16ths would be
_better_ than going to /10ths.
Bleh...
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www.cbbrowne.com/info/linux.html
"I will not send lard through the mail" ^ 100 -- Bart Simpson
In article <·····················@news20.bellglobal.com>, "cbbrowne"
<········@acm.org> wrote:
> "Daniel Lakeland" <········@sil-no.spam-con.com> writes:
>> In article <······················@typhoon.ne.mediaone.net>, "Scott
>> McKay" <···@mediaone.net> wrote:
>> > It's ironic, isn't it, that US stock markets now use decimals because
>> > we're in the computer age, and decimals are more accurate than those
>> > silly old 1/8's. Oops.
>>
>> I thought that was funny too.
>
> That one irritated me big-time; it's a representation that makes it
> _dead easy_ to do exact arithmetic. And these clowns expect that moving
> to FP is NOT going to give them a lot of new headaches?
>
>> but I think the real reason is because our monetary system is decimal,
>> and people have an easier time understanding the difference between say
>> ..13 and .19 vs 1/8 and 3/16
>
> If they wanted more accuracy, going from /8ths to /16ths would be
> _better_ than going to /10ths.
>
> Bleh...
But I don't think it's *accuracy* they wanted, it was rapid comprehension
by humans. If you're in the pit doing trades for millions of shares every
few seconds, you don't want to have to think, "is 13/16 ths better than
24/32nds?"
In fact they used prices all the way down to 128ths for small stocks.
"Daniel Lakeland" <········@sil-no.spam-con.com> writes:
[snip stock fractions of two -> decimal fractions discussion]
> But I don't think it's *accuracy* they wanted, it was rapid comprehension
> by humans. If you're in the pit doing trades for millions of shares every
> few seconds, you don't want to have to think, "is 13/16 ths better than
> 24/32nds?"
>
> In fact they used prices all the way down to 128ths for small
> stocks.
if they were real men, they'd switch to a logarithmic scale. dB might
be too big. how about mB (milli-Bells)? then my stocks could go up
and down X mB. you could support a wide range of values, a stock
doubling would be a 301 mB gain &c.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
sysengr
In article <·····················@news20.bellglobal.com>,
········@acm.org wrote:
> "Daniel Lakeland" <········@sil-no.spam-con.com> writes:
> > In article <······················@typhoon.ne.mediaone.net>, "Scott
> > McKay"
> > <···@mediaone.net> wrote:
> > > It's ironic, isn't it, that US stock markets now use decimals because
> > > we're in the computer age, and decimals are more accurate than those
> > > silly old 1/8's. Oops.
> >
> > I thought that was funny too.
>
> That one irritated me big-time; it's a representation that makes it
> _dead easy_ to do exact arithmetic. And these clowns expect that
> moving to FP is NOT going to give them a lot of new headaches?
OK, I guess I'm thick, but surely with the old way computer systems
would actually store the stock price as the integer equal to eight times
the price in dollars? And now they'll store it as the integer equal to
a hundred times the price in dollars (are they quoted to 2 decimal
places?).
What's the problem?
-- Bruce
doesn't know much about the US stockmarket, but used to
program systems in a New Zealand brokerage
In article <···············@panix2.panix.com>,
Rajappa Iyer <···@panix.com> wrote:
>Raymond Toy <···@rtp.ericsson.se> writes:
>
>> Sashank> algol notation:lisp notation::
>> Sashank> newton's calculus notation:leibniz's calculus notation
>>
>> Do you have a pointer to what the notation looked like? Just curious.
>
>You mean Newton's calculus notation?
>
>IIRC, where Leibniz had a generalized notation for differentials of
>the nth order.
>
> n
>d y
>-----
> n
>dx
>
>Whereas Newton explicitly enumerated the successive differentiations:
>
>d (d (d (d y)))
>---------------
>d (d (d (d x)))
>
>(Hm...)
>
>or something like that.
The denominator doesn't look like something that could
have come from Newton, since it notates the change of
the change of ... x, and Newton surely knew better.
Our received notation for derivatives, whether it
should properly be laid at the feet of Newton or
Leibniz, is unfunctional (of all the places to so
be!) and ambiguous anyway. See Abelson and Wisdom's
_Structure and Interpretation of Classical Mechanics_,
preface, footnote 2
(http://mitpress2.mit.edu/sicm/book-Z-H-5.html).
--d
In article <············@news.gte.com>, Dorai Sitaram <····@gte.com> wrote:
>Our received notation for derivatives, whether it
>should properly be laid at the feet of Newton or
>Leibniz, is unfunctional (of all the places to so
>be!) and ambiguous anyway. See Abelson and Wisdom's
>_Structure and Interpretation of Classical Mechanics_,
>preface, footnote 2
>(http://mitpress2.mit.edu/sicm/book-Z-H-5.html).
Oops. s/Abelson/Sussman/.
--d
····@goldshoe.gte.com (Dorai Sitaram) writes:
> In article <············@news.gte.com>, Dorai Sitaram <····@gte.com> wrote:
> >Our received notation for derivatives, whether it
> >should properly be laid at the feet of Newton or
> >Leibniz, is unfunctional (of all the places to so
> >be!) and ambiguous anyway. See Abelson and Wisdom's
> >_Structure and Interpretation of Classical Mechanics_,
> >preface, footnote 2
> >(http://mitpress2.mit.edu/sicm/book-Z-H-5.html).
>
> Oops. s/Abelson/Sussman/.
Nope. You got it right the first time.
I did not know about the book. Looks interesting. Like the previous
one on Turtle geometry by Abelson.
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Rajappa Iyer:
RI> IIRC, where Leibniz had a generalized notation for differentials of
RI> the nth order.
[...]
RI> Whereas Newton explicitly enumerated the successive differentiations:
No. Newton only considered derivation w.r.t. time, and wrote
. .. ...
x, x , x
for what Leibnitz wrote dx/dt, d2x/dt2, d3x/dt3.
I also seem to recall that Newton used ``o'' as the notation for an
infinetisimal time interval, so that differentials were written
. .. ...
xo, x oo, x ooo
for dx, d2x and d3x (i.e. (dx/dt)dt, (d2x/dt2)dt2, etc.).
While it is possible to divide differentials in Newton's calculus, the
only functions that can be differentiated are functions of time.
Thus, the difference between the two calculi is far from being merely
notational: unlike Newton's, Leibnitz' calculus does generalise to
situations with multiple independent variables (or, in modern
mathematical notation, to functions of multiple arguments).
(Notationally, on the other hand, Newton's calculus is simple and
elegant, whereas Leibnitz' can get heavy at times. Is that the point
the OP was trying to make by comparing Cambridge Polish with Leibnitz'
notation?)
Of course, both Leibnitz' and Newton's works, brilliant as they were,
were based on rough intuitions (infinetisimals, negligible values,
etc.). Formalisation would only happen with d'Alembert (limits) and
Cauchy (derivatives).
Juliusz
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> This is definately something I've noticed as well, and it points out a
> serious hole in the education of American CS/EECS undergrads: how can
> there be so many of them who literally have *never*, not even lightly,
> used a non-Alogol-like language??? These people have CS degrees, for
> godsakes, and have never even seen something that looks like Lisp, or
> Forth, or PostScript, or SmallTalk, or ...
Does anyone else who, like me, talks of "Algol-like languages" wonder
if any of those in CS these days ever get to see the spec for, much
less a running implementation of, Algol? Not that I suppose it
matters if the answer is no, but maybe I'll be pleasantly surprised.
It's just funny that the term appears so often yet in many, perhaps
most, cases probably hasn't been taught in schools for ages.
I remember being shocked some years back when I noticed the movie industry
had switched to a near-uniform policy of every time they mention an
actor/actress marking it with a hint afterward of who the person might be,
said hint almost universally being the last movie they were in (as opposed
to the best). What jarred me into noticing this was the reference to
Julie Andrews followed by, in case you hadn't seen her in any movies, the
notation ("S.O.B.") ... ah, yes, THAT Julie Andrews. I knew I'd seen her
in something.
Even being among it, I have to admit the American culture needs a
serious overhaul of its manner of instilling an appreciation for
history. For all I can tell, it's presently being taught more a
geometry problem where the words "Columbus" and "1492" define two ends
of a straight line. And it's just hard to see how that kind of "point
knowledge" generalizes.
> Kent, you said you're writing a book/books? PLEASE have the code in
> the books look like actual Lisp code that people use. Please please
> please.
Don't worry about that one. I have no patience for Lisp as an exercise
in recursive pain. I'm sure that's adequately covered in other texts.
(If you have other specific ideas about styles/issues/applications/techniques
that need attention, drop me a line in email.)
Kent M Pitman <······@world.std.com> wrote in message news:<···············@shell01.TheWorld.com>...
> Does anyone else who, like me, talks of "Algol-like languages" wonder
> if any of those in CS these days ever get to see the spec for, much
> less a running implementation of, Algol? Not that I suppose it
> matters if the answer is no, but maybe I'll be pleasantly surprised.
> It's just funny that the term appears so often yet in many, perhaps
> most, cases probably hasn't been taught in schools for ages.
A Google search reveals that apparently the Algol-60 revised report
is on the web.
http://www.masswerk.at/algol60/report.htm
--
T. Kurt Bond, ···@tkb.mpl.com
There are also the files RRA60.info and RRA60.ps.gz from the Debian
package nase-a60, containing ``Revised Report on the Algoritmic
Language Algol 60''.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Kent M Pitman <······@world.std.com> writes:
> Does anyone else who, like me, talks of "Algol-like languages" wonder
> if any of those in CS these days ever get to see the spec for, much
> less a running implementation of, Algol? Not that I suppose it
> matters if the answer is no, but maybe I'll be pleasantly surprised.
> It's just funny that the term appears so often yet in many, perhaps
> most, cases probably hasn't been taught in schools for ages.
I'm pretty sure most don't. I sure haven't used an Algol system, but
I have seen several hundred lines of Algol code.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@tornado.ocf.berkeley.edu>,
···@tornado.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Kent M Pitman <······@world.std.com> writes:
>
>> Does anyone else who, like me, talks of "Algol-like languages" wonder
>> if any of those in CS these days ever get to see the spec for, much
>> less a running implementation of, Algol? Not that I suppose it
>> matters if the answer is no, but maybe I'll be pleasantly surprised.
>> It's just funny that the term appears so often yet in many, perhaps
>> most, cases probably hasn't been taught in schools for ages.
>
> I'm pretty sure most don't. I sure haven't used an Algol system, but
> I have seen several hundred lines of Algol code.
which algol? 58 (jovial, neliac, mad), 60, or 68?
hs
--
Apart from the obvious disagreement about who the good guys are, what
is the difference between "You are either with us or against us" and
"There are only good muslim and infidels"?
··@heaven.nirvananet (Hartmann Schaffer) writes:
> In article <···············@tornado.ocf.berkeley.edu>,
> ···@tornado.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> > Kent M Pitman <······@world.std.com> writes:
> >
> >> Does anyone else who, like me, talks of "Algol-like languages" wonder
> >> if any of those in CS these days ever get to see the spec for, much
> >> less a running implementation of, Algol? Not that I suppose it
> >> matters if the answer is no, but maybe I'll be pleasantly surprised.
> >> It's just funny that the term appears so often yet in many, perhaps
> >> most, cases probably hasn't been taught in schools for ages.
> >
> > I'm pretty sure most don't. I sure haven't used an Algol system, but
> > I have seen several hundred lines of Algol code.
>
> which algol? 58 (jovial, neliac, mad), 60, or 68?
68
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> ··@heaven.nirvananet (Hartmann Schaffer) writes:
>> which algol? 58 (jovial, neliac, mad), 60, or 68?
>
> 68
>
Damn straight. Most orthogonal language ever developed. Worth learning
simply for that fact alone. The specification is amazingly succint due to
the use of meta-grammar. Note to budding computer linguists: This is
probably the best exemplar of a procedural language out there. Learn from
it. It's worth it...
faa
Frank A Adrian:
Hartmann Schaffer:
HS> which algol? 58 (jovial, neliac, mad), 60, or 68?
ALGOL-60 is a wonderful language. ALGOL-60 is fully lexically scoped,
and includes both call-by-value and call-by-name semantics. It took
years for its very creators to fully understand the subtelties of the
latter. (Search for ``Jensen's device.'' Who needs higher-order
functions, with a semantics like that?)
The ALGOL-60 report[1] is a stunning example of clarity of exposition in
natural, legible prose. It contains many of the ideas we still thrive
on, such as the use of BNF, or the distinction between abstract and
concrete syntax (sorely absent in early descriptions of FORTRAN --
remember, the preliminary report came out in 58).
A minor wart is the ``switch'' data structure, which was replaced by
Dijkstra's (?) ``case'' statement in ALGOL-W and later in PASCAL.
Unfortunately, ALGOL-W also did away with call-by-name, replacing it
with call-by-value on references instead (the ``variable arguments''
of PASCAL).
Kent M Pitman:
KMP> Does anyone else who, like me, talks of "Algol-like languages" wonder
KMP> if any of those in CS these days ever get to see the spec for, much
KMP> less a running implementation of, Algol?
I hope you meant ``ALGOL''?
I am sorry to say, many don't. The ones that are lucky only have it
mentioned en passant when learning about call-by-name.
Aside: it is unfortunate that so many programming language specialists
are unaware of the full beauty of cbn imperative languages, only
associating cbn to ``lazy'' functional languages. [2]
Thomas F. Burdick:
TB> 68
That's Algol 68. It has nothing to do with ALGOL.
Algol 68 is a monstrous attempt to include all of ALGOL and all of
PL/I and all of Dijkstra's work on concurrency and whatever else any
committee member had vaguely heard about from his brother-in-law's
barber. Algol 68 is built around the idea that a programming language
need not be consistent as long as it is ``orthogonal.'' Whatever that
means.
Algol 68 attempts to overgeneralise everything, leading to an
unimplementable language. The report then goes on to specify a random
set of restrictions on interactions between features (is that what
they mean by ``orthogonal''?) , which may or may not make the language
possible to implement. I do not know whether anyone or anything ever
claimed to implement full Algol 68.
Of course, this discussion is somewhat pointless as nobody really
understands Algol 68. First, the Algol 68 report[3] randomly permutes
the names of everything[4], calling types ``modes'' and using the term
``type'' for something completely unrela^Worthogonal. Second, the
Algol 68 report is riddled with Van Wijngaarden's grammars, an
unrepeatable transition-based notation which is used to describe both
its syntax and its semantics. (Of course, the fact that van Wijngaar-
den happened to be the report's editor is merely coinciden^Worthogonal.)
The Algol 68 report comes with a ``minority opinion'', signed by
prominent members of the Algol 68 committee (including Hoare and
Dijkstra), saying that after working on the language for years, they
do not feel that it represents what they have worked for.
(If you did not get the minority opinion with your Algol 68 report,
you've been ripped off.)
TB> Waitaminute ... "all full of junk" ... don't you use Common Lisp
Common Lisp is actually a highly consistent language. The evaluation
rules are very simple and systematic. The dynamically typed object
semantics are highly consistent (but badly described IMHO), and CLOS
is surprisingly consistent with the rest of the language.
All the rest is library.
Juliusz
[1] Peter Naur, ed. ``Revised Report on the Algorithmic Language
ALGOL-60.'' Numerische Mathematik, 4:420-453. 1963. (Also
published in the Communications of the ACM 6(1):1-17 (1963) and
Computer Journal 5:349--.)
[2] John Reynolds. ``The essence of Algol.''
[3] A. Van Wijngaarden, ed. ``Revised Report on the Algorithmic
Language Algol 68.'' Cloaca Informatica 5:1-236, 1975. Also
published by Springer-Verlag (1976) and SIGPLAN Notices 12(5) (1977).
[4] Lewis Caroll. ``Through the looking glass.''
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> Kent M Pitman:
>
> KMP> Does anyone else who, like me, talks of "Algol-like languages" wonder
> KMP> if any of those in CS these days ever get to see the spec for, much
> KMP> less a running implementation of, Algol?
>
> I hope you meant ``ALGOL''?
>
> I am sorry to say, many don't. The ones that are lucky only have it
> mentioned en passant when learning about call-by-name.
>
> Aside: it is unfortunate that so many programming language specialists
> are unaware of the full beauty of cbn imperative languages, only
> associating cbn to ``lazy'' functional languages. [2]
The unfortunate thing is that it has only been fairly recently that
Algol compilers have again become fairly readily available.
They were pretty available on mainframes, but students never see those
anymore.
There seem to be a whole bunch of ALGOL68-to-C translators emerging
from the darkness. Perhaps unfortunately, the number of ALGOL 60
options are fewer...
It may soon be possible for students to realistically have the
opportunity to actually have access to ALGOL development tools again,
of whatever variation, which would probably be a good thing.
--
(concatenate 'string "cbbrowne" ·@cbbrowne.com")
http://www.ntlug.org/~cbbrowne/algol.html
"The cost of living has just gone up another dollar a quart."
-- W.C. Fields
On Tue, 13 Nov 2001 18:22:31 GMT, ········@acm.org wrote:
>Juliusz Chroboczek <···@pps.jussieu.fr> writes:
>> Kent M Pitman:
>
>There seem to be a whole bunch of ALGOL68-to-C translators emerging
>from the darkness. Perhaps unfortunately, the number of ALGOL 60
>options are fewer...
>
>It may soon be possible for students to realistically have the
>opportunity to actually have access to ALGOL development tools again,
>of whatever variation, which would probably be a good thing.
Not saying about Simula, the first OO language, based on Algol, that
was and is available all the time
http://www.iro.umontreal.ca/~simula/
A.L.
In article <·······················@news20.bellglobal.com>,
<········@acm.org> wrote:
>>
>> Aside: it is unfortunate that so many programming language specialists
>> are unaware of the full beauty of cbn imperative languages, only
>> associating cbn to ``lazy'' functional languages. [2]
>
>The unfortunate thing is that it has only been fairly recently that
>Algol compilers have again become fairly readily available.
>
>They were pretty available on mainframes, but students never see those
>anymore.
>
>There seem to be a whole bunch of ALGOL68-to-C translators emerging
>from the darkness. Perhaps unfortunately, the number of ALGOL 60
>options are fewer...
Whole bunch? I know only 1. This is the RSA Malvern developed ctrans,
sometimes named a68toc. Algol60 options are 2 (a60, MARST). Look into
http://dmoz.org/Computers/Programming/Languages/Algol..
>It may soon be possible for students to realistically have the
>opportunity to actually have access to ALGOL development tools again,
>of whatever variation, which would probably be a good thing.
Anyway, Algol68 has no cbn. There is an almost equivalent there in
having 1st class functions. But as the 'proceduring' coercion has
been dropped from Algol68 in the Revised Report, only the semantics,
but not the syntax of cbn are available in Algol68.
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257
Wilhelm B Kloke:
WK> Anyway, Algol68 has no cbn. There is an almost equivalent there in
WK> having 1st class functions.
It's not quite clear to me. In ALGOL-60, you can set a place (to use
the Common Lisp term) that you pass by name. Whence the ability to
use Jensen's device:
real procedure Sum(j, lo, hi, body);
value lo, hi;
integer lo, hi;
begin
real s;
s := 0;
for j := lo step 1 until hi do
s := s + body;
Sum := s
end;
...
s := Sum(i, 0, 100, sin(i/100.0));
...
One possible implementation is that the first argument to Sum is a
couple of a getter and a setter. However, the language guarantees
that the setter and the getter refer to the same memory location,
something that is no longer guaranteed if you use funargs for the
setter and the getter.
With a little bit of macrology, you can almost (but not quite)
implement cbn in portable Common Lisp. For simplicity, I'll only
consider single-argument functions.
(defstruct (thunk (:constructor make-thunk (getter setter)))
getter
setter)
(defun thunk-value (thunk) (funcall (thunk-getter thunk)))
(defun (setf thunk-value) (thunk value) (funcall (thunk-setter thunk) value))
(defun place-p (form &optional env)
;; return true if (setf form) makes sense
;; I don't think it can be implemented in portable Common Lisp,
;; so let's do a ``good enough'' implementation
(or (symbol form)
(and (consp form) (member (car form)
'(aref svref car cdr)))))
(defmacro thunk (form &environment env)
(if (place-p form env)
`(make-thunk #'(lambda () ,form)
#'(lambda (arg) (setf ,form arg))) ; arg should be a GENSYM
`(make-thunk #'(lambda () ,form)
#'(lambda (arg) (error "~S is not a place" ',form)))))
(defmacro cbn-funcall (fun arg)
`(funcall ,fun (thunk ,arg)))
(defmacro cbn-lambda ((arg) &body body)
`(lambda (,arg)
(let ((arg-thunk ,arg)) ; should be a GENSYM
(symbol-macrolet ((,arg (thunk-value arg-thunk)))
,@body))))
The magic here is in the interaction between (SETF THUNK-VALUE) and
SYMBOL-MACROLET.
The problem is then apparent if you consider that there's nothing that
prevents the user from calling a CBN-LAMBDA with an arbitrary ``bad
thunk'' constructed by MAKE-THUNK, not necessarily a proper thunk
produced by the THUNK macro.
(On a related note: the semantics constructed by Abramsky and McCusker
for Idealised Algol includes just such ``bad variables.'')
Juliusz
P.S. Anyone care implementing PLACE-P, perhaps using the CLtL2
environment abstraction? I'd be curious to see how it can be done.
Juliusz Chroboczek <···@pps.jussieu.fr> writes:
> (defun place-p (form &optional env)
> ;; return true if (setf form) makes sense
> ;; I don't think it can be implemented in portable Common Lisp,
> ;; so let's do a ``good enough'' implementation
> (or (symbol form)
> (and (consp form) (member (car form)
> '(aref svref car cdr)))))
[...]
> P.S. Anyone care implementing PLACE-P, perhaps using the CLtL2
> environment abstraction? I'd be curious to see how it can be done.
It can be implemented in portable CL:
(defun place-p (form)
t)
Or in other words: You can't establish at compile-time (that's when
you use place-p in your code) whether something is going to be a valid
place at run-time or not, since everything that hasn't been declared a
valid place via defsetf or the ANSI standard, can always become a
valid place by defining a setf function, even after the setf form has
been macroexpanded[1]. This works, because (setf (foo ...) ...) will
expand to a call to #'(setf foo) if foo isn't defined via defsetf, or
some "built-in" rule, as specified by the standard. In that case an
error will only be raised at run-time, should #'(setf foo) not be
defined.
But as far as I understand your code, you don't need that anyhow:
> (defmacro thunk (form &environment env)
> (if (place-p form env)
> `(make-thunk #'(lambda () ,form)
> #'(lambda (arg) (setf ,form arg))) ; arg should be a GENSYM
> `(make-thunk #'(lambda () ,form)
> #'(lambda (arg) (error "~S is not a place" ',form)))))
This can just be written as
(defmacro thunk (form)
`(make-thunk #'(lambda () ,form)
#'(lambda (arg) (setf ,form arg)))) ; arg should be a GENSYM
because the expansion of setf will signal an error if form isn't a
place all by itself.
That being said, I don't think your code will work correctly in the
presence of side-effects in the places. A real solution probably
needs to use get-setf-expansion, but I'm too lazy to think more about
this...
Regs, Pierre.
Footnotes:
[1] Actually, for certain symbols in the CL package you can probably
statically answer nil, since the standard doesn't allow users to
define setf functions for those. But that doesn't really matter
here.
--
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
In article <··············@pps.jussieu.fr>,
Juliusz Chroboczek <···@pps.jussieu.fr> wrote:
>Wilhelm B Kloke:
>
>WK> Anyway, Algol68 has no cbn. There is an almost equivalent there in
>WK> having 1st class functions.
>
>It's not quite clear to me. In ALGOL-60, you can set a place (to use
>the Common Lisp term) that you pass by name. Whence the ability to
>use Jensen's device:
>
> real procedure Sum(j, lo, hi, body);
> value lo, hi;
> integer lo, hi;
> begin
> real s;
> s := 0;
> for j := lo step 1 until hi do
> s := s + body;
> Sum := s
> end;
> ...
> s := Sum(i, 0, 100, sin(i/100.0));
> ...
I only argue about Algol68(RR). If you want to program this, you make
the parameters of Sum of modes REF INT, INT, INT and PROC REAL.
The 4th parameter cannot be coerced to PROC REAL, as there is no proceduring.
So you have to change this call into
sum( i, 0, 100, PROC REAL: sin(i/100.0))
This is almost equivalent to call by name, but technically it IS call by
value.
The restriction 'almost' alludes to the fact that Algol60 allows
some polymorphism by not declaring the parameters of Sum. In this case
the type of parameters is determined from the type of actual parameters
(at least in pre-modified Algol60).
--
Dipl.-Math. Wilhelm Bernhard Kloke
Institut fuer Arbeitsphysiologie an der Universitaet Dortmund
Ardeystrasse 67, D-44139 Dortmund, Tel. 0231-1084-257
"Juliusz Chroboczek" <···@pps.jussieu.fr> wrote in message
···················@pps.jussieu.fr...
> Wilhelm B Kloke:
>
> WK> Anyway, Algol68 has no cbn. There is an almost equivalent there in
> WK> having 1st class functions.
>
> It's not quite clear to me. In ALGOL-60, you can set a place (to use
> the Common Lisp term) that you pass by name. Whence the ability to
> use Jensen's device:
In my humble opinion, if Jenson's device were given its proper
name -- "Jensen's Horrible Kludge" -- it would get the respect
it deserves. It's a triumph of cleverness over clarity.
We're much better off passing funargs, where the intent is expressed
clearly in the code.
> real procedure Sum(j, lo, hi, body);
> value lo, hi;
> integer lo, hi;
> begin
> real s;
> s := 0;
> for j := lo step 1 until hi do
> s := s + body;
> Sum := s
> end;
> ...
> s := Sum(i, 0, 100, sin(i/100.0));
> ...
>
Juliusz Chroboczek wrote:
> Algol 68 is a monstrous attempt to include all of ALGOL and all of
> PL/I and all of Dijkstra's work on concurrency and whatever else any
> committee member had vaguely heard about from his brother-in-law's
> barber. Algol 68 is built around the idea that a programming language
> need not be consistent as long as it is ``orthogonal.'' Whatever that
> means.
What it meant essentially was that all modes were supposed to be "first
class objects". This was something amazingly absent in most other
languages of the time. For instance, this was one of the first languages
that tried to enforce static type safety upon procedure references.
> Algol 68 attempts to overgeneralise everything, leading to an
> unimplementable language. The report then goes on to specify a random
> set of restrictions on interactions between features (is that what
> they mean by ``orthogonal''?) , which may or may not make the language
> possible to implement. I do not know whether anyone or anything ever
> claimed to implement full Algol 68.
It was, at the time, hard to implement. Especially efficiently. Probably
still is. But the same could be said of (and has been said of) Common
Lisp. At the time, there were few complete implementations. The man issue
were the multiple stacks you needed for proper implementation of the proc's
and the difficulty of efficiently implementing the generic arithmetic
types. When you wrapped that with the problems of havng no standard
library defined and some basic problems of orthogonality (how does one make
a file of proc's anyhow :-), it is no wonder that the outcome of many
implementations were less than satisfactory.
> Of course, this discussion is somewhat pointless as nobody really
> understands Algol 68. First, the Algol 68 report[3] randomly permutes
> the names of everything[4], calling types ``modes'' and using the term
> ``type'' for something completely unrela^Worthogonal. Second, the
> Algol 68 report is riddled with Van Wijngaarden's grammars, an
> unrepeatable transition-based notation which is used to describe both
> its syntax and its semantics. (Of course, the fact that van Wijngaar-
> den happened to be the report's editor is merely coinciden^Worthogonal.)
I would say that the specification and terminology is no less opaque than
any other standard. What you get out of it is proportional to the effort
you put into it. IMHO, the specification is still a model of elegance. It
does take a fair amount of study to understand, but so do most standards.
It's a lot gentler than most newbies' introduction to the denotational
semantics model of Scheme.
> The Algol 68 report comes with a ``minority opinion'', signed by
> prominent members of the Algol 68 committee (including Hoare and
> Dijkstra), saying that after working on the language for years, they
> do not feel that it represents what they have worked for.
>
> (If you did not get the minority opinion with your Algol 68 report,
> you've been ripped off.)
This is true. the minority report *is* more interesting reading than the
rest of the report. Many of the criticisms do hit home. But then, I'm
sure that had the ANSI Common Lisp committee published a minority report,
it would have been just as interesting.
There are no perfect standards. In fact, standards are about the most
complex things around, `opaque in their need for precision and flawed by
compromise. They are also products of their times. The Algol 68 committee
met during the time that language design was starting to be recognized as a
rigorous field. As such, they were horrified at the "ad hoc" and arbitrary
nature of the languages then existant (look at your example of PL/I, or
COBOL, or FORTRAN (or even Lisps of the time!)). They tried to do better
than the current languages with respect to "ad-hoc'ness" while adding
features that seemed important in the languages of the day. This is the
reason why the language turned out to be extremely elegant in its
orthogonality, but also bloated and, ultimately, impossible to implement in
toto.
Besides, if you wre on the committe and just wanted a "better Algol-60",
there were many to choose from during and shortly after that period -
Algol-W, Simula, and Pascal all spring to mind. Second guessing the
standard writers with 30+ years of hindsight as an advantage without taking
into account what the issues they were trying to solve seems a bit unseemly.
faa
>> Algol 68 is built around the idea that a programming language need
>> not be consistent as long as it is ``orthogonal.'' Whatever that
>> means.
Frank A Adrian:
FA> What it meant essentially was that all modes were supposed to be "first
FA> class objects".
I would agree that it includes that, but the wording used by the
report seems to imply a wider agenda:
The number of independent primitive concepts has been minimized in
order that the language be easy to describe, to learn, and to
implement. On the other hand, these concepts have been applied
``orthogonally'' in order to maximize the expressive power of the
language while trying to avoid deleterious superfluities.
Is that vague enough? (Quotation marks theirs.)
(I'm not a native speaker, and won't comment on their style.)
[Bunch of very interesting comments snipped.]
FA> I would say that the specification and terminology is no less
FA> opaque than any other standard.
Taking a page at random:
A ``paranotion'' P is a hypernotion which is used, in the text of this
report, to designate any construct whose original O satisfies the
following:
P, regarded as a hypernotion, designates an ``abstraction'' of O.
Not to be confused with ``protonotion'', of course, which is defined
two pages earlier. Or with ``metanotion'', for that matter.
(On a different note, I find your comment about Denotational Semantics
being obscure very interesting, as I can no longer judge them with an
outsider's eye. Milner chose to shun their use, and use a finitary
relational semantics in his ``Definition of Standard ML.'')
FA> [standards] are also products of their times. The Algol 68
FA> committee met during the time that language design was starting to
FA> be recognized as a rigorous field. As such, they were horrified
FA> at the "ad hoc" and arbitrary nature of the languages then
FA> existant (look at your example of PL/I, or COBOL, or FORTRAN (or
FA> even Lisps of the time!)).
While you have a good point here (duly taken), you should recall that
Algol 68 was an IFIP standard, not a random scientific paper (as, say,
PASCAL and Scheme used to be) or the manual of an implementation (as
e.g. FORTRAN IV).
I am not condemning the line of thought that lead to Algol 68: in
fact, had Algol 68 been an compiler's manual rather than a standard, I
might consider it as being a very interesting piece of research. Even
with Van Wijngaarden grammars. (Well, perhaps not.)
But IFIP (or ANSI, or ISO for that matter) is not the right forum to
let your imagination run wild, unless you're into abusing your
political power to push your pet idea. You cannot just dump every
feature in, describe it using your latest notational toy, have no
implementation experience, and declare the result to be an
``international standard''. (Even W3C calls the result of such a
process a mere ``recommendation.'')
(Okay, I'm being somewhat disingeneous here. This very process led to
some fairly successful standards.)
But the worst is that the Algol 68 committee usurped the sacred name
of ALGOL for what you will agree is a completely different language.
I think this is the bit that I really can't forgive them.
FA> Second guessing the standard writers with 30+ years of hindsight
FA> as an advantage without taking into account what the issues they
FA> were trying to solve seems a bit unseemly.
Well... this is a Usenet posting, isn't it?
Juliusz
Juliusz Chroboczek wrote:
>
> FA> I would say that the specification and terminology is no less
> FA> opaque than any other standard.
>
> Taking a page at random:
>
> A ``paranotion'' P is a hypernotion which is used, in the text of this
> report, to designate any construct whose original O satisfies the
> following:
>
> P, regarded as a hypernotion, designates an ``abstraction'' of O.
>
> Not to be confused with ``protonotion'', of course, which is defined
> two pages earlier. Or with ``metanotion'', for that matter.
OK, it did get a bit over the top :-). But I wonder what someone who was
new to the CL standard would make of slot declarations, method
combinations, forms, and compiler macros vs. macros, all of which are
defined in separate places with an execution model that would not be
immediately obvious without a fair amount of previous Lisp knowledge.
>
> (On a different note, I find your comment about Denotational Semantics
> being obscure very interesting, as I can no longer judge them with an
> outsider's eye. Milner chose to shun their use, and use a finitary
> relational semantics in his ``Definition of Standard ML.'')
To paraphrase Barbie, "Denotational semantics is hard". It's a powerful
description, but that the power of the description comes with a high price
in understandability by "mere mortals". I've worked my way through
denotational semantics enough to pick through RxRS and Lisp in Small
Pieces. I've even read Stoy's book. But don't ask me to actually prove
anything using it :-). I think it's a more dense method of describing
semantics than either operational or axiomatic (??) semantics. Coming in
cold, understanding it is a daunting task. I think it's the same way with
whatever type of description you want to use as an example. The denser the
specification, the harder it is to understand. And wahtever else you want
to say about it, the Algol 68 standard *was* dense.
> FA> [standards] are also products of their times. The Algol 68
> FA> committee met during the time that language design was starting to
> FA> be recognized as a rigorous field. As such, they were horrified
> FA> at the "ad hoc" and arbitrary nature of the languages then
> FA> existant (look at your example of PL/I, or COBOL, or FORTRAN (or
> FA> even Lisps of the time!)).
>
> While you have a good point here (duly taken), you should recall that
> Algol 68 was an IFIP standard, not a random scientific paper (as, say,
> PASCAL and Scheme used to be) or the manual of an implementation (as
> e.g. FORTRAN IV).
Yup, and we probably weren't nearly as good at knowing what a "good"
description of a programming language was back then.
> I am not condemning the line of thought that lead to Algol 68: in
> fact, had Algol 68 been an compiler's manual rather than a standard, I
> might consider it as being a very interesting piece of research. Even
> with Van Wijngaarden grammars. (Well, perhaps not.)
I won't argue that it probably would have made a better scientific paper
than a standard, but again, back then, the definition of a "good" standard
was in flux. What the (undeniably academic) members thought was a good
standard, in the face of the descriptions of (say) PL/I that were put forth
at the time, caused overkill in `the desire to be scientific.
> But the worst is that the Algol 68 committee usurped the sacred name
> of ALGOL for what you will agree is a completely different language.
> I think this is the bit that I really can't forgive them.
Well, I see your point there. It was a great deviation from the Algol 60
language. And the denseness of the standard did not help
understandability. People who like simplicity would probably be greatly
agrieved.
> FA> Second guessing the standard writers with 30+ years of hindsight
> FA> as an advantage without taking into account what the issues they
> FA> were trying to solve seems a bit unseemly.
>
> Well... this is a Usenet posting, isn't it?
You bet! Probably a good thing, too, even for my ramblings.
From: Valeriy E. Ushakov
Subject: Re: ALGOL, Algol, and Lisp [was: Slashdot]
Date:
Message-ID: <9ssnul$cqo$1@news.spbu.ru>
Juliusz Chroboczek <···@pps.jussieu.fr> wrote:
> Algol 68 attempts to overgeneralise everything, leading to an
> unimplementable language. [...] I do not know whether anyone or
> anything ever claimed to implement full Algol 68.
There were several A68 compilers written here in St.Petersburg Uni.
There was a compiler for IBM mainframes, a compiler for x86 that ran
under MS-DOS and there was a localy built machine named "Samson"
(after the biggest fountain in Peterhoff, near the University campus)
that had a whole OS for it written in A68 (my friend wrote an
assembler for it). I heard anecdotes that software for several USSR
space missions (to Venus, ISTR) was written in A68.
(I never programmed in A68 myself - in school I was in the group that
was taught PL/I, but the other group was taught A68 - and I remember
their jokes about "three piglets: Nif-Nif, Naf-Naf and ref ref". ;)
SY, Uwe
--
···@ptc.spbu.ru | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> ··@heaven.nirvananet (Hartmann Schaffer) writes:
>
> ...
> > which algol? 58 (jovial, neliac, mad), 60, or 68?
>
> 68
Hmm. I think I've only ever seen/used 60. My impression is that 68 was
all full of junk, like later versions of Fortran.
Kent M Pitman <······@world.std.com> writes:
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > ··@heaven.nirvananet (Hartmann Schaffer) writes:
> >
> > ...
> > > which algol? 58 (jovial, neliac, mad), 60, or 68?
> >
> > 68
>
> Hmm. I think I've only ever seen/used 60. My impression is that 68 was
> all full of junk, like later versions of Fortran.
Hmm, I'd much rather code in Fortran 90 than 77. Waitaminute ... "all
full of junk" ... don't you use Common Lisp ;-)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"Thomas F. Burdick" wrote:
>
> Kent M Pitman <······@world.std.com> writes:
>
> > Hmm. I think I've only ever seen/used 60. My impression is that 68 was
> > all full of junk, like later versions of Fortran.
>
> Hmm, I'd much rather code in Fortran 90 than 77.
Fortran 77 is one of those "later versions of Fortran" full of junk like
if/then/else.
"T.M. Sommers" <····@mail.ptd.net> writes:
> "Thomas F. Burdick" wrote:
> >
> > Kent M Pitman <······@world.std.com> writes:
> >
> > > Hmm. I think I've only ever seen/used 60. My impression is that 68 was
> > > all full of junk, like later versions of Fortran.
> >
> > Hmm, I'd much rather code in Fortran 90 than 77.
>
> Fortran 77 is one of those "later versions of Fortran" full of junk like
> if/then/else.
Hmm. Most of Fortran's life would then land in "later". I guess I
could see if/then/else being seen as junk in the FORmula TRANslation
language, though.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
"T.M. Sommers" <····@mail.ptd.net> writes:
> "Thomas F. Burdick" wrote:
> >
> > Kent M Pitman <······@world.std.com> writes:
> >
> > > Hmm. I think I've only ever seen/used 60. My impression is that 68 was
> > > all full of junk, like later versions of Fortran.
> >
> > Hmm, I'd much rather code in Fortran 90 than 77.
>
> Fortran 77 is one of those "later versions of Fortran" full of junk like
> if/then/else.
Indeed. That's what I meant to imply. I'm pretty sure the FORTRAN IV
that I learned was FORTRAN 66 compliant, not 77. It was pretty raw.
I recall no if/then/else. Also, all for loops had to have positive
increments. Great stuff. It's not that I think it was bad to add
that extra stuff. Peoople probably needed it. It's just that it
always seemed to me it lost its distinctive FORTRANish character and
became just another Algol-like language in many ways.
In article <···············@shell01.theworld.com>,
Kent M Pitman <······@world.std.com> writes:
> ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
>> ··@heaven.nirvananet (Hartmann Schaffer) writes:
>>
>> ...
>> > which algol? 58 (jovial, neliac, mad), 60, or 68?
>>
>> 68
>
> Hmm. I think I've only ever seen/used 60. My impression is that 68 was
> all full of junk, like later versions of Fortran.
wrong impression. what imo prevented it from being widely accepted
was
1. they developed a new description style which most people found very
hard to understand
2. there was nobody "marketing" it
3. the language definition pushed implementation technology, i.e. it
had a few features that at that time nobody (or at most very few
people) had an idea how to implement efficiently
hs
--
Apart from the obvious disagreement about who the good guys are, what
is the difference between "You are either with us or against us" and
"There are only good muslim and infidels"?
Thomas F. Burdick <···@conquest.ocf.berkeley.edu> wrote:
> This is definately something I've noticed as well, and it points out a
> serious hole in the education of American CS/EECS undergrads: how can
> there be so many of them who literally have *never*, not even lightly,
> used a non-Alogol-like language??? These people have CS degrees, for
> godsakes, and have never even seen something that looks like Lisp, or
> Forth, or PostScript, or SmallTalk, or ...
Many undergrad CS students are "exposed" to other kinds of languages,
but usually not in a context that requires them to master them.
The common "smorgasbord" approach to teaching the principles of
programming languages usually exposes just enough of each language
to make students think they don't like it.
>> 7.) The lack of books. Yes, there are some really great books on
>> Common Lisp. PAIP is superb. I've heard good things about
>> Graham's Lisp book. However, in general the people that tried
>> them had a hard time with them. ...
>
> Oh, no kidding. "Object Oriented Common Lisp" (I think that's the one
> I'm thinking of) has done a good job of convincing the hardcore
> OO-heads I've pointed towards it, of how cool Lisp is. AI people tend
> to be open-minded enough (in my experience) that you can convince them
> that their previous problem with Lisp was because they were writing
> C-in-Lisp (I know quite a few people whose professors never commented
> on their Lisp style, or bothered to help them -- and looking at their
> code, I'm amazed they were as productive as they were. It's so much
> easier to write C in C, than to try to force Lisp to be C. How did
> their profs not mention this???).
I would wager that many (most?) of the profs don't *know* good
Lisp style. They are products of the same schools and have
often never mastered functional programming or Lisp. Some
schools have folks who are Lisp masters, and some of those folks
do a good job teaching Lisp, but others either don't or don't
teach the course.
>> ObDisclaimer: I truly love Common Lisp. I'm not trying to bash it.
>> Let me be the first to acknowledge I don't know nearly as much about
>> it or its circumstances as many of the people here....
>
> Didn't sound at all like bashing, more like loving criticism of the
> state of afairs.
... and I don't mean to bash university professors. We are
a product of our own environments. I went to an undergrad
school at which we saw about 3 weeks of Lisp--just enough for
most students to think it was horrible. Maybe the *right*
3 weeks would be good enough, but I think that students
should write real programs for a while in a language and
style so that they can learn its feel. But even folks who
want to do this at many univesities face two obstacles: the
faculty member himself isn't a Lisp master, and he can't
convince his colleagues to teach something "weird" or "not
standard" in the precious hours available.
---- Eugene
> I would wager that many (most?) of the profs don't *know* good
> Lisp style. They are products of the same schools and have
> often never mastered functional programming or Lisp. Some
> schools have folks who are Lisp masters, and some of those folks
> do a good job teaching Lisp, but others either don't or don't
> teach the course.
I don't know about many or most, but I know at least some professors
(and many coworkers) that don't know lisp is an object oriented
language, because the last time they used lisp was 10 years ago.
Moreover, they still think Common Lisp is just a bigger dialect of lisp
-- rather than basically the only lisp anyone uses these days, and a
distinct creature from scheme.
These professors are whizzes at ML, Prolog, etc., but Lisp has evolved
to become useful and they somehow didn't ever see "Object Oriented
Common Lisp" on a shelf or on amazon, and don't realize CLOS is part of
the ANSI standard etc. etc.
The point being that of course they don't know lisp style. They don't
know lisp. They don't even know ABOUT lisp. And they don't care about
learning and teaching good lisp because of the myth (yes, it's a myth)
that "There's no industry demand."
As people "in the know" we should continue to put pressure on our bosses
and our colleagues and on professors to learn _about_ lisp -- unlearning
the myths and learning the facts, even if they don't learn lisp itself.
That's what will give lisp a stronger footing when we try to advocate
it's use for this or that project.
Heck, maybe we should just forget logic and try the sell instead. We
need an advertising campaign like Java had -- Sun marketed Java from a
nothing into a something. Probably we on c.l.lisp don't have that kind
of cash, but I think a strong grass-roots effort could benefit us all...
I'm thinking of a flyer that has some sound bites on it and some pretty
colors that we could pass out to the the local CS faculty, our managers,
etc.
h
Hamilton Link <······@sandia.gov> writes:
> learning and teaching good lisp because of the myth (yes, it's a myth)
> that "There's no industry demand."
How is this a myth?
Yes, there are people out there using Lisp professionally. But
relative to the number of people using Java (ick), C++ (shudder), or
even Visual Basic (spastic convulsions), I'd be willing to bet that
the demand for professional Common Lispers is utterly
insignificant. I'd be very interested in language use statistics, if
any such things exist (or are even possible to accurately gather).
A search on monster.com for "Common Lisp" yields a single job at "SRI
International" which requires a PhD with a specialization in AI. A
search for "C++ OR Java" returns 4,997 jobs. "Visual Basic AND NOT
Java AND NOT C++" returns 1467. "Cobol" returns 1040. "RGP" returns
352. Even "Algol," arguably more obscure then Common Lisp, returns 5.
If you're graduating with an undergraduate degree, and want a job
using Lisp, I don't really think your (ok, "my" ;)) hopes should be
that great! If industry demand is to be a primary criteria for
deciding if a language is taught, then Common Lisp is a very bad
language to teach.
I happen to think that industry demand is a lousy criteria, myself. :)
Gabe Garza
Gabe Garza <·······@ix.netcom.com> wrote in message news:<············@kynopolis.org>...
> If you're graduating with an undergraduate degree, and want a job
> using Lisp, I don't really think your (ok, "my" ;)) hopes should be
> that great! If industry demand is to be a primary criteria for
> deciding if a language is taught, then Common Lisp is a very bad
> language to teach.
An alternative to consider would be to find a job where you would be
the only programmer, and where nobody would care what programming
language you used.
I think there is a widespread perception that Lisp is hard to learn,
and therefore hard to find programmers for. But if they only want one
programmer, and don't care what programming language is used, they
won't be so concerned about such things.
I think there are thousands of jobs where Lisp could be used, but
those jobs might be hard to find, because you wouldn't know what
keywords to enter in the search. Maybe focus on your non-programming
skills, to find a job using both those skills and programming.
Another alternative would be to get a non-Lisp programming job and
gradually subvert it into a Lisp job. E.g. write programs in Java as
directed, but write programs in Lisp to test the Java programs. Write
more programs in Lisp to find bugs in Java programs and to analyze
Java programming style. Or to generate documentation with diagrams,
etc., of Java programs. Keep doing such subversion for several years,
and you will gradually become known as the company Lisp expert, and
some of your Lisp programs might trigger new projects to build better
versions for more general purposes, with you being the manager of the
project, and the person who chooses the programming language.
Another alternative would be to do something like what Paul Graham
did. Maybe start in your spare time, but eventually build it into
something really great, which a big company would pay millions for, or
which you could use as the foundation of your own company which might
eventually grow very big.
Lisp programmers have to think out of the box. The box is the idea
that you need a "Lisp Job" or that there is not enough demand for
"Lisp Programmers". It's a big world out there and the demand for
what you can accomplish is overwhelming. You just have to find a way
to connect with that demand, and to make people understand that you
are the person they need.
On 10 Nov 2001, Software Scavenger wrote:
> An alternative to consider would be to find a job where you would be
> the only programmer, and where nobody would care what programming
> language you used.
That's what I do. I am a univeristy student and doing ecological
research. (majors are CS and Biology) My research is mostly analysis,
basically coding to find some answers in our data. The people I work with
are all ecologists and biologists. As such, they don't really care what I
use, as long as it produces results and in a reasonable time frame. (I
use Squeak, not Lisp, but am planning on starting to use MCL when the OS X
version comes out)
Regards,
Aaron
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/
"truth is beautiful, without doubt; but so are lies." :: r. w. emerson
On 10 Nov 2001 01:00:29 -0800, ··········@mailandnews.com (Software
Scavenger) wrote:
> An alternative to consider would be to find a job where you would be
> the only programmer, and where nobody would care what programming
> language you used.
It looks like there is some sort of feeling that you have a Lisp job only
when you work for a Fortune 500-like megacorporation. Might this be a
consequence of the Yahoo! Store success?
If those who are looking for a Lisp job are willing to settle for something
less, I suggest that they check with their relatives and close friends.
Some of them may be in need of some software system, and may not care at
all about the language used to develop it: the trust relationship may be
stronger than--real or perceived--technical issues.
Some time ago I wrote for a friend an application for Palm OS PDAs. I used
LispMe[*], and I even got "paid" (a couple of pizzas :) for it. I'm
probably going to write some more software for him in Common Lisp, this
time for real money and not for food.
Paolo
[*] Okay, it's Scheme and not Lisp. But it's equally fun on such a tiny
device.
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
* Software Scavenger
| Another alternative would be to get a non-Lisp programming job and
| gradually subvert it into a Lisp job. E.g. write programs in Java as
| directed, but write programs in Lisp to test the Java programs. Write
| more programs in Lisp to find bugs in Java programs and to analyze Java
| programming style. Or to generate documentation with diagrams, etc., of
| Java programs. Keep doing such subversion for several years, and you
| will gradually become known as the company Lisp expert, and some of your
| Lisp programs might trigger new projects to build better versions for
| more general purposes, with you being the manager of the project, and the
| person who chooses the programming language.
This is a very good idea. It does, however, require that those who would
do this are more "mature" than those irresponsible, short-sighted people
who regard every position they hold as a spring board to the next job,
which I personally cannot fathom why anyone would want to hire in the
first place, and it requires people who are interested in _investing_ in
their own future and that of the company they work for, not just get a
bunch of money and neither learn nor leave anything of value when they
find a new job. I think the selfish, short-sighted nature of most of
today's "young IT professionals" has caused problems that it will take
many years to repair. Fortunately, fringe/elite languages like Common
Lisp can help repair it more and better than the "langage du jour" can.
This is probably the only one of the many problems resulting from rampant
idiocy in the "IT" business that I would _not_ blame on management. In
my view, you would have to be no better than a prostitute if you accepted
a job _only_ for the money and already had in mind getting a new job
before you started working there. The kind of assembly-line workers that
_can_ switch jobs this easily fit into positions that are of no value to
anyone but from the scarcity of people who can fill them combined with
the perceived, but _not_ real, need to fill these positions, but these
are created by the people who _fill_ these jobs, not by management. What
kind of manager would _want_ to deal with the hassle of hiring people so
frequently, with the foreknowledge that he only need to fill a job that
performs a specific task that exists only because of the _incompetence_
of previous hires who had quit? In my view, a manager worth his salt
would have nightmares thinking about all the one-trick ponies he had to
hire to get a more complex job done at all. Therefore, I do not think a
manager would do anything to continue this trend as soon as he saw where
it was going, nor start it if he looked at how he would have to pay ever
more for less value if he only lured people with money.
Today's unskilled or one-skilled younger generation of computer geeks
will face the wall of uselessness much faster and much sooner than most
of them would ever expect. The sets of skills that are needed to make
some version of some particular program that is overly complicated (yet
"user friendly" in the wrong ways) because it was written and designed by
stupid people in a surreal hurry, will go out of vogue faster than they
can learn the next similar program or upgrade themselves to use the next
version better than the competition getting into the market from being
bored in high school, where they sacrifice learning real skills to short-
term money-making adventures. I may be becoming a grumpy old man, but it
appears that if you want to get serious computer-related work done these
days, do not hire people below the age of 25, _whatever_ they claim to
know -- whatever it is, it is probably the _only_ thing they know, and
they have no additional knowledge to evaluate its appropriateness of use.
Do not hire people who know Java -- hire people who know Java, _too_.
| Lisp programmers have to think out of the box.
Conversely, if you need someone who is used to think outside the box,
hire a (Common) Lisp programmer, and expect to get uncommon flexibility
in their thinking skills, a wide variety of backgrounds, serious
interests in many aspects of the development process, etc.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
In article <···························@posting.google.com>, "Software
Scavenger" <··········@mailandnews.com> wrote:
> Gabe Garza <·······@ix.netcom.com> wrote in message
> news:<············@kynopolis.org>...
>> If you're graduating with an undergraduate degree, and want a job
>> using Lisp, I don't really think your (ok, "my" ;)) hopes should be
>> that great! If industry demand is to be a primary criteria for
>> deciding if a language is taught, then Common Lisp is a very bad
>> language to teach.
> I think there is a widespread perception that Lisp is hard to learn, and
> therefore hard to find programmers for. But if they only want one
> programmer, and don't care what programming language is used, they won't
> be so concerned about such things. I think there are thousands of jobs
> where Lisp could be used, but those jobs might be hard to find, because
> you wouldn't know what keywords to enter in the search. Maybe focus on
> your non-programming skills, to find a job using both those skills and
> programming.
That's an important point: there's probably not much of a market for pure
Lisp programmers in the same way there appears to be a market for pure
Java and Perl programmers, but that doesn't mean that there isn't a
healthy market for Lisp jobs. For an analogy, look to another language
that is as old as Lisp: Fortran. I bet that for the last 30 years there
have been a vanishingly tiny number of "Fortran jobs", but many thousands
of scientists and engineers still do serious Fortran programming daily.
In the same way, there don't seem to be too many pure Lisp opportunities
around unless you're a Lisp superstar, but there are a fair number of
opportunities (see Franz' webpage) if you have some expertise in AI,
scheduling, compilers, eCommerce, etc.
So yeah, your non-programming language skills are as least as important
as your Lisp skills for getting a job in which you can use Lisp.
I should also note that the range of advertised Lisp jobs look *way* more
interesting than the range of typical IT jobs, assuming you have the
skills to do them. IMHO.
Tim
Software Scavenger wrote:
>
> An alternative to consider would be to find a job where you would be
> the only programmer, and where nobody would care what programming
> language you used.
Exactly what I do. My bosses pay me to write software that helps them
make money, and that's pretty much all they care about. So I get to use
whatever I want, and much of the time that's Lisp.
Howard
--
Howard Ding
······@worldnet.att.net
http://math.sunysb.edu/~hading http://thunder.prohosting.com/~hading
··········@mailandnews.com (Software Scavenger) writes:
>
> An alternative to consider would be to find a job where you would be
> the only programmer, and where nobody would care what programming
> language you used.
>
Yes. And yet another alternative is to hone your skills, and
become responsible for a development team. You must do this
in a company where management trusts you to make technical
decisions, and you trust management to make correct business
decisions. Then evaluate your needs, and perhaps you will find
that lisp fits them. Then you tell management that you will
be using Lisp.
Note, for this to work: management has to TRUST you. They
have to know you have a stake, they have to know you'll be
there some years from now.
That's been my story. We evaluated technologies, and basically
came down to lisp or python. Somewhat surprisingly (to me), it
was easier to recruite lisp programmers than python programmers.
You will NOT be able to do this in an environment where people are
scared of taking risks, or treat their employees poorly (i.e. as
if they were interchangeable). In a previous job, I failed to
change a single programming practice after over 3 years of delivering
on every task. I took the hint. When the dotcom bust hit, that
company's stock went from $17 to $0.05, and that came as no surprise
to me.
Advice to a prospective young programmer: find out from your
employer how they work, and what they do that is different
from their competitors. If the answer is that they're sheep,
and only do what "everybody else" is doing (e.g. Java Bandwagon
shops) you don't want to work there.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
Alain Picard <·······@optushome.com.au> writes:
> When the dotcom bust hit, that
> company's stock went from $17 to $0.05, and that came as no surprise
> to me.
Good thing you weren't using Lisp or it might have caused this. ;-)
heh-heh, the story of how CliniSys ended up using Lisp:
Alain Picard wrote:
>
> ··········@mailandnews.com (Software Scavenger) writes:
>
> >
> > An alternative to consider would be to find a job where you would be
> > the only programmer, and where nobody would care what programming
> > language you used.
> >
>
> Yes. And yet another alternative is to hone your skills, and
> become responsible for a development team. ... Then you tell management that you will
> be using Lisp.
>
> Note, for this to work: management has to TRUST you.
"Kenny Tilton" <·······@nyc.rr.com> wrote
> heh-heh, the story of how CliniSys ended up using Lisp:
>
> Alain Picard wrote:
> >
> > ··········@mailandnews.com (Software Scavenger) writes:
> >
> > >
> > > An alternative to consider would be to find a job where you would be
> > > the only programmer, and where nobody would care what programming
> > > language you used.
> > >
> >
> > Yes. And yet another alternative is to hone your skills, and
> > become responsible for a development team. ... Then you tell management
that you will
> > be using Lisp.
> >
> > Note, for this to work: management has to TRUST you.
I also think that trust *is* the major factor. This applies to in-house and
even more to contract programming.
The trouble for new programmers is that they don't have the years of
practice that build that trust. They have to build it by solving problems in
an efficient and clean way. (rather easy compared to the Java/C*/script
languages/etc. crowds)
When the trust is there, the second problem is : "Where will we find people
to work on your stuff is you (or your company) disappear for any reason."
Maybe it could be a good idea to have a list somewhere (alu, cliki ?) of
people/companies that are able to work on Lisp projects.
Marc
On Sun, 11 Nov 2001 13:34:58 +0100, "Marc Battyani" <·············@fractalconcept.com>
wrote:
>
>"
>I also think that trust *is* the major factor. This applies to in-house and
>even more to contract programming.
>The trouble for new programmers is that they don't have the years of
>practice that build that trust. They have to build it by solving problems in
>an efficient and clean way. (rather easy compared to the Java/C*/script
>languages/etc. crowds)
>
Technical decision in the industry are not based on "trust" or personal opinions of
this-or-that developer. Developers don't decide about programming languages unless this
is single person, basement-type operation. These mechanisms cause that it is very hard to
convince management to use something that is not Java, C++ or VB.
Finally, maybe somebody would give me at least one good reason (other than "because I like
it") why LISP should be used instead of one of the above mentioned languages.
A.L.
"Andrzej Lewandowski" <·············@attglobal.net> wrote in message
·······································@4ax.com...
> convince management to use something that is not Java, C++ or VB.
>
> Finally, maybe somebody would give me at least one good reason (other than
"because I like
> it") why LISP should be used instead of one of the above mentioned languages.
>
troll.
On Sun, 11 Nov 2001 18:09:10 GMT, "Coby Beck" <·····@mercury.bc.ca> wrote:
>
>"Andrzej Lewandowski" <·············@attglobal.net> wrote in message
>·······································@4ax.com...
>> convince management to use something that is not Java, C++ or VB.
>>
>> Finally, maybe somebody would give me at least one good reason (other than
>"because I like
>> it") why LISP should be used instead of one of the above mentioned languages.
>>
>
>troll.
>
I am not a troll. I am in charge of selecting tools for AI-based components of products
being developed by my company (it does't matter what is the name). Our business area is
supply channel management and logistics. These AI based components are mostly constraint
programming and agents. We are currently using Prolog, but Prolog (despite its obvious
advantages) has obvious disadvantages. One is that it is pretty hard (well...
inconvenient) to write parts of the algorithm that have purely procedural character. Since
we are extending the product lines, one obvious question is whether it would be reasonable
and justified to use something else instead of Prolog. LISP definitely is the alternative,
but... I have posted a qeustion about constraint solver for LISP - it seems that nothing
is available. There are several for Prolog, Java anc C++. I have also posted question
about interfaces to commercial linear programming solvers. None. There are number of them
for Prolog, C++ and Java.
Therefore, again: could you give me a reason why we should use LISP?...
A.L.
Andrzej Lewandowski <·············@attglobal.net> writes:
> but... I have posted a qeustion about constraint solver for LISP -
> it seems that nothing is available. There are several for Prolog,
> Java anc C++. I have also posted question about interfaces to
> commercial linear programming solvers. None. There are number of
> them for Prolog, C++ and Java.
Have you looked at LispWorks from Xanalys (www.xanalys.com)? Their
"Enterprise Edition" comes with an embedded prolog interpreter that can
use either a Lisp'ish or traditional prolog syntax. Might give you the
best of both worlds.
Gabe Garza
On Sun, 11 Nov 2001 20:43:31 GMT, Gabe Garza <·······@ix.netcom.com> wrote:
>Andrzej Lewandowski <·············@attglobal.net> writes:
>
>> but... I have posted a qeustion about constraint solver for LISP -
>> it seems that nothing is available. There are several for Prolog,
>> Java anc C++. I have also posted question about interfaces to
>> commercial linear programming solvers. None. There are number of
>> them for Prolog, C++ and Java.
>
> Have you looked at LispWorks from Xanalys (www.xanalys.com)? Their
>"Enterprise Edition" comes with an embedded prolog interpreter that can
>use either a Lisp'ish or traditional prolog syntax. Might give you the
>best of both worlds.
>
This is not what I am looking for. I would like to replace Prolog by LISP, but not bring
one more language to the organization. Moreover, I am not using just-a-Prolog. I am using
Prolog that has built-in constraint solver (CLP(fd), strictly speaking), and currently
there are 5 such Prologs on the market. This what Xanalys has doesn't belong to this
category.
A.L.
Andrzej Lewandowski wrote:
> On Sun, 11 Nov 2001 20:43:31 GMT, Gabe Garza <·······@ix.netcom.com>
> wrote:
>
>>Andrzej Lewandowski <·············@attglobal.net> writes:
>>
>>> but... I have posted a qeustion about constraint solver for LISP -
>>> it seems that nothing is available. There are several for Prolog,
>>> Java anc C++. I have also posted question about interfaces to
>>> commercial linear programming solvers. None. There are number of
>>> them for Prolog, C++ and Java.
>>
>> Have you looked at LispWorks from Xanalys (www.xanalys.com)? Their
>>"Enterprise Edition" comes with an embedded prolog interpreter that can
>>use either a Lisp'ish or traditional prolog syntax. Might give you the
>>best of both worlds.
>>
>
> This is not what I am looking for. I would like to replace Prolog by LISP,
> but not bring one more language to the organization. Moreover, I am not
> using just-a-Prolog. I am using Prolog that has built-in constraint solver
> (CLP(fd), strictly speaking), and currently there are 5 such Prologs on
> the market. This what Xanalys has doesn't belong to this category.
>
> A.L.
http://directory.google.com/Top/Computers/Programming/Languages/Mercury/
maybe they can help you
--
···········@pulsesoft.com
On Mon, 12 Nov 2001 01:42:44 +0300, ······@comtv.ru wrote:
>Andrzej Lewandowski wrote:
>
>> On Sun, 11 Nov 2001 20:43:31 GMT, Gabe Garza <·······@ix.netcom.com>
>> wrote:
>>
>>>Andrzej Lewandowski <·············@attglobal.net> writes:
>>>
>>>> but... I have posted a qeustion about constraint solver for LISP -
>>>> it seems that nothing is available. There are several for Prolog,
>>>> Java anc C++. I have also posted question about interfaces to
>>>> commercial linear programming solvers. None. There are number of
>>>> them for Prolog, C++ and Java.
>>>
>>> Have you looked at LispWorks from Xanalys (www.xanalys.com)? Their
>>>"Enterprise Edition" comes with an embedded prolog interpreter that can
>>>use either a Lisp'ish or traditional prolog syntax. Might give you the
>>>best of both worlds.
>>>
>>
>> This is not what I am looking for. I would like to replace Prolog by LISP,
>> but not bring one more language to the organization. Moreover, I am not
>> using just-a-Prolog. I am using Prolog that has built-in constraint solver
>> (CLP(fd), strictly speaking), and currently there are 5 such Prologs on
>> the market. This what Xanalys has doesn't belong to this category.
>>
>> A.L.
>http://directory.google.com/Top/Computers/Programming/Languages/Mercury/
>maybe they can help you
Yes, I know Mercury. Other option (even better) wpuld be Mozart-Oz www.mozart-oz.org
Unfortunately, both don't offer maintenance/support, both are experimental, and there is
no sufficient experience with applying this stuff in large commercial projects.
A.L.
Andrzej Lewandowski <·············@attglobal.net> writes:
> > On Sun, 11 Nov 2001 20:43:31 GMT, Gabe Garza <·······@ix.netcom.com> wrote:
>
> > Have you looked at LispWorks from Xanalys (www.xanalys.com)? Their
> >"Enterprise Edition" comes with an embedded prolog interpreter that can
> >use either a Lisp'ish or traditional prolog syntax. Might give you the
> >best of both worlds.
> This is not what I am looking for. I would like to replace Prolog by
> LISP, but not bring one more language to the organization. Moreover,
> I am not using just-a-Prolog. I am using Prolog that has built-in
> constraint solver (CLP(fd), strictly speaking), and currently there
> are 5 such Prologs on the market. This what Xanalys has doesn't
> belong to this category.
Unless you want a transitional solution instead of an overnight one.
Honestly, you say in another post that you don't want to pay more than
for another language. A language is a packaged commodity tool, it is not
a custom tool to a specific business need.
Yet you have a very specific list of constraints that are your personal
business constraints and that don't match the constraints of anyone else
I've heard post here, nor met in real life.
The commercial world does not work this way generally. It packages things in
a way it thinks will sell well to a lot of people. When people don't like
those configurations, they pay more. When they insist on both getting more
and paying less, they get nothing.
I hope if you finally get the constriant solver and you plug this
query into it, it will help you to understand why people are sounding
snippy. The problem sounds overconstrained to me, and they are
expressing what I consider to be frustration at that after having each
(myself included) volunteered a bit of their personal time to hearing
you and trying to make good-faith suggestions. Personally, I'm not
going to beat my head against the wall further on it. I've read the
other posts on this thread and can see I'm not going to be able to
make you happy, so I will decline to trouble you further by trying. I
do wish you luck though.
On Mon, 12 Nov 2001 01:56:23 GMT, Kent M Pitman
<······@world.std.com> wrote:
>Andrzej Lewandowski <·············@attglobal.net> writes:
>
>> > On Sun, 11 Nov 2001 20:43:31 GMT, Gabe Garza <·······@ix.netcom.com> wrote:
>>
>> > Have you looked at LispWorks from Xanalys (www.xanalys.com)? Their
>> >"Enterprise Edition" comes with an embedded prolog interpreter that can
>> >use either a Lisp'ish or traditional prolog syntax. Might give you the
>> >best of both worlds.
>
>> This is not what I am looking for. I would like to replace Prolog by
>> LISP, but not bring one more language to the organization. Moreover,
>> I am not using just-a-Prolog. I am using Prolog that has built-in
>> constraint solver (CLP(fd), strictly speaking), and currently there
>> are 5 such Prologs on the market. This what Xanalys has doesn't
>> belong to this category.
>
>Unless you want a transitional solution instead of an overnight one.
>
>Honestly, you say in another post that you don't want to pay more than
>for another language. A language is a packaged commodity tool, it is not
>a custom tool to a specific business need.
>
>Yet you have a very specific list of constraints that are your personal
>business constraints and that don't match the constraints of anyone else
>I've heard post here, nor met in real life.
>
Then, maybe we are living in difefrent worlds. When I was in the
Academia, I was thinking your way. Then, I have discovered that real
life is a bit different.
What regards cost: when I suggest that new language or development
tools should be introduced, I have to provide answer to the
following questions: a) how much this transition will cost, b) what
will be teh benefits, c) what are the risks. I have to demonstrate
what we get for each dollar invested.
This is more or less teh difference between the Academia where
"technical beauty" is the main criterion, and the real life where
(unfortunately) the dollar rules.
>The commercial world does not work this way generally. It packages things in
>a way it thinks will sell well to a lot of people. When people don't like
>those configurations, they pay more. When they insist on both getting more
>and paying less, they get nothing.
>
Were, very naive view.... If customers are asked to pay more, they
go to the competition...
>I hope if you finally get the constriant solver and you plug this
>query into it, it will help you to understand why people are sounding
>snippy. The problem sounds overconstrained to me, and they are
>expressing what I consider to be frustration at that after having each
>(myself included) volunteered a bit of their personal time to hearing
>you and trying to make good-faith suggestions.
All real life problems are overconstrained, both business problems
like those I mentioned and relating to technology and tool
selection, and these problems that I am solving using constraint
solver. There is a whole branch of Constraint Satisfaction that
deals with overconstraint problems. Can provide links if you want to
learn something new.
> Personally, I'm not
>going to beat my head against the wall further on it. I've read the
>other posts on this thread and can see I'm not going to be able to
>make you happy, so I will decline to trouble you further by trying. I
>do wish you luck though.
Thanks.
A.L.
* Andrzej Lewandowski wrote:
| * Kent Pitman wrote:
| >The commercial world does not work this way generally. It packages
| >things in a way it thinks will sell well to a lot of people. When
| >people don't like those configurations, they pay more. When they
| >insist on both getting more and paying less, they get nothing.
|
| Were, very naive view.... If customers are asked to pay more, they
| go to the competition...
How is his view naive? Suppose you want to buy a car, that costs
$20,000, without a radio. You don't like this configuration, and want
a radio, which costs an additional $1000. Do you go to the
competition, because now you have to pay $21,000? That's strange.
Boris
--
·····@uncommon-sense.net - <http://www.uncommon-sense.net/>
He only knew his iron spine held up the sky -- he didn't realize his brain
had fallen to the ground.
-- The Book of Serenity
On Sun, 11 Nov 2001 16:26:28 -0500, Andrzej Lewandowski
<·············@attglobal.net> wrote:
> On Sun, 11 Nov 2001 20:43:31 GMT, Gabe Garza <·······@ix.netcom.com> wrote:
[...]
> > Have you looked at LispWorks from Xanalys (www.xanalys.com)? Their
> >"Enterprise Edition" comes with an embedded prolog interpreter that can
> >use either a Lisp'ish or traditional prolog syntax. Might give you the
[...]
> This is not what I am looking for. I would like to replace Prolog by LISP, but not bring
> one more language to the organization. Moreover, I am not using just-a-Prolog. I am using
This way you bring just one language with many programming paradigms.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Andrzej Lewandowski wrote:
> I am not a troll.
it seemed that way since you did not offer all this other useful
background in your original somewhat contentious "one good reason"
challnege--didn't really seem like a question, and indeed it still seems
as if you have made up your mind and are just looking for a scrap. But
maybe that is just your style, so...
> I have posted a qeustion about constraint solver for LISP - it seems
> that nothing is available. There are several for Prolog, Java anc C++. I have also posted question
> about interfaces to commercial linear programming solvers. None. There are number of them
> for Prolog, C++ and Java.
Can you call these commercial packages thru the Lisp foreign function
interface? Would that be acceptable? We use a few third party packages
in our app, none of them in Lisp.
>
> Therefore, again: could you give me a reason why we should use LISP?...
>
I think first we need to figure out if you can get to the commercial
constraint systems you like from Lisp, or it does not matter how many
reasons there are for using Lisp. Is that right?
kenny
clinisys
On Sun, 11 Nov 2001 22:12:11 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>Andrzej Lewandowski wrote:
>> I am not a troll.
>
>it seemed that way since you did not offer all this other useful
>background in your original somewhat contentious "one good reason"
>challnege--didn't really seem like a question, and indeed it still seems
>as if you have made up your mind and are just looking for a scrap. But
>maybe that is just your style, so...
>
>> I have posted a qeustion about constraint solver for LISP - it seems
>> that nothing is available. There are several for Prolog, Java anc C++. I have also posted question
>> about interfaces to commercial linear programming solvers. None. There are number of them
>> for Prolog, C++ and Java.
>
>Can you call these commercial packages thru the Lisp foreign function
>interface? Would that be acceptable? We use a few third party packages
>in our app, none of them in Lisp.
>
Yes, but this would be technical and economical nonsense. I can call these modules from
C++ already, and I can do in C++ what I can do in LISP (although I would prefer LISP).
Adding additional layer would have no sense. Moreover, such layer would increase all
possible costs - tools, implementation and runtime fees. Each time I want to introduce new
tool, I have to provide arguments that this new tool will simplify development, reduce
cost and reduce time to market. Bringing LISP as interafce between C++ and C++ could be
not justified. Bringing Prolog as constraint solver simplified a lot of things, reducing
essentially the development and reducing the cost
>>
>> Therefore, again: could you give me a reason why we should use LISP?...
>>
>
>I think first we need to figure out if you can get to the commercial
>constraint systems you like from Lisp, or it does not matter how many
>reasons there are for using Lisp. Is that right?
>
No. Question was rhetorical. In this sense I AM a troll :) I always consider amusing
discussions between guys from the academia on "what to do to make language XXX more
popular in the industry". By the way, this is not only LISP. See Eiffel, for example. In
most cases they have the same knowledge of industry as I have about Japanese dance
Kabuki. Don't be offended guys, I spent 25 years in the Academia. I know :)
Being serious: I want to know whether selecting Prolog was The Best Idea. Bringing Prolog
as constraint solver simplified a lot of things, reduced essentially the development and
runtime cost. As I have mentioned, from technical standpoint it is not the ideal one.
Maybe there is better solution. Or Prolog is the best. Who knows. Therefore, the
question: is there any other language that
1. Would replace Prolog and the associated functionality,
2. There is sufficient number of commercially available components or interfaces to these
components (constraints, LP solvers, database, COM),
3. Would have better run-time efficiency than Prolog,
4. Would have adequate support and maintenance,
5. Vendors would be in good financial health, thus giving guarantee that they will not go
belly-up next year. There should be more than a single vendor,
6. Using this language would be cost effective, with little impact on the bottom-line
(i.e. no runtime fees or small runtime fees),
7. Is the language known for long enough and is there established record of commercial
applications,
8. Is it easy to find EXPERIENCED programmers somewhere here, not, say in the Antarctica
(training is not the option),
9. How much such programmers would cost.
LISP is obvious candidate, with many positive answers, but not all. At least, for today.
A.L.
P.S. By the way, first time I was using LISP about 1970, on CDC 6600 and CDC 3170
"supercomputers"... This was fun. On punched cards.
Andrzej Lewandowski wrote:
>
> On Sun, 11 Nov 2001 22:12:11 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
>
> >
> >
> >Andrzej Lewandowski wrote:
> >> I am not a troll.
> >
...
> No. Question was rhetorical. In this sense I AM a troll :)
...
> Being serious:.... [followed by more flamebait]
chya.
kenny
clinisy
"Andrzej Lewandowski" <·············@attglobal.net> wrote in message
·······································@4ax.com...
> On Sun, 11 Nov 2001 18:09:10 GMT, "Coby Beck" <·····@mercury.bc.ca> wrote:
>
> >
> >"Andrzej Lewandowski" <·············@attglobal.net> wrote in message
> >·······································@4ax.com...
> >> convince management to use something that is not Java, C++ or VB.
> >>
> >> Finally, maybe somebody would give me at least one good reason (other
than
> >"because I like
> >> it") why LISP should be used instead of one of the above mentioned
languages.
> >>
> >
> >troll.
> >
>
> I am not a troll. I am in charge of selecting tools for AI-based
components of products
Your tone looks like you are trolling
> being developed by my company (it does't matter what is the name).
Curious people can find it in a few seconds just by typing your name + CLP
in google...
> Our business area is
> supply channel management and logistics. These AI based components are
mostly constraint
> programming and agents. We are currently using Prolog, but Prolog (despite
its obvious
> advantages) has obvious disadvantages. One is that it is pretty hard
(well...
> inconvenient) to write parts of the algorithm that have purely procedural
character. Since
> we are extending the product lines, one obvious question is whether it
would be reasonable
> and justified to use something else instead of Prolog. LISP definitely is
the alternative,
> but... I have posted a qeustion about constraint solver for LISP - it
seems that nothing
> is available. There are several for Prolog, Java anc C++. I have also
posted question
> about interfaces to commercial linear programming solvers. None. There are
number of them
> for Prolog, C++ and Java.
>
> Therefore, again: could you give me a reason why we should use LISP?...
Your problem is that you put a constraint : "Must have a commercially
supported constraint solver written in it"
So in *your* case, as it doesn't seem there is one in Lisp we can all infer
that you can't use Lisp.
It's like if somebody wants to write an Excel macro, Lisp will probably not
be the best solution to his needs.
Nobody said that Lisp was the solution for every problem in the world. Lisp
is the best solution to write programs to solve problems, but *you* don't
want to program, *you* want to use a constraint solver and nobody has ever
said that Lisp was the best solution to use a constraint solver. So *you*
have no reasons to use Lisp (at least in this case)
BTW .
Marc
Andrzej Lewandowski <·············@attglobal.net> wrote in message news:<··································@4ax.com>...
[In fact in a much earlier message]
> >> Finally, maybe somebody would give me at least one good reason (other than
> "because I like
> >> it") why LISP should be used instead of one of the above mentioned languages.
And then you wrote
> I have posted a qeustion about constraint solver for LISP - it seems that nothing
> is available. There are several for Prolog, Java anc C++. I have also posted question
> about interfaces to commercial linear programming solvers. None. There are number of them
> for Prolog, C++ and Java.
So really, what you *meant* was that given a very specific set of
requirements - specifically a commercially supported package to do a
certain specific task, Lisp doesn't meet the requirements. Given
this, your phrasing in the initial article was misleading at best.
I'm sure you didn't intend to mislead, but you might want to work on
your English.
--tim
On 12 Nov 2001 08:02:06 -0800, ··········@tfeb.org (Tim Bradshaw)
wrote:
>Andrzej Lewandowski <·············@attglobal.net> wrote in message news:<··································@4ax.com>...
>
>I'm sure you didn't intend to mislead, but you might want to work on
>your English.
Thanks for advice. I consider my English good enough. At least for me.
Congratulations for being promoted to Kill File.
A.L.
Andrzej Lewandowski <·············@attglobal.net> writes:
> On 12 Nov 2001 08:02:06 -0800, ··········@tfeb.org (Tim Bradshaw)
> wrote:
> >Andrzej Lewandowski <·············@attglobal.net> wrote in message news:<··································@4ax.com>...
> >I'm sure you didn't intend to mislead, but you might want to work
> >on your English.
> Thanks for advice. I consider my English good enough. At least for
> me. Congratulations for being promoted to Kill File.
Apparently it wasn't up to communicating what you _really_ wanted.
That's probably _not_ an issue of quality-of-English.
If you promote guys like Tim to your Kill File, that presumably
diminishes the number of disagreements you have, but is also pretty
likely to diminish the quality of the discussion that you see. (He
may have been unkind, but you probably deserved it, much as we all do,
at our own times.)
If you cut people out based just on not liking what you hear, that
hurts you more than it does anybody else.
--
(concatenate 'string "chris" ·@cbbrowne.com")
http://www.cbbrowne.com/info/advocacy.html
When they ship styrofoam, what do they pack it in?
Andrzej Lewandowski <·············@attglobal.net> writes:
> >I'm sure you didn't intend to mislead, but you might want to work on
> >your English.
>
> Thanks for advice. I consider my English good enough. At least for me.
It should be noted, that English is a language, and that it's primary
purpose (barring some linguistic critical-theory acrobatics) is
communication with others. So while your command of the language may
seem good enough to you, it may not be sufficient for communicating
with others.
I think Tim was attempting to give you the benefit of the doubt,
suggesting that your use of inflammatory terms was an unintentional
mistake.
I however think you know exactly what you are implying and chalk it up
not to a deficiency in your command of English, but to the frustration
of not being able to evaluate the use of CL in your context in a
rational manner due to lack of information (solvable), and lack of
insight into how such evaluations should be carried out (solvable as
well).
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
All around the world hearts pound with the rythym. Fear not of
men because men must die. - Mos Def
Craig Brozefsky <·····@red-bean.com> wrote in message news:<··············@piracy.red-bean.com>...
> I think Tim was attempting to give you the benefit of the doubt,
> suggesting that your use of inflammatory terms was an unintentional
> mistake.
>
Well, I see two choices really. (1) his English is not good so he
posted the original message which I, as a native speaker and I think
in common with other native speakers in c.l.l, interpreted as `show me
a reason why *anyone* should use Lisp'(which I think is a pretty
inflamatory and stupid thing to post in c.l.l), when what he mant was
`show me a reason I should use Lisp for this specific problem', which
is a completely different question and one that both more interesting
and much less offensive (really, not offensive at all, unless you are
one of the lunatic fringe who thinks all problems are best solved in
Lisp). (2) His English is fine, and he was simply deliberately being
offensive (trolling, I suppose). I don't see a middle way.
He seems to have answered the question though: he was indeed trying to
be offensive, apparently.
As an aside, this is the first time anyone has ever publicly
kill-filed me - I am *so* proud!
--tim
In article <··································@4ax.com>, "Andrzej
Lewandowski" <·············@attglobal.net> wrote:
> On Sun, 11 Nov 2001 18:09:10 GMT, "Coby Beck" <·····@mercury.bc.ca>
> wrote:
>
>
>>"Andrzej Lewandowski" <·············@attglobal.net> wrote in message
>>·······································@4ax.com...
>>> convince management to use something that is not Java, C++ or VB.
>>>
>>> Finally, maybe somebody would give me at least one good reason (other
>>> than
>>"because I like
>>> it") why LISP should be used instead of one of the above mentioned
>>> languages.
>>>
>>>
>>troll.
>>
>>
> I am not a troll. I am in charge of selecting tools for AI-based
> components of products being developed by my company (it does't matter
> what is the name). Our business area is supply channel management and
> logistics. These AI based components are mostly constraint programming
> and agents. We are currently using Prolog, but Prolog (despite its
> obvious advantages) has obvious disadvantages. One is that it is pretty
> hard (well... inconvenient) to write parts of the algorithm that have
> purely procedural character. Since we are extending the product lines,
> one obvious question is whether it would be reasonable and justified to
> use something else instead of Prolog. LISP definitely is the
> alternative, but... I have posted a qeustion about constraint solver for
> LISP - it seems that nothing is available. There are several for Prolog,
> Java anc C++. I have also posted question about interfaces to commercial
> linear programming solvers. None. There are number of them for Prolog,
> C++ and Java.
>
> Therefore, again: could you give me a reason why we should use LISP?...
>
>
I think the screamer package has a constraints solver, do a google search
for "screamer common lisp"
or just go here:
http://www.cis.upenn.edu/~screamer-tools/screamer-intro.html
Interfacing to a commercial linear programming module will probably
require a FFI (foreign function interface) based interface. Pick your
implementation, then write an FFI, some implementations will read C header
files and write the FFI for you.
One of the biggest pluses you will get from using lisp, is the ability to
choose just about any style of programming you want, and have it integrate
into the language clearly and concisely. Lisp programs can be functional,
transformational, non-deterministic, procedural, object oriented,
constraints based, whatever, and all at once if you want.
Plus the powerful ability to create a sub-language that expresses your
problem more clearly using Lisp macros is unparalleled.
You should get ahold of "On Lisp" if you can find a copy (out of print
now) and "ANSI Common Lisp", both by Paul Graham.
You might also try "Paradigms of AI Programming", by Peter Norvig.
Without knowing more about the problems you have specifically I can't help
you more than this. If you would like to consult with me, see my website
at:
http://www.endpointcomputing.com
and I'd be happy to negotiate a reasonable fee to help you evaluate Lisp
or other languages
for your uses.
"Daniel Lakeland" <········@sil-no.spam-con.com> writes:
> I think the screamer package has a constraints solver, do a google search
> for "screamer common lisp"
>
> or just go here:
>
> http://www.cis.upenn.edu/~screamer-tools/screamer-intro.html
At this point, I couldn't care less about the OP, but if anyone else
is somewhat interested in Lisp constraints solvers, apparently Michel
Lema�tre <http://www.cert.fr/fr/dcsd/CD/CDPUB/MEMBRES/lemaitre/>
[warning, the page is in French] has a constraints library that's
still being maintained at <ftp://ftp.cert.fr/pub/lemaitre/LVCSP/>
[in English]
Disclaimer: I don't know a thing about constraints (sigh ... so much
to learn); I was pointed here some time ago for a reason I can't
remember. But then, there it was in my poorly-organized bookmarks.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Andrzej Lewandowski <·············@attglobal.net> writes:
> We are currently using Prolog, but Prolog (despite its obvious
> advantages) has obvious disadvantages. One is that it is pretty hard
> (well... inconvenient) to write parts of the algorithm that have
> purely procedural character. Since we are extending the product
> lines, one obvious question is whether it would be reasonable and
> justified to use something else instead of Prolog. LISP definitely
> is the alternative, but... I have posted a qeustion about constraint
> solver for LISP - it seems that nothing is available.
Harlequin (now Xanalys) used to have an integrated Lisp/Prolog
environment, I think. I don't know if it still does. And I think it
has their KnowledgeWorks expert system shell, which is either the same
thing or something similar -- I know it's something that integrates
with Lisp at the meta-object level. I don't know the details, nor do
I get a commission for mentioning it, but I'd recommend contacting them.
I'm sure there are expert system shells and constraint solvers written in
Lisp. How to go about looking for them seems more the problem. That's
an important issue, for sure, but it arguably isn't one that you should
take up on a disorganized newsgroup. I might suggest take it up with
individual Lisp vendors sales/marketing departments. I'd be surprised if
Franz couldn't help you, too.
Of course, you didn't say you were willing to pay money for a solution,
but I'm assuming if it has commercial value to you that you are.
> Therefore, again: could you give me a reason why we should use LISP?...
I posted a response to this under separate cover so won't repeat myself.
On Sun, 11 Nov 2001 21:31:41 GMT, Kent M Pitman <······@world.std.com> wrote:
>Andrzej Lewandowski <·············@attglobal.net> writes:
>
>> We are currently using Prolog, but Prolog (despite its obvious
>> advantages) has obvious disadvantages. One is that it is pretty hard
>> (well... inconvenient) to write parts of the algorithm that have
>> purely procedural character. Since we are extending the product
>> lines, one obvious question is whether it would be reasonable and
>> justified to use something else instead of Prolog. LISP definitely
>> is the alternative, but... I have posted a qeustion about constraint
>> solver for LISP - it seems that nothing is available.
>
>Harlequin (now Xanalys) used to have an integrated Lisp/Prolog
>environment, I think. I don't know if it still does. And I think it
>has their KnowledgeWorks expert system shell, which is either the same
>thing or something similar -- I know it's something that integrates
>with Lisp at the meta-object level. I don't know the details, nor do
>I get a commission for mentioning it, but I'd recommend contacting them.
>
>I'm sure there are expert system shells and constraint solvers written in
>Lisp.
Expert systems, yes. What regards constraint solvers, there is one named Screamer, but it
is academic project abandoned in 1994 (and it seems, never finished). I am looking for
commercially supported stuff.
>How to go about looking for them seems more the problem. That's
>an important issue, for sure, but it arguably isn't one that you should
>take up on a disorganized newsgroup. I might suggest take it up with
>individual Lisp vendors sales/marketing departments.
Response mostly negative.
>Of course, you didn't say you were willing to pay money for a solution,
>but I'm assuming if it has commercial value to you that you are.
>
Exactly. I am looking for commercial solution, with support etc. But I am not going to pay
substantially more than for Prolog, C++ or Java solutions...
A.L.
Andrzej Lewandowski <·············@attglobal.net> writes:
> On Sun, 11 Nov 2001 21:31:41 GMT, Kent M Pitman <······@world.std.com> wrote:
> >How to go about looking for them seems more the problem. That's
> >an important issue, for sure, but it arguably isn't one that you should
> >take up on a disorganized newsgroup. I might suggest take it up with
> >individual Lisp vendors sales/marketing departments.
>
> Response mostly negative.
Did you tell them your situation, why you were considering Lisp, what
problem area you were going to be tackling, why you needed the
features you do, and did you sound receptive to help; or, did you post
a demand without any context, like you did on c.l.l?
If you spoke to the vendors like you initially did to this newsgroup,
I can understand the negative response. You didn't sound serious nor
receptive. Context is good, if you want help, give it.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
On 11 Nov 2001 14:27:56 -0800, ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>Andrzej Lewandowski <·············@attglobal.net> writes:
>
>> On Sun, 11 Nov 2001 21:31:41 GMT, Kent M Pitman <······@world.std.com> wrote:
>
>> >How to go about looking for them seems more the problem. That's
>> >an important issue, for sure, but it arguably isn't one that you should
>> >take up on a disorganized newsgroup. I might suggest take it up with
>> >individual Lisp vendors sales/marketing departments.
>>
>> Response mostly negative.
>
>Did you tell them your situation, why you were considering Lisp, what
>problem area you were going to be tackling, why you needed the
>features you do, and did you sound receptive to help; or, did you post
>a demand without any context, like you did on c.l.l?
>
>If you spoke to the vendors like you initially did to this newsgroup,
>I can understand the negative response. You didn't sound serious nor
>receptive. Context is good, if you want help, give it.
I don't understand what the "tone" has to do here. Vendors are in money making business,
and, whoever they are, they are looking for customers. I do know how to talk to vendors,
you don't need to teach me. I posted "I am looking for CLP solver" message AFTER talking
to vendors, searching google, alta vista and all possible ways, as well as e-mailing and
calling people that are in constraint solving business. I don't know what "context" (and
WHAT context) of my question has anythuing in common with constraint solving, LISP and my
question.
A.L.
Andrzej Lewandowski <·············@attglobal.net> writes:
> On 11 Nov 2001 14:27:56 -0800, ···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) wrote:
>
> >Andrzej Lewandowski <·············@attglobal.net> writes:
> >
> >> On Sun, 11 Nov 2001 21:31:41 GMT, Kent M Pitman <······@world.std.com> wrote:
> >
> >> >How to go about looking for them seems more the problem. That's
> >> >an important issue, for sure, but it arguably isn't one that you should
> >> >take up on a disorganized newsgroup. I might suggest take it up with
> >> >individual Lisp vendors sales/marketing departments.
> >>
> >> Response mostly negative.
> >
> >Did you tell them your situation, why you were considering Lisp, what
> >problem area you were going to be tackling, why you needed the
> >features you do, and did you sound receptive to help; or, did you post
> >a demand without any context, like you did on c.l.l?
> >
> >If you spoke to the vendors like you initially did to this newsgroup,
> >I can understand the negative response. You didn't sound serious nor
> >receptive. Context is good, if you want help, give it.
>
> I don't understand what the "tone" has to do here. Vendors are in
> money making business, and, whoever they are, they are looking for
> customers. I do know how to talk to vendors, you don't need to teach
> me. I posted "I am looking for CLP solver" message AFTER talking to
> vendors, searching google, alta vista and all possible ways, as well
> as e-mailing and calling people that are in constraint solving
> business. I don't know what "context" (and WHAT context) of my
> question has anythuing in common with constraint solving, LISP and
> my question.
Who said anything about "tone" (besides you)? I don't know how the
commercial vendors budget their customer service time, but if you
didn't give them enough information to know what you were trying to
do, and if you didn't sound serious, I wouldn't be surprised if they
didn't take you as seriously as they would have if you sounded like a
serious request. You sure didn't sound serious at first, here.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Andrzej Lewandowski <·············@attglobal.net> writes:
| Expert systems, yes. What regards constraint solvers, there is
| one named Screamer, but it is academic project abandoned in 1994
Perhaps you should tell that to the authors, too; they might not be
aware that they have abandoned the project. The latest version
(which I got from the other author (Siskind) about two months ago)
I have mentions 1997 and I don't recall him mentioning that it is
abandoned.
| (and it seems, never finished). I am looking for commercially
| supported stuff.
I take it that asking whether the authors might be willing to sell
you commercial support is out of the question? On second thought,
if you ask them, I'd advice you not to tell your silly assumptions
about their "abandoned project" to them as truths.
*plonk*
--
Hannu
On 12 Nov 2001 02:32:06 +0200, Hannu Koivisto <·····@iki.fi> wrote:
>Andrzej Lewandowski <·············@attglobal.net> writes:
>
>| Expert systems, yes. What regards constraint solvers, there is
>| one named Screamer, but it is academic project abandoned in 1994
>
>Perhaps you should tell that to the authors, too; they might not be
>aware that they have abandoned the project. The latest version
>(which I got from the other author (Siskind) about two months ago)
>I have mentions 1997 and I don't recall him mentioning that it is
>abandoned.
>
>| (and it seems, never finished). I am looking for commercially
>| supported stuff.
>
>I take it that asking whether the authors might be willing to sell
>you commercial support is out of the question? On second thought,
>if you ask them, I'd advice you not to tell your silly assumptions
>about their "abandoned project" to them as truths.
>
>*plonk*
All links about Screamer lead to the following page
ftp://ftp.cis.upenn.edu/pub/screamer-tools/public_html/index.html
that was updated last time June 7, 1994. This is the official Screamer distribution, with
manual that is partially completed with some sections consisting only of section headers.
This is version 3.20. After close inspection of the code you will find long list of bugs
and "things to do". This fits my definition of "abandoned" project.
If you know about any other distribution/publications that are after the above date,
please let me know.
A.L.
On 12 Nov 2001 02:32:06 +0200, Hannu Koivisto <·····@iki.fi> wrote:
>Andrzej Lewandowski <·············@attglobal.net> writes:
>
>| Expert systems, yes. What regards constraint solvers, there is
>| one named Screamer, but it is academic project abandoned in 1994
>
>Perhaps you should tell that to the authors, too; they might not be
>aware that they have abandoned the project. The latest version
>(which I got from the other author (Siskind) about two months ago)
>I have mentions 1997 and I don't recall him mentioning that it is
>abandoned.
>
Ach... By the way, if you go to mark Siskind's web page
http://www.neci.nec.com/homepages/qobi/
go to Software section, then you will find link (on the very bottom) to the "Screamer
resource page" dated June 7, 1994. It is also possible to click on link "Screamer",
download the stuff, unzip, and read the following lines:
;;; Screamer
;;; A portable efficient implementation of nondeterministic CommonLisp
;;; Version 3.20
A.L.
On 12 Nov 2001 02:32:06 +0200, Hannu Koivisto <·····@iki.fi> wrote:
>Andrzej Lewandowski <·············@attglobal.net> writes:
>
>| Expert systems, yes. What regards constraint solvers, there is
>| one named Screamer, but it is academic project abandoned in 1994
>
>Perhaps you should tell that to the authors, too; they might not be
>aware that they have abandoned the project. The latest version
>(which I got from the other author (Siskind) about two months ago)
>I have mentions 1997 and I don't recall him mentioning that it is
>abandoned.
>
>| (and it seems, never finished). I am looking for commercially
>| supported stuff.
>
>I take it that asking whether the authors might be willing to sell
>you commercial support is out of the question? On second thought,
>if you ask them, I'd advice you not to tell your silly assumptions
>about their "abandoned project" to them as truths.
>
>*plonk*
To finish this "discussion" - I talked to Mark Siskind. He confirmed
that he is not actively working on Screamer anymore and haven't been
working on Screamer for a number of years. Last release is 3.24 dated
1997.
A.L.
From: Friedrich Dominicus
Subject: Re: Lisp Jobs (was Re: Slashdot)
Date:
Message-ID: <87y9lcbgoc.fsf@frown.here>
Kent M Pitman <······@world.std.com> writes:
> Andrzej Lewandowski <·············@attglobal.net> writes:
>
> > We are currently using Prolog, but Prolog (despite its obvious
> > advantages) has obvious disadvantages. One is that it is pretty hard
> > (well... inconvenient) to write parts of the algorithm that have
> > purely procedural character. Since we are extending the product
> > lines, one obvious question is whether it would be reasonable and
> > justified to use something else instead of Prolog. LISP definitely
> > is the alternative, but... I have posted a qeustion about constraint
> > solver for LISP - it seems that nothing is available.
>
> Harlequin (now Xanalys) used to have an integrated Lisp/Prolog
> environment, I think. I don't know if it still does.
Just for the record. It is still there.
>
> I'm sure there are expert system shells and constraint solvers written in
> Lisp.
How about D3? http://d3.informatik.uni-wuerzburg.de/d3-e.shtml
Regards
Friedrich
On 12 Nov 2001 08:18:43 +0100, Friedrich Dominicus
<·····@q-software-solutions.com> wrote:
>
>> Harlequin (now Xanalys) used to have an integrated Lisp/Prolog
>> environment, I think. I don't know if it still does.
>Just for the record. It is still there.
>
>>
>> I'm sure there are expert system shells and constraint solvers written in
>> Lisp.
>
>How about D3? http://d3.informatik.uni-wuerzburg.de/d3-e.shtml
>
Thanks, quite interesting, but it is not exactly what I am looking
for...
A.L.
Andrzej Lewandowski <·············@attglobal.net> writes:
> On Sun, 11 Nov 2001 13:34:58 +0100, "Marc Battyani" <·············@fractalconcept.com>
> wrote:
>
> >" I also think that trust *is* the major factor. This applies to
> >in-house and even more to contract programming. The trouble for
> >new programmers is that they don't have the years of practice that
> >build that trust. They have to build it by solving problems in an
> >efficient and clean way. (rather easy compared to the
> >Java/C*/script languages/etc. crowds)
>
> Technical decision in the industry are not based on "trust" or
> personal opinions of this-or-that developer. Developers don't
> decide about programming languages unless this is single person,
> basement-type operation.
I agree with you partly. But sometimes one does trust a manager who will
be willing to make more aggressive "can do" claims than his peers. There
are some domains in which I would definitely feel more confident doing this
in Lisp, even not having seen the specific programming assignment. There
are other domains in which I would probably not. If you're just writing
little UI widgets to attach to someone else's system, I'd probably still do
it in VB or Javascript or something just to not rock the boat... BUT EVEN
THERE, I might write a Lisp program to generate that junk because it's ugly
and hard to maintain, and Lisp gives me the power to simplify things where
the underlying language, by not providing adequate macro capability or
whatever, might not.
> These mechanisms cause that it is very hard
> to convince management to use something that is not Java, C++ or VB.
I don't think one argues for Lisp. I wouldn't. I'd be as likely to
argue for modularity integrity and absolute control of what
implementational technologies I use. And I'd argue for some
modularity interface I was confident I could get Lisp to deliver for.
The problem is the same in other business management problems. What if
I see a team of ten people and, Lisp or not, I think I could do the job
with two such people, better paid, plus one huge computer, and maybe also
free coca-cola. I don't make that case to management. Instead, I might
try to put my neck on the line if it's not delivered, tell them to just
give me signing authority for the budget I need, and tell them to leave
me alone until then. I think this does involve trust.
My formative management experience was in being in JROTC in high
school (a high school version of college ROTC), where I was (after 2
years of working up the ranks), a cadet Major (and later cadet
Lieutenant Colonel) on the "batallion staff" (our batallion had about
200-250 people in it, I think), working as executive officer ... The
position was roughly analogous to that of a Chief Operating Officer in
business terms. Our "work" was what seemed to me (both then and now)
a pretty realistic year-long simulation, both in class and after
class, of being a manager. I managed other staffers and also company
commanders doing all kinds of projects. What we were taught there,
both formally in class and informally in the active practice of our
roles, and what I believe to this day, is this: "trust your
subordinates or replace them, but DON'T second-guess them". You don't
micromanage. Yes, you can question them, and give them edicts, but
ultimately they're the ones who have to do the mission and if you tie
their hands and don't let them do it the way they feel empowered to do
it, it's your fault, not theirs, when it fails. I think this attitude
they taught us built trust and responsibility in both directions (and
I'm hardly surprised the military has it down to a science given the
number of people they have to manage world-wide). I never went on to
be in the military, nor even to study it further, but I was happy for
this little moment of training. The sense of pride and teamwork that
it routinely evoked in people is not something I've really seen much of
in many companies I've worked at in my career, and I attribute a lot of
it to that failure of managers to build and reward trust and autonomy.
Most software modularity works this way, too; you check output, but
you don't interrupt a program to see if it's got good intermediate
values. A lot of business does not seem to blackbox itself enough, I
think. That's not a comment about Lisp particularly, but it seems to
impact Lisp more than some other things because it takes certain
critical decisions away from people who use and understand a
particular technology (such as Lisp), and puts those decisions into
the hands of someone who is often uninformed, prejudiced, and not
willing to trust. Of course, I'm generalizing, and there are always
exceptions. But this pattern I describe does happen with enough frequency
to be worthy of note.
> Finally, maybe somebody would give me at least one good reason
> (other than "because I like it") why LISP should be used instead of
> one of the above mentioned languages.
In a non-trivial number of cases, the answer is "because everyone who
happened to prefer other languages has already said it's impossible
and the only people left standing that think it's doable are Lispers".
Sometimes for doable you can replace "doable by tomorrow" or "doable and
maintainable in realtime" or "deployable while still building parts of it".
You can also add little things like "must be up continuously even when
receiving patches" (Java is almost set up to do this but not quite; I
think some guys at MIT did some mods to make it more possible, but it's
still not really a strength). Or problems that need to automatically
synthesize code, compile that code, and then call the compiled code without
exiting.
And you can add programs that require small changes in the available
kinds of data (i.e., to the type tree) to cause small changes in the
compiled file set. That is, most languages when you change the type
tree require you to recompile all your files because the compiler
secretly makes assumptions about types that make compiled code fragile
against change and force excess compilation.
But the fact is that for any problem that someone thinks is doable in another
language, I usually just say "sure why not?" because I don't see talking
anyone out of programming in their language of choice when it's going to
work for them. The only thing I say is to be watchful of "practice effects",
which tend to cause people to want to use something familiar even when they
sense it's going to let them down or make things hard. The key thing is
to know what Lisp offers you and when you might want to switch over. You
simply cannot make the decision to learn Lisp on the day you finally need
it because (a) you won't be able to tool up that fast to be a competent
programmer in ANY language and (b) you probably won't recognize, without
some familiarity, what a good problem is for Lisp without at least some
actual play in the language.
* Andrzej Lewandowski <·············@attglobal.net>
| Technical decision in the industry are not based on "trust" or personal
| opinions of this-or-that developer. Developers don't decide about
| programming languages unless this is single person, basement-type
| operation.
I can only pity you for your lack of experience, but these things happen
quite frequently. It probably does not apply in the Java, C++, VB, etc,
world, where trust in the developer is a non-issue, where the personal
value of the individual programmer seems to be irrelevant at best, and
where the ability to replace such a programmer is valued much higher than
making sure that programmer contributes to the company's bottom line.
However, this extremely sorry situation is _not_ representative of the
whole world, despite the fact that those who live under such conditions
would leave the second they learned freedom was available to them, too,
and thus nobody in that world will believe it is possible to be trusted,
to have their opinions heard, to be both designer and programmer, etc.
Of course, I am only slightly exaggerating, but those who think their
personal experiences up to some point make it unnecessary to ever open
their eyes again and thus declare everything contrary to their personal
experience invalid at best or a lie at worst, have already given up the
most important value of being conscious: The world you experience is not
what you expect it to be, if you look closely enough, and that looking at
it with open eyes all the time is the only working way to deal with it.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
On Sun, 11 Nov 2001 20:40:29 GMT, Erik Naggum <····@naggum.net> wrote:
>* Andrzej Lewandowski <·············@attglobal.net>
>| Technical decision in the industry are not based on "trust" or personal
>| opinions of this-or-that developer. Developers don't decide about
>| programming languages unless this is single person, basement-type
>| operation.
>
> I can only pity you for your lack of experience, but these things happen
> quite frequently.
What do you know about my experience?...
A.L.
* Andrzej Lewandowski <·············@attglobal.net>
| What do you know about my experience?...
What you told me, of course, which was more than sufficient to comment on
your statement, but if you _really_ want to quibble and defend yourself,
instead of supporting your claims, which at least could be interesting,
please do it elsewhere, OK?
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
On Mon, 12 Nov 2001 03:07:46 GMT, Erik Naggum <····@naggum.net> wrote:
>* Andrzej Lewandowski <·············@attglobal.net>
>| What do you know about my experience?...
>
> What you told me, of course, which was more than sufficient to comment on
> your statement, but if you _really_ want to quibble and defend yourself,
> instead of supporting your claims, which at least could be interesting,
> please do it elsewhere, OK?
>
It instead technical argument you prefer personal ones, then please,
do this elsewhere.
A.L.
* Andrzej Lewandowski <·············@attglobal.net>
| It instead technical argument you prefer personal ones, then please,
| do this elsewhere.
You took something personally that was not. That also tells me something
about you that you probably should have kept strictly to yourself if you
want to avoid personal exchanges. Figure out cause and effect until next
time you feel the need to defend yourself. Just because you _feel_ the
need to defend yourself personally does not mean that anyone has actually
attacked you in any way. That you feel the need to defend yourself means
that _you_ are taking the initiative to go personal. If you do not like
personal exhanges, DO NOT ENGAGE IN THEM. Yes, it is that simple. Now,
do as you want -- you are not being controlled by anyone, you are free to
do exactly what you think is right all the time, you cannot blame anyone
for your choice of action. Do you understand this? Your best answer is
probably a lack of response.
///
--
Norway is now run by a priest from the fundamentalist Christian People's
Party, the fifth largest party representing one eighth of the electorate.
--
Carrying a Swiss Army pocket knife in Oslo, Norway, is a criminal offense.
"Andrzej Lewandowski" <·············@attglobal.net> wrote in message
·······································@4ax.com...
> On Sun, 11 Nov 2001 13:34:58 +0100, "Marc Battyani"
<·············@fractalconcept.com>
> wrote:
>
> >
> >"
> >I also think that trust *is* the major factor. This applies to in-house
and
> >even more to contract programming.
> >The trouble for new programmers is that they don't have the years of
> >practice that build that trust. They have to build it by solving problems
in
> >an efficient and clean way. (rather easy compared to the Java/C*/script
> >languages/etc. crowds)
> >
>
> Technical decision in the industry are not based on "trust" or personal
opinions of
> this-or-that developer.
You are either naive or lucky...
> Developers don't decide about programming languages
Yes Sir!
If you are talking about corporate drones, then yes we agree, but these guys
don't decide on anything.
>unless this
> is single person, basement-type operation. These mechanisms cause that it
is very hard to
> convince management to use something that is not Java, C++ or VB.
>
> Finally, maybe somebody would give me at least one good reason (other than
"because I like
> it") why LISP should be used instead of one of the above mentioned
languages.
There are lots of reasons why Lisp is currently the best way to write
software, but as you told us in other posts, you are not looking for this,
you just need a constraint solver.
Marc
On Sun, 11 Nov 2001 23:47:50 +0100, "Marc Battyani" <·············@fractalconcept.com>
wrote:
>
>>
>> Finally, maybe somebody would give me at least one good reason (other than
>"because I like
>> it") why LISP should be used instead of one of the above mentioned
>languages.
>
>There are lots of reasons why Lisp is currently the best way to write
>software, but as you told us in other posts, you are not looking for this,
>you just need a constraint solver.
>
I know that LISP is the best way of writing software, but for me, if it lacks constraint
solver it is useless. It lacks some other things that I consider critical. And that C++,
Java, VB, Prolog and others provide without troubles and with pleasure.
A.L.
Andrzej Lewandowski <·············@attglobal.net> writes:
> I know that LISP is the best way of writing software, but for me, if it lacks constraint
> solver it is useless. It lacks some other things that I consider critical. And that C++,
> Java, VB, Prolog and others provide without troubles and with pleasure.
I'm not understanding this logic.
There are constraint solvers of the particular type you need written
for these other languages, but you have not found one, possibly
because it does not exist, in CL, so you are saying that CL is
useless.
Perhaps you should be sure to constraint your definition of useless to
the immediate problem domain at hand. Even then, I would hesitate to
call CL useless, since implementing said constraint solver is surely
possible in CL, tho it may cost you more in development time.
It is not a matter of being useless, rather, it is a matter of having
a near-term investment requirement. It could be that you don't have
the time or financial resources to meet this near-term investment
requirement, or that you think that that investment would not be
offset by the advantages CL (some of which I listed already) would
give you.
A "rational technical evaluation", which you are positing is the
appropriate basis of such technical decisions, would attempt to
quantify the time/money costs of the near-term investment in
implementing the CS of the required type in CL, against projected
improvmenets in project development speed, supportability, feature
enhancement and flexability gained by using CL.
Either way, the term "useless" is not IMO applicable here.
It seems to me that you are frustrated by the lack of this CS in CL,
as you want to use CL, and feel stymied because you haven't found a
way to get beyond the immediate lack of said CS. Perhaps attempting
to quanitfy the costs of implementing that CS, and the advantages of
using CL will help you get around that blockage and formulate an
argument for the others in your group to us CL.
There are research papers which compare CL to C++ and Java which you
could reference in order to formulate the "advantage" of moving to CL.
As far as the cost of implementing the CS in CL, I'm afraid I'm
insufficiently trained in that arena to offer much assistance.
Perhaps others here, and the software packages they reccomend, can
help you quanitfy that cost and minimize it thru the re-use of
existing code.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
All around the world hearts pound with the rythym. Fear not of
men because men must die. - Mos Def
On Mon, 12 Nov 2001 17:17:34 GMT, Craig Brozefsky <·····@red-bean.com>
wrote:
> Andrzej Lewandowski <·············@attglobal.net> writes:
>
> > I know that LISP is the best way of writing software, but for me, if it lacks constraint
> > solver it is useless. It lacks some other things that I consider critical. And that C++,
[...]
> the immediate problem domain at hand. Even then, I would hesitate to
> call CL useless, since implementing said constraint solver is surely
> possible in CL, tho it may cost you more in development time.
Is Garnet's KR the kind of constraint solver that is being discussed here?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Andrzej Lewandowski <·············@attglobal.net> writes:
> [About Constraint Solving, Common LISP, Prolog, etc.]
If you have problems that require multiple paradigms, and would like a
tool that allows to unify them, you may want to have a peek at poplog
(see comp.lang.pop or freepoplog.org). Based on a same virtual machine,
they unify at least POP-11, Prolog, Common LISP and ML. If there is a
some reasonably portable CLP(fd) package in prolog, it might well work
in the Prolog part of poplog while interacting tightly with other things
written in Common LISP.
As for Screamer, just because it hasn't been worked on recently doesn't
mean it's unusable - after all, the source is there to be hacked on, if
it misses some feature you need or has any defect that bugs you.
Also, ILOG was doing lots of constraints solving and LISP
but they recently dropped their LISP business :-(
As for Mozart-Oz, a company I left worked at was using it for resource
allocation problems (they did not use it in unattended fully automated
transactions, though; I don't know if it's robust enough for you).
Just my two cents worth.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
Don't worry about what anybody else is going to do. The best way to predict
the future is to invent it. Really smart people with reasonable funding can
do just about anything that doesn't violate too many of Newton's Laws!
-- Alan Kay, 1971
On 13 Nov 2001 01:43:15 +0100, Francois-Rene Rideau
<···········@tunes.org> wrote:
>Andrzej Lewandowski <·············@attglobal.net> writes:
>> [About Constraint Solving, Common LISP, Prolog, etc.]
>If you have problems that require multiple paradigms, and would like a
>tool that allows to unify them, you may want to have a peek at poplog
>(see comp.lang.pop or freepoplog.org). Based on a same virtual machine,
>they unify at least POP-11, Prolog, Common LISP and ML. If there is a
>some reasonably portable CLP(fd) package in prolog, it might well work
>in the Prolog part of poplog while interacting tightly with other things
>written in Common LISP.
>
Thanks, you are right, Poplog is interesting option. However, I
don't know about CLP(fd) specifically for Poplog. Unfortunately, all
other CLP(fd) packages for Prolog are a) proprietary, b) are based
on proprietary extensions to WAM c) because of a and b they are not
portable. Other option would be LispWorks Prolog, but again - I
don't think that there exists Prolog cosntraint solver that would
work in this environment.
>As for Screamer, just because it hasn't been worked on recently doesn't
>mean it's unusable - after all, the source is there to be hacked on, if
>it misses some feature you need or has any defect that bugs you.
>
Agree, but we are not in "hacking business"... Generally, we prefer
to pay for solvers than develop such things in house. Developing
lasts too long and costs too much compared to simply purchasing
commercial products. Anyway, I am in the process of "hacking", just
to see what happens...
>Also, ILOG was doing lots of constraints solving and LISP
>but they recently dropped their LISP business :-(
>
Yes, I know ILOG current products and the history... Actually, their
LISP stuff has never been visible (at least, in the USA) as
commercial products.
>As for Mozart-Oz, a company I left worked at was using it for resource
>allocation problems (they did not use it in unattended fully automated
>transactions, though; I don't know if it's robust enough for you).
>
Mozart-OZ is still the option and is being investigated. However, as
I have mentioned, we are not convinced about robustenss and
scalability. Other thing that I personally don't like in Mozart-Oz
is that it is necessary to use C++ to extend constraint solver (to
write "propagators"). Since we have a lot of custom global
constraints, C++ would be heavily used, and this is exactly what I
would like to avoid. Anyway, other features (concurrency and
distribution) make Mozart-OZ interesting alternative, despite these
shortcommings. We will see..
>Just my two cents worth.
>
Thanks.
A.L.
From: Aaron Sloman See text for reply address
Subject: Re: Constraint Solving and Common LISP (Screamer)
Date:
Message-ID: <9ssf8o$egm$1@soapbox.cs.bham.ac.uk>
[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]
Francois-Rene Rideau <···········@tunes.org> writes:
> Date: 13 Nov 2001 01:43:15 +0100
>
> Andrzej Lewandowski <·············@attglobal.net> writes:
> > [About Constraint Solving, Common LISP, Prolog, etc.]
> If you have problems that require multiple paradigms, and would like a
> tool that allows to unify them, you may want to have a peek at poplog
> (see comp.lang.pop or freepoplog.org). Based on a same virtual machine,
That should be
http://www.cs.bham.ac.uk/research/poplog/freepoplog.html
or
http://www.poplog.org
> they unify at least POP-11, Prolog, Common LISP and ML. If there is a
> some reasonably portable CLP(fd) package in prolog, it might well work
> in the Prolog part of poplog while interacting tightly with other things
> written in Common LISP.
>
> As for Screamer, just because it hasn't been worked on recently doesn't
> mean it's unusable - after all, the source is there to be hacked on, if
> it misses some feature you need or has any defect that bugs you.
If anyone is interested, there's a version of screamer that works in
Poplog Common Lisp (ported originally by the author of Screamer, Jeff
Siskind) here
http://www.cs.bham.ac.uk/research/poplog/screamer.tar.gz
I don't know how performance of screamer in Poplog will compare with
other implmentations: probably run-time speed will be lower than the
best (e.g. allegro) though compilation may be faster (it uses an
incremental compiler, and does not have an interpreter). It also has
a very fast garbage collector (two actually).
If anyone wants to try Poplog out on linux+PC, I suggest fetching the
package I have just put together for our students here:
http://www.cs.bham.ac.uk/research/poplog/linux-cd/
(21 Mbyte gzipped tar file including various optional extras from
Sussex and Birmingham.)
Poplog was previously an expensive commercial product ( used in
Clementine -- see www.isl.co.uk, and in various other commercial
products, e.g. an Ada validator sold by Praxis, ---
http://www.sparkada.com/spark.html
http://www.praxis-cs.co.uk/
and may be unwittingly being used by a company you know!)
It has been available free of charge (courtesy of SPSS and Sussex
University) with full sources for use on a variety of platforms for
about two years, since SPSS bought ISL.
Aaron
====
Aaron Sloman, ( http://www.cs.bham.ac.uk/~axs/ )
School of Computer Science, The University of Birmingham, B15 2TT, UK
EMAIL A.Sloman AT cs.bham.ac.uk (········@please !)
PAPERS: http://www.cs.bham.ac.uk/research/cogaff/ (And free book on Philosophy of AI)
FREE TOOLS: http://www.cs.bham.ac.uk/research/poplog/freepoplog.html
On Wed, 14 Nov 2001 00:52:40 +0000 (UTC),
···············@cs.bham.ac.uk (Aaron Sloman See text for reply
address) wrote:
>[To reply replace "Aaron.Sloman.XX" with "A.Sloman"]
>
>Francois-Rene Rideau <···········@tunes.org> writes:
>
>> Date: 13 Nov 2001 01:43:15 +0100
>>
>> Andrzej Lewandowski <·············@attglobal.net> writes:
>> > [About Constraint Solving, Common LISP, Prolog, etc.]
>> If you have problems that require multiple paradigms, and would like a
>> tool that allows to unify them, you may want to have a peek at poplog
>> (see comp.lang.pop or freepoplog.org). Based on a same virtual machine,
>
[..................]
>
>Poplog was previously an expensive commercial product ( used in
>Clementine -- see www.isl.co.uk, and in various other commercial
>products, e.g. an Ada validator sold by Praxis, ---
> http://www.sparkada.com/spark.html
> http://www.praxis-cs.co.uk/
>and may be unwittingly being used by a company you know!)
>
>It has been available free of charge (courtesy of SPSS and Sussex
>University) with full sources for use on a variety of platforms for
>about two years, since SPSS bought ISL.
>
>Aaron
GREAT! Thanks for good news!
A.L.
The writers of Poplog should be praised. Their system is quite
amazing.
I only wish I had a little bit more time to make the CL system more
ANSI (from what I saw and given the quality of the help you can get
from the Poplog folks, it should just be a matter of time).
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
In article <··································@4ax.com>, Andrzej
Lewandowski <·············@attglobal.net> wrote:
> Technical decision in the industry are not based on "trust" or
> personal opinions of this-or-that developer. Developers don't
> decide about programming languages unless this is single person,
> basement-type operation. These mechanisms cause that it is very
> hard to convince management to use something that is not Java,
> C++ or VB.
I guess you're new.
When I started using C++ for production work in 1989 it was exactly as
hard to convince management to use C++ then (instead of C or Pascal or
FORTRAN) as it is to convince them to use CL or Dylan now.
C++ was established mostly from the grassroots level. Source-level
compatibilty with C helped it, but I don't think it was essential.
Java and VB seem to have some in more from the other end -- large
companies persuaded managament that they should use them, and they were
then imposed on developers.
> Finally, maybe somebody would give me at least one good reason
> (other than "because I like it") why LISP should be used instead
> of one of the above mentioned languages.
Exactly the same reason that Java should often be used instead of C, but
squared.
Personally, I prefer Dylan, but I'd be perfectly happy to see CL start
to win, too.
-- Bruce
Andrzej Lewandowski <·············@attglobal.net> wrote:
> Finally, maybe somebody would give me at least one good reason (other
> than "because I like it") why LISP should be used instead of one of
> the above mentioned languages.
Emacs is a very good reason. I work in the telecom field,
populated by network elements that spits files of different formats
that are customized to suit the services provided by the operators. To
view what's inside these files, rather than write a nice tool
with Java/C/C++ to display the stuff, I use Emacs to parse and display
the contents.
What's great is that people can customize the output
according to their needs without touching the core program and,
better, I didn't even have to think about how to let people customize
the stuff because they can overwrite functions and variables at will.
Now, all people in my department use Emacs to view these files and
don't have too much trouble customizing it to suit their needs,
without knowing Lisp ! Even better, our customers use it as well...
I mean, when they see things like:
(defvar *data-output-list*
'((50001 "Call type" list->integer)
(50002 "Call number" list->digits)
(50003 "Call date" list->date)
(50004 "Call result" list->call-result)
...
))
(defun list->call-result (list)
(let ((call-type (list->integer list)))
(case call-type
(0 "answered / CLG released")
(1 "answered / CLD released")
(2 "busy")
(3 "no reply")
(4 "no routing")
(t (format "~A ? unknown value" call-type))
)))
they don't have too much trouble figuring how to customize it...
With C or whatever, I'd have to set up a whole framework (with
issues such as: "parse the configuration file with ultra strict syntax
otherwise coredump", "I need some new functionalities, could you
please add it in your program?", "oh, I didn't know there should be no
space after the = sign !", etc...) to have something like this and it
would not as flexible as with Lisp (if yes, then congratulations, you
have implemented a new Lisp).
Also, as it's Emacs, when people want to display one file, they
use dired-mode, where a key is bound to do the parse/display thing and
when displayed, they can do copy/paste, search, ..., whatever, without
extra work for me. And yes, no horrible things such as:
$ parse-cdr cdr-file1 > cdr-output1
$ vi cdr-output1
(quit vi)
$ parse-cdr cdr-file2 > cdr-output2
$ vi cdr-output2
For batch processing, I use the same approach with Common Lisp and
the configuration file is populated by CLOS individual methods such as:
(defmethod output ((tag (eql 50004)) list)
...
)
If I wanted, I could use Common Lisp for both (viewer and batch),
where Emacs would use the CL program in the background. Then, there
would be 2 generic functions: output-batch and output-view, or maybe
one (output) with an extra parameter that would be either 'batch or
'view.
--
Georges Ko (Taipei, Taiwan) 2001-11-12 ···@gko.net / ICQ: 8719684
Lundi 12 novembre 2001
Andrzej Lewandowski <·············@attglobal.net> writes:
> Technical decision in the industry are not based on "trust" or
> personal opinions of this-or-that developer. Developers don't
> decide about programming languages unless this is single person,
> basement-type operation. These mechanisms cause that it is very hard
> to convince management to use something that is not Java, C++ or VB.
I think you overestimate the position of "rational technical
evaluation" in the software industry. I understand that asserting
that such rational evaluations are the basis for these decisions is
considered proper professionalism, but let us take a step back and
seperate the rhetoric of professionalism (whate veryone tells one
another is going on) and what is actually going on.
> Finally, maybe somebody would give me at least one good reason
> (other than "because I like it") why LISP should be used instead of
> one of the above mentioned languages.
It's been listed in this newsgroup, and in this thread a dozen times
prolly:
1. Faster development time due to various advances like interactive
development and debugging, macros, more expressive data
representation and algorithm building tools, and a well developed
language core.
2. Well-developed debugging environment with the ability to fix bugs
and restart the program.
3. Implementations with across the whole supprt/license cost spectrum,
ranging from public domain, to runtime licenses with support
contracts.
--
Craig Brozefsky <·····@red-bean.com>
http://www.red-bean.com/~craig
All around the world hearts pound with the rythym. Fear not of
men because men must die. - Mos Def
Andrzej Lewandowski <·············@attglobal.net> writes:
>
> Technical decision in the industry are not based on "trust" or personal opinions of
> this-or-that developer. Developers don't decide about programming languages unless this
> is single person, basement-type operation.
That statement is, quite simply, false. Demonstrably so, by counter example.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
>>>>> On 12 Nov 2001 18:27:37 +1100, Alain Picard ("Alain") writes:
Alain> Andrzej Lewandowski <·············@attglobal.net> writes:
>> Technical decision in the industry are not based on "trust" or personal opinions of
>> this-or-that developer. Developers don't decide about programming languages unless this
>> is single person, basement-type operation.
Alain> That statement is, quite simply, false. Demonstrably so, by counter example.
At most companies I've been at (whether 10 person or 10,000 person),
for substantial projects, the decision about programming languages
(and other technologies, such as which quarter-million-dollar database to use,
which platforms to deliver on, etc.) is usually made by a high-level manager,
perhaps the vice president of technology. This person is usually not the
developer who will write the software. The three equal major factors are:
(1) is this a reliable technology we can bet the future of the company on,
(2) are there multiple vendors of this technology, from companies that are
at least as stable as we are, and (3) will we be able to hire programmers
to develop and maintain this system. Different people in different situations
with different backgrounds and information will have different evaluations,
How is that different from your experience?
Christopher Stacy <······@spacy.Boston.MA.US> writes:
> >>>>> On 12 Nov 2001 18:27:37 +1100, Alain Picard ("Alain") writes:
> Alain> Andrzej Lewandowski <·············@attglobal.net> writes:
> >> Technical decision in the industry are not based on "trust" or personal opinions of
> >> this-or-that developer. Developers don't decide about programming languages unless this
> >> is single person, basement-type operation.
>
> Alain> That statement is, quite simply, false. Demonstrably so, by counter example.
>
> At most companies I've been at (whether 10 person or 10,000 person),
> for substantial projects, the decision about programming languages
> (and other technologies, such as which quarter-million-dollar database to use,
> which platforms to deliver on, etc.) is usually made by a high-level manager,
> [SNIP]
> How is that different from your experience?
Not very different. But that high-level manager usually has some trusted
technical people from whom he solicits input, and to which (if he's smart)
he gives great weight.
--
It would be difficult to construe Larry Wall, in article
this as a feature. <·····················@netlabs.com>
"Gabe Garza" <·······@ix.netcom.com> wrote in message
·················@kynopolis.org...
> Hamilton Link <······@sandia.gov> writes:
>
>
> > learning and teaching good lisp because of the myth (yes, it's a myth)
> > that "There's no industry demand."
>
> How is this a myth?
>
> Yes, there are people out there using Lisp professionally. But
> relative to the number of people using Java (ick), C++ (shudder), or
> even Visual Basic (spastic convulsions), I'd be willing to bet that
> the demand for professional Common Lispers is utterly
> insignificant. I'd be very interested in language use statistics, if
> any such things exist (or are even possible to accurately gather).
>
> A search on monster.com for "Common Lisp" yields a single job at "SRI
> International" which requires a PhD with a specialization in AI. A
> search for "C++ OR Java" returns 4,997 jobs. "Visual Basic AND NOT
> Java AND NOT C++" returns 1467. "Cobol" returns 1040. "RGP" returns
> 352. Even "Algol," arguably more obscure then Common Lisp, returns 5.
>
I get 121 from flipdog.com Yes, it is less but they are out there. I have
searched for and found lisp jobs three times in as many years. It is harder,
but can be done! Any way, "no industry demand" is just false, less, yes.. but
less is more, right?
Coby
(can't resist a quote from "Frasier" : "if less is more, just think how much
more more will be!")
--
(remove #\space "coby . beck @ opentechgroup . com")
Actually, there have been object-oriented (the media buzzword's
definition of ``OO'', that is) Lisps since quite a while longer than
10 years.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> writes:
> Actually, there have been object-oriented (the media buzzword's
> definition of ``OO'', that is) Lisps since quite a while longer than
> 10 years.
The recent use of OO is distorted from the original meaning. People
now seem to mean "programmable" and "having encapsulation" by OO. But
originally it meant simply "treating data as first class objects with
significant identity". And we've had that for 40+ years, even before we
had standard-class. It's the presence of EQL and its ability to apply
to all data, even built-in data like numbers, that makes Lisp OO in my
mind.
I agree. However, I was pointing out that Lisp has also had
more-or-less buzzword-compliant OO capabilities since, IIRC, the early
1980s.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Gabe Garza <·······@ix.netcom.com> writes:
> "Wade Humeniuk" <········@cadvision.com> writes:
>
> I'm going to give a lot my opinions. They're largely based on
> introducing Lisp to a couple of professional programmers in a company
> I interned for last summer (I fear I'm gonna be looking back on it as
> my only period has a professional Common Lisp programmer... :(). I'm
> obviously writing with far less experience and background then most of
> the regulars on this newsgroup, so please bear with me....
A fascinating analysis and very helpful. Thanks. I'm taking notes for
books I'm working on. The more of this kind of thoughtful analysis,
especially based on multiple real data points, the better.
Gabe Garza <·······@ix.netcom.com> writes:
May I add some points and remarks? I was on a fair last week and got
some extra comments.
>
> 5.) Having never heard of the language.
5.a) having heard before from Lisp and are asking What Lisp is still
alive? And people are using it?
5.b) having worked with Lisp before and think of it as
- either too slow, too complex too....
- beeing lightyears beyond what was available to there time
>
> 6.) Being compiled and interpreted.
Usually question isn't Lisp an Intepreter ...
>
> 7.) The lack of books. Yes, there are some really great books on
> Common Lisp. PAIP is superb. I've heard good things about
> Graham's Lisp book. However, in general the people that tried
> them had a hard time with them. Is there a book *in print* about
> Common Lisp that doesn't emphasize recursion at all, doesn't
> emphasizes the List data structure to the exclusion of hash
> tables, vectors with fill pointers, etc., and doesn't mention
> anything AI'ish? They'd go (yes, they actually went and
> looked) looking for Lisp books in a book store and not find any
> amid bookcases full of 33 thousand mostly horrid C++ and Java
> books. It does give one a certain impression of the language.
try Object Oriented programming Common Lisp and/or Ansi Common Lisp
>
> 8.) The lack of courses. One of the first questions my boss asked
> was where it was taught. The typical places a professional
> programmer might look to take a course (Community Colleges,
> local state schools, etc.) don't even mention the language.
Well some said they were forced to look at Lisp too. Some walk along
ans smiled about our posters (which was in fact a good thing, because
you could easily start tlaking with them) I had a lot of papers with
me for a course I would like to do in December. I'll have to wait and
see if people will participate.
9) The found it very impressive that we could change a running program
without problems and they hardly believe that you could add slots to
objects during runtime.
10) The did not have any idea that how easy a language could be
extended. They hardly believe that one can even introduce new control
flow elements just as easily as new Datastructures. And they were very
suprised to see how other "languages" could be embedded into Common
Lisp. The cl-http Server was really an eye opener for many of them,
and it was a pleasure to see how positivly they reacted.
This give me some hope on a broader usage of Common Lisp BTW. XP will
probably help too, but the point that you can change code during
runtime will probably help much more as will the easy way just to try
out an idea.
>
> There are also some "new" misconceptions that I've noticed as a
> (graduating this semester) CS undergrad at Berkeley. A lot of the
> students here, both grads and undergrads, have an impression of Lisp
> heavily tainted by Scheme, which is the only exposure most get. They
> can't even conceive of a fast compiled Lisp with iterative constructs
> and a huge library of useful functions.
Well even if they are Scheme influenced, I guess they will use MIT
Scheme to a large extend and the libraries from MIT Scheme are
extremly large and profound too.
>
> > 2) The expressed desire to have a more expressive GUI (someone mentioned
> > SWING). Better FLI support. Here again it seems to be a plea for Lisp to
> > become more mainstream (integrated) and that here should be less
> grunt work
This was an easy win for us on that fair. I just took a header and the
Lisp Version I was using simply wrote the Lisp wrappers.
>
> These criticisms I have a really hard time disagreeing with. :/ I
> really would like to see stuff like multiprocessing, GUI (although
> CLIM seems to the de facto standard for the last two), FFI, defsystem,
> possibly POSIX interfaces, SQL interfaces, etc. standardized. I don't
> necessarily mean "included in the standard for ANSI Common Lisp."
Well they asked most of the time for the GUI side, and SQL but no one
asked fo a POSIX interface or a common defsystem.
>
> I just think that many different vendors providing a variety of
> different interfaces to the same functionality is exactly the kind of
> thing that standardization was invented for. Yes, it's possible to
> write wrappers like CLOCC graciously provides. But having to use
> wrappers to write portable code seems like a cry for
> standardization.
again that was not a problem the visitos found. They were moire basic.
the were suprised
- that Lisp is still around
- that people were using it
- and what people were doing with it
>
> Incidently, CAPI and CLIM were both viewed *very* positively by the
> people I showed them to this summer. Having a GUI that's source code
> compatible between Windows and Unix was *huge* to them. Common Lisp's
> portability is one of its many great strengths.
Well it was important that it was there. I just could tell them well
the whole IDE uses CAPI that was enough for them.
>
> ObDisclaimer: I truly love Common Lisp. I'm not trying to bash it.
I can't see where you were bashing Common Lisp.
> Let me be the first to acknowledge I don't know nearly as much about
> it or its circumstances as many of the people here....
Well that's true for me too. I'm using Common Lisp nearly exclusivly
now but it's a long way to go and quite a bunch to learn. I'm happy I
started my journey some time ago. And I'm glad Common Lisp is there.
Regards
Friedrich
Hello!
In article <··············@frown.here>,
Friedrich Dominicus <·····@q-software-solutions.com> wrote:
>[...]
>9) The found it very impressive that we could change a running program
>without problems and they hardly believe that you could add slots to
>objects during runtime.
Yeah, that's impressive. However, I hear the name "Erlang" called.
IMHO there's much more infrastructure for *structured* hot code
swap in Erlang than in Lisp.
>[...]
>> Let me be the first to acknowledge I don't know nearly as much about
>> it or its circumstances as many of the people here....
>Well that's true for me too. I'm using Common Lisp nearly exclusivly
>now but it's a long way to go and quite a bunch to learn. I'm happy I
>started my journey some time ago. And I'm glad Common Lisp is there.
At work too? Just tell: Where can one do Lisp at work? :-)
>Regards
>Friedrich
Kind regards,
Hannah.
······@schlund.de (Hannah Schroeter) writes:
> Yeah, that's impressive. However, I hear the name "Erlang" called.
> IMHO there's much more infrastructure for *structured* hot code
> swap in Erlang than in Lisp.
If you have the time, could you explain the differences between
updating a running Erlang program and updating a Lisp system? I'd
be very interested...
> At work too? Just tell: Where can one do Lisp at work? :-)
See the current thread "Lisp Jobs," in which a half dozen or so
very helpful people have given excellent advice on how one goes about
doing Lisp at work. As long as you're over 25. ;)
Gabe Garza
Gabe Garza <·······@ix.netcom.com> writes:
> If you have the time, could you explain the differences between
> updating a running Erlang program and updating a Lisp system? I'd
> be very interested...
In Erlang it works as follows. Threads typically keep themselves
alive by making tail calls, so a simple process f will basically
look like
f(A,B,C) :-
do_something
f(NewA, NewB, NewC)
where NewA, NewB and NewC are the new values for the state variables
A, B and C. If f resides in module m, one can write the tail call
alternatively as
m:f(NewA, NewB, NewC)
This will call f as defined in the latest version of m. One can thus
update a server by loading in a new version of the module where it
is defined. If memory serves right, there can be two versions of
a module at any given time, the "old" and the "new" version, and the
old one can be purged once it is no longer being executed.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
On 11/8/01 21.40, in article ············@kynopolis.org, "Gabe Garza"
<·······@ix.netcom.com> wrote:
>
> 8.) The lack of courses. One of the first questions my boss asked
> was where it was taught. The typical places a professional
> programmer might look to take a course (Community Colleges,
> local state schools, etc.) don't even mention the language.
Most languages aren't really taught per se, though. UMass is using Java for
almost all of the undergrad courses, but I don't see any real push to create
Java experts.
> There are also some "new" misconceptions that I've noticed as a
> (graduating this semester) CS undergrad at Berkeley. A lot of the
> students here, both grads and undergrads, have an impression of Lisp
> heavily tainted by Scheme, which is the only exposure most get. They
> can't even conceive of a fast compiled Lisp with iterative constructs
> and a huge library of useful functions.
This, I think is related to my point above. Most students see scheme in a
very particular context, namely that of SICP. I don't have the latest
version, but in the first edition, it uses lists for everything. I think
this is a subset of what even scheme offers. While this works well for
SICP---the book made me want to be a programmer---it doesn't present Lisp as
being a good everyday language.
When people join the lab where I work, most of them have either never
programmed in Lisp or not seen things like arrays, CLOS, loop, setf, etc.
Since we use MCL a lot, it's pretty easy to get people up to speed. ILISP
and Allegro's eli are good if you are already a Lisp programmer, but I have
noticed that people getting started find them pretty opaque. (For example,
I've seen smart people completely miss the fact that there is a debugger in
Allegro.)
I'm a little surprised that this is the case at Berkeley, though.
^L
P.S. I looked at KMP's interview on slashdot, and while he did a really good
job addressing the usual questions, I'm not sanguine about converting
anybody, if only because it would appear that the fashion in that community
is to not like it.
Louis Theran <······@cs.umass.edu> writes:
> On 11/8/01 21.40, in article ············@kynopolis.org, "Gabe Garza"
> <·······@ix.netcom.com> wrote:
>
> >
> > 8.) The lack of courses. One of the first questions my boss asked
> > was where it was taught. The typical places a professional
> > programmer might look to take a course (Community Colleges,
> > local state schools, etc.) don't even mention the language.
>
> Most languages aren't really taught per se, though. UMass is using
> Java for almost all of the undergrad courses, but I don't see any
> real push to create Java experts.
At first-tier universities, as a part of the CS program, no, they
aren't. These programs are supposed to teach computer science.
However, even Cal has a CS 9 series that just teaches languages, with
no emphasis on CS, just on teaching the language as a
practical/vocational skill. The current version of the series is "X
for Programmers", with intro to symbolic programming as the prereq,
where X is Fortran and MatLab; Pascal; C; Scheme and Functional
Programming; Productive use of UNIX; C++; Java. They're all 1-unit,
semester-long classes. (And it looks like they've modernized the
Fortran class since I took it, which is a very good thing, considering
how many bio majors I knew who took it)
Cal's CS 9 series is an odd bit of vocation thrown in to an academic
school. However, language classes that are a part of things like the
vocational programs at Community Colleges, and union training programs
like WashTech's, should allow someone with software engineering skills
to become ate least reasonably competent in the language.
> I'm a little surprised that this is the case at Berkeley, though.
We do have one CS professor (Fateman), who is a serious CL fan. He's
teaching the upper-division compilers class this semester, and they're
doing all of their programming in Common Lisp. Much to the chagrin of
some of the students who do a remarkable amount of bitching about one
or both of (a) they don't want to learn lisp because it won't help
them get a job; (b) they have a hard time using lisp with vi, but
refuse (on really stupid principal) to learn emacs. Then again, I'm
not so sure I'd be sad if people like these end out using Java or C++
exclusively once they're graduated.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> At first-tier universities, as a part of the CS program, no, they
> aren't. These programs are supposed to teach computer science.
> However, even Cal has a CS 9 series that just teaches languages, with
> no emphasis on CS, just on teaching the language as a
> practical/vocational skill.
Does it count for the actual major, though? There's a series of
classes here which just teach languages, but they count not a whit
towards either a CS major or minor.
--
Brian Palmer
"Whoever fights monsters should see to it that in the process he does
not become a monster. And when you look long into an abyss, the abyss
also looks into you" - Nietzsche
Brian Palmer <·······@leland.stanford.edu> writes:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > At first-tier universities, as a part of the CS program, no, they
> > aren't. These programs are supposed to teach computer science.
> > However, even Cal has a CS 9 series that just teaches languages, with
> > no emphasis on CS, just on teaching the language as a
> > practical/vocational skill.
>
> Does it count for the actual major, though? There's a series of
> classes here which just teach languages, but they count not a whit
> towards either a CS major or minor.
Nope. They're not even necessarily for CS people, either, at least
not to the exclusion of others.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@elaine0.Stanford.EDU>, Brian Palmer
<·······@leland.stanford.edu> wrote:
> ···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
>
> > At first-tier universities, as a part of the CS program, no, they
> > aren't. These programs are supposed to teach computer science.
> > However, even Cal has a CS 9 series that just teaches languages, with
> > no emphasis on CS, just on teaching the language as a
> > practical/vocational skill.
>
> Does it count for the actual major, though? There's a series of
> classes here which just teach languages, but they count not a whit
> towards either a CS major or minor.
That's interesting.
My university days were back in the early 80's, at Waikato Universty in
MiddleEar^H^H^H^H^H^H^H^H^HNew Zealand. I don't think any NZ university
pretends to be on a level with a 1st-tier US school -- simply no
population to support it, and most people go to the US for PhD level
work.
But all the same, as I recall there was very seldom any restriction on
what language you used for your assignments.
The first year classes used Pascal. There was a 2nd year class that
used COBOL for a project. And I recall that the 3rd year AI (boo, hiss)
class required the use of Franz-Lisp, complete with the mandated
every-data-structure-is-a-list mentality.
But for the rest, it was normally expected that you'd use Pascal for
everything (and 99% of people did just that), but in fact you could use
anything you wanted and I made a point of trying to do every project in
a different language. I recall using Pascal in the Numerical Analysis
paper ("NAG only works with FORTRAN", I was told by the lecturer, but he
was of course wrong, given %REF in VAX Pascal). I used Modula-2 for
several projects, and BCPL for several more. I used STOIC (a
FORTH-alike) for one. I used C (under Eunice) for one. I don't think I
managed to get Edinburgh PROLOG to do anything useful, but I tried.
Ah, those were the days! When the 2 MB VAX 11/780 with 60 users crawled
like a dog during the day, but felt positively zippy after 2 am when
there were less than half a dozen people left!
-- Bruce
Louis Theran <······@cs.umass.edu> writes:
> On 11/8/01 21.40, in article ············@kynopolis.org, "Gabe Garza"
> <·······@ix.netcom.com> wrote:
>
> >
> > 8.) The lack of courses. One of the first questions my boss asked
> > was where it was taught. The typical places a professional
> > programmer might look to take a course (Community Colleges,
> > local state schools, etc.) don't even mention the language.
>
> Most languages aren't really taught per se, though. UMass is using
> Java for almost all of the undergrad courses, but I don't see any
> real push to create Java experts.
At first-tier universities, as a part of the CS program, no, they
aren't. These programs are supposed to teach computer science.
However, even Cal has a CS 9 series that just teaches languages, with
no emphasis on CS, just on teaching the language as a
practical/vocational skill. The current version of the series is "X
for Programmers", with intro to symbolic programming as the prereq,
where X is Fortran and MatLab; Pascal; C; Scheme and Functional
Programming; Productive use of UNIX; C++; Java. They're all 1-unit,
semester-long classes. (And it looks like they've modernized the
Fortran class since I took it, which is a very good thing, considering
how many bio majors I knew who took it)
Cal's CS 9 series is an odd bit of vocation throw in to an academic
school. However, things like the vocational programs at Community
Colleges, and union training programs like WashTech's, are
specifically and the programming language courses should allow someone with software engineering skills to become ate least reasonably competant
>
> > There are also some "new" misconceptions that I've noticed as a
> > (graduating this semester) CS undergrad at Berkeley. A lot of the
> > students here, both grads and undergrads, have an impression of Lisp
> > heavily tainted by Scheme, which is the only exposure most get. They
> > can't even conceive of a fast compiled Lisp with iterative constructs
> > and a huge library of useful functions.
>
> This, I think is related to my point above. Most students see scheme in a
> very particular context, namely that of SICP. I don't have the latest
> version, but in the first edition, it uses lists for everything. I think
> this is a subset of what even scheme offers. While this works well for
> SICP---the book made me want to be a programmer---it doesn't present Lisp as
> being a good everyday language.
>
> When people join the lab where I work, most of them have either never
> programmed in Lisp or not seen things like arrays, CLOS, loop, setf, etc.
> Since we use MCL a lot, it's pretty easy to get people up to speed. ILISP
> and Allegro's eli are good if you are already a Lisp programmer, but I have
> noticed that people getting started find them pretty opaque. (For example,
> I've seen smart people completely miss the fact that there is a debugger in
> Allegro.)
>
> I'm a little surprised that this is the case at Berkeley, though.
>
>
> ^L
>
> P.S. I looked at KMP's interview on slashdot, and while he did a really good
> job addressing the usual questions, I'm not sanguine about converting
> anybody, if only because it would appear that the fashion in that community
> is to not like it.
>
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Louis Theran <······@cs.umass.edu> writes:
> On 11/8/01 21.40, in article ············@kynopolis.org, "Gabe Garza"
> <·······@ix.netcom.com> wrote:
>
> >
> > 8.) The lack of courses. One of the first questions my boss asked
> > was where it was taught. The typical places a professional
> > programmer might look to take a course (Community Colleges,
> > local state schools, etc.) don't even mention the language.
>
> Most languages aren't really taught per se, though. UMass is using
> Java for almost all of the undergrad courses, but I don't see any
> real push to create Java experts.
This depends widely on the school and the curricula it has adopted. I
transferred to Berkeley from a community college, and with the
exception of a "Data Structures" course, the entire CS curricula there
centered around languages, e.g., there was a C++ class, an x86
assembly language class, a C class, etc.
I think this is a complex issue. If you have the time to persue a CS
degree, then obviously it's better to take coursework that will give
you a broad background. But not everyone/every school has that
luxury, for a variety of different reasons.
> > There are also some "new" misconceptions that I've noticed as a
> > (graduating this semester) CS undergrad at Berkeley. A lot of the
> > students here, both grads and undergrads, have an impression of
> > Lisp heavily tainted by Scheme, which is the only exposure most
> > get. They can't even conceive of a fast compiled Lisp with
> > iterative constructs and a huge library of useful functions.
>
> This, I think is related to my point above. Most students see
> scheme in a very particular context, namely that of SICP. I don't
> have the latest version, but in the first edition, it uses lists for
> everything. I think this is a subset of what even scheme offers.
> While this works well for SICP---the book made me want to be a
> programmer---it doesn't present Lisp as being a good everyday
> language.
I agree, although I think that even Scheme in a less pedagogic light
would still spread the the misconception. Scheme is simply lacking
(AFAIK) constructs that are necessary for a smart compiler to generate
efficient code. Type declarations come to mind.
<snip>
> P.S. I looked at KMP's interview on slashdot, and while he did a
> really good job addressing the usual questions, I'm not sanguine
> about converting anybody, if only because it would appear that the
> fashion in that community is to not like it.
You gotta start somewhere. That community, even if they sometimes do
seem to have the attention span of a hyperactive chimp and a knowledge
of computers that doesn't extend past the most recent buzzwords, does
represent an active segment of the programming community. And I'd be
willing to bet that more then a few people who read it were convinced
to give CL a try.
Gabe Garza
"Wade Humeniuk" <········@cadvision.com> writes:
> So far from reading the responses to your interview I have gleaned a
> couple of points.
Let me add my two cents:
1. It looks to me as if the exposure to Lisp or Scheme in high school
or university courses contributes to the bad reputation that Lisp
has. It reminds me of my experiences with mathematics: In high
school it was rather easy for me, but I also found it quite boring
and not very interesting, so I decided to study something
else. It was pure luck that I came across a couple of books that
taught me how fascinating mathematics can be and caused me to
cancel my current studies and pick up mathematics. I studied logic
and set theory for about ten years (until I finished my Ph.D.) and
I really _loved_ it - I never regretted my decision.
If I'm talking about mathematics to someone I don't know the usual
reaction is: "Mathematics? No, please!! I've always hated it!!" If
the person is open-minded enough and if I have some time, I will
usually succed in explaining to them how interesting and cool
mathematics can be, but I can nevertheless understand their first
reaction: The mathematics curriculum in high school is mainly
geared towards using mathematics as a tool for other stuff, people
are drilled in small realms like applied analysis, and most of what
mathematics is all about is completely left out. Nobody is really
interested in showing the beauty and greatness of it - I have yet
to find a teacher who is willing _and_ able to do this. (It is my
personal experience from educating students of mathematics for four
years that the ones who decide to become teachers usually aren't
the ones who are really good and love what they're doing.)
Coming back to Lisp: I had to attend a couple of CS courses in my
first two years at the university and I was exposed to Lisp - which
was the main language taught there. (They've recently switched to
Scheme.) I mostly didn't care about computers and programming
languages for the rest of my studies and I can't say that the Lisp
courses left any impression on me. I can only remember that it was
rather boring - which I also attribute to the teacher and the stuff
that was actually taught.
Now, after having been a professional programmer for about five
years (doing the usual stuff - C, C++, Java, Perl), I have
rediscovered Lisp about half a year ago and I'm really in love. I'm
very glad I found it, and I spend much of my spare time reading
about it, trying to learn more about it and writing programs in
it. It is like meeting a girl that you've known since kindergarten
but who was away for a couple of years and finally realizing how
beautiful she is and _also_ realizing that she always was a beauty
but you somehow didn't get it earlier...
My conclusion is that in both cases - mathematics and Lisp - the
educational system has been quite counterproductive. Only through
the writings of people who really cared about their subject was I
able to grasp the beauty of something that I would have missed
otherwise. I don't know what we can do to change the current
situation, but maybe - as long as we're not able to turn the
educational system upside down - we shouldn't be to frustrated if
high schools and universities teach Java or C instead of Lisp. This
might help us in the long run... :)
(Disclaimer: These are my experiences based on the situation in
Germany. But I suspect that it'll be about the same in other
countries.)
2. I'd like to thank Kent Pitman for this great interview but after
reading the comments I'm not sure if it'll change anything. If you
watch the number of comments for this interview and for other
articles that appear on Slashdot for some time, you'll realize that
none of the topics there is able to capture the audience's
attention for more than a couple of hours. It'll take less than a
day and your article's headline has vanished from the main page
which is more or less equivalent to not being there at all. Combine
this with the comments themselves (of which 90% are moronic) and
the fact that there's virtually no discussion thread which has a
depth of three or higher and you'll come to the conclusion that
Slashdot is just another incarnation of the MTV culture: There has
to be a new video (er, article) at least every hour, and most of
the stuff that they're 'playing' consists of the same old 'pop
songs' (my editor/OS is better than yours, Microsoft is bad, AMD
has released a new chip) over and over again.
Well, maybe I'm too pessimistic, and KMP was able to attract two or
three people who will actually try to learn more about Lisp and who
will realize how great it is - maybe that's all we can ask for.
Sorry for the long posting,
Edi.
···@agharta.de (Dr. Edmund Weitz) wrote in message:
> Well, maybe I'm too pessimistic, and KMP was able to attract two or
> three people who will actually try to learn more about Lisp and who
> will realize how great it is - maybe that's all we can ask for.
Maybe. There are many people looking for a better language and a
better tool, and they will certainly listen.
I myself started on a journey about a year ago, when some people at
comp.lang.ruby kept refering to functional programming languages and
Lisp and the resemblence of their features in Ruby. My background is
C++, Java, Python, a little SmallTalk, Ruby, the Agile Alliance,
patterns and a "few" other things.
This resulted in me buying a copy of SICP, learning Scheme (after
serious consideration of starting with Common Lisp) and studying
OCAML, Haskell and Common Lisp on the side line. I'm now half way
through SICP -- and I'm still not even at university studying! :-)
Needless to say: It has turned my view of programming upside-down.
Common Lisp looks more and more attractive as I find out more about
it. So interviews such like the one at slashdot are among the only way
I can find out more about Common Lisp style.
That is, besides from reading this news group, reading websites from
Robert Kent Dybvig, Bruno Haible, Oleg, Paul Graham and so on. I
haven't decided on what Lisp-book to buy yet. Dave Touretzsky's book
is quite too easy for me, and CLTL2 doesn't give much in the way about
the Common Lisp Style (maybe Paul Grahams book will do it?). It's
actually a bit hard to shift from Scheme to Common Lisp, making Common
Lisp programs as elegant as I can do them in Scheme...
Sorry, I got sidetracked.
What I wanted to say, is: There are some among us out there looking
and reading and trying to find more. I would heartily welcome an up to
date textbook on Lisp with great examples of code -- especially if the
examples aren't all just AI and mathematics, but more "common"
examples, that will make Lisp look cool! :-)
All you seniors: Keep talking about and showing the wonders of Lisp! I
think we desperately need it.
Best Regards,
Dennis Decker Jensen
COGNOSCERE NON VIDERI
·············@hotmail.com (Dennis Decker Jensen) writes:
> Common Lisp looks more and more attractive as I find out more about
> it. So interviews such like the one at slashdot are among the only way
> I can find out more about Common Lisp style.
>
> That is, besides from reading this news group, reading websites from
> Robert Kent Dybvig, Bruno Haible, Oleg, Paul Graham and so on. I
> haven't decided on what Lisp-book to buy yet. Dave Touretzsky's book
> is quite too easy for me, and CLTL2 doesn't give much in the way about
> the Common Lisp Style (maybe Paul Grahams book will do it?). It's
> actually a bit hard to shift from Scheme to Common Lisp, making Common
> Lisp programs as elegant as I can do them in Scheme...
Graham's book ("ANSI Common Lisp") is written in something of a
Schemier style than most CL code I've seen. But it's definitely a
Common Lisp book. My poor copy is getting all worn out from passing
it around to people who've come through Cal's CS 61 program where they
teach Scheme. I definately think it's a good fit for someone trying
to get to CL from Scheme, based on experience. Just don't listen to a
word he has to say about LOOP :)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
···@agharta.de (Dr. Edmund Weitz) wrote in message
news:<··············@bird.agharta.de>...
> It reminds me of my experiences with mathematics: In high
> school it was rather easy for me, but I also found it quite boring
> and not very interesting, so I decided to study something
> else. It was pure luck that I came across a couple of books that
> taught me how fascinating mathematics can be and caused me to
> cancel my current studies and pick up mathematics. I studied logic
> and set theory for about ten years (until I finished my Ph.D.) and
> I really _loved_ it - I never regretted my decision.
What what books were these? They sound like something I might
want to read myself.
--Andrew
··········@hotmail.com (Andrew) writes:
> ···@agharta.de (Dr. Edmund Weitz) wrote in message
> news:<··············@bird.agharta.de>...
>
> > It reminds me of my experiences with mathematics: In high
> > school it was rather easy for me, but I also found it quite boring
> > and not very interesting, so I decided to study something
> > else. It was pure luck that I came across a couple of books that
> > taught me how fascinating mathematics can be and caused me to
> > cancel my current studies and pick up mathematics. I studied logic
> > and set theory for about ten years (until I finished my Ph.D.) and
> > I really _loved_ it - I never regretted my decision.
>
> What what books were these? They sound like something I might
> want to read myself.
>
> --Andrew
OK, this is off the top of my head and only backed up by a quick peek
through my bookshelves, so I'm not sure if I missed one or if this is
entirely correct, but here we go:
1. It all started with "Moderne Mathematik" by Walter Fuchs. This was
part of a series called "Exakte Geheimnisse" by Droemer/Knaur (the
publisher) which also included some good books about other themes
like physics or chemistry. I'm not sure if this is available in
English.
2. Courant/Robbins; What is Mathematics
3. G�rding: Encounter with Mathematics
4. 'G�del's Proof' by Nagel and Newman led me to logic and set
theory.
5. I was also pretty amazed by Hofstadter's 'G�del-Escher-Bach' at
that time.
I'm pretty sure there must be more or even better books but I'm not
familiar with the current literature. Maybe other readers of this
newsgroup want to help?
If you're like me and you come to the conclusion that infinite set
theory and cardinal arithmetic is the real deal you might even want to
read a book that I have co-written. It's at
<http://www.birkhauser.ch/books/math/6124.htm>
I wouldn't recommend to start with this one, though... :)
I hope you'll be one of the chosen few who have fun with mathematics.
Good luck,
Edi.
···@agharta.de (Dr. Edmund Weitz) wrote in message
news:<··············@bird.agharta.de>...
> OK, this is off the top of my head and only backed up by a quick peek
> through my bookshelves
[list snipped]
Much obliged for the list :)
> If you're like me and you come to the conclusion that infinite set
> theory and cardinal arithmetic is the real deal you might even want to
> read a book that I have co-written. It's at
>
> <http://www.birkhauser.ch/books/math/6124.htm>
>
> I wouldn't recommend to start with this one, though... :)
..I think I'll give it a few years.
> I hope you'll be one of the chosen few who have fun with mathematics.
Well I've recently discovered the joy of computer *science* - it may
very well lead me back to math too. Who knows. :)
--Andrew
Dr. Edmund Weitz wrote:
> 2. I'd like to thank Kent Pitman for this great interview but after
> reading the comments I'm not sure if it'll change anything. If you
> watch the number of comments for this interview and for other
> articles that appear on Slashdot for some time, you'll realize that
> none of the topics there is able to capture the audience's
> attention for more than a couple of hours.
I'd like to be a counterpoint to this. It was a link to a Paul Graham
article on Slashdot that got me (re)interested in Lisp. The real
problem is that 95% (99%?) of programmers don't really like programming
that much. They only want to know what they need to know to get a paycheck.
Here's my big question on the topic: Do languanges ever recapture
significant mindshare? Has any language ever made a significant
comeback? I don't think so. I hope CL can be the first.
jeff <·····@houseofdistraction.com> writes:
> Here's my big question on the topic: Do languanges ever recapture
> significant mindshare? Has any language ever made a significant
> comeback? I don't think so. I hope CL can be the first.
BASIC, I think. Did it have much mindshare at all by he end of the
80's? It sure does now (VisualBasic).
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Thomas F. Burdick wrote:
> jeff <·····@houseofdistraction.com> writes:
>
>
>>Here's my big question on the topic: Do languanges ever recapture
>>significant mindshare? Has any language ever made a significant
>>comeback? I don't think so. I hope CL can be the first.
>>
>
> BASIC, I think. Did it have much mindshare at all by he end of the
> 80's? It sure does now (VisualBasic).
>
>
VisualBasic is to BASIC as Modula-2 is to Pascal. It's not really the
same language. But it does offer a good example of what CL needs to
revive. The thing that makes VB so popular is that you can make an
application almost withouth programming. That's it! I'm going to start
the VisualCommonLisp project as soon as I figure out how to get CL to
talk efficiently & easily to GTK.
jeff <·····@houseofdistraction.com> writes:
> VisualBasic is to BASIC as Modula-2 is to Pascal. It's not really the
> same language. But it does offer a good example of what CL needs to
Modula-2 is to Pascal as ANSI Common Lisp is to Lisp 1.5 ...
> the VisualCommonLisp project as soon as I figure out how to get CL to
> talk efficiently & easily to GTK.
You might want to look at cl-gtk and clg. clg packages for CMUCL just
went into cCLan, oddly enough
http://ww.telent.net/cliki/clg
http://ww.telent.net/cliki/cl-gtk
http://ww.telent.net/cliki/cCLan
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> jeff <·····@houseofdistraction.com> writes:
>>the VisualCommonLisp project as soon as I figure out how to get CL to
>>talk efficiently & easily to GTK.
>>
>
> You might want to look at cl-gtk and clg. clg packages for CMUCL just
> went into cCLan, oddly enough
>
> http://ww.telent.net/cliki/clg
> http://ww.telent.net/cliki/cl-gtk
> http://ww.telent.net/cliki/cCLan
Really? Cool. How does it handle callbacks (i.e. the calling from C
into CMUCL problem)?
jeff <·····@houseofdistraction.com> writes:
> Really? Cool. How does it handle callbacks (i.e. the calling from C
> into CMUCL problem)?
Using funcall[0123], I'd guess (I haven't checked, but that's the
normal way). Calling from C into CMUCL is not impossible, it's just a
bit messy.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
jeff <·····@houseofdistraction.com> writes:
> Daniel Barlow wrote:
>
> > jeff <·····@houseofdistraction.com> writes:
> >> the VisualCommonLisp project as soon as I figure out how to get CL
> >> to talk efficiently & easily to GTK.
>
> >>
> > You might want to look at cl-gtk and clg. clg packages for CMUCL
> > just
>
> > went into cCLan, oddly enough
> > http://ww.telent.net/cliki/clg
>
> > http://ww.telent.net/cliki/cl-gtk
> > http://ww.telent.net/cliki/cCLan
>
> Really? Cool. How does it handle callbacks (i.e. the calling from C
> into CMUCL problem)?
clg looks pretty interesting; it is unfortunately pretty closely tied
to the latest experimental versions of GTK, which are pretty "in
flux."
Between GTK 1.3.8 and 1.3.10, gtk_menu_item_set_placement seems to
have gone away, which causes some breakage.
Probably it stabilizes a version or two hence (of GTK :-(); doesn't
seem _quite_ ready yet...
--
(reverse (concatenate 'string ·············@" "enworbbc"))
http://www.cbbrowne.com/info/lisp.html
Don't be so open-minded that your brains fall out.
········@acm.org writes:
> jeff <·····@houseofdistraction.com> writes:
> > Daniel Barlow wrote:
> >
> > > You might want to look at cl-gtk and clg. clg packages for CMUCL
> > > just
> >
> > > went into cCLan, oddly enough
> > > http://ww.telent.net/cliki/clg
> >
> > Really? Cool. How does it handle callbacks (i.e. the calling from C
> > into CMUCL problem)?
>
> clg looks pretty interesting; it is unfortunately pretty closely tied
> to the latest experimental versions of GTK, which are pretty "in
> flux."
>
> Between GTK 1.3.8 and 1.3.10, gtk_menu_item_set_placement seems to
> have gone away, which causes some breakage.
>
> Probably it stabilizes a version or two hence (of GTK :-(); doesn't
> seem _quite_ ready yet...
I don't think it's quite ready, no, but allegedly the gtk developers
are in API freeze, so (fingers crossed) it seems like a sensible time
to start exploring the possibilities.
Of course, the documentation on the lisp side is currently a little
sparse...
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> ········@acm.org writes:
>
> > clg looks pretty interesting; it is unfortunately pretty closely tied
> > to the latest experimental versions of GTK, which are pretty "in
> > flux."
> >
> > Between GTK 1.3.8 and 1.3.10, gtk_menu_item_set_placement seems to
> > have gone away, which causes some breakage.
> >
> > Probably it stabilizes a version or two hence (of GTK :-(); doesn't
> > seem _quite_ ready yet...
>
> I don't think it's quite ready, no, but allegedly the gtk developers
> are in API freeze, so (fingers crossed) it seems like a sensible time
> to start exploring the possibilities.
And they took so long to get there! I've been looking forward to a
clg I can use without having to install bleeding-edge gtk stuff. Sun
was supposed to ship Gnome 2 with its last Solaris release, but it
wasn't ready. Since they *are* part of GTK development, I'm guessing
they'll put pressure on to get it out by the next quarter, so they
don't have to ship CDE as the default again. So, there's probably
hope of having GTK quiet down by the next quarter.
> Of course, the documentation on the lisp side is currently a little
> sparse...
(Crud, I was hoping this would improve before GTK stabalized)
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
Christophe Rhodes <·····@cam.ac.uk> writes:
> ········@acm.org writes:
>
> > jeff <·····@houseofdistraction.com> writes:
> > > Daniel Barlow wrote:
> > >
> > > > You might want to look at cl-gtk and clg. clg packages for CMUCL
> > > > just
> > >
> > > > went into cCLan, oddly enough
> > > > http://ww.telent.net/cliki/clg
> > >
> > > Really? Cool. How does it handle callbacks (i.e. the calling from C
> > > into CMUCL problem)?
> >
> > clg looks pretty interesting; it is unfortunately pretty closely tied
> > to the latest experimental versions of GTK, which are pretty "in
> > flux."
Use clg-0.51, which is for GTK+1.2.*.
> >
> > Between GTK 1.3.8 and 1.3.10, gtk_menu_item_set_placement seems to
> > have gone away, which causes some breakage.
> >
> > Probably it stabilizes a version or two hence (of GTK :-(); doesn't
> > seem _quite_ ready yet...
These are GTK+1.3.* and are supposed to be unstable.
^
Odd number here for unstable version.
Even number here for stable version.
>
> I don't think it's quite ready, no, but allegedly the gtk developers
> are in API freeze, so (fingers crossed) it seems like a sensible time
> to start exploring the possibilities.
>
> Of course, the documentation on the lisp side is currently a little
> sparse...
There is always the ultimate documentation available: the source code:)
A good way to learn CLG is to take a look at src/testgtk.lisp in the
clg-0.51 distribution, poke around in the ultimate documentation a bit,
and use the tutorial at http://www.gtk.org/tutorial/.
Best,
-cph
In article <··············@noetbook.telent.net>, Daniel Barlow wrote:
>jeff <·····@houseofdistraction.com> writes:
>
>> VisualBasic is to BASIC as Modula-2 is to Pascal. It's not really the
>> same language. But it does offer a good example of what CL needs to
>
>Modula-2 is to Pascal as ANSI Common Lisp is to Lisp 1.5 ...
Modula 2 and Pascal are distinct languages, that lead parallel lives
and are separately standardized; so it's not exactly true that Pascal
is an obsolete version of Modula 2.
The Pascal standards are:
ISO 7185:1990 (Programming Languages --- Pascal) and
ISO 10206:1990 (Programming Languages --- Extended Pascal).
Both can be found in PostScript form on the net; I don't know whether
these are latest. Modula has these:
ISO 10514-1:1996 (Modula-2 --- Base Language)
ISO 10514-2:1998 (Modula-2 --- OO extension)
ISO 10514-3:1998 (Modula-2 --- Generic extension)
Daniel Barlow wrote:
> You might want to look at cl-gtk and clg. clg packages for CMUCL just
> went into cCLan, oddly enough
>
> http://ww.telent.net/cliki/clg
> http://ww.telent.net/cliki/cl-gtk
> http://ww.telent.net/cliki/cCLan
>
I just installed the clg package but either it or I seem to be broken.
This is what happens when I try to load the hello-world example that
came with it:
Starting lisp -core /usr/lib/cmucl/lisp-safe.core ...
; Loading #p"/home/jlb/.cmucl-init.cl".
;; Loading #p"/var/lib/cmucl/site-init.lisp".
;;; Loading #p"/etc/lisp-config.lisp".
;;; Loading
#p"/usr/share/common-lisp/source/common-lisp-controller/common-lisp-controller.lisp".
*
* (load "hello-world.lisp")
; Loading #p"/home/jlb/cl/hello-world.lisp".
The package named "GTK" doesn't exist.
jeff <·····@houseofdistraction.com> writes:
> Daniel Barlow wrote:
>
> > You might want to look at cl-gtk and clg. clg packages for CMUCL just
> > went into cCLan, oddly enough
> > http://ww.telent.net/cliki/clg
> > http://ww.telent.net/cliki/cl-gtk
> > http://ww.telent.net/cliki/cCLan
> >
>
> I just installed the clg package but either it or I seem to be
> broken. This is what happens when I try to load the hello-world
> example that came with it:
Or both. :-)
You would normally do (require :clg) from the top level before loading
the hello-world.lisp example file, as installing the package should
arrange for compilation of the sources but not dumping a new core with
this loaded. This was missing from the transcript you appended, so I
suspect you haven't done that.
That said, there is a problem in the automated compilation, in that
the clg build process currently requires access to a running X session
(as some of the modules involve loading libg{d,t}k-x11-foo.so and
running g{d,t}k_init), which common-lisp-controller (hi, Peter!)
doesn't allow.
The long-term fix to this is to fix the compilation of clg, I think;
as a workaround, you can arrange so that you have a root shell that
can talk to your X session (via sux, ssh -X, xauth, or whatever), then
run cmucl and do
(mk:oos :clg :compile)
Then (as a normal user) you should be able to do
(require :clg)
(load "/usr/share/doc/clg/examples/hello-world.lisp")
I hope that all makes sense,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes wrote:
> jeff <·····@houseofdistraction.com> writes:
>
>
>>Daniel Barlow wrote:
>>
>>
>>>You might want to look at cl-gtk and clg. clg packages for CMUCL just
>>>went into cCLan, oddly enough
>>>http://ww.telent.net/cliki/clg
>>>http://ww.telent.net/cliki/cl-gtk
>>>http://ww.telent.net/cliki/cCLan
>>>
>>>
>>I just installed the clg package but either it or I seem to be
>>broken. This is what happens when I try to load the hello-world
>>example that came with it:
>>
>
> Or both. :-)
>
> You would normally do (require :clg) from the top level before loading
> the hello-world.lisp example file, as installing the package should
> arrange for compilation of the sources but not dumping a new core with
> this loaded. This was missing from the transcript you appended, so I
> suspect you haven't done that.
>
> That said, there is a problem in the automated compilation, in that
> the clg build process currently requires access to a running X session
> (as some of the modules involve loading libg{d,t}k-x11-foo.so and
> running g{d,t}k_init), which common-lisp-controller (hi, Peter!)
> doesn't allow.
>
> The long-term fix to this is to fix the compilation of clg, I think;
> as a workaround, you can arrange so that you have a root shell that
> can talk to your X session (via sux, ssh -X, xauth, or whatever), then
> run cmucl and do
>
> (mk:oos :clg :compile)
>
> Then (as a normal user) you should be able to do
>
> (require :clg)
> (load "/usr/share/doc/clg/examples/hello-world.lisp")
>
> I hope that all makes sense,
>
Indeed it does. That's three levels of glitch you've helped me over:
1. That I needed (require :clg) instead of (require :gtk)
2. That auto-compilation requires a running X server
3. And finally that auto-compilation also requires root privs
Thanks.
jeff wrote:
> Christophe Rhodes wrote:
>
>> jeff <·····@houseofdistraction.com> writes:
>>
>>
>>> Daniel Barlow wrote:
>>>
>>>
>>>> You might want to look at cl-gtk and clg. clg packages for CMUCL just
>>>> went into cCLan, oddly enough
>>>> http://ww.telent.net/cliki/clg
>>>> http://ww.telent.net/cliki/cl-gtk
>>>> http://ww.telent.net/cliki/cCLan
>>>>
>>>>
>>> I just installed the clg package but either it or I seem to be
>>> broken. This is what happens when I try to load the hello-world
>>> example that came with it:
>>>
>>
>> Or both. :-)
>>
>> You would normally do (require :clg) from the top level before loading
>> the hello-world.lisp example file, as installing the package should
>> arrange for compilation of the sources but not dumping a new core with
>> this loaded. This was missing from the transcript you appended, so I
>> suspect you haven't done that.
>>
>> That said, there is a problem in the automated compilation, in that
>> the clg build process currently requires access to a running X session
>> (as some of the modules involve loading libg{d,t}k-x11-foo.so and
>> running g{d,t}k_init), which common-lisp-controller (hi, Peter!)
>> doesn't allow.
>>
>> The long-term fix to this is to fix the compilation of clg, I think;
>> as a workaround, you can arrange so that you have a root shell that
>> can talk to your X session (via sux, ssh -X, xauth, or whatever), then
>> run cmucl and do
>>
>> (mk:oos :clg :compile)
>>
>> Then (as a normal user) you should be able to do
>>
>> (require :clg)
>> (load "/usr/share/doc/clg/examples/hello-world.lisp")
>>
>> I hope that all makes sense,
>>
>
>
> Indeed it does. That's three levels of glitch you've helped me over:
>
> 1. That I needed (require :clg) instead of (require :gtk)
> 2. That auto-compilation requires a running X server
> 3. And finally that auto-compilation also requires root privs
>
> Thanks.
>
Unfortunately there was an unforseen fourth level of glitch. What
worked for me finally was to turn off access controls in X and then
reinstall:
$ xhost +
$ su
# apt-get --reinstall install clg
jeff <·····@houseofdistraction.com> writes:
> Unfortunately there was an unforseen fourth level of glitch. What
> worked for me finally was to turn off access controls in X and then
> reinstall:
>
> $ xhost +
> $ su
> # apt-get --reinstall install clg
Nice. That's definitely better than doing it by hand.
There's not some way of having this tie, at recompile time, to some
sort of "null" X server, is there?
Alternatively, it would at least be an improvement for the install to
check to see if it's got an X environment to work with, and give a bit
more indication that that's the problem... I'm not sure if there's a
good way to do that inside the dpkg processing...
--
(reverse (concatenate 'string ········@" "enworbbc"))
http://www.cbbrowne.com/info/rdbms.html
Never knock on Death's door; ring the doorbell and run (he hates
that).
········@acm.org writes:
> There's not some way of having this tie, at recompile time, to some
> sort of "null" X server, is there?
If you have Xvfb, this evil Perl script should do the trick: public
domain, no warranties, etc etc. It's not pretty, it may need
adjusting for X setup if you have the fonts somewhere I don't, and it
probably gets quoting wrong, but it might be a starting point. I
wrote it a few years ago to export dia documents to epsf from a shell
script - dia is a gtk app and has exactly the same problem
#!/usr/bin/perl -w
# start Xvfb on first unused display and run the supplied program
opendir(D,"/tmp");
@displays=grep(/\.X[0-9]+-lock/, readdir(D));
$display= ":".(1+$#displays);
print "Using X display $display\n";
$pid=fork();
if($pid==0) { # child
exec("Xvfb $display -ac -fp /usr/X11R6/lib/X11/fonts/misc/")
|| print ("exec failed?");
} else {
sleep(1);
if($pid>0) { # parent
$ENV{'DISPLAY'}=$display;
system(join(" ",@ARGV));
kill(15,$pid) || warn("$!");
} else { die "$!"; }
}
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
jeff <·····@houseofdistraction.com> writes:
> jeff wrote:
>
> > Indeed it does. That's three levels of glitch you've helped me over:
> > 1. That I needed (require :clg) instead of (require :gtk)
> > 2. That auto-compilation requires a running X server
> > 3. And finally that auto-compilation also requires root privs
> > Thanks.
> >
>
> Unfortunately there was an unforseen fourth level of glitch. What
> worked for me finally was to turn off access controls in X and then
> reinstall:
>
> $ xhost +
> $ su
> # apt-get --reinstall install clg
Let me just clarify this, too. Your first two points are correct, but
the third in your list above is not. Auto-compilation, in this
context, means that in the post-install scripts of the Debian-style
package a command that looks like
/usr/sbin/register-common-lisp-source <package-name>
which
* chowns the /usr/lib/common-lisp and /usr/share/common-lisp
hierarchies to the nobody user
* executes something conceptually equivalent to
"su nobody -c 'lisp -eval \'(mk:oos <package-name> :compile)\''"[1]
* rechowns the hierarchies back to root.root
So it's because that the compiling user (here nobody) cannot talk to
the running X session (whether that's a root session or a normal user)
that compilation fails. The workaround you have found is fine;
similarly, it should work for root to do
"lisp -eval '(mk:oos <package-name> :compile)'", as long as the root
user can talk to the running X session.
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> jeff <·····@houseofdistraction.com> writes:
>
> > jeff wrote:
> >
> > > Indeed it does. That's three levels of glitch you've helped me over:
> > > 1. That I needed (require :clg) instead of (require :gtk)
> > > 2. That auto-compilation requires a running X server
> > > 3. And finally that auto-compilation also requires root privs
> > > Thanks.
> > >
> >
> > Unfortunately there was an unforseen fourth level of glitch. What
> > worked for me finally was to turn off access controls in X and then
> > reinstall:
> >
> > $ xhost +
> > $ su
> > # apt-get --reinstall install clg
>
> Let me just clarify this, too. Your first two points are correct, but
> the third in your list above is not. Auto-compilation, in this
> context, means that in the post-install scripts of the Debian-style
> package a command that looks like
> /usr/sbin/register-common-lisp-source <package-name>
> which
> * chowns the /usr/lib/common-lisp and /usr/share/common-lisp
> hierarchies to the nobody user
> * executes something conceptually equivalent to
> "su nobody -c 'lisp -eval \'(mk:oos <package-name> :compile)\''"[1]
> * rechowns the hierarchies back to root.root
>
> So it's because that the compiling user (here nobody) cannot talk to
> the running X session (whether that's a root session or a normal user)
> that compilation fails. The workaround you have found is fine;
> similarly, it should work for root to do
> "lisp -eval '(mk:oos <package-name> :compile)'", as long as the root
> user can talk to the running X session.
Well, another point of view is to emit a gigantic: "I don't _care_
what the details are."
The _point_ is that when apt-get is trying to recompile this, _it
fails_. I don't care what sort of workaround is used; the above
approach seems not too painful to do by hand.
The Right Answer is to take one or another solution (n'importe quoi),
and use that _within the packaging_ so that the need to do _anything_
"by hand" goes away.
--
(concatenate 'string "cbbrowne" ·@acm.org")
http://www.cbbrowne.com/info/linux.html
"I heard that if you play the Windows CD backward, you get a satanic
message. But that's nothing compared to when you play it forward: It
installs Windows...." -- G. R. Gaudreau
In article <················@houseofdistraction.com>,
jeff <·····@houseofdistraction.com> writes:
> 1. That I needed (require :clg) instead of (require :gtk)
> 2. That auto-compilation requires a running X server
Just out of curiousity, why does CLG need X access at compile time? Seems
kind of strange.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> In article <················@houseofdistraction.com>,
> jeff <·····@houseofdistraction.com> writes:
> > 1. That I needed (require :clg) instead of (require :gtk)
> > 2. That auto-compilation requires a running X server
> Just out of curiousity, why does CLG need X access at compile time? Seems
> kind of strange.
It actually doesn't. But it compiling requires loading of the
dependencies, and the defsystem runs gtk_init() just after loading
libgtk.so. Of course, if we're just compiling, we don't need to have
gtk init the display, but that's complicated given the current
mk-defsystem design (at least as far as I understand it, which isn't
too far...)
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
Christophe Rhodes <·····@cam.ac.uk> writes:
> Then (as a normal user) you should be able to do
> (require :clg)
> (load "/usr/share/doc/clg/examples/hello-world.lisp")
Wouldn't it be reasonable to put that (require :clg) into
hello-world.lisp?
--
(reverse (concatenate 'string ·············@" "sirhc"))
http://www.cbbrowne.com/info/lsf.html
How is my programming? Call 1-800-DEV-NULL
···@agharta.de (Dr. Edmund Weitz) writes:
> 2. I'd like to thank Kent Pitman for this great interview
Aw...
> but after reading the comments I'm not sure if it'll change anything.
The world is not changed all at once, but one step at a time.
If you read the replies, you see two things: people who didn't like Lisp
who still don't like Lisp. And people close to the margin who said outright
"hey, I haven't given Lisp a fair chance and maybe I'll look into it".
I think that's probably as good as we're going to get from one article.
But people can make more articles and do more things to bring Lisp into
view.
> Well, maybe I'm too pessimistic, and KMP was able to attract two or
> three people who will actually try to learn more about Lisp and who
> will realize how great it is - maybe that's all we can ask for.
Exactly. Two or three well-placed thoughtful people can change two or three
organizations. One or more of those organizations might become a Lisp
success story.
> Sorry for the long posting,
Uh oh. Do I have to apologize for all of mine? Let's not go there.
···@agharta.de (Dr. Edmund Weitz) writes:
> 2. I'd like to thank Kent Pitman for this great interview but after
> reading the comments I'm not sure if it'll change anything. If you
> watch the number of comments for this interview and for other
> articles that appear on Slashdot for some time, you'll realize that
> none of the topics there is able to capture the audience's
> attention for more than a couple of hours. It'll take less than a
> day and your article's headline has vanished from the main page
> which is more or less equivalent to not being there at all. Combine
> this with the comments themselves (of which 90% are moronic) and
> the fact that there's virtually no discussion thread which has a
> depth of three or higher and you'll come to the conclusion that
> Slashdot is just another incarnation of the MTV culture: There has
> to be a new video (er, article) at least every hour, and most of
> the stuff that they're 'playing' consists of the same old 'pop
> songs' (my editor/OS is better than yours, Microsoft is bad, AMD
> has released a new chip) over and over again.
I'm gonna take that MTV comment and run with it (warning). I sure
hope it's like a blip on MTV, particularly if it can be a recurring
blip. Time shift back to 1994. I'm thinking here of "Yo! MTV Raps",
which was a pretty small blip on MTV as a whole, and was the only
place they allowed hip-hop to be played (again, we're in 1994). But
when it started back in the '80s, it was the first exposure a lot of
the country had to hip-hop, and it made a point of exporting both
hip-hop music and culture from NYC. Sure, it would've made it to
Chicago and California anyway, but Yo! was vital in the spread of
hip-hop to places like Seattle, St. Louis, etc., both of which have
had healthy, flourishing hip-hop communities for 15 years, thanks in
part to Yo!. If this double-feature interview on Slashdot can be the
first blip of Yo! MTV Raps on MTV, maybe Lisp can get exported to
seedling communities. And, time shifting back to now ...
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
In article <···············@shell01.TheWorld.com>, Kent M Pitman wrote:
>The first of two parts of my Slashdot interview is posted at slashdot.org
>
>Feel free to contribute comments or to answer the comments of non-believers.
>Let's make the Lisp community look alive, folks.
This is aggravating; I made one lengthy response with some programming
example, and I couldn't post it (nor even preview it) on grounds of some
``lameness detector'' which detected too many ``bogus characters''.
Needless to say, I couldn't figure out how to edit the submission to
satisfy the lameness detector, so I gave up.
That is too bad, because I had a good point, and spent some time
preparing the response.
In article <···················@news.uswest.net>, David McClain wrote:
>Please post your message here so we can all see it!
I've reworked it and resubmitted it. Only, I did not include the macro
example that I originally wanted.
In article <···················@news.uswest.net>, David McClain wrote:
>Please post your message here so we can all see it!
I've reworked it and resubmitted it after all. Only, I did not include
the macro example that I originally wanted.
···@ashi.footprints.net (Kaz Kylheku) writes:
> In article <···················@news.uswest.net>, David McClain wrote:
> >Please post your message here so we can all see it!
>
> I've reworked it and resubmitted it after all. Only, I did not include
> the macro example that I originally wanted.
Thanks. Discussion over there is better than over here, I think.
That way a different crew of people gets to see it. It also contributes
to a sense of diversity in our community. I don't want to be the only
one posting. (I'd bore people even more than I probably already did in
the interview, and anyway, my point of view is not the only one.)
Kent M Pitman <······@world.std.com> writes:
> ···@ashi.footprints.net (Kaz Kylheku) writes:
>
> > In article <···················@news.uswest.net>, David McClain wrote:
> > >Please post your message here so we can all see it!
> >
> > I've reworked it and resubmitted it after all. Only, I did not include
> > the macro example that I originally wanted.
>
> Thanks. Discussion over there is better than over here, I think.
Well, lots of trolls too :)
> That way a different crew of people gets to see it. It also contributes
> to a sense of diversity in our community. I don't want to be the only
> one posting. (I'd bore people even more than I probably already did in
> the interview, and anyway, my point of view is not the only one.)
I guess the value of the slashdot discussion is that it forces me
(us?!?) to take into account other opinions.
I posted on ML languages and refrained from posting about Python
(tllotbafir). I feel I did a good thing today :)
Cheers
--
Marco Antoniotti ========================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://bioinformatics.cat.nyu.edu
"Hello New York! We'll do what we can!"
Bill Murray in `Ghostbusters'.
Marco Antoniotti <·······@cs.nyu.edu> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > ···@ashi.footprints.net (Kaz Kylheku) writes:
> >
> > > In article <···················@news.uswest.net>, David McClain wrote:
> > > >Please post your message here so we can all see it!
> > >
> > > I've reworked it and resubmitted it after all. Only, I did not include
> > > the macro example that I originally wanted.
> >
> > Thanks. Discussion over there is better than over here, I think.
>
> Well, lots of trolls too :)
Sorry, I meant it's preferrable to DO the same discussion there rather
than here. I did not mean to make a judgment comment about whether
the nature of the discussion there was of superior quality to any occurring
here.
> > That way a different crew of people gets to see it. It also contributes
> > to a sense of diversity in our community. I don't want to be the only
> > one posting. (I'd bore people even more than I probably already did in
> > the interview, and anyway, my point of view is not the only one.)
>
> I guess the value of the slashdot discussion is that it forces me
> (us?!?) to take into account other opinions.
And it allows others to talk to us. We get to be our own ambassadors.
What they learn is whatever we choose to say. When we fail to say
anything, they make up their own mind based on whatever misinformation
one person asserts out of nowhere and another scores as Interesting.
I think most of the misimpressions have been corrected and the scoring
has been doing ok about raising reasonable points to the top. I can imagine
better scoring mechanisms, but at least the remarks about Lisp being gay
all got marked as -1.
> I posted on ML languages and refrained from posting about Python
> (tllotbafir). I feel I did a good thing today :)
Sounds like it.
I have not finished reading the interview part, but I am wondering if anybody
has done anything to follow up the interest generated by this?
I guess what I am looking for i something like "here is how you install what
you need on your Debian/Red Hat/Windows system and a few well-chosen
examples that let you try out the environment". Ideally it should be specific
and complete enough to work without reference to other information sources.
--
Fredrik Stax\"ang | rot13: ····@hcqngr.hh.fr
Kent M Pitman <······@shell01.TheWorld.com> wrote in
····················@shell01.TheWorld.com:
> The first of two parts of my Slashdot interview is posted at
> slashdot.org
>
> Feel free to contribute comments or to answer the comments of
> non-believers. Let's make the Lisp community look alive, folks.
Ok, I saw the article and I'm taking up the reins. I want to
learn the highest-possible-level language, and from what I
understand, Lisp is the way to go. I even went out and bought
a book. Exhaustively searched the 33,000 C++, Java and MCSE
books at the bookstore, only to find the only Lisp book in
the whole place laying on the floor. "Lisp 3rd edition" by
Winston and Horn. I hope it's good.
Anyway, I want to make regular user apps with windows, dialogs,
animation, the whole bit. My question is, is there a certain
GUI library/Lisp environment that I should be looking into that
would be good for cross-platform programming, esp. for future
OS's, like when 64-bit becomes mainstream? I don't want to
write software that will become obsolete in 10 or 20 years, if
I can avoid it.
IOW, is there a library that is considered by the Lisp community
as the standard with which to program GUI apps?
Thanks
Matt Gregory
In article <··························@24.131.1.118>, Matt Gregory
<·········@nospam.com> wrote:
>Anyway, I want to make regular user apps with windows, dialogs,
>animation, the whole bit. My question is, is there a certain
>GUI library/Lisp environment that I should be looking into that
>would be good for cross-platform programming, esp. for future
>OS's, like when 64-bit becomes mainstream? I don't want to
>write software that will become obsolete in 10 or 20 years, if
>I can avoid it.
>
>IOW, is there a library that is considered by the Lisp community
>as the standard with which to program GUI apps?
i know this works against your desire for full generality from
the get-go, but could you tell us what platform you will be
developing on/for?
·············@vanderbilt.edu (Sashank Varma) wrote in
···································@129.59.212.53:
> In article <··························@24.131.1.118>, Matt Gregory
> <·········@nospam.com> wrote:
>
>>Anyway, I want to make regular user apps with windows, dialogs,
>>animation, the whole bit. My question is, is there a certain GUI
>>library/Lisp environment that I should be looking into that would be
>>good for cross-platform programming, esp. for future OS's, like when
>>64-bit becomes mainstream? I don't want to write software that will
>>become obsolete in 10 or 20 years, if I can avoid it.
>>
>>IOW, is there a library that is considered by the Lisp community as the
>>standard with which to program GUI apps?
>
> i know this works against your desire for full generality from
> the get-go, but could you tell us what platform you will be
> developing on/for?
Well, I normally use Windows 2000, but I am currently installing a
fresh copy of Linux as a dual boot and I would like to switch over
to that for development, but be able to run programs on Windows as
well. I also have a machine that runs Windows 98 because it's the
only OS that supports my MIDI patchbay, and I would like to write
some software for that, too. I should probably get a new patchbay
but they are expensive, plus all my audio software is for Windows.
I am a complete hobbyist programmer; like a jack of all trades,
master of none. I want to master something, and hope Lisp will
be worth mastering, because nothing else seems worth it. I have
been struggling with Visual Studio for a few years and it's just
way too much work to use for my casual purposes. Visual Basic
is ok, I guess, but it makes me ill. MFC is way too complicated
and legacy-design-burdened to be much help. C++ as a language
is way too complicated for my needs. C is my favorite language,
but it's just too much work to debug. All of my C programs have
tons of bugs.
Anyway, I'm excited about Lisp. It is fascinating how it maps
computer language so cleanly with the English language. Even
if it doesn't fulfill my every requirement, I will probably
learn it anyway.
Matt
Matt Gregory <·········@nospam.com> writes:
>
> Anyway, I'm excited about Lisp. It is fascinating how it maps
> computer language so cleanly with the English language. Even
> if it doesn't fulfill my every requirement, I will probably
> learn it anyway.
I sugget looking at LispWorks it runs on Windows as it does on
Linux. You can try out there personal edition visit
http://www.xanalys.com
regards
Friedrich
I don't know much about CLIM, but I think there are good
implementations of it for both GNU/Linux (and other Unices) and
MS-Windows (probably MacOS, too, and perhaps for Genera).
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
In article <··························@24.131.1.118>, Matt Gregory
<·········@nospam.com> wrote:
>Ok, I saw the article and I'm taking up the reins.
PS: Welcome aboard! Check out www.alu.org (= www.lisp.org) for
more information, including online tutorials, code collections,
etc.
Matt Gregory wrote:
> "Lisp 3rd edition" by
> Winston and Horn. I hope it's good.
IIRC that book is pre-common lisp. But it will get you going. Amazon has
a lot of books on Lisp, I think. And if high-level is your goal,
Graham's "On Lisp" is all about that.
>
> IOW, is there a library that is considered by the Lisp community
> as the standard with which to program GUI apps?
CLIM is headed that way, but I took a quick look, didn't like it.
Here is a link to a kazillion Lisp GUI projects:
http://ww.telent.net/cliki/Graphics%20Toolkit
To the extent that X is becoming a cross-platform standard, one of the
CLX projects might be the way to go.
You can defer that choice and just go with the GUI framework offered by
whichever Lisp you settle on. I know MCL and ACL come with their own
frameworks, LispWorks as well perty sure.
kenny
clinisys
Kenny Tilton <·······@nyc.rr.com> writes:
> Matt Gregory wrote:
> > "Lisp 3rd edition" by
> > Winston and Horn. I hope it's good.
>
> IIRC that book is pre-common lisp. But it will get you going. Amazon has
> a lot of books on Lisp, I think. And if high-level is your goal,
> Graham's "On Lisp" is all about that.
The Winston and Horn book has been around for a long time (1981
actually), and the original edition didn't use Common Lisp, because it
didn't exist at the time (it was just in the process of creation,
starting from 1980 and culminating in the publication of CLtL (now
called CLtL1 to distinguish it from CLtL2, which never was a
standard), the first standard for Common Lisp. The 3rd edition
(published 1989 and reprinted with corrections 1997) very definitely
uses Common Lisp, and maybe the 2nd edition (1984) did so, too.
Of course the Common Lisp isn't yet complete ANSI CL (since the ANSI
standard was only cast in stone in 1994), but it includes some amount
of post-CLtL1 stuff, like CLOS, although it doesn't yet cover the
Common Lisp Condition System or Extended LOOP.
I personally think the book is quite good, providing a cross between
something like ANSI Common Lisp by Graham, and Paradigms of AI
Programming by Norvig, by including lots of non-trivial (not in the
"very intricate" sense mathematicians like to apply to it, but rather
in the simple "slightly more complex than trivial" sense) examples.
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
My bad. thx for the correction.
kenny
clinisys
"Pierre R. Mai" wrote:
> The 3rd edition
> (published 1989 and reprinted with corrections 1997) very definitely
> uses Common Lisp, and maybe the 2nd edition (1984) did so, too.
Actually, X has almost always been cross-platform. Not only is it not
tied to any one OS, it also doesn't require any particular language.
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> writes:
> Actually, X has almost always been cross-platform. Not only is it not
> tied to any one OS, it also doesn't require any particular language.
VMS and Unix were the two primary traditional platforms.
I found it fairly surprising when I heard of an OS/390 implementation,
not so much because it would not be possible, but rather because X is
pretty "event-laden," and mainframes aren't particularly
interrupt-friendly...
Are there direct bindings out there for X for much other than C and
CL? I understand there's a Java one, but the "obvious" alternative
language, C++, seems generally set up to go through C libraries to get
at X...
--
(concatenate 'string "cbbrowne" ·@cbbrowne.com")
http://www.cbbrowne.com/info/sap.html
"By your private definition, they were poor, but who cares?. By my
private definition, you are an elm tree."
-- Mike Coffin <···@Eng.Sun.COM>
········@acm.org writes:
> Brian P Templeton <···@tunes.org> writes:
>> Actually, X has almost always been cross-platform. Not only is it not
>> tied to any one OS, it also doesn't require any particular language.
>
> VMS and Unix were the two primary traditional platforms.
>
> I found it fairly surprising when I heard of an OS/390 implementation,
> not so much because it would not be possible, but rather because X is
> pretty "event-laden," and mainframes aren't particularly
> interrupt-friendly...
>
> Are there direct bindings out there for X for much other than C and
> CL? I understand there's a Java one, but the "obvious" alternative
> language, C++, seems generally set up to go through C libraries to get
> at X...
I've heard of Emacs Lisp and Python (the language, not the CL
compiler) bindings; I think I've seen some libraries for Perl and Tcl,
but I'm not sure.
> --
> (concatenate 'string "cbbrowne" ·@cbbrowne.com")
> http://www.cbbrowne.com/info/sap.html
> "By your private definition, they were poor, but who cares?. By my
> private definition, you are an elm tree."
> -- Mike Coffin <···@Eng.Sun.COM>
--
BPT <···@tunes.org> /"\ ASCII Ribbon Campaign
backronym for Linux: \ / No HTML or RTF in mail
Linux Is Not Unix X No MS-Word in mail
Meme plague ;) ---------> / \ Respect Open Standards
Brian P Templeton <···@tunes.org> writes:
> ········@acm.org writes:
>
> > Brian P Templeton <···@tunes.org> writes:
> >> Actually, X has almost always been cross-platform. Not only is it not
> >> tied to any one OS, it also doesn't require any particular language.
> >
> > VMS and Unix were the two primary traditional platforms.
> >
> > I found it fairly surprising when I heard of an OS/390 implementation,
> > not so much because it would not be possible, but rather because X is
> > pretty "event-laden," and mainframes aren't particularly
> > interrupt-friendly...
> >
> > Are there direct bindings out there for X for much other than C and
> > CL? I understand there's a Java one, but the "obvious" alternative
> > language, C++, seems generally set up to go through C libraries to get
> > at X...
> I've heard of Emacs Lisp and Python (the language, not the CL
> compiler) bindings; I think I've seen some libraries for Perl and
> Tcl, but I'm not sure.
I'm not sure you're following the pointed part of the question...
It's not of whether or not there's some way of "doing X stuff" with
these various languages; it is whether or not there is a _direct_
binding for the language in question, that doesn't go through C, to
Xlib, with that intermediary layer.
If those bindings for Elisp and Python require having Xlib installed,
then they likely are using such intermediaries.
--
(concatenate 'string "aa454" ·@freenet.carleton.ca")
http://www3.sympatico.ca/cbbrowne/unix.html
Rules of the Evil Overlord #126. "Rather than having only one secret
escape pod, which the hero can easily spot and follow, I'll
simultaneously launch a few dozen decoys to throw him off track."
<http://www.eviloverlord.com/>
········@acm.org writes:
> Brian P Templeton <···@tunes.org> writes:
> > ········@acm.org writes:
> >
> > > Are there direct bindings out there for X for much other than C and
> > > CL? I understand there's a Java one, but the "obvious" alternative
> > > language, C++, seems generally set up to go through C libraries to get
> > > at X...
> >
> > I've heard of Emacs Lisp and Python (the language, not the CL
> > compiler) bindings; I think I've seen some libraries for Perl and
> > Tcl, but I'm not sure.
>
> I'm not sure you're following the pointed part of the question...
>
> It's not of whether or not there's some way of "doing X stuff" with
> these various languages; it is whether or not there is a _direct_
> binding for the language in question, that doesn't go through C, to
> Xlib, with that intermediary layer.
>
> If those bindings for Elisp and Python require having Xlib installed,
> then they likely are using such intermediaries.
I once saw what appeared to be the beginning of a clx for Emacs, but a
quick look through emacs lisp sites and google doesn't bring anything
up. That doesn't mean it was abandoned (*you* try to formulate that
search, yikes), but I'd guess it was, because, well, that doesn't
sound like it's worth the pain. Of course, if something were
implemented in CL, and ported to elisp, I'd hardly call it
multi-lingual :-). I'd guess that the reason there's not a C++ X
client library is because if you *can* just reuse the C peoples' work,
it's easier.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
>>>>> "tfb" == Thomas F Burdick <···@famine.OCF.Berkeley.EDU> writes:
tfb> I once saw what appeared to be the beginning of a clx for Emacs, but a
tfb> quick look through emacs lisp sites and google doesn't bring anything
tfb> up. That doesn't mean it was abandoned (*you* try to formulate that
tfb> search, yikes), but I'd guess it was, because, well, that doesn't
tfb> sound like it's worth the pain.
yep, see <URL:http://cedet.sourceforge.net/ftpgate.shtml>. It mostly
works, too.
--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>
>>>>> "TFB" == Thomas F Burdick <···@famine.OCF.Berkeley.EDU> writes:
TFB> I once saw what appeared to be the beginning of a clx for Emacs, but a
TFB> quick look through emacs lisp sites and google doesn't bring anything
TFB> up.
You are probably refering to
<URL:http://cedet.sourceforge.net/ftp/X-0.3a.tar.gz>.
TTFN,
'mr
--
rydis (Martin Rydstr|m) @CD.Chalmers.SE ; With a spirit soaring ten miles high,
<URL:http://www.cd.chalmers.se/~rydis/> ; I sing loud words that make me cry...
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
········@acm.org writes:
> If those bindings for Elisp and Python require having Xlib
> installed, then they likely are using such intermediaries.
I'm reasonably certain the Python one doesn't use Xlib. I'm also
reasonably certain that it hasn't been maintained in years, and no-one
uses it. Draw any conclusions from this you like.
Cheers,
M.
Thanks for the replies everyone. I will look into all that. I wish
"On Lisp" was still in print! I really want to read that. A book
with some philosophical and historical depth would be good right about
now.
Thanks!
Matt
Matt Gregory <·········@nospam.com> writes:
> Thanks for the replies everyone. I will look into all that. I wish
> "On Lisp" was still in print! I really want to read that. A book
> with some philosophical and historical depth would be good right
> about now.
Then get PAIP, i.e. Norvig's "Paradigms of Artificial Intelligence
Programming: Case Studies in Common Lisp". I've never understood the
fuss about On Lisp; PAIP seems to be similar in scope and better (and
still in print, I think).
Cheers,
M.
--
Q: What are 1000 lawyers at the bottom of the ocean?
A: A good start.
(A lawyer told me this joke.)
-- Michael Str�der, comp.lang.python
Michael Hudson <···@python.net> writes:
> Matt Gregory <·········@nospam.com> writes:
>
> > Thanks for the replies everyone. I will look into all that. I wish
> > "On Lisp" was still in print! I really want to read that. A book
> > with some philosophical and historical depth would be good right
> > about now.
>
> Then get PAIP, i.e. Norvig's "Paradigms of Artificial Intelligence
> Programming: Case Studies in Common Lisp". I've never understood the
> fuss about On Lisp; PAIP seems to be similar in scope and better (and
> still in print, I think).
i have both and i think they are very different.
_On Lisp_ talks mostly about macros. many short macros are given to
demonstrate small hacks and useful constructions.
_PAIP_ shows some longer (relative to paul graham) programs and gives
good examples of lisp programming. norvig does not emphasize macros.
having both is good. they have large areas which do not overlap.
if *i* had to get only one, i would choose _PAIP_. but that is mostly
because the construction of large lisp programs was more difficult for
me to grasp than creating short blurbs like a couple of defuns. ymmv.
--
J o h a n K u l l s t a m
[········@mediaone.net]
Matt Gregory <·········@nospam.com> writes:
>
> Anyway, I want to make regular user apps with windows, dialogs,
> animation, the whole bit. My question is, is there a certain
> GUI library/Lisp environment that I should be looking into that
> would be good for cross-platform programming, esp. for future
> OS's, like when 64-bit becomes mainstream?
Well I'm biased, so take it with some pounds of salt.
Every commercial Lisp comes with support for that kind of
programming. As I understand the quasi standard for that GUI stuff is
CLIM. Well it was told me from the Xanalys side that most of their
customers do use CAPI. In my opinion LispWorks offers a very good
environment and I'm using it.
>I don't want to
> write software that will become obsolete in 10 or 20 years, if
> I can avoid it.
Well I guess the "kernel" will be still around. But I guess a lot of
software is "re-written" at some point. That is a guess!
>
> IOW, is there a library that is considered by the Lisp community
> as the standard with which to program GUI apps?
I think it's CLIM.
Regards
Friedrich
Kent,
Very nice writeup about parens and historical keyword/function names.
Will you be maintaining a "frequent misconceptions" page that I could
link to?
Also, could you xpost to comp.lang.scheme when the next part comes out?
It seems of interest to both communities.
--
Bruce R. Lewis <·······@[(if (brl-related? message)
"users.sourceforge.net"
"alum.mit.edu")]> http://brl.sourceforge.net/