Hi,
Apologies for the attention grabbing title.
I'm from the UK, and self-taught as a software engineer - which
means that I've used a lot of C and Java, but have only used more
"academic" :-) languages in my spare time and, even if I had done
comp-sci, would have met Prolog and/or ML rather than Lisp.
Despite all that, I've recently decided to learn Lisp because it seems
to be one of the few languages that lets you use whatever
programming paradigm you choose, rather than forcing you in one
direction. I've ordered (and, today, received) Norvig's book on AI
which looks fascinating (I realise it may be out-of date in that it
doesn't contain "modern" AI, but it still seems like a nice book).
However - and forgive the preceding biography but it is intended to set
the ground and show this isn't flame-bait - I get the impression that
Lisp is on the way out. Now this is only a vague impression (more so
because, being in the UK which, whether we like it or not, is in Europe,
Lisp was never "in" here) - but with Harlequin going belly-up it seems
legitimate to ask: is Lisp a dying language?
If so, what is it's current level of use? And what next? Dylan?!
ML?!!! C++?!!!!!!!!!!!!!! It strikes me as a unique and very powerful
language, so what went wrong?
By "dying" I mean in decline, I would guess it's still used more than
any other "second league" language (anything other than C, C++ and maybe
Java) - but for how long?
As I hope is obvious, I would be happy to be corrected!
Thanks,
Andrew
http://www.andrewcooke.free-online.co.uk/index.html
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Andrew Cooke wrote:
...
> direction. I've ordered (and, today, received) Norvig's book on AI
> which looks fascinating (I realise it may be out-of date in that it
> doesn't contain "modern" AI, but it still seems like a nice book).
It is a good book. Time will not cause that become untrue, just give it
more cohorts.
> Lisp is on the way out. Now this is only a vague impression (more so
> because, being in the UK which, whether we like it or not, is in Europe,
> Lisp was never "in" here) - but with Harlequin going belly-up it seems
> legitimate to ask: is Lisp a dying language?
My impression is that there a plethora of factors involved in Harlequin going "belly-up".
[ I'd label it as being in intensive care, a number of people recover
from being on the critical list. That isn't quite the same as being
in the morgue.]
"Lisp", "ML", and "Dylan", the languages, in and of themselves weren't the major cause of
these problems for Harlequin. Harlequin also had an "experimental" corportate
structure, for their relative size, which I surmise was also a factor.
There are dozens of ways to run your company out of business that have nothing
to do with whether you are providing a product/service that is viable.
The "lisp business" isn't a license to print money so if you stumble across one
of the dozen you may trip and fall.
Everyone keeps pointing the figure at the Language business. I get the impression
that the margins shrank, perhaps quickly, on the printing side of house too.
( there were likely cross subsidies, but whether they were "necessary" or not
is likely debatable) Harlequin isn't a publically accountable firm so what exactly
happened is somewhat a mystery.
> By "dying" I mean in decline, I would guess it's still used more than
> any other "second league" language (anything other than C, C++ and maybe
> Java) - but for how long?
"second league"? In terms of number of lines in commerical use I
imagine Cobol puts all of the above into the "second league". It doesn't
have no where near the "hype" factor going for it though. So perhaps it is
a matter of perception.
This all has be taken in perspective. If C++ and Java grow at 50% per year and
"Lisp" grows at 20% per year is Lisp "dying"? Some will say yes. Possibly
because the "biggest herd" always wins or that the language business is some sort
of zero sum game. So growth and overall percentage is all that ever counts. Others
will say no. All ecosystems have niches; being in a niche doesn't mean you're
"dying". "Lisp" has a proven track record as a long term survivor.
IMHO, if "Harlequin" does disappear and no new competitor pops up to replace it then
"Lisp" isn't very healthly. A reasonable amount of competition keeps the vendor(s)
honest. Although "Lisp" has more then enough "external" competition to contend with.
---
Lyman
>
> IMHO, if "Harlequin" does disappear and no new competitor pops up to
replace it then
> "Lisp" isn't very healthly. A reasonable amount of competition keeps
the vendor(s)
> honest. Although "Lisp" has more then enough "external" competition to
contend with.
A Harlequin tech support representative I've been corresponding with is
under the impression that they'll be bought up soon and continue with Lisp
virtually uninterrupted.
As to the first topic, I'm just about to start a job search and have
been informed there aren't any Lisp jobs out there.
Neil Cohen
Bridge Trix
Producers of the Bobby Wolff Bridge Mentoring Series
http://www.bridgetrix.com
From: Christopher R. Barry
Subject: Re: Harlequin was: Re: Is LISP dying?
Date:
Message-ID: <87pv1z0zpg.fsf@2xtreme.net>
······@bridgetrix.com writes:
> As to the first topic, I'm just about to start a job search and have
> been informed there aren't any Lisp jobs out there.
There are hundreds of thousands of Lisp jobs out there. It's a matter
of your perspective. Just because when you look through ads all you
see is "BS with 3 years experience and strong C, C++, Perl and Java
skills..." doesn't necessarily mean that you can't use Lisp for the
job, or at least part of the job.
Also, it's easier to ask forgiveness than permission....
Christopher
On Sun, 11 Jul 1999 18:58:38 GMT, ······@2xtreme.net (Christopher R.
Barry) wrote:
>There are hundreds of thousands of Lisp jobs out there. It's a matter
>of your perspective. Just because when you look through ads all you
>see is "BS with 3 years experience and strong C, C++, Perl and Java
>skills..." doesn't necessarily mean that you can't use Lisp for the
>job, or at least part of the job.
>
>Also, it's easier to ask forgiveness than permission....
This is true. I just finished a contract job using C when what was
requested was Perl. In this particular case, my employer had no
in-house programmers, and it was easy to persuade him that a C
programmer would be easier to find down the road than a Perl
programmer. (After I convinced him that CGI scripts don't have to be
written in Perl, of course, which took some doing.)
Smaller shops are more open to this sort of thing than big corporate
installations, but there are exceptions everywhere. The ads in the
paper are often discouraging, but then again, they are often written
by HR personnel who are just repeating buzzwords.
-E.
+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+
http://members.tripod.com/~abadger
······@2xtreme.net (Christopher R. Barry) wrote:
>······@bridgetrix.com writes:
>
>> As to the first topic, I'm just about to start a job search and have
>> been informed there aren't any Lisp jobs out there.
>
>There are hundreds of thousands of Lisp jobs out there. It's a matter
>of your perspective. Just because when you look through ads all you
>see is "BS with 3 years experience and strong C, C++, Perl and Java
>skills..." doesn't necessarily mean that you can't use Lisp for the
>job, or at least part of the job.
I'm rather skeptical of the claim that there are hundreds of thousands of Lisp
jobs out there. In fact, I bet there are fewer than 50 paying lisp job openings
open this minute around the world. (I'm talking about commercial software
endeavors which are using lisp to code the software).
However I have one available and will post elsewhere in this conference.
Send resumes to (concatenate 'string "dtenny"
·@" "truesoft.com") if you want more info.
As to whether lisp is dying, I prefer to think of it as "commercially
challenged". It'll never die as long as there's interest. Finding a good
commercially supported lisp for business is getting more difficult however.
In this regard, Franz may be pricey, but their business model is probably more
solid than many lisp vendors which went before them, as evidenced by the fact
they're still around.
D. Tenny
············@mediaone.net - no spam please
From: ············@mediaone.net [···················@mediaone.net]
> Franz may be pricey, but their business model is probably more
> solid than many lisp vendors which went before them, as evidenced by
the fact
> they're still around.
> D. Tenny
what's a "business model"?
[trimmed to comp.lang.lisp]
* my-last-name wrote:
> I'm rather skeptical of the claim that there are hundreds of
> thousands of Lisp jobs out there. In fact, I bet there are fewer
> than 50 paying lisp job openings open this minute around the
> world. (I'm talking about commercial software endeavors which are
> using lisp to code the software).
Well, there may not be very many jobs which say `Lisp' in the job
description. But I use Lisp every day at work (in a commercial
environment), though no one but me knows or cares about anything other
than whether stuff gets done. Lisp gets stuff done for me...
--tim
>>>>> On Sun, 11 Jul 1999 18:58:38 GMT,
······@2xtreme.net (Christopher R. Barry) said:
Christopher> Also, it's easier to ask forgiveness than permission....
I like Eric Naggum's "Nike approach to Lisp":
No apologies. No excuses. Just do it.
--
Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
······@bridgetrix.com writes:
> As to the first topic, I'm just about to start a job search and have
> been informed there aren't any Lisp jobs out there.
Hmmm, there was a job ad on here a couple of days ago. Last time I
had a look at the offerings of a popular Job search engine over here,
I had no problem finding 3-5 jobs featuring Lisp here in Europe.
So I think there are a number of Lisp jobs out there. OTOH you
probably have to be more flexible to take advantage of them
(i.e. relocating, changing areas of interest, etc.), than for many
other languages that are a tad more popular.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
* Pierre R. Mai
| So I think there are a number of Lisp jobs out there. OTOH you probably
| have to be more flexible to take advantage of them (i.e. relocating,
| changing areas of interest, etc.), than for many other languages that are
| a tad more popular.
in my experience, which is somewhat limited, but that may actually serve
the point, certain areas of interest are best catered to by adding lots
of manpower to their solution, areas which will be "popular" in the most
obvious sense of the word, while other areas of interest will not attract
people in great spades regardless of the monetary rewards, such as those
that ask for significant dedication because of such things as very high
risks, skill requirements, entry costs, etc. if you choose one of those
areas of interest, no manager in his right mind places silly demands on
your programming language of choice and he will probably fire you if you
choose "popular" languages subject to vendors who care only about the
mass market and not about quality, unless his real plan is to fire you,
anyway, only to replace you by someone equally uncritical of his tools.
e.g., write some software to analyze the quality of the Y2K code that
really _stupid_ managers have invested in some 20 years too late and now
have lost control over to the point where the solution (fixing broken
code with new, largely untested code written by the kind of people who
think there's nothing wrong with ripping really stupid people off) opens
up for even more costly problems than the problem. if you can manage to
write software that can identify vulnerabilities in newly added code by
the turn of the century, such that people can use your tool to prepare
counter-attacks or invest in security measures or schedule time in the
court system when they know whom to sue for what and how much, you could
stand to make more money in the remaining 167 days than you could in the
whole of the next millennium.
solution: find areas of interest not invaded by populistic opportunists.
my suggestion is to avoid _any_ area where the solution space is covered
by existing code. on the other hand, generalizations where people make
do with "menial" systems because of too varying requirements may be a
good place to introduce intelligent programming languages. e.g., while
accounting and finance are pretty well known areas, you could figure out
a way to plan for budget reallocation according as political conditions
change (such as taxes) -- frightening amounts of human intelligence are
wasted on beating the idiots who change the rules all the time. such a
tool might also help the idiots in power "visualize" the likely effects
of their many proposals, which _might_ help us get less political idiocy
beta-tested using people's lives.
is it still "artificial intelligence" when the task is to model human
stupidity, or would only preventing its devastating consequences get an
"AI" rating?
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
Erik Naggum <····@naggum.no> wrote in message
·····················@naggum.no...
> solution: find areas of interest not invaded by populistic opportunists.
> my suggestion is to avoid _any_ area where the solution space is covered
> by existing code. on the other hand, generalizations where people make
> do with "menial" systems because of too varying requirements may be a
> good place to introduce intelligent programming languages. e.g., while
> accounting and finance are pretty well known areas, you could figure out
> a way to plan for budget reallocation according as political conditions
> change (such as taxes) -- frightening amounts of human intelligence are
> wasted on beating the idiots who change the rules all the time. such a
> tool might also help the idiots in power "visualize" the likely effects
> of their many proposals, which _might_ help us get less political idiocy
> beta-tested using people's lives.
You assume, of course, that the people with their fingers on the budget
actually care about the fiscal consequences of their actions on common
people's lives and that they could be swayed by being shown these negative
consequences. In my experience, this is not likely.
> is it still "artificial intelligence" when the task is to model human
> stupidity, or would only preventing its devastating consequences get an
> "AI" rating?
I'd call it AI, but (sadly) worthless in practice. But then, I'm a cynic.
Frank A. Adrian
* "Frank A. Adrian" <·······@uswest.net>
| You assume, of course, that the people with their fingers on the budget
| actually care about the fiscal consequences of their actions on common
| people's lives and that they could be swayed by being shown these negative
| consequences. In my experience, this is not likely.
no, I assume that they care only about tax revenue, and that those who
produce the tax revenue (i.e., companies) care about their customers and
the cost of hiring people, which, in the nth degree, means caring about
the consequences for common people, but it's the "nth degree" thing that
far exceeds the mental capacity of those who make political decisions.
introducing AI to such problems doesn't seem entirely bogus to me. my
point was, however, not to go and do this, but to think in different
terms, so maybe somebody out there might get an idea for how to help make
budget reallocations in accounting software based on the decisions of
politicians, to minimize the effects of their decisions immediately,
instead of through getting burned and then trial and error, which is how
it happens today, often with devastating secondary effects, such as whole
companies folding or whole markets drying out.
| But then, I'm a cynic.
no problem. cynics are the only people who can deal with reality. the
key is to let the right cynics set up the fantasies that people want to
live. (yeah, I've seen the Matrix, but this is a different angle. :)
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
In article <·······················@isdn5-67.ip.realtime.net>,
<······@bridgetrix.com> wrote:
(snip)
> As to the first topic, I'm just about to start a job search and have
>been informed there aren't any Lisp jobs out there.
Hey, I use some Modula-3 in my current job, and also write Modula-3 as
a consultant to another place, and I would bet that Common Lisp is
much 'bigger' than M3! (-: Quite simply, you just have to find jobs
where your employers are more interested in the fact that you're
solving their problems than in imposing their half-baked notions of
the best way to go about it. So, if you don't find any Lisp jobs, look
for flexible software-development posts. If you can demonstrate decent
software you've already written, that goes a long way.
(Just be verbose in your comments, etc. to help colleagues with little
Lisp knowledge work on the code if they have to!)
This is fairly general, so fu set to c.l.m only.
-- Mark
Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
> However - and forgive the preceding biography but it is intended to set
> the ground and show this isn't flame-bait - I get the impression that
> Lisp is on the way out. Now this is only a vague impression (more so
> because, being in the UK which, whether we like it or not, is in Europe,
> Lisp was never "in" here) - but with Harlequin going belly-up it seems
> legitimate to ask: is Lisp a dying language?
It's one of the oldest languages still in active use. Many
organizations and individuals are still using it. There are several
free implementations, including one in the public domain that is rather
good, and still several commercial vendors.
So, it has more commercial implementations than perl, python, and tcl,
put together. It's an ANSI standard (CommonLisp that is). It has
more free implementations than just about any other language except
scheme (a member of the Lisp family itself).
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
I say woe unto those who are wise in their own eyes, and yet
imprudent in 'dem outside -Sizzla
Craig Brozefsky <·····@red-bean.com> writes:
>
> So, it has more commercial implementations than perl, python, and tcl,
> put together. It's an ANSI standard (CommonLisp that is). It has
> more free implementations than just about any other language except
> scheme (a member of the Lisp family itself).
<offtopic and doesn't really matter, but anyways>
I would guess there are more Forths than Schemes.
-Andi
--
This is like TV. I don't like TV.
Andi Kleen <·····@muc.de> wrote:
+---------------
| I would guess there are more Forths than Schemes.
+---------------
Really??? There are dozens & dozens of Schemes[*] that *I* know of...
How many Forths are there? Even a dozen?
-Rob
[*] This is one of the frequent criticisms of Scheme! ;-}
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
In article <············@fido.engr.sgi.com>, ····@rigden.engr.sgi.com
says...
> Really??? There are dozens & dozens of Schemes[*] that *I* know of...
> How many Forths are there? Even a dozen?
If we only count the systems that a single programmer knows, we might
dismiss any language as irrelevant. The numbers argument is always a
weak one (see my final point, below). The numbers only matter when you
can count the number of implementations on the fingers of one hand and
such implementations require considerable effort to create.
I've known Forth programmers who create a Forth just like sneezing. I
wouldn't be suprised if there are Scheme implementors who can do the
same thing, but in Forth there's a very fine line between using Forth
and implementing Forth. (It used to take me about 3 weeks to create a
Forth from scratch, and I'm no expert.) In Lisp, we tend to build the
language up rather than down. In Forth, we go up _and_ down.
Glancing over my monitor at my bookcase, I spy a book that features a
series of Scheme implementations, none of them very big. If we're
talking about commercial and freeware Forths, that's another matter.
Systems like that tend to need documentation.
It looks to me like Forth is as much in decline as Common Lisp and
Scheme, and neither language is in danger of dying. Perhaps we should
be counting programmers instead of systems, but that's much harder to
do. Comparing web/ftp logs might be easier.
All I know is, everytime somebody asks if (or claims that) a language
is dead, dozens of programmers jump up and shout about how healthy it
is, and how many people are using it. Then somebody mentions Cobol.
--
Remove insect from address | You can never browse enough
will write code that writes code that writes code for food
On 11 Jul 1999 10:11:19 GMT, Rob Warnock wrote:
>Andi Kleen <·····@muc.de> wrote:
>+---------------
>| I would guess there are more Forths than Schemes.
>+---------------
>Really??? There are dozens & dozens of Schemes[*] that *I* know of...
>How many Forths are there? Even a dozen?
Grin... There's at least one Forth for every Forth programmer. It's
almost a rite of passage -- to be a Forth programmer you have to implement
your own Forth. Preferably experimental in nature, but otherwise
compatible.
With the arrival of ANSI this slowed down; now that Chuck's mentioned
Machine Forth it's sped back up again.
>-Rob
--
-William "Billy" Tanksley
On 11 Jul 1999 10:11:19 GMT, Rob Warnock <····@rigden.engr.sgi.com> posted:
>Andi Kleen <·····@muc.de> wrote:
>+---------------
>| I would guess there are more Forths than Schemes.
>+---------------
>
>Really??? There are dozens & dozens of Schemes[*] that *I* know of...
>How many Forths are there? Even a dozen?
There were a half-dozen Forths for Atari 8 bit, and about a half-dozen
for Atari ST.
I count 28 distinct implementations at
<http://www.forth.org/compilers.html>, and that list is decidedly not
comprehensive.
--
Lisp Users:
Due to the holiday next Monday, there will be no garbage collection.
········@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
Christopher B. Browne wrote:
>
> On 11 Jul 1999 10:11:19 GMT, Rob Warnock <····@rigden.engr.sgi.com> posted:
> >Andi Kleen <·····@muc.de> wrote:
> >+---------------
> >| I would guess there are more Forths than Schemes.
> >+---------------
> >
> >Really??? There are dozens & dozens of Schemes[*] that *I* know of...
> >How many Forths are there? Even a dozen?
>
> There were a half-dozen Forths for Atari 8 bit, and about a half-dozen
> for Atari ST.
>
> I count 28 distinct implementations at
> <http://www.forth.org/compilers.html>, and that list is decidedly not
> comprehensive.
I have Forth for the AIM-65 in ROM, SYM-1 on tape, and FOCAL (a sort-of
Forth) for KIM-1. Also Aforth standalone for Z-80. Lately, I haven't
seen them on any list.
> --
> Lisp Users:
> Due to the holiday next Monday, there will be no garbage collection.
> ········@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
--
Engineering is the art | Let's talk about what
of making what you want | you need; you may see
from things you can get. | how to do without it.
---------------------------------------------------------
Jerry Avins <·······@erols.com> wrote:
+---------------
| I have Forth for the AIM-65 in ROM, SYM-1 on tape, and FOCAL (a sort-of
| Forth) for KIM-1...
+---------------
Uh... Having ported Doug Wrege's version of PDP-8 FOCAL/F to the PDP-10
Spring 1971, I can say with some confidence that FOCAL isn't even *vaguely*
Forth-like -- it's much closer to JOSS & MUMPS, and in fact, was developed
by Richey Lary following his participation in the first installation of
MUMPS at Mass Gen. While (old, original) MUMPS had "string" as it's only
data type (like Tcl), FOCAL had "floating point" as its only data type.
(In fact, mutable "strings" were emulated with arrays of floating-point
numbers, each array element representing one character.)
Like JOSS & MUMPS & BASIC & FORTRAN -- but unlike Forth -- FOCAL has
traditional infix arithmetic with "the usual" operator priorities,
that is, the assignment "SET A=B+C*4.35-D/2.468" is interpreted as
"SET A=((B+(C*4.35))-(D/2.468))".
-Rob
p.s. My FOCAL-10 port involved some serious rewriting of the internal
FOCAL lexical subroutines SORTC & SORTJ to become two-instruction macros
that made heavy use of the PDP-10 byte pointer stuff and "byte strips"
to encode enumerated character equivalence classes. (Hey, it made it
run 25 times faster!) It used some really hairy "MACRO-10" (the PDP-10
assembler) macros to build those tables at compile time. Imagine my
immense delight when I was exposed to Common Lisp and learned that:
1. The style of table-building I'd been writing in PDP-10 assembler
could be done *much* more naturally -- almost trivially, in fact --
with Lisp macros; and
2. That Common Lisp had preserved at least a little of the flavor of
the PDP-10 variable-sized byte operations... with the same names,
even: LDB, DPB, BYTE, BYTE-SIZE, BYTE-POSITION. Way cool!
I just wish I'd gotten into Lisp 20 years earlier than I did... (*sigh*)
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Rob Warnock wrote:
>
> Jerry Avins <·······@erols.com> wrote:
> +---------------
> | I have Forth for the AIM-65 in ROM, SYM-1 on tape, and FOCAL (a sort-of
> | Forth) for KIM-1...
> +---------------
>
> Uh... Having ported Doug Wrege's version of PDP-8 FOCAL/F to the PDP-10
> Spring 1971, I can say with some confidence that FOCAL isn't even *vaguely*
> Forth-like -- it's much closer to JOSS & MUMPS, and in fact, was developed
> by Richey Lary following his participation in the first installation of
> MUMPS at Mass Gen. While (old, original) MUMPS had "string" as it's only
> data type (like Tcl), FOCAL had "floating point" as its only data type.
> (In fact, mutable "strings" were emulated with arrays of floating-point
> numbers, each array element representing one character.)
>
> Like JOSS & MUMPS & BASIC & FORTRAN -- but unlike Forth -- FOCAL has
> traditional infix arithmetic with "the usual" operator priorities,
> that is, the assignment "SET A=B+C*4.35-D/2.468" is interpreted as
> "SET A=((B+(C*4.35))-(D/2.468))".
>
> -Rob
>
> p.s. My FOCAL-10 port involved some serious rewriting of the internal
> FOCAL lexical subroutines SORTC & SORTJ to become two-instruction macros
> that made heavy use of the PDP-10 byte pointer stuff and "byte strips"
> to encode enumerated character equivalence classes. (Hey, it made it
> run 25 times faster!) It used some really hairy "MACRO-10" (the PDP-10
> assembler) macros to build those tables at compile time. Imagine my
> immense delight when I was exposed to Common Lisp and learned that:
>
> 1. The style of table-building I'd been writing in PDP-10 assembler
> could be done *much* more naturally -- almost trivially, in fact --
> with Lisp macros; and
>
> 2. That Common Lisp had preserved at least a little of the flavor of
> the PDP-10 variable-sized byte operations... with the same names,
> even: LDB, DPB, BYTE, BYTE-SIZE, BYTE-POSITION. Way cool!
>
> I just wish I'd gotten into Lisp 20 years earlier than I did... (*sigh*)
>
> -----
> Rob Warnock, 8L-855 ····@sgi.com
> Applied Networking http://reality.sgi.com/rpw3/
> Silicon Graphics, Inc. Phone: 650-933-1673
> 1600 Amphitheatre Pkwy. FAX: 650-933-0511
> Mountain View, CA 94043 PP-ASEL-IA
Rob,
I remember a Forth-like program I ran on the KIM, sitting at the
teletype in my kid's room working out algorithms to move an NC machine
in arbitrary circular arcs. I remember being annoyed because it seemed
that the major difference from Forth was the renaming of words just to
be different. My recollection that it was called Focal is evidently
faulty. Does anyone know what it might have been? (I had a video RAM on
that KIM, connected to a small TV monitor so I could plot the
trajectories. It was a better machine for my purpose than the mainframe
at work.)
Jerry
--
Engineering is the art | Let's talk about what
of making what you want | you need; you may see
from things you can get. | how to do without it.
---------------------------------------------------------
Rob Warnock wrote:
>Like JOSS & MUMPS & BASIC & FORTRAN -- but unlike Forth -- FOCAL has
>traditional infix arithmetic with "the usual" operator priorities,
>that is, the assignment "SET A=B+C*4.35-D/2.468" is interpreted as
>"SET A=((B+(C*4.35))-(D/2.468))".
This must be totally off-topic, but...
I thought I had read that one of the peculiarities of MUMPS is that the
was NO operator precedence? That everything was just executed from left
to right? That, therefore,
SET A=B+C*4.35-D/2.468
would be interpreted as
SET A=(((B+C)*4.35)-D)/2.468
?
Bart.
Bart Lateur wrote:
>I thought I had read that one of the peculiarities of MUMPS is that the
>was NO operator precedence? That everything was just executed from left
>to right? That, therefore,
>
> SET A=B+C*4.35-D/2.468
>
>would be interpreted as
>
> SET A=(((B+C)*4.35)-D)/2.468
>
>?
Somebody suggested (by e-mail) that I must have been thinking about
another language. Well, I looked it up. Here it is:
M[UMPS] by example: operators
http://www.jacquardsystems.com/Examples/operator.htm
I quote:
M[UMPS] evaluates strictly from left to right, so that 1+1*2
yields 4 and not 3.
Bart.
Bart Lateur <···········@skynet.be> wrote:
+---------------
| M[UMPS] by example: operators
| http://www.jacquardsystems.com/Examples/operator.htm
+---------------
Thanks for the pinter!
+---------------
| M[UMPS] evaluates strictly from left to right, so that 1+1*2
| yields 4 and not 3.
+---------------
Well, what can I say?!? FOCAL *was* inspired directly by MUMPS, yet
it *did* have operator precedence, for arithmetic exprs at least --
I remember coding that part of FOCAL-10 as direct transliteration
of the FOCAL/F code. There was a separate small data stack for
intermediate results. (And a FOCAL-in-C snarfed off the net some
time ago agrees, too.)
Oh, well...
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Bart Lateur <···········@skynet.be> wrote:
+---------------
| M[UMPS] by example: operators
| http://www.jacquardsystems.com/Examples/operator.htm
+---------------
Thanks for the pointer!
+---------------
| M[UMPS] evaluates strictly from left to right, so that 1+1*2
| yields 4 and not 3.
+---------------
Well, what can I say?!? FOCAL *was* inspired directly by MUMPS, yet
it *did* have operator precedence, for arithmetic exprs at least --
I remember coding that part of FOCAL-10 as direct transliteration
of the FOCAL/F code. There was a separate small data stack for
intermediate results. (And a FOCAL-in-C snarfed off the net some
time ago agrees, too.)
Oh, well...
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Christopher B. Browne wrote:
> On 11 Jul 1999 10:11:19 GMT, Rob Warnock <····@rigden.engr.sgi.com
> posted:
> >Andi Kleen <·····@muc.de> wrote:
> >+---------------
> >| I would guess there are more Forths than Schemes.
> >+---------------
> >Really??? There are dozens & dozens of Schemes[*] that *I* know of...
> >How many Forths are there? Even a dozen?
> There were a half-dozen Forths for Atari 8 bit, and about a half-dozen
> for Atari ST.
> I count 28 distinct implementations at
> <http://www.forth.org/compilers.html>, and that list is decidedly not
> comprehensive.
There are roughly a hundred versions of Forth that you can
get copies of. If you have a need for a special version of
Forth,
mention it on comp.lang.forth, and somebody will offer to send
you a copy of his unpublished version that he never got around
to
finishing. Counting versions is not the way to tell the health
of
a computer language. Count the number of textbooks on the
shelves
of bookstores intead. I conclude that Lisp and Scheme are still
alive with about half to one third as many books as Fortran,
while Fortran has about one tenth as many books as the big guys
like C, Java, Visual Basic and C++. Forth comes out at zero.
When I meet people who tell me they want to learn all
about computing, including programming, I want to say learn
Forth. But I know that woun't work since they can't even go
to the bookstore and buy a book about it. Well at least they
can still get some nice books about Logo to get then started.
--
Michael Coughlin ··········@ne.mediaone.net Cambridge, MA USA
--------------C7E14BF3D1C60B539428F583
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Michael Coughlin wrote:
> There are roughly a hundred versions of Forth that you can
> get copies of. If you have a need for a special version of
> Forth,
> mention it on comp.lang.forth, and somebody will offer to send
> you a copy of his unpublished version that he never got around
> to
> finishing. Counting versions is not the way to tell the health
What would be cool would be an Open Sourced OpenFirmware.
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
--------------C7E14BF3D1C60B539428F583
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Michael Coughlin wrote:
<blockquote TYPE=CITE> There are roughly a hundred
versions of Forth that you can
<br>get copies of. If you have a need for a special version of
<br>Forth,
<br>mention it on comp.lang.forth, and somebody will offer to send
<br>you a copy of his unpublished version that he never got around
<br>to
<br>finishing. Counting versions is not the way to tell the health</blockquote>
What would be cool would be an Open Sourced OpenFirmware.
<pre>--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html</pre>
</html>
--------------C7E14BF3D1C60B539428F583--
Michael Coughlin wrote in message <·················@ne.mediaone.net>...
>... Counting versions is not the way to tell the health
>of
>a computer language. Count the number of textbooks on the
>shelves
>of bookstores intead. I conclude that Lisp and Scheme are still
>alive with about half to one third as many books as Fortran,
>while Fortran has about one tenth as many books as the big guys
>like C, Java, Visual Basic and C++. Forth comes out at zero.
>
> When I meet people who tell me they want to learn all
>about computing, including programming, I want to say learn
>Forth. But I know that woun't work since they can't even go
>to the bookstore and buy a book about it. Well at least they
>can still get some nice books about Logo to get then started.
Is Amazon a bookstore? Several Forth books there.
Cheers,
Elizabeth
Elizabeth D Rather wrote:
> Michael Coughlin wrote in message <·················@ne.mediaone.net>...
> >... Counting versions is not the way to tell the health
> >of a computer language. Count the number of textbooks on
> >the shelves of bookstores intead. I conclude that Lisp
> >and Scheme are still alive with about half to one third
> >as many books as Fortran, while Fortran has about one tenth
> >as many books as the big guys like C, Java, Visual Basic
> >and C++. Forth comes out at zero.
> > When I meet people who tell me they want to learn all
> >about computing, including programming, I want to say learn
> >Forth. But I know that woun't work since they can't even go
> >to the bookstore and buy a book about it. Well at least they
> >can still get some nice books about Logo to get then
> >started.
> Is Amazon a bookstore? Several Forth books there.
Amazon is not a bookstore. You can't drop in and
browse. If you don't know what Forth is, or think that Forth
isn't used anymore, you woun't notice a book about it by
accident when you're looking for some other topic on
programming. You can't just buy a book because you have it
in your hot little hand and it looks interesting. You can't
wrap it up and take it right home. People who don't even have an
account to access amazon.com and the web are the easiest to
influence to at least take a look at Forth. They have not
learned the bad habits of other programming languages and can
immediately appreciate the advantages of Forth.
I just looked for Forth books on amazon.com. Yes there
are several listings. There is only one listed as being in
print, and they say expect delivery within 4 to 6 weeks. There
are also listings for books by Leo Brodie. When I clicked on
"Thinking Forth" I got nothing but a system error. There are
five separate listings for Leo Brodie's book -- "Starting
Forth". That's reasonable since it is at least five times better
than the average book on programming. But its out of print. Its
available only by a special search. It will take them weeks to
find it or tell you if its not available. They don't tell you to
get it faster from the Forth Interest Group in California,
http://www.fig.org/ (at least until their special printing runs
out). Relying on amazon.com to sell Forth textbooks is not a
good thing. It would be better to have a publisher promoting the
book and getting it into bookstores.
Elizabeth Rather is much too shy and modest. She failed to
mention her own book the "Forth Programmers' Handbook". So I'll
tell everyone that it is the one Forth textbook that is in print
and for sale at amazon.com. When I go to my local technical
bookstores to see if it has finally arrived on the shelves (it
hasn't), I find instead books on the equally neglected computer
languages Lisp, Scheme and Logo. I think that Lisp and its
relatives are much more lively than Forth since they still have
recently revised textbooks for sale. Since Forth is still being
used, I can deduce that Lisp is still being used, even tho I
don't know where. But how long will Forth last without at least
a few easily found textbooks?
I wish old Forth programmers would become inspired by Lisp
programmers to write textbooks so they would be able to train
their replacements.
--
Michael Coughlin ··········@ne.mediaone.com Cambridge, MA USA
Michael Coughlin wrote:
>
> Elizabeth D Rather wrote:
>
> > Michael Coughlin wrote in message <·················@ne.mediaone.net>...
> > >... Counting versions is not the way to tell the health
> > >of a computer language.
...
>
> > Is Amazon a bookstore? Several Forth books there.
>
> Amazon is not a bookstore. You can't drop in and
> browse.
...
> I just looked for Forth books on amazon.com. Yes there
> are several listings. There is only one listed as being in
> print, and they say expect delivery within 4 to 6 weeks.
Amazon always says "4 to 6 weeks", even if they know that the shipment
will arrive tomorrow. Does it take them that long to reprogram their
computer?
...
> --
> Michael Coughlin ··········@ne.mediaone.com Cambridge, MA USA
Jerry
--
Engineering is the art | Let's talk about what
of making what you want | you need; you may see
from things you can get. | how to do without it.
---------------------------------------------------------
In article <·············@ieee.org>, Jerry Avins <·······@erols.com> wrote:
(snip)
>Amazon always says "4 to 6 weeks", even if they know that the shipment
>will arrive tomorrow. Does it take them that long to reprogram their
>computer?
(snip)
Nonsense - that's been by far the minority of books I've ordered from
them - for instance, the first language book that I could think of,
"C: A Reference Manual", is claimed to ship in two to three days.
Certainly, number of in-print books and their expected delivery time
is not a bad way of getting a first estimate for the 'health' of a
language! Counting the number of currently-supported compilers you
could use to produce marketable software isn't a bad one either.
[ followups trimmed ]
-- Mark
On Wed, 14 Jul 1999 13:31, Michael Coughlin <··········@ne.mediaone.net> wrote:
> [...]
>get it faster from the Forth Interest Group in California,
>http://www.fig.org/ (at least until their special printing runs
> [...]
The URL should be <http://www.forth.org/> rather than the above.
Mark
--
Mark K. Gardner (········@cs.uiuc.edu)
University of Illinois at Urbana-Champaign
Real-Time Systems Laboratory
--
Michael Coughlin wrote:
>
> Elizabeth D Rather wrote:
>
[snipp]
> Since Forth is still being
> used, I can deduce that Lisp is still being used, even tho I
> don't know where.
[snipp]
In EMACS, of course (if you're talking about the language
with the parentheses :-).
Csaba
--
Csaba Raduly, Software Developer (OS/2), Sophos Anti-Virus
···················@sophos.com http://www.sophos.com/
US Support +1 888 SOPHOS 9 UK Support +44 1235 559933
Life is complex, with real and imaginary parts.
On Thu, 15 Jul 1999 18:57:07 +0100, Csaba Raduly <············@sophos.com> wrote:
>In EMACS, of course (if you're talking about the language
>with the parentheses :-).
EMACS is making the transition to Scheme, I believe, because of a simpler
(read: easier to maintain) implementation. Also, the GIMP uses Scheme as
its native scripting language.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
Oceanside, CA |......................................................
······@dolphin.openprojects.net (Samuel A. Falvo II) writes:
> On Thu, 15 Jul 1999 18:57:07 +0100, Csaba Raduly <············@sophos.com> wrote:
> >In EMACS, of course (if you're talking about the language
> >with the parentheses :-).
>
> EMACS is making the transition to Scheme, I believe, because of a simpler
> (read: easier to maintain) implementation.
You have obviously never taken a look at eval.c in Guile. I'm not
sure you could argue that it simplifies anything.
It is a ways off before we see guile in emacs. Year minimum.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
I say woe unto those who are wise in their own eyes, and yet
imprudent in 'dem outside -Sizzla
On 15 Jul 1999 12:08:35 -0500, Craig Brozefsky <·····@red-bean.com> wrote:
>······@dolphin.openprojects.net (Samuel A. Falvo II) writes:
>
>> On Thu, 15 Jul 1999 18:57:07 +0100, Csaba Raduly <············@sophos.com> wrote:
>>
>> EMACS is making the transition to Scheme, I believe, because of a simpler
>> (read: easier to maintain) implementation.
>
>You have obviously never taken a look at eval.c in Guile. I'm not
>sure you could argue that it simplifies anything.
I may just be muddying the waters, but I read Csaba's comment as meaning
that it's easier to implement Emacs in Scheme than in Lisp, and Craig's as
that it's no easier to implement Scheme than Lisp. These seem to be at
cross-purposes.
--
http://sc3d.org/rrt/ | certain, a. insufficiently analysed
* ···@persephone.joh.cam.ac.uk (Reuben Thomas)
| I may just be muddying the waters, but I read Csaba's comment as meaning
| that it's easier to implement Emacs in Scheme than in Lisp, and Craig's as
| that it's no easier to implement Scheme than Lisp. These seem to be at
| cross-purposes.
of course it's easier to implement Emacs in Guile than in C, but Guile is
implemented in C, which makes it much harder to implement Emacs. because
any Scheme used in the real world will accumulate approximately 6 billion
special-purpose functions that do very small things because Scheme does
not support abstractions conveniently and nobody can agree on how to do
it inconveniently, Guile will do a full circle and be approximately 360
times bigger than Common Lisp (except all the OO stuff will be glued on
inefficiently, because OO is complex and Scheme is simple and elegant or
so says the book, therefore the OO stuff is always too complex, so yet
another attempt is always needed as soon as the last attempt approaches
useful asymptotically from below), with cultural differences in naming
and argument conventions and such, and then someone will come along and
write a Common Lisp layer on top of everything, just like cl.el because
Emacs Lisp actually sucks, but at least we know _how_ it sucks, unlike
Guile, which will suck in entirely new, and much improved, ways.
also, Emacs is easier to implement in Guile because it hasn't actually
been done, whereas we know exactly how hard it was to do it in C and a
dynamically scoped Lisp (and nobody will ever do _that_ again, which also
means it's trivially easier to do it Guile, simply because someone is
actually trying to do that.) and obviously, whoever thought it would be
easier had ignored the fact that Guile Emacs needs to implement Emacs
Lisp, too, considering the millions of lines of really crappy Emacs Lisp
out there that gets run at completely random times because it has wound
up in default.el and .emacs and such, having been copied all over the
globe across amazingly lossy connections that each introduce a minor
mistake on every copy, and equally amazingly, doesn't work at all from
version to version of Emacs, or from the system admin's equally messed up
changes to default.el from week to week as users complain. oh, joy!
this is Emacs. this is Guile. this is Emacs on Guile. any questions?
#:Erik, who thinks Guile is a bigger mistake than MULE
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
Erik Naggum wrote:
> ... considering the millions of lines of really crappy Emacs Lisp
> out there that gets run at completely random times because it has wound
> up in default.el and .emacs and such, having been copied all over the
> globe across amazingly lossy connections that each introduce a minor
> mistake on every copy, and equally amazingly, doesn't work at all from
> version to version of Emacs, or from the system admin's equally messed up
> changes to default.el from week to week as users complain. oh, joy!
>
> this is Emacs. this is Guile. this is Emacs on Guile. any questions?
Is Emacs actually a retro-virus? (as in a living organism type thing and not a
computer program to show what a lousy operating MS write). All it need to do now
is replicate itself and excrete and you would have 'Attack of the 50" Emacs.' or
something.
:-) will
Samuel A. Falvo II <······@dolphin.openprojects.net> wrote:
+---------------
| Also, the GIMP uses Scheme as its native scripting language.
+---------------
Yeah, but didn't they use "SIOD" as their Scheme?
*Old* syntax, no where near R[45]RS...
-Rob
p.s. Don't get me wrong, SIOD is nice & small, and *fast*-starting.
But picking it for the scripting base of a new tool and then saying
"uses Scheme" makes about as much sense as picking (say) Lisp 1.6 and
then saying "Hey, what are you CL guys complaining about, we used Lisp"...
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
For what it's worth I ordered The Forth Programmer's Handbook directly from
Forth. Inc (www.forth.inc) on Wednesday and it's been sitting on my desk
since this morning. (Friday). So it's available and it looks pretty good so
far.
Barry
Michael Coughlin <··········@ne.mediaone.net> wrote in message
······················@ne.mediaone.net...
> Elizabeth D Rather wrote:
>
> > Michael Coughlin wrote in message <·················@ne.mediaone.net>...
> > >... Counting versions is not the way to tell the health
> > >of a computer language. Count the number of textbooks on
> > >the shelves of bookstores intead. I conclude that Lisp
> > >and Scheme are still alive with about half to one third
> > >as many books as Fortran, while Fortran has about one tenth
> > >as many books as the big guys like C, Java, Visual Basic
> > >and C++. Forth comes out at zero.
>
> > > When I meet people who tell me they want to learn all
> > >about computing, including programming, I want to say learn
> > >Forth. But I know that woun't work since they can't even go
> > >to the bookstore and buy a book about it. Well at least they
> > >can still get some nice books about Logo to get then
> > >started.
>
> > Is Amazon a bookstore? Several Forth books there.
>
> Amazon is not a bookstore. You can't drop in and
> browse. If you don't know what Forth is, or think that Forth
> isn't used anymore, you woun't notice a book about it by
> accident when you're looking for some other topic on
> programming. You can't just buy a book because you have it
> in your hot little hand and it looks interesting. You can't
> wrap it up and take it right home. People who don't even have an
> account to access amazon.com and the web are the easiest to
> influence to at least take a look at Forth. They have not
> learned the bad habits of other programming languages and can
> immediately appreciate the advantages of Forth.
>
> I just looked for Forth books on amazon.com. Yes there
> are several listings. There is only one listed as being in
> print, and they say expect delivery within 4 to 6 weeks. There
> are also listings for books by Leo Brodie. When I clicked on
> "Thinking Forth" I got nothing but a system error. There are
> five separate listings for Leo Brodie's book -- "Starting
> Forth". That's reasonable since it is at least five times better
> than the average book on programming. But its out of print. Its
> available only by a special search. It will take them weeks to
> find it or tell you if its not available. They don't tell you to
> get it faster from the Forth Interest Group in California,
> http://www.fig.org/ (at least until their special printing runs
> out). Relying on amazon.com to sell Forth textbooks is not a
> good thing. It would be better to have a publisher promoting the
> book and getting it into bookstores.
>
> Elizabeth Rather is much too shy and modest. She failed to
> mention her own book the "Forth Programmers' Handbook". So I'll
> tell everyone that it is the one Forth textbook that is in print
> and for sale at amazon.com. When I go to my local technical
> bookstores to see if it has finally arrived on the shelves (it
> hasn't), I find instead books on the equally neglected computer
> languages Lisp, Scheme and Logo. I think that Lisp and its
> relatives are much more lively than Forth since they still have
> recently revised textbooks for sale. Since Forth is still being
> used, I can deduce that Lisp is still being used, even tho I
> don't know where. But how long will Forth last without at least
> a few easily found textbooks?
> I wish old Forth programmers would become inspired by Lisp
> programmers to write textbooks so they would be able to train
> their replacements.
>
> --
> Michael Coughlin ··········@ne.mediaone.com Cambridge, MA USA
>
Michael Coughlin <··········@ne.mediaone.net> wrote:
> I conclude that Lisp and Scheme are still
> alive with about half to one third as many books as Fortran,
> while Fortran has about one tenth as many books as the big guys
> like C, Java, Visual Basic and C++. Forth comes out at zero.
So, can you recommend any of those "zero" books? I've never used Forth
and I'm not sure I ever will. I'm much more attracted to languages from
the Lisp family -- nonetheless, my curiousity has slowly grown over the
years.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
Michael Schuerig wrote:
>
> Michael Coughlin <··········@ne.mediaone.net> wrote:
>
> > I conclude that Lisp and Scheme are still
> > alive with about half to one third as many books as Fortran,
> > while Fortran has about one tenth as many books as the big guys
> > like C, Java, Visual Basic and C++. Forth comes out at zero.
>
> So, can you recommend any of those "zero" books? I've never used Forth
> and I'm not sure I ever will. I'm much more attracted to languages from
> the Lisp family -- nonetheless, my curiousity has slowly grown over the
> years.
>
> Michael
>
> --
> Michael Schuerig
> ···············@acm.org
> http://www.schuerig.de/michael/
Look at http://erwin.phys.virginia.edu/classes/551/primer.txt That
should get you started.
Jerry
--
Engineering is the art | Let's talk about what
of making what you want | you need; you may see
from things you can get. | how to do without it.
---------------------------------------------------------
Michael Schuerig wrote:
> Michael Coughlin <··········@ne.mediaone.net> wrote:
> > I conclude that Lisp and Scheme are still
> > alive with about half to one third as many books as Fortran,
> > while Fortran has about one tenth as many books as the
> > big guys like C, Java, Visual Basic and C++. Forth comes
> > out at zero.
> So, can you recommend any of those "zero" books? I've never
> used Forth and I'm not sure I ever will. I'm much more
> attracted to languages from the Lisp family -- nonetheless,
> my curiousity has slowly grown over the years.
There are many sources of knowledge about Forth for an
experienced computer user and net surfer. The problem I'm always
complaining about is the lack of Forth instructional material
for complete computer novices. I think this lack of interest in
providing new beginners material lowers the quality and quantity
of tutorial material for all levels of Forth.
The best book I've ever seen on programming for any
language was written for Forth -- "Starting Forth" by Leo
Brodie. Unfortunately this is out of print and available only
thru special order; its not on the shelf of bookstores like it
was for over ten years. There is one new book on Forth for
experienced programmers available from Amazon.com (not
bookstores) and also Forth Inc (http://www.forth.com). Of the
very roughly 100 versions of Forth available for various
computers and operating systems, 10 or 20 have some
documentation that will show how to use Forth for someone who
already knows how to program. The other systems assume that you
have read a book like "Starting Forth" or have learned another
version of Forth and can reverse engineer uncommented Forth
source code. There are several tutorials and articles on the web
that are very good and the amount of material is slowly growing.
See the FAQ for comp.lang.forth for a list. Actually there are
too many web pages for Forth and it is hard to sort thru all of
them to find the ones that tell you exactly what you want to
know. If you don't find what you need, post a message to
comp.lang.forth stating your favorite operating system, cpu and
applications and someone point you to the right place.
--
Michael Coughlin ··········@ne.mediaone.net Cambridge, MA USA
In article <·················@ne.mediaone.net>,
Michael Coughlin <··········@ne.mediaone.net> writes:
> Counting versions is not the way to tell the health
> of
> a computer language. Count the number of textbooks on the
> shelves
> of bookstores intead. I conclude that Lisp and Scheme are still
> alive with about half to one third as many books as Fortran,
> while Fortran has about one tenth as many books as the big guys
> like C, Java, Visual Basic and C++. Forth comes out at zero.
Your result may be biased by your selection of bookstores. They'll
probably have to close MIT before LISP and Scheme books will vanish
from the Cambridge (MA) bookstores.
I was just at two bookstores near TU Wien. I did not see LISP,
Scheme, or Forth books. Interestingly, I did not even see a Prolog
book, although we have an obligatory Prolog course in our curriculum;
apparently the course notes are good enough. I saw books for some not
so popular languages: Ada, Haskell, Icon, Miranda, ML, Modula-2,
Oberon.
Concerning the metric you use to evaluate the health of a language: I
think we have now enough experience to conclude that it is wrong. You
whined about the lack of Forth books five years ago, but I see no
indication that Forth is any worse off than then, on the contrary,
other indicators are usually positive: clf traffic has grown, there
are fewer "Forth is dying" postings, implementations for new platforms
(e.g., PalmPilot, Lego Mindstorms) are demanded and supplied quickly,
participation at EuroForth is stable...
> When I meet people who tell me they want to learn all
> about computing, including programming, I want to say learn
> Forth. But I know that woun't work since they can't even go
> to the bookstore and buy a book about it.
And later you claim that Amazon.com is not a book store for this
purpose. Why? Sure, they cannot browse, but they have your
recommendation, and in the case of the Forth Programmer's Handbook
AFAIK they can even download an evaluation copy.
Moreover, there are several on-line Forth courses, so why would they
need to buy a book in a bookstore to learn Forth?
Using my metric of postings in comp.lang groups, here are the postings
present on news.tuwien.ac.at on July 11, 1997 and July 16, 1999. You
will notice that a lot of newsgroups have vanished, that's because
this newsserver has dropped groups that nobody here reads:
1997 1999
3 comp.lang.JavaScript
476 268 comp.lang.ada
206 comp.lang.apl
6 2 comp.lang.asm
786 581 comp.lang.asm.x86
78 comp.lang.asm370
117 144 comp.lang.awk
1 comp.lang.basic
447 comp.lang.basic.misc
114 646 comp.lang.basic.visual
282 comp.lang.basic.visual.3rdparty
691 760 comp.lang.basic.visual.database
3115 3429 comp.lang.basic.visual.misc
39 comp.lang.beta
2458 2471 comp.lang.c
2286 2518 comp.lang.c++
59 comp.lang.c++.leda
328 568 comp.lang.c++.moderated
51 63 comp.lang.c.moderated
968 comp.lang.clarion
731 655 comp.lang.clipper
224 625 comp.lang.clipper.visual-objects
32 comp.lang.clos
23 comp.lang.clu
485 comp.lang.cobol
5 comp.lang.cplu
5 comp.lang.crass
40 comp.lang.dylan
334 152 comp.lang.eiffel
6 comp.lang.for
233 470 comp.lang.forth
53 comp.lang.forth.mac
421 473 comp.lang.fortran
57 87 comp.lang.functional
31 comp.lang.hermes
31 28 comp.lang.icon
32 comp.lang.idl
122 183 comp.lang.idl-pvwave
309 252 comp.lang.java
815 1318 comp.lang.java.advocacy
12 comp.lang.java.announce
137 72 comp.lang.java.api
118 178 comp.lang.java.beans
210 comp.lang.java.corba
2 comp.lang.java.database
277 394 comp.lang.java.databases
4 comp.lang.java.developer
391 1045 comp.lang.java.gui
772 1625 comp.lang.java.help
15 comp.lang.java.javascript
84 171 comp.lang.java.machine
208 comp.lang.java.misc
3440 3864 comp.lang.java.programmer
194 212 comp.lang.java.security
40 comp.lang.java.setup
223 295 comp.lang.java.softwaretools
259 comp.lang.java.tech
1732 2869 comp.lang.javascript
16 comp.lang.limbo
197 791 comp.lang.lisp
24 comp.lang.lisp.franz
46 comp.lang.lisp.mcl
25 comp.lang.lisp.x
130 comp.lang.logo
136 110 comp.lang.misc
14 comp.lang.ml
88 comp.lang.modula2
69 comp.lang.modula3
171 comp.lang.mumps
72 comp.lang.oberon
66 101 comp.lang.objective-c
55 26 comp.lang.pascal
69 comp.lang.pascal.ansi-iso
664 297 comp.lang.pascal.borland
23 51 comp.lang.pascal.delphi
163 comp.lang.pascal.delphi.advocacy
21 comp.lang.pascal.delphi.announce
49 21 comp.lang.pascal.delphi.components
306 140 comp.lang.pascal.delphi.components.misc
222 comp.lang.pascal.delphi.components.usage
306 77 comp.lang.pascal.delphi.components.writing
1 comp.lang.pascal.delphi.database
888 comp.lang.pascal.delphi.databases
2061 864 comp.lang.pascal.delphi.misc
67 comp.lang.pascal.mac
221 111 comp.lang.pascal.misc
56 165 comp.lang.perl
7 1 comp.lang.perl.announce
1865 4223 comp.lang.perl.misc
260 comp.lang.perl.moderated
256 411 comp.lang.perl.modules
115 232 comp.lang.perl.tk
41 comp.lang.pl1
28 comp.lang.pop
284 252 comp.lang.postscript
77 comp.lang.prograph
83 97 comp.lang.prolog
404 999 comp.lang.python
141 155 comp.lang.rexx
3 comp.lang.rexx.tso
4 comp.lang.rexx.vm
26 51 comp.lang.sather
160 178 comp.lang.scheme
32 comp.lang.scheme.c
26 12 comp.lang.scheme.scsh
491 430 comp.lang.smalltalk
737 1235 comp.lang.tcl
23 7 comp.lang.tcl.announce
95 comp.lang.verilog
155 190 comp.lang.vhdl
2 comp.lang.visual
44 380 comp.lang.visual.basic
260 209 comp.lang.vrml
According to these numbers, both clf and cll traffic has grown a lot
in these two years, so I doubt that these languages are dying.
For more statistics, take a look at
http://metalab.unc.edu/usenet-i/hier-s/comp.lang.html. E.g., it
claims that clf has 24000 readers, and that cll has 31000 readers.
- anton
--
M. Anton Ertl Some things have to be seen to be believed
·····@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html
·····@mips.complang.tuwien.ac.at (Anton Ertl) writes:
& According to these numbers, both clf and cll traffic has grown a lot
& in these two years, so I doubt that these languages are dying.
The true question is, is the growth rate of comp.lang.forth greater
than or less than the growth rate of Usenet traffic in general? I
wouldn't say that more articles in, for example, talk.bizarre means
that the world is necessarily getting more bizarre. I'd say rather
that more bizarre people are posting more. What's the average
increase in posts in *lang* groups, and where does comp.lang.forth
stand on the curve?
--
U. Z. Puckett replace "sendnospam" with "puckett"
On Sun, 11 Jul 1999 17:10:15 GMT, ········@news.brownes.org
(Christopher B. Browne) wrote:
>On 11 Jul 1999 10:11:19 GMT, Rob Warnock <····@rigden.engr.sgi.com> posted:
>>Andi Kleen <·····@muc.de> wrote:
>>Really??? There are dozens & dozens of Schemes[*] that *I* know of...
>>How many Forths are there? Even a dozen?
>I count 28 distinct implementations at
><http://www.forth.org/compilers.html>, and that list is decidedly not
>comprehensive.
>--
>Lisp Users:
>Due to the holiday next Monday, there will be no garbage collection.
>········@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
Is there a "Forth in LISP" or a "LISP in FORTH"? I know only of a
Forth native code compiler written in PROLOG (recursion is natural in
PROLOG so the backtracking lends itself to compiling primitives first
and succeeding hilevel words).
Andreas
Andreas Kochenburger wrote in message <················@news.kwu.erl.siemens.de>...
[..]
>Is there a "Forth in LISP" or a "LISP in FORTH"?
[..]
LISP in Forth exists. Well, it doesn't try to emulate LISP but it adds
a LISP-like vocabulary to Forth, mainly list building words with garbage collection. The original
F-PC code for it is on Taygeta, it even has some documentation.
The GC stinks, I never got it to reliably work in a 32-bit flat model
Forth (iForth) after I converted it from its segment-based origin.
I've added some Prolog code to it published in JFAR (Feuerbacher?). The
demo is a rule-based AI program to determine animals :-)
-marcel
In article <················@news.kwu.erl.siemens.de>,
············@gmx.de (Andreas Kochenburger) wrote:
> Is there a "Forth in LISP" or a "LISP in FORTH"?
Ullrich Hoffmann wrote a Lisp in Forth, but IIRC, like many Forth
projects, he didn't really finish it. Alex Burger wrote and uses a
Lisp/Forth crossing (everything is list/symbol/number, but syntax is
Forth, or at least very Forth-like), called Lifo and Teatime (same, but
implemented in Java, with Java objects as first class data types).
IMHO Forth and Lisp are much closer to each other than to the rest of
the language space (Algol, Fortran, Cobol and derivatives).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
[I've restricted this to comp.lang.lisp only, x posting to
comp.lang.misc seems like a bad idea to me..]
* Andrew Cooke wrote:
> However - and forgive the preceding biography but it is intended to set
> the ground and show this isn't flame-bait - I get the impression that
> Lisp is on the way out. Now this is only a vague impression (more so
> because, being in the UK which, whether we like it or not, is in Europe,
> Lisp was never "in" here) - but with Harlequin going belly-up it seems
> legitimate to ask: is Lisp a dying language?
No, it's not dying. Statistics are hard to come by and not often very
useful, but the evidence I see is that it is doing reasonably well,
albeit in areas that are not very visible. A few years ago things
were worse (I guess as reaction to all the AI hype which Lisp got
associated with), but I think things are OK now. I think use is
increasing.
As far as I know, neither Harlequin nor Lucid before them went under
as a result of their Lisp business: Lucid (I think) went under because
of a failed (but very interesting) C++ development system, and
Harlequin went under because of something-not-Lisp.
--tim
* Tim Bradshaw
|
| Lucid (I think) went under because of a failed (but very
| interesting) C++ development system
Richard Gabriel writes about this in 'Patterns of Software', and they
did a Lisp development system first and then turned to C++. The
reasons they failed seemed to be a mix of bad luck, personnel problems
and a bad move. (The latter being to invest heavily in development for
an IBM platform that never came off the way it should have.)
This is from memory, though, so apply a grain of salt.
--Lars M.
:Is LISP dying?
This is a frequently asked question, even if not a Frequently Asked
Question.
A short summary:
Lisp took a hit when the "AI wave" faded away, but is recovering
nicely.
The reason Lisp seems so small is that the rest of the computer
industry is so enourmous.
Stig Hemmer,
Jack of a Few Trades.
On 11 Jul 1999 19:47:05 +0200, Stig Hemmer <····@pvv.ntnu.no> wrote:
>The reason Lisp seems so small is that the rest of the computer
>industry is so enourmous.
I'm glad someone pointed this out. If language X used to be used for
25% of all applications (as if we have _any_ way of acquiring reliable
statistics like that), but is now being used for only 5% of all
applications, one might be tempted to say it is in decline --- but not
if the number of applications has grown by, say, 500%.
Advocates of the popular languages/methodologies du jour like to say
that their favorite language will soon eliminate everything else, the
current offenders being C++ and Java. But this is pure bull; the
number of languages and methodologies continues to grow, which is,
IMHO, a sign of the increasing diversity and maturity of the field.
If COBOL can persist as long as it has, it's a safe bet that our
grandchildren will be debugging C programs.
-E.
+-------------------------------------------------------------------+
| "I have come a very long way from myself only to realize that |
| identity is a skill and self-betrayal is a habit. Once lost, the |
| former is very hard to regain; once gained, the latter is very |
| hard to lose." ---I. Corvus, _The Europe of Our Dreams_ |
+-------------------------------------------------------------------+
http://members.tripod.com/~abadger
[ replying to comp.lang.lisp only
http://world.std.com/~pitman/pfaq/cross-posting.html ]
Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
> I get the impression that Lisp is on the way out.
Lisp marketing is tricky and not always done right. High tech
marketing in general is hard to do. Look at the Macintosh. Not
exactly a piece of junk. Keeping a company going is harder than
keeping interest in the company going. Cash flow can be very tricky.
If you like something, buy its products.
Btw, there are a LOT of users of Lisp who do not buy its products and
prefer to use freeware; if you ask me, it is that practice which hurts
the community most of all. People need to either contribute money (or
public effort, if they insist on using publicware) but they should not
expect to just "consume" without putting something back and have the
community survive.
Also, seems to me that you should not see yourself as an isolated
party. Your words can have an effect, and flamebait or not, you
should take that into account when choosing both the forum and the
subject line for posts--ESPECIALLY when cross-posting, since that
virtually assures you will see an audience of people who are talking
at crossed purposes with zero hope of resolution.
Subject lines such as the one you chose and the forum in which you
chose to express it (I've removed comp.lang.misc) are dangerous. You
potentially do damage to any product by asking these questions in a
highly visible forum if what you say is within a threshold range that
someone who isn't paying attention is just looking for an excuse to
say "oh, look, someone else was wondering the same".
The questions that are relevant are not "how many other people like
this" but "is this good for me". If you don't know what it takes to
make something "good enough" for your purposes, you probably have some
things about the technical world and the business world that you
should be more concerned about catching up on than you are about
worrying about lisp. A good engineer should know what it will take to
satisfy their needs, independent of the businesses involved. For
example, if I told you all the hammer companies in the world were
going out of business, would you (a) rush to buy a hammer or (b) try
to build your next house without a hammer?
How many other people are using something is not very relevant if
you're producing finished applications. What matters is speed, time
to market, If you really think your application can be written in some
other language, and that it won't take any more time to do it in
another language, then use the other language for that reason. Most
people who use Lisp use it because there are big gains to be had for
using it in terms of development time, debuggability, flexible
retargetability in case of changing conditions, etc. If you don't
need those features, and perhaps others like them, you are probably in
the space of "commodity languages" and not seeing the reason people
cling to Lisp. But if you need the things for which Lisp offers
almost unique solutions, then stop sending posts asking if Lisp is
dying and start trying to make it win. Such posts, flame bait or not,
simply do NOT help, and I for one think you should read my HTML page
on cross-posting and take it very seriously ESPECIALLY for posts like
this which are such high risk of being misinterpreted, confused, and
otherwise attracting random, uninformed opinions.
I have little tolerance for this kind of discussion these days. It's been
flogged to death and you'd be better off pulling up one of its clones
from Deja News (http://www.deja.com/home_ps.shtml) than making us repeat it.
If you really can't deal with CL because of the risk, try Scheme. But
please don't cross-post those communities either. For all its similarity,
it's really quite different and discussions that seek to draw us together
often backfire.
I may or may not follow up on this thread further, but I am going to try
not to. I really don't think this was a good use of my time, and I did
it only grudgingly as a form of damage control after you, intentionally
or otherwise, took the like-it-or-not negative act of starting this thread.
You'd have done better to just send private mail to someone you saw post here
or to do some thread research for similar threads before starting this.
On Mon, 12 Jul 1999 00:57:13 GMT, Kent M Pitman <······@world.std.com>
wrote:
>[ replying to comp.lang.lisp only
> http://world.std.com/~pitman/pfaq/cross-posting.html ]
>
>Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
>
>> I get the impression that Lisp is on the way out.
>
>Lisp marketing is tricky and not always done right. High tech
>marketing in general is hard to do. Look at the Macintosh. Not
>exactly a piece of junk. Keeping a company going is harder than
>keeping interest in the company going. Cash flow can be very tricky.
>If you like something, buy its products.
>
>Btw, there are a LOT of users of Lisp who do not buy its products and
>prefer to use freeware; if you ask me, it is that practice which hurts
>the community most of all. People need to either contribute money (or
>public effort, if they insist on using publicware) but they should not
>expect to just "consume" without putting something back and have the
>community survive.
>
That's a wonderful sentiment - but reality dictates another course
because business rarely takes a long term market view. It does indeed
cost a significant amount to develop a decent language development
system and bring it to market, but many companies try to recoup too
quickly and price themselves out of the market.
The reason C/C++, and before that Pascal, took off was because forward
looking companies [I'm thinking of Borland in particular, but others
were also involved] took chances and sold their systems at well below
cost hoping to create their markets. It is true that these systems
were typically stripped down relative to "professional" development
systems available, but they introduced people to the language at
affordable cost and built a base of programmers familiar with both the
language in general and the company's products in particular.
Curious newcomers who lack the ability to set up a shareware/freeware
system may be willing to try a low cost commercial system which is
easy to install and use. Commercial Lisp implementors, for the most
part, either didn't offer low cost intro packages or didn't advertise
that they did. Out of sight, out of mind.
George Neuner
Dynamic Resolutions, Inc.
===================================================
The opinions expressed herein are my own and do not
reflect the opinions or policies of my employer.
===================================================
·······@dyn.com (George Neuner) writes:
> Curious newcomers who lack the ability to set up a shareware/freeware
> system may be willing to try a low cost commercial system which is
> easy to install and use. Commercial Lisp implementors, for the most
> part, either didn't offer low cost intro packages or didn't advertise
> that they did. Out of sight, out of mind.
This is fine, but said people should not lament the passing of things
they are not willing to invest in. This newsgroup has a number of people
who my sense is both want a lot of free things and want to debug why
Lisp is in the trouble it's in. I think as much as anyone that the language
should be competitively priced and free things should be available. But
I also don't think there's any mystery that there are financial problems
that result from this.
In some ways, computer science got along better when things cost more.
It could afford to take a long-term point of view and invest. People
keep trying to ascribe the success or failure of companies to the
technology, but it's just plain hard managing the day-to-day cash
flow, because if you blink--or worse, if you take a moment to look at
the long term instead of the short term--you can lose out utterly now.
That's sad. Yes, the companies need to do their part, if they care to
stay in business, to keep prices low. The users need to do their
part, if they care to still have vendors, to sometimes buy from
them. It's not like you can just opt out of the paying part and still
reserve the right to care what happens.
> The reason C/C++, and before that Pascal, took off was because forward
> looking companies [I'm thinking of Borland in particular, but others
> were also involved] took chances and sold their systems at well below
> cost hoping to create their markets. It is true that these systems
> were typically stripped down relative to "professional" development
> systems available, but they introduced people to the language at
> affordable cost and built a base of programmers familiar with both the
> language in general and the company's products in particular.
I advocate this as much as anyone. But the fact is that there are a
LOT of free offerings of Lisp and of good quality. Each commercial
vendor pretty much has one. So this is NOT what we need more of.
Lisp itself is extraordinarily affordable already. To the point where
I think a lot of people who would be willing to buy it don't. Free software
can work both ways and should not be seen as a panacea.
On Wed, 14 Jul 1999 17:35:09 GMT, Kent M Pitman <······@world.std.com> wrote:
>
>I advocate this as much as anyone. But the fact is that there are a
>LOT of free offerings of Lisp and of good quality. Each commercial
>vendor pretty much has one. So this is NOT what we need more of.
>Lisp itself is extraordinarily affordable already. To the point where
>I think a lot of people who would be willing to buy it don't. Free software
>can work both ways and should not be seen as a panacea.
I called Franz a while back to find out about how much it would cost me
to get a Lisp system for use on my Linux box as a learning tool (I am
in grad school). I wanted to be able to use CLIM. The cost was
somewhere upwards of $1500.00. Because of this price tag I will not be
in the position to recommend CLIM to some future employer. I will not be
in a position to know its strengths or weaknesses. The Lisp community
may have just cost themselves quite a bit of money; there is no way to
tell.
Without free or low priced complete lisp systems (a system without a GUI
is not a system in todays market) available, the market will not grow.
--
Kenneth P. Turvey <·······@SprocketShop.com>
----------------- http://www.tranquility.net/~kturvey
Reasonable people adapt themselves to the world. Unreasonable people
attempt to adapt the world to themselves. All progress, therefore,
depends on unreasonable people. -- George Bernard Shaw
From: Christopher R. Barry
Subject: Lisp ain't dying, but CLIM is. (was Re: Is LISP dying?)
Date:
Message-ID: <87hfn5pvnm.fsf_-_@2xtreme.net>
·······@pug1.sprocketshop.com (Kenneth P. Turvey) writes:
> I called Franz a while back to find out about how much it would cost me
> to get a Lisp system for use on my Linux box as a learning tool (I am
> in grad school). I wanted to be able to use CLIM. The cost was
> somewhere upwards of $1500.00.
That is incredibly cheap for them. The usual quote for the
Professional Edition (their most basic commercial offering) is $4200,
and with CLIM added on it's in the 7s (if I remember MikeMac
correctly...). Of course, the only accurate source of pricing
information for Franz's products is Franz....
For less than the price you mentioned (I'm pretty sure...) you can get
LispWorks with CLIM and deliver applications royalty free. (IIRC I
think I read when I downloaded the Linux Beta that they bundle it with
their Professional version....)
> Because of this price tag I will not be in the position to recommend
> CLIM to some future employer. I will not be in a position to know
> its strengths or weaknesses. The Lisp community may have just cost
> themselves quite a bit of money; there is no way to tell.
Its funny that an old Lisp Machine is the cheapest way to get your
hands on CLIM. For not too much more you can get an iMac and MCL with
CLIM. I also think that a CLIM to use under similar terms as the
current Trial/Free editions could only help Lisp. A lot of people that
buy licenses do not buy CLIM as an add-on, so only a small fraction of
the people that read this group and Lispers as a whole have real
exposure and knowledge of CLIM. The rare CLIM questions here go
unanswered, or people get referred to this voluminous tome known as
_The CLIM User's Guide_. There are no decent (any?) tutorials on the
web for CLIM and there are no books at Amazon that cover CLIM, nor is
there likely any market for a CLIM book.
If there was a Trial CLIM, this what I see happening:
1. Many licensees and non-licensees alike would at least _try_
CLIM. If they try CLIM, they'll know what the're missing out on by
speaking CORBA or sockets or whatever to Swing to do their GUI
instead (or something...).
2. Tutorials on the web would appear. In time there may even be a
market for someone to write a good book.
3. Interest about it would increase and questions here would start
to get asked more and actually answered, thus increasing the value
of vendor's CLIM offerings by there being an actual community of
CLIM users, just like this group and the general community of Lisp
users increases the value of their Lisp offerings. In time there
could even start to be annual CLIM User's Group meetings (like the
LUGM), who knows?
4. Free CLIM software would appear, giving real good examples with
source of how to do cool things with CLIM, showing how the
presentation facility makes GUIs that belong to the more
sophisticated classes of human-computer-interaction about 10 times
easier to program and require about 5-10% the code.
> Without free or low priced complete lisp systems (a system without a
> GUI is not a system in todays market) available, the market will not
> grow.
Everyone's Free/Trial edition except for the Franz Linux/BSD one has
some form of proprietary-API interface builder included. With CMUCL
you can use the (kinda buggy and slow, but powerful) Garnet. None of
these support the presentation facility of CLIM, which is what makes
CLIM so cool.
If you read some of the posts that touched on CLIM over the past few
days (from Nick Levine and others), it would seem that CLIM is not
profitable for any vendor (gee I wonder why...) and that they would
rather just not maintain it and let it die.
Christopher
In article <·················@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> Its funny that an old Lisp Machine is the cheapest way to get your
> hands on CLIM.
Additonally: Symbolics Genera 8.3 and Open Genera 2.0 come with CLIM sources.
Digitool sells a source+site license for CLIM.
> exposure and knowledge of CLIM. The rare CLIM questions here go
> unanswered, or people get referred to this voluminous tome known as
> _The CLIM User's Guide_.
There is the CLIM specification and Symbolics has its
CLIM documentation.
http://www2.cons.org:8000/clim-spec/cover.html
> There are no decent (any?) tutorials on the
http://kogs-www.informatik.uni-hamburg.de/%7Emoeller/uims-clim/clim-intro.html
http://kogs-www.informatik.uni-hamburg.de/~moeller/clim-examples/
http://kogs-www.informatik.uni-hamburg.de/~moeller/clim-examples/clim-examples-images/screen-shots.html
http://www.informatik.uni-stuttgart.de/ifi/is/Lehre/Vorlesung/symbolv/clim/handout.html
http://www.sover.net/~nichael/work/portfolio/index.html
ftp://openmap.bbn.com/pub/customer-redirect/kanderson/scigraph-19981027.tar.gz
ftp://ftp.digitool.com/pub/clim/
> nor is there likely any market for a CLIM book.
There is.
> If you read some of the posts that touched on CLIM over the past few
> days (from Nick Levine and others), it would seem that CLIM is not
> profitable for any vendor (gee I wonder why...) and that they would
> rather just not maintain it and let it die.
I still have the feeling some have sabotaged it.
AFAIK Harlequin had a CLIM-based development environment -
it never surfaced.
Ask one of the frequent posters (from the US ;-) ) - I heard
that he has written an Emacs-like editor in CLIM ...
From: Christopher R. Barry
Subject: Re: Lisp ain't dying, but CLIM is. (was Re: Is LISP dying?)
Date:
Message-ID: <87yagho7xw.fsf@2xtreme.net>
······@lavielle.com (Rainer Joswig) writes:
> Additonally: Symbolics Genera 8.3 and Open Genera 2.0 come with CLIM sources.
> Digitool sells a source+site license for CLIM.
>
> > exposure and knowledge of CLIM. The rare CLIM questions here go
> > unanswered, or people get referred to this voluminous tome known as
> > _The CLIM User's Guide_.
>
> There is the CLIM specification and Symbolics has its
> CLIM documentation.
The CLIM specification is less usable as a reference than the CLIM
User's Guide. Neither have any tutorial value other than in the
HyperSpec sense. The Symbolics CLIM documention is essentially an
older, slightly different (from the Harlequin one) copy of the CLIM
User's Guide, combined with a very brief tutorial on defining
application frames and using presentations. It gives you just enough
information so that you can get started and know how to create the
support code to try out a function from the User's Guide.
> > There are no decent (any?) tutorials on the
>
> http://kogs-www.informatik.uni-hamburg.de/%7Emoeller/uims-clim/clim-intro.html
> http://kogs-www.informatik.uni-hamburg.de/~moeller/clim-examples/
> http://kogs-www.informatik.uni-hamburg.de/~moeller/clim-examples/clim-examples-images/screen-shots.html
>
I've seen these before from altavista searches. They either describe
CLIM and some of its concepts, or give a little demo/example code but
its not that great.
http://www.informatik.uni-stuttgart.de/ifi/is/Lehre/Vorlesung/symbolv/clim/handout.html
That one is 99.9% German. Remember, not all of us can speak it. :-)
There wasn't any source code in it either and it's probably not that
great anyways.
> http://www.sover.net/~nichael/work/portfolio/index.html
> ftp://openmap.bbn.com/pub/customer-redirect/kanderson/scigraph-19981027.tar.gz
These are just some source and technical papers of a lot of the CLIM
stuff the BBN is now (I hear) converting to Java. Nothing tutorial or
very useful/usable about it.
> ftp://ftp.digitool.com/pub/clim/
That looks like the same ancient CLIM demo stuff you can get from the
CMU AI Repository.
> > nor is there likely any market for a CLIM book.
>
> There is.
What makes you think there is? I'd like to believe that that is true,
but can find anything to convince myself.
> > If you read some of the posts that touched on CLIM over the past few
> > days (from Nick Levine and others), it would seem that CLIM is not
> > profitable for any vendor (gee I wonder why...) and that they would
> > rather just not maintain it and let it die.
>
> I still have the feeling some have sabotaged it.
>
> AFAIK Harlequin had a CLIM-based development environment -
> it never surfaced.
>
> Ask one of the frequent posters (from the US ;-) ) - I heard
> that he has written an Emacs-like editor in CLIM ...
Zmacs? :-) After having used a Symbolics so much, I wonder why none of
the vendors have ever made a CLIM-based listener and editor so that
you can do some of the same cool stuff. The Symbolics Dynamic Windows
(same CLIM presentations functionality for those that don't know) UI
is pushing two decades of age now. Time for a vendor to offer us one
with 1/10th the functionality and coolness and 1/2 the efficiency.
Christopher
In article <··············@2xtreme.net>,
······@2xtreme.net (Christopher R. Barry) writes:
> ······@lavielle.com (Rainer Joswig) writes:
>> > If you read some of the posts that touched on CLIM over the past few
>> > days (from Nick Levine and others), it would seem that CLIM is not
>> > profitable for any vendor (gee I wonder why...) and that they would
>> > rather just not maintain it and let it die.
>>
>> I still have the feeling some have sabotaged it.
I thought I was the most cynical about CLIM around here but I wouldn't go
quite that far. At least, not deliberately sabotaged. Mostly I think the
vendors just didn't know what to do with it. The joint ownership of it may
also be complicating things. Just figuring out who owns the thing probably
would keep some lawyers busy for quite a while. (I don't know what the
contractual agreement was between the original CLIM partners. I'm only
speculating that it'd keep any one of them from just releasing the sources. [I
do believe that there are other arraingements that could be pursued other
releasing the source to everyone if thecontract is this way.] It'd probably
require all six of them to agree to it. Finding everyone is probably a major
task.)
>> AFAIK Harlequin had a CLIM-based development environment -
>> it never surfaced.
>>
>> Ask one of the frequent posters (from the US ;-) ) - I heard
>> that he has written an Emacs-like editor in CLIM ...
>
> Zmacs? :-) After having used a Symbolics so much, I wonder why none of
> the vendors have ever made a CLIM-based listener and editor so that
> you can do some of the same cool stuff.
CLIM is a complicated system that's expensive to support. The vendors want
to see sufficient customer demand before they invest their limited resources
in pursuing it. Since it is a complicated system and the potential customers
don't know enough about it except the cost, they're not eager to commit their
limited resources and demand it. As a result, we have a sort of stand off.
Each side is waiting for the other side to blink. It'll take something drastic
to break the jam, either a customer with a lot of money and guts or a vendor
willing to take a risk. At the moment, I don't have much faith that either
will appear.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> CLIM is a complicated system that's expensive to support. The vendors want
> to see sufficient customer demand before they invest their limited resources
> in pursuing it. Since it is a complicated system and the potential customers
> don't know enough about it except the cost, they're not eager to commit their
> limited resources and demand it. As a result, we have a sort of stand off.
> Each side is waiting for the other side to blink. It'll take something drastic
> to break the jam, either a customer with a lot of money and guts or a vendor
> willing to take a risk. At the moment, I don't have much faith that either
> will appear.
>
> Mike McDonald
> ·······@mikemac.com
(Sorry about the rambling note. Its getting late, and the disorganized
message merely reflects the swirling confusion in my mind.)
I've had some experience with CLIM, and am one of the poor souls that tried
posting to get some answers. The symbolics CLIM 1.0 book that I managed to
find is by far the best documentation I have been able to get my hands
on. And it certainly is not from lack of searching.
There are two problems that I see with CLIM:
1. Poor documentation, "non-standard" paradigm.
2. Cost.
Consider a programmer (even a Lisp programmer) that has never played with
CLIM, and has to write an interface. As good as this programmer might be at
Lisp, I believe that she/he would have a very difficult time learning CLIM,
simply because its approach to building a GUI is very different from
current practice.
The one thing that I haven't yet found is a good, clear and concise
description of what you can do with CLIM that would be hard with another
GUI environment. (I had seen one article, I don't remember where, that
attempted this, but knowing what I do now I felt it only touched on a small
subset of CLIM's facilities.) Even if you know what CLIM can do for you, it
doesn't help if you don't know how to do it. And we get back to tutorials
and documentation.
The first couple of times I tried creating a GUI in CLIM, the results were,
well, just short of disasterous. I simply didn't understand how the thing
worked. In most present day GUI's, you place widgets on screen, and attach
code to those widgets. That makes getting a basic GUI together (which is
what I wanted) rather straightforward. You can even throw together a GUI
builder relatively easily. (Witness Allegro CL and MCL.) Of course,
extending it to handle complex interactions of the type presentations
enable takes an incredible amount of work.
I once tried to explain to an HCI graduate student CLIM can potentially do,
but I had a really hard time convincing her of its utility. Partly because
I didn't know enough to do a good job of it. For what I did get across, I
got the response, "That paradigm in interface design was abandoned ages
ago." Given current practice, CLIM is hard, CLIM is mysterious, and without
decent tutorials that clearly get across its strengths, CLIM is worse than
GUI's available on non-Lisp environments. I'd like to say I don't agree
with this position, but without decent documentation that clearly
demonstrates the power of CLIM (as opposed to toy examples and code without
any documentation), I find myself in partial agreement. I once tried to
create a draggable object on screen in CLIM. Not pleasant.
The second problem, cost, I find equally troubling. If I were not a
student, I would not dream of trying to acquire and experiment with a copy
of CLIM. And to reiterate what others have said, high price would be a
reason to not get my hands dirty. I have a dozen other GUI's out there that
I can experiment with for free, and one of them is bound to at least
partially meet my needs. What might possibly lead me to believe that CLIM
is fantastically better than anything I have tried? Especially in the
absence of documentation? I see no reason whatsoever that anyone might
consider using CLIM for building an interface.
Soon I shall no longer be a student. I suspect I shall not be fooling
around with CLIM that much longer. Most present-day (deliverable) programs
are complex enough that a command line interface is insufficient. Lisp
potentially has a great GUI environment in CLIM, only it is next to
impossible for the average user (programmer) to play with. And for many,
this may be reason enough to drop lisp and look at an environment that's
more accessible.
In my undergrad school, the professor with whom I was working was
*relieved* to be able to abandon CLIM 1.x. He moved to Allegro CL when
Lucid went under, and loved the GUI builder. It wasn't more powerful,
merely less buggy and obtuse. I can't compare CLIM 1.x and 2.x, but 2.x
appears to be usable. But still obtuse.
A closing remark: I want to be able to use a GUI with my lisp programs. I
have to work with enough data and such that having a GUI would greatly ease
my life. I would also like to be able to interface with non-lisp elements
easily and reliably. I have tried running a quicktime movie on an SGI in
lispworks, and it is hell. I don't really *care* if I don't have the
perfect GUI where I can interact with the underlying objects directly. I'd
trade a little simplicity and transparency for that power. (I invite you to
read Don Norman's book, "The design of everyday things" I believe is the
name, to understand why I believe this is important.) Lisp arguably tends
to be on the opaque side, but at least you can get a sense for what the
language is about if you have had a good education in CS and are willing to
read a book or two. Unfortunately, there is no theory of interfaces that
one can learn to understand CLIM. I believe this is a problem that needs
fixing, by either making CLIM more available or accessible, or putting some
effort into a GUI that is easier to implement, debug and use.
Sunil
From: ················@hybrid.fi
Subject: Re: Lisp ain't dying, but CLIM is. (was Re: Is LISP dying?)
Date:
Message-ID: <7mmfb4$5li$1@nnrp1.deja.com>
In article <···············@whizzy.cc.gatech.edu>,
Sunil Mishra <·······@whizzy.cc.gatech.edu> wrote:
> ·······@mikemac.com (Mike McDonald) writes:
>
>
> The first couple of times I tried creating a GUI in CLIM, the results
were,
> well, just short of disasterous. I simply didn't understand how the
thing
> worked. In most present day GUI's, you place widgets on screen, and
attach
> code to those widgets. That makes getting a basic GUI together (which
is
> what I wanted) rather straightforward. You can even throw together a
GUI
> builder relatively easily. (Witness Allegro CL and MCL.) Of course,
> extending it to handle complex interactions of the type presentations
> enable takes an incredible amount of work.
>
Hmm, I liked the menu user interface what we did in one research project
implementing Common-lisp to C Compiler in AIX 6000 and Sunos.
Basically the definition of menu looked like
(defpresentation map-menu-bar
$(a menu-bar :structure
(("File" (("Save River" cb-save-river)
("Close" close-shell)))
("Edit" (
("Edit Object")
("Delete")
("Generate River" cb-generate-river)
("Deselect" ck-deselect)
))
("View" (("Color Coding ->" (("Ph" (cb-set-color ccf-ph))
("Temperature" (cb-set-color
ccf-temp))
("Flow" (cb-set-color ccf-flow))
("O2" (cb-set-color ccf-o2))
("N" (cb-set-color ccf-n))
("Alarm Index" (cb-set-color
ccf-alarm))))
("Layers ..." cb-layers)
))
("Time" (("Set Simulation Start Time"
tl-set-simulation-start-time)
("Set Simulation End Time" tl-set-simulation-end)))
("Model" (("Run ...")))
("Step" (("Step one delta" run-delta-t)
("Step n deltas" run-delta-many)))
("Status" (("Get simulation status" tl-get-sim-status))))))
It was quite fun to write user interfaces and test them quickly.
heh heh, the compiler beat the s**t out from other CL implementations on
that time in gabriel benchmarks.
Unfortunately one has to life and cannot affort to spend time going
through the code and make the thing to compiler java byte code...
Unfortunately most of the people around doesn't understand, that the CL
could be used in very difficult project.
Or should we be better to say, that the marketing doesn't like the sound
when engineer says "It only interrepts for 1-2 milliseconds to collect
GARGABE"..
"GARBAGE", how in earth we can sell this thing to customers ???
Currently I have spent a year as a member of team designing and
implementing snmp management system with C++,CORBA ,and yack RPC. There
are VERYYYYY many configuration files, which basically define how the
system behaves in the fly, how traps are converted to alarm
notifications, how things are collected, where there are stored etc...
It would have taken maybe 3-6 months to write the whole thing in CL
alone.
We have spent much more..
PKY
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
From: Chuck Fry
Subject: Re: Lisp ain't dying, but CLIM is. (was Re: Is LISP dying?)
Date:
Message-ID: <7mnkkp$mgh$1@shell5.ba.best.com>
In article <··············@2xtreme.net>,
Christopher R. Barry <······@2xtreme.net> wrote:
>Zmacs? :-) After having used a Symbolics so much, I wonder why none of
>the vendors have ever made a CLIM-based listener and editor so that
>you can do some of the same cool stuff. The Symbolics Dynamic Windows
>(same CLIM presentations functionality for those that don't know) UI
>is pushing two decades of age now. Time for a vendor to offer us one
>with 1/10th the functionality and coolness and 1/2 the efficiency.
A couple of nits to pick:
- As I (vaguely) recall, DW was introduced with Genera 7.0, in about
1986 (or maybe late '85). That makes it a teenager, but not 20 years
old.
- I think you mean "Time for a vendor [...] with *twice* the
efficiency." Or are you being sarcastic?
- Some of you might recall that the initial release of DW was so
inefficient that it brought the mightiest Lisp machines of the time to
their knees. It wasn't until the next point release that DW was made
remotely efficient, but by that time few people cared, because its
previous (lack of) performance had left such a bad impression on many
users that they turned it off out of habit. In later releases DW became
very speedy, and extremely useful.
Ah, for the good old days...
-- Chuck, ex-Symboolean
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@home.com (MIME enabled)
Lisp bigot, mountain biker, car nut, sometime guitarist and photographer
The addresses above are real. All spammers will be reported to their ISPs.
From: Jason Trenouth
Subject: Re: Lisp ain't dying, but CLIM is. (was Re: Is LISP dying?)
Date:
Message-ID: <3797e8bd.154367218@newshost>
On Thu, 15 Jul 1999 23:08:07 +0200, ······@lavielle.com (Rainer Joswig) wrote:
> AFAIK Harlequin had a CLIM-based development environment -
> it never surfaced.
Yonks ago Fry prototyped some browser/inspector ideas for a Dylan environment
in CLIM but these ideas weren't an entire environment and never made it into
production. I think Scott also wrote a CLIM-based listener to use himself and
share with a couple of other like-minded souls (mostly at 1CC). AFAIK we never
had a whole Lisp environment in CLIM, but perhaps some other tools existed as
well. Most of the CLIM-addicts resided at 1cc, but conversely that place also
had its fair share of EMACS-junkies.
BTW The current Dylan Interactor (aka Listener) has a presentation-style
interface. E.g. You can right click on the results and recursively inspect
them in the listener with successive results being active in the same way.
__Jason
From: Nick Levine
Subject: Re: Lisp ain't dying, but CLIM is. (was Re: Is LISP dying?)
Date:
Message-ID: <7mv11d$12v$2@epos.tesco.net>
>If you read some of the posts that touched on CLIM over the past few
>days (from Nick Levine and others), it would seem that CLIM is not
>profitable for any vendor (gee I wonder why...)
Because it's unmaintainable.
>AFAIK Harlequin had a CLIM-based development environment -
I don't believe this is true.
- n
From: Kent M Pitman
Subject: Re: Lisp ain't dying, but CLIM is. (was Re: Is LISP dying?)
Date:
Message-ID: <sfwd7xood41.fsf@world.std.com>
"Nick Levine" <···········@tesco.net> writes:
> >AFAIK Harlequin had a CLIM-based development environment -
>
> I don't believe this is true.
But this IS true. Scott McKay wrote such an environment years ago.
You may or may not have perceived this, but from the US side of
things, there was an enormous cultural war a few years back when Jo
hired a lot of the Symbolics/Genera refugees. I used it. Scott used
it. I think one or two other people used it. Harlequin folk can find
it in HOPE (the Harlequin-internal source control system) under the
compound name "bagel" (stands for "Bagel's A Genera Environment
Lookalike", which it really wasn't quite, but it was kinda sorta
similar, enough that it was worth working into the acronym as a
tribute to the inspiration Genera had been to the system). But like
many things Harlequin, it was good technology that never saw the light
of day.
Those of us from the Genera camp felt a good deal of personal
embarrassment at the degree to which our attempts to influence product
direction were rebuffed within Harlequin. Although it was politically
improper within Harlequin to frame it this way (and the fact of that
political issue made it hard to confront the issue directly), this
was perceived in the US as very much a US/UK clash. The UK had strong
hold over the sources and things didn't get done unless the people in
the UK wanted them done. In the US, it was perceived very much as an
NIH problem [not invented here], since CAPI was from the UK and CLIM
was from the US. I suspect that in the UK the thought was that CAPI
was just technically better, and people probably don't realize the degree
to which this didn't sit well with the US. Of course, it's common with
NIH for people to not frame it that way in their own minds. But the fact
that there was never a meeting to simply resolve this fact once and for
all was telling.
Indeed, Harlequin had very few mechanisms for resolving internal wars
of this kind. This management shortfall was touted at the time as one
of harlequin's strengths; Harlequin has some good software, but would
have had a lot more of it, IMO, without this "strength". I can only
hope that now under new ownership and management, that fact will
change. I think a solution to the various long-festering problems
(CAPI vs CLIM, LCL vs LW, Dylan vs Lisp, etc.) is key to its ever
digging itself out of the financial pit it's in of late. And I have
to say that in this post-Dilbert era, few are the companies that have
cried out for "more" (rather than "less") management, so you can see
just how far Harlequin had gone...
But in any case, I wrote this message mainly to say that this CLIM-based
development system did exist. Bad enough for poor old Scott McKay that
no one ever used the fruit of his labors but to have people deny it ever
happened on top of it is too much. Surely he must feel the kind of
private agony over this that I was remarking the other day I had felt
about the CL HyperSpec being buried for so long before its release.
Scott just didn't have the energy to push as hard for bagel's release.
(Btw, if you talk to mckay about it, don't use the name Bagel, or he
might not recognize it. He doesn't call it that. But I needed a
check-in name for it when I put it into HOPE, and I asked him what
name he wanted one day in the hallway. He gave me "bagel" on a whim and
told me to think up an acronym expansion, but I think he thought he
was kidding. I think he calls it something boring like the "CLIM
development environment".)
In article <···············@world.std.com>, Kent M Pitman <······@world.std.com> wrote:
> "Nick Levine" <···········@tesco.net> writes:
>
> > >AFAIK Harlequin had a CLIM-based development environment -
> >
> > I don't believe this is true.
>
> But this IS true.
Harlequin, how about putting it in an "unsupported" directory
on your file server or on the next LispWorks CD? ;-)
Rainer Joswig
From: Nick Levine
Subject: Re: Lisp ain't dying, but CLIM is. (was Re: Is LISP dying?)
Date:
Message-ID: <7n1cul$e9n$1@epos.tesco.net>
Kent M Pitman wrote in message ...
>"Nick Levine" <···········@tesco.net> writes:
>
>> >AFAIK Harlequin had a CLIM-based development environment -
>>
>> I don't believe this is true.
>
>But this IS true ...
Noted, thanks.
> ... I think a solution to the various long-festering problems
>(CAPI vs CLIM, LCL vs LW, Dylan vs Lisp, etc.) is key to its ever
>digging itself out of the financial pit it's in of late...
Indeed. Too much of Hqn management spent too much of the time missing
crucial things: authority, budget, direction, business sense, interest, a
substitute for grey fluff between the ears. So we limped on for years using
the wrong people to generate the wrong products and the amazing thing is
that we didn't do a whole load worse, faster.
- nick (wishing the new vendor better opinions than the old employer (have I
got that right?))
·······@pug1.sprocketshop.com (Kenneth P. Turvey) writes:
> On Wed, 14 Jul 1999 17:35:09 GMT, Kent M Pitman <······@world.std.com> wrote:
> >
> >I advocate this as much as anyone. But the fact is that there are a
> >LOT of free offerings of Lisp and of good quality. Each commercial
> >vendor pretty much has one. So this is NOT what we need more of.
> >Lisp itself is extraordinarily affordable already. To the point where
> >I think a lot of people who would be willing to buy it don't. Free software
> >can work both ways and should not be seen as a panacea.
>
> I called Franz a while back to find out about how much it would cost me
> to get a Lisp system for use on my Linux box as a learning tool (I am
> in grad school). I wanted to be able to use CLIM. The cost was
> somewhere upwards of $1500.00. Because of this price tag I will not be
> in the position to recommend CLIM to some future employer.
$1500 can be a lot or a triffling sum depending on circumstance.
for you at this time, it's expensive. $1500 would be some 15% of my
gross income back when i was a graduate student at georgia tech. i
understand you need to eat.
however, $1500 is not a lot of money for business purposes[1].
test equipment such as spectrum analysers cost many thousands.
consider good asic chip design tools; these can cost $150k for a
license. if lisp is useful to you, $1500 is a bargain. the people at
franz also need to eat.
the problem is that without prior lisp experience, you will be hard
pressed to recommend it to your employer.
> I will not be in a position to know its strengths or weaknesses.
> The Lisp community may have just cost themselves quite a bit of
> money; there is no way to tell.
life isn't fair. i think franz is very generous with their trial
edition.
> Without free or low priced complete lisp systems (a system without a GUI
> is not a system in todays market) available, the market will not
> grow.
you can use the linux trial edition. you can use clisp or cmucl.
so there are systems you can use. i agree that gui construction ought
to be a natural for lisp and that the trial editions do not make it as
readily available as, e.g., visual basic[2]. there seems to be a
little bit of work[3] with gui toolkits and cmucl going on. perhaps
joining that effort would help you get started at a price you can
afford.
[1] businesses can deduct expenses from their taxes.
[2] visual basic while a weak programming language gives access to
many gui building functions.
[3] e.g., making a free clim, calling gtk through a ffi.
--
J o h a n K u l l s t a m
[········@ne.mediaone.net]
Don't Fear the Penguin!
Johan Kullstam <········@ne.mediaone.net> wrote:
>you can use the linux trial edition. you can use clisp or cmucl.
>so there are systems you can use. i agree that gui construction ought
>to be a natural for lisp and that the trial editions do not make it as
>readily available as, e.g., visual basic[2].
>[2] visual basic while a weak programming language gives access to
> many gui building functions.
acl5 for windows has a V-alike GUI builder, just a little bit better.
in a free trial edition.
visual basic for windows has no free trial edition.
unix is a different story, but there you have at least garnet for free.
--
Reini
In article <··············@sophia.axel.nom>, Johan Kullstam <········@ne.mediaone.net> wrote:
> > I called Franz a while back to find out about how much it would cost me
> > to get a Lisp system for use on my Linux box as a learning tool (I am
> > in grad school). I wanted to be able to use CLIM. The cost was
> > somewhere upwards of $1500.00.
The Professional Edition of LispWorks 4.1 for the Windows platform
is priced at $799. LispWorks for Linux is currently in beta.
I guess it will priced similarly.
Yes, it includes CLIM 2.
Yes, you can deliver applications royalty free.
Yes, it has an IDE.
http://www.harlequin.com/products/ads/lisp/
http://services.harlequin.com/lisp/lwl.nsf/RegistrationPersonal?OpenForm
Fernando Mato Mira wrote in message <·················@iname.com>...
>Rainer Joswig wrote:
>
>> Yes, you can deliver applications royalty free.
>
>Can you use LOAD-FILE royalty-free?
IIRC, essentially, as long as your "product" isn't a "Lisp Development
Environment" or similiar, you can pretty much do anything you want.
I do get the impression that there may be some kind of extra licensing
involved with deployment of the Enterprise Edition however (i.e. the CORBA
stuff I imagine), but I'm not sure.
I was going to upgrade to 4.1 but they removed the ODBC drivers and put that
into their Enterprise Edition. But with the free ODBC layer available,
perhaps I'll reconsider.
Best Regards,
Will Hartung
(······@home.com)
"Will Hartung" <······@home.com> writes:
> Fernando Mato Mira wrote in message <·················@iname.com>...
> >Rainer Joswig wrote:
> >
> >> Yes, you can deliver applications royalty free.
> >
> >Can you use LOAD-FILE royalty-free?
>
>
> IIRC, essentially, as long as your "product" isn't a "Lisp Development
> Environment" or similiar, you can pretty much do anything you want.
>
> I do get the impression that there may be some kind of extra licensing
> involved with deployment of the Enterprise Edition however (i.e. the CORBA
> stuff I imagine), but I'm not sure.
>
> I was going to upgrade to 4.1 but they removed the ODBC drivers and put that
> into their Enterprise Edition. But with the free ODBC layer available,
> perhaps I'll reconsider.
>
> Best Regards,
>
> Will Hartung
> (······@home.com)
I believe they charge *much* more if you want the ability to compile
generated source files in the delivered application. For instance,
compiling a rules file in an expert system.
Sunil
>
> Without free or low priced complete lisp systems (a system
> without a GUI
> is not a system in todays market) available, the market will
> not grow.
The opportunity is there with CL-HTTP...a web system--the GUI part is
the
browser + HTML. Stear clear of javascript and non-standard tags,
just don't go there. Stick to fundamental page layout and server
round-trip.
Frames are clunky.
* ·······@pug1.sprocketshop.com (Kenneth P. Turvey)
| Without free or low priced complete lisp systems (a system without a GUI
| is not a system in todays market) available, the market will not grow.
is there any other market for which this is true and which you can make a
reasonable comparison with, or are you making a claim that software is
unique? if the latter, I'd be much more interested in your reasoning
than in your conclusion.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
On Wed, 14 Jul 1999 17:35:09 GMT, Kent M Pitman <······@world.std.com>
wrote:
> ... people should not lament the passing of things they are not
>willing to invest in. This newsgroup has a number of people
>who my sense is both want a lot of free things and want to debug why
>Lisp is in the trouble it's in.
Agreed.
> ... the fact is that there are a LOT of free offerings of Lisp
>and of good quality.
Now. I remember things being pretty difficult to find in the days
before the World Wide Wait - even with pointers.
George Neuner
Dynamic Resolutions, Inc.
===================================================
The opinions expressed herein are my own and do not
reflect the opinions or policies of my employer.
===================================================
In article <··················@asgard>,
·······@dyn.com (George Neuner) writes:
> On Wed, 14 Jul 1999 17:35:09 GMT, Kent M Pitman <······@world.std.com>
> wrote:
>
>> ... people should not lament the passing of things they are not
>>willing to invest in. This newsgroup has a number of people
>>who my sense is both want a lot of free things and want to debug why
>>Lisp is in the trouble it's in.
>
> Agreed.
The problem is that the cost to investigate whether its worth investing
in is somewhat steep.
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
* ··@inferno.nirvananet (Hartmann Schaffer)
| The problem is that the cost to investigate whether its worth investing
| in is somewhat steep.
this must have been in the times of _really_ expensive long distance or
international phone calls. if you get a system for a period to try it
out, without paying for it or with a full refund policy, what does it
_take_ to satisfy your demands? I don't know a single market where you
are actively disallowed from determining whether you can use a product
_except_ software _other_ than Lisp environments. and considering that
people can learn Common Lisp with free environments, just what are you
going to consider before investing in a commercial environment that needs
it to be free or extremely low-cost?
all of you guys who scream and shout about low-cost Common Lisp systems,
do you _really_ go out and _buy_ the low-cost versions of all the
environments of all the languages out there to try them out? I don't
think anybody actually does that. if you wanted to take a test-drive,
how come you accept the policies that come with shrink-wrapped software?
I wonder: what is the _real_ argument behind all these weird claims?
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
In article <················@naggum.no>,
Erik Naggum <····@naggum.no> writes:
> * ··@inferno.nirvananet (Hartmann Schaffer)
>| The problem is that the cost to investigate whether its worth investing
>| in is somewhat steep.
>
> this must have been in the times of _really_ expensive long distance or
> international phone calls. if you get a system for a period to try it
> out, without paying for it or with a full refund policy, what does it
> _take_ to satisfy your demands? I don't know a single market where you
> are actively disallowed from determining whether you can use a product
> _except_ software _other_ than Lisp environments. and considering that
Thanks for that information. I was under the impression you have to buy
it.
> people can learn Common Lisp with free environments, just what are you
> going to consider before investing in a commercial environment that needs
> it to be free or extremely low-cost?
You really can't learn CLIM in a free environment, and one of the posts
in this thread mentioned a pretty high $ figure to get a version with
CLIM.
> all of you guys who scream and shout about low-cost Common Lisp systems,
Was I scrteaming????
> do you _really_ go out and _buy_ the low-cost versions of all the
> environments of all the languages out there to try them out? I don't
> think anybody actually does that. if you wanted to take a test-drive,
> how come you accept the policies that come with shrink-wrapped software?
>
> I wonder: what is the _real_ argument behind all these weird claims?
>
> #:Erik
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
* Hartmann Schaffer
| You really can't learn CLIM in a free environment, and one of the posts
| in this thread mentioned a pretty high $ figure to get a version with
| CLIM.
so people who can't use Lisp for free won't know that they should use it
because they don't know what it is, but people know they should use CLIM
and can't because it isn't free? I don't get it. how did they discover
the need to use CLIM to begin with?
there's something going on that is not at all about the issues you guys
keep dragging up. this is _so_ not about free environments! can't you
guys do us all a favor and stop hitting on that single argument and be a
little more precise in what you're _actually_ after? this is just like
listening to people who have thought up a solution to all the world's
problems and keep whining that nobody will do as they say. that's not
how this world works. you can't decide for yourself that you have the
solution and then go apply it to all problems.
where is this "free environment" requirement _coming_ from? people go
through their very expensive educations, most spend half their life
paying back the loans or saving up for their own kids to get educated,
and then they suddenly want one particular thing for free or they won't
even try, but will instead sit there and whine that it isn't free. who
gives a fuck about these people? _I_ don't want to give such people
anything at all, especially not for free. I don't expect those who have
what they want to have very different sentiments, even if they, like me,
have given away tremendous amount of work and values previously.
what happens when CLIM is available for free? hey, it might need MOTIF.
whine, whine, MOTIF isn't free, so we can't use CLIM, and we can't use
Common Lisp because we can't use CLIM, and life is hell, or whatever.
what I _really_ don't understand is why you guys all want somebody else
to take a huge risk (providing expensive software for free) when you
obviously won't take the slightest risk yourselves (spend the time to
learn something from the manuals).
what's hugely important in the free software world is to distinguish
those who will not stop asking for more from those who can make do with
whatever they get and return something useful to the community. I have
come to conclude that the successes of those who cry for more has made it
hard for those who want to work something out for themselves to keep up
their spirits. in my view, whining should be punishable by law, and
parents who give in to whining should be punished, too, because I guess
the only reason grown men whine when they can't get something for free is
that they are reduced to children who don't get what they want from
whoever they still think has an obligation to cater to their needs, and
they could only have learned that from weak-willed, unfit parents.
make take on this is: just fucking do it. we're programmers, damn it!
the whole _point_ is to bring stuff into existence that exist merely in
our dreams and on our wish lists. yeah, it sucks that we have to live
with inferior solutions instead of perfection all around us all the time.
yeah, programming is frustrating at the very core of the task, but do we
not do this because we want to solve problems that are too hard to do
manually all the time? why does this not apply to our own tools? and if
it does apply, why does it _have_ to be free? I really don't get this.
we can only expect that which is extremely well-known to be free, because
the dilution of investment that this information society is all about is
itself an extremely expensive process -- making a new concept into common
knowledge is estimated to cost more than 10 billion dollars, and it has
to be a community effort, with journalists, authors, teachers, and even
politicians involved in its spread. it is clear to me that graphic user
interfaces and window systems are still largely unknown technologies and
that getting it usefully right involves a serious investment in genius
time. in particular, doing something that is intended to track the
myriad failures that Microsoft is going through with their random trial
and error-based development process with beta-testing using customers and
software developers who do it only because they are afraid to be left
behind the times, is doomed to equal or greater failure from the start.
to get this stuff right probably needs a whole new infrastructure, and
that won't happen until the paranoid psychotic behavior of Microsoft is
stopped and people can actually begin to develop real software again.
my suggestion is to write software that is completely independent of its
graphic user interface, using protocols and very abstract programming
interfaces between the user interface module and the functionality that
enables a protection of investment in the functionality even while the
user interface keeps changing. sadly, this is not a programming style
that "modern" programmers know how to write, because they have been
reduced to deal with user interfaces that invade the entire system.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
On 19 Jul 1999 14:12:47 +0000, Erik Naggum <····@naggum.no> wrote:
> what's hugely important in the free software world is to distinguish
> those who will not stop asking for more from those who can make do with
> whatever they get and return something useful to the community. I have
> come to conclude that the successes of those who cry for more has made it
> hard for those who want to work something out for themselves to keep up
> their spirits. in my view, whining should be punishable by law, and
> parents who give in to whining should be punished, too, because I guess
> the only reason grown men whine when they can't get something for free is
> that they are reduced to children who don't get what they want from
> whoever they still think has an obligation to cater to their needs, and
> they could only have learned that from weak-willed, unfit parents.
Don't bring law into this - laws were invented to prevent the masses
from participating in the activities of the priviledged. Whining
should be punished with a bitch slap, not a criminal proceeding.
Nature takes the path of least resistance, thus humans naturally want
something for nothing. We all do. Part of growing up is learning
that the world doesn't work that way (at least most of the time and
when you can keep liberals away from the budget).
> make take on this is: just fucking do it. we're programmers, damn it!
> the whole _point_ is to bring stuff into existence that exist merely in
> our dreams and on our wish lists. yeah, it sucks that we have to live
> with inferior solutions instead of perfection all around us all the time.
> yeah, programming is frustrating at the very core of the task, but do we
> not do this because we want to solve problems that are too hard to do
> manually all the time? why does this not apply to our own tools? and if
> it does apply, why does it _have_ to be free? I really don't get this.
>
Check the other language boards - there is always somebody looking for
a free implementation. It's pervasive.
I think part of the problem is the environment in which Lisp was
originally developed - the college hacker community which McCarthy
used as his work force. In this particular venue, software was viewed
much as literature; to be read, enjoyed and learned from.
Unix in general suffers from the same fate - most people know that
AT&T licensed the source for Unix and the development system to
universities, basically for nothing, for years. They really didn't
treat Unix as a product until version 7.
All of us who went through college during this period and did any
computing became accustomed to the use of free (more rightly
"subsidized") software. Was it a good thing? Probably not given the
trend today of treating every burp as "intellectual property" and
suing at the drop of a hat.
Hindsight is perfect - foresight is cloudy at best.
George Neuner
Dynamic Resolutions, Inc.
===================================================
The opinions expressed herein are my own and do not
reflect the opinions or policies of my employer.
===================================================
·······@dyn.com (George Neuner) writes:
>
> Nature takes the path of least resistance, thus humans naturally want
> something for nothing. We all do. Part of growing up is learning
> that the world doesn't work that way (at least most of the time and
> when you can keep liberals away from the budget).
Speak for yourself- its somewhat of an oversimplification to assume
one knows how the world works- or to have certainty about what humans
want and don't want. Or that liberals are the only things that screw
up budgets.
> Check the other language boards - there is always somebody looking for
> a free implementation. It's pervasive.
Likewise, to impune motives to a group based on the actions of a
given, non-zero and variable percentage of fruits, nuts and flakes is
also an oversimplification. Not all who like OpenSource (or whichever
acronym you choose) think all software must be free- or that people
are somehow beholden to offer their laboriously coded systems for
nothing.
>
> All of us who went through college during this period and did any
> computing became accustomed to the use of free (more rightly
> "subsidized") software. Was it a good thing? Probably not given the
> trend today of treating every burp as "intellectual property" and
> suing at the drop of a hat.
I think this phenomenon is due to other causes than a particular
software development technique. Consider how many frivolus lawsuits
occur in other areas- software is another natural victim to the
pathology.
Gregm
On 19 Jul 1999 13:21:02 -0400, Greg Menke <······@erols.com> wrote:
>·······@dyn.com (George Neuner) writes:
>>
>> Nature takes the path of least resistance, thus humans naturally want
>> something for nothing. We all do. Part of growing up is learning
>> that the world doesn't work that way (at least most of the time and
>> when you can keep liberals away from the budget).
>
>Speak for yourself- its somewhat of an oversimplification to assume
>one knows how the world works- or to have certainty about what humans
>want and don't want. Or that liberals are the only things that screw
>up budgets.
>
I would claim that there is ample empirical evidence for the least
resistance argument, but the debate is for another board. So too
liberals - they may not be the only that screw up budgets, but they
are definately the only ones that waste MY resources.
>> Check the other language boards - there is always somebody looking for
>> a free implementation. It's pervasive.
>
>Likewise, to impune motives to a group based on the actions of a
>given, non-zero and variable percentage of fruits, nuts and flakes is
>also an oversimplification. Not all who like OpenSource (or whichever
>acronym you choose) think all software must be free- or that people
>are somehow beholden to offer their laboriously coded systems for
>nothing.
I'm not "impuning" anything - I'm stating a fact.
>
>>
>> All of us who went through college during this period and did any
>> computing became accustomed to the use of free (more rightly
>> "subsidized") software. Was it a good thing? Probably not given the
>> trend today of treating every burp as "intellectual property" and
>> suing at the drop of a hat.
>
>I think this phenomenon is due to other causes than a particular
>software development technique. Consider how many frivolus lawsuits
>occur in other areas- software is another natural victim to the
>pathology.
You're correct - it has nothing whatever to do with any particular
field or subject. Society has simply become lawsuit happy.
George Neuner
Dynamic Resolutions, Inc.
===================================================
The opinions expressed herein are my own and do not
reflect the opinions or policies of my employer.
===================================================
·······@dyn.com (George Neuner) writes:
> On 19 Jul 1999 13:21:02 -0400, Greg Menke <······@erols.com> wrote:
...
> I would claim that there is ample empirical evidence for the least
> resistance argument, but the debate is for another board. So too
> liberals - they may not be the only that screw up budgets, but they
> are definately the only ones that waste MY resources.
Please get this thread out of here ASAP. Usually it is conservatives
sounding remarks like this in newsgroup who make ME wast my time and
resources :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
George Neuner wrote:
> On 19 Jul 1999 13:21:02 -0400, Greg Menke <······@erols.com> wrote:
>
> >·······@dyn.com (George Neuner) writes:
> >>
> >> Nature takes the path of least resistance, thus humans naturally want
> >> something for nothing. We all do. Part of growing up is learning
> >> that the world doesn't work that way (at least most of the time and
> >> when you can keep liberals away from the budget).
> >
> >Speak for yourself- its somewhat of an oversimplification to assume
> >one knows how the world works- or to have certainty about what humans
> >want and don't want. Or that liberals are the only things that screw
> >up budgets.
> >
>
> I would claim that there is ample empirical evidence for the least
> resistance argument, but the debate is for another board.
That's true, but you are the one who brought it up here.
> So too
> liberals - they may not be the only that screw up budgets, but they
> are definately the only ones that waste MY resources.
Depends. I'd say you're either fabously wealthy or very foolish
if you beleive this, but again it's a debate for another area.
dave
Erik Naggum <····@naggum.no> writes:
> what I _really_ don't understand is why you guys all want somebody else
> to take a huge risk (providing expensive software for free) when you
> obviously won't take the slightest risk yourselves (spend the time to
> learn something from the manuals).
Agreed!
Those who write the code get to choose the license, no whining
allowed. It's a truism, but it seems to be forgotten quite often.
Lisp systems require a tremendous amount of resources to produce in
their entirety. They are on the outer edge of what Free Software
production practices are capable of creating, and these systems are
not even complete. Even if someone GAVE us a free CL, there is IMO,
no way it could be supported without significant infrastructure. It
is indeed expensive software, very expensive to produce and maintain.
This does not mean privatisation of that code base, but at least an
organization who is making a significant investment in the system.
Cygnus and others provided these resources for gcc, without which the
compiler would be nowhere near as usable and portable as it is today.
Despite recent hype, Free Software does not maintain itself.
Harlequin and Franz have put *tremendous* effort and resources into
their systems, that cannot be overlooked.
The code bases are their already in CMUCL, CLisp and others. So you
can help build the infrastructure to maintain these giant systems by
either becoming a developer yourself and contributing your time and
energy, or you could find a way to get more developers involved. One
way to do that is to pay people to work on the system. That might
mean starting a company that sells support contracts or customization
work or any other Free Software business model.
I think that competitive and complete Free Lisp systems are a
possibility, but not by whining for the commercial vendors to free
their investments as loss leaders or something of that sort. Those
who want it need to take responsibility for making it happen, and that
means giving energy, time, and thought to how it can be done.
> what's hugely important in the free software world is to distinguish
> those who will not stop asking for more from those who can make do with
> whatever they get and return something useful to the community. I have
> come to conclude that the successes of those who cry for more has made it
> hard for those who want to work something out for themselves to keep up
> their spirits.
No idea where this came from but I think it's fitting:
"Just because it's free doesn't mean you can afford it."
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
I say woe unto those who are wise in their own eyes, and yet
imprudent in 'dem outside -Sizzla
Craig Brozefsky <·····@red-bean.com> writes:
...
> I think that competitive and complete Free Lisp systems are a
> possibility, but not by whining for the commercial vendors to free
> their investments as loss leaders or something of that sort.
Since when using "loss leaders" is considered bad business practice?
I am *not* asking CLIM for free. I am asking why Franz and
Harlequin keep distributing Common Windows and CAPI *bundled* (read:
almost "gratis") with their systems (even the "free" editions
downloadable from the net), instead of phasing them out and start
shipping CLIM in the *same* fashion instead (i.e. with no extra
charge). (Alright, Harlequin seems to be doing something like that
when you by their Professional Edition).
I believe that all the developers in those outfits see this point.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Kent M Pitman
Subject: Re: Free Lisp Responsibilities Was: Is LISP dying?
Date:
Message-ID: <sfwvhbf5syc.fsf@world.std.com>
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
> I am *not* asking CLIM for free. I am asking why Franz and
> Harlequin keep distributing Common Windows and CAPI *bundled* (read:
> almost "gratis") with their systems (even the "free" editions
> downloadable from the net), instead of phasing them out and start
> shipping CLIM in the *same* fashion instead (i.e. with no extra
> charge).
I have NO knowledge of why Frand and Harlequin do as they do, BUT one
thought you should consider is that it costs too much to support people
who use CLIM and perhaps they are making sure they don't introduce a
support nightmare by making it too accessible.
It is a fact about marketing that the lower the cost, the larger the
potential market. For any product that requires potentially a lot of
support, it is a disaster to price it too low. That would imply a lot
of parallelism in the discontent created.
The fact is that CLIM, while very powerful, is also very hard to QA
because there are so many promises it makes and there is no "normative
programming model" that would lead a QA department to be able to say
"if only we did this much, we'd cover 90% of uses".
There was a time in the past when I think CLIM should have been
aggressively pursued. Now, without a large cash infusion to do
various redesign things, I'm not so sure. I think open-sourcing is
a nice compromise because it places the support burden on the user
base and focuses vendors squarely back on developing new product of
other kinds, which I think is a better use of their time.
CLIM's process/thread model, graphic context model, stream model,
event model, etc. seem to me all just enough off center from what's
being done in the standard marketplace that Lisp programmers need to
interface to at the base level, that I would prefer to see a CAPI/CG
style interface of native, event-based widgets standardized for the
community and CLIM thought of, like Waters iteration stuff, as an
optional extera for things that like that kind of thing.
In article <···············@world.std.com>, Kent M Pitman <······@world.std.com> wrote:
> The fact is that CLIM, while very powerful, is also very hard to QA
> because there are so many promises it makes and there is no "normative
> programming model" that would lead a QA department to be able to say
> "if only we did this much, we'd cover 90% of uses".
One thing that's necessary: Tools that are based on CLIM and
make CLIM programming more accessible.
Stuff like graphical inspectors, interface designers,
presentation inspectors, menu designer, command interpreter
inspectors, a graphical component model, an inspector
for layouts, output record inspector, ...
I always wondered how one should work with a UIMS without
*graphical* tools or tools at all.
But that's not how it should be.
No wonder people get lost and it has no "success".
You can't expect that (besides the implementors) have
all the classes, constants and functions in their head -
even the documentation is too complex for an end user
(-> a Lisp programmer who to develop a UI).
It's also one essence of Lisp programming -> tool building
to manage complexity.
Rainer Joswig
Kent M Pitman <······@world.std.com> writes:
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> writes:
>
> > I am *not* asking CLIM for free. I am asking why Franz and
> > Harlequin keep distributing Common Windows and CAPI *bundled* (read:
> > almost "gratis") with their systems (even the "free" editions
> > downloadable from the net), instead of phasing them out and start
> > shipping CLIM in the *same* fashion instead (i.e. with no extra
> > charge).
>
> I have NO knowledge of why Frand and Harlequin do as they do, BUT one
> thought you should consider is that it costs too much to support people
> who use CLIM and perhaps they are making sure they don't introduce a
> support nightmare by making it too accessible.
I understand this. Mine is a perfect example of "perfect hindsight" :)
...
> CLIM's process/thread model, graphic context model, stream model,
> event model, etc. seem to me all just enough off center from what's
> being done in the standard marketplace that Lisp programmers need to
> interface to at the base level, that I would prefer to see a CAPI/CG
> style interface of native, event-based widgets standardized for the
> community and CLIM thought of, like Waters iteration stuff, as an
> optional extera for things that like that kind of thing.
Not an easy thing to do. It would still require the vendors to agree
on *one* thing and then have them both ship it as standard. This is
very unlikely to happen and in the long run harmful to the (small)
Lisp community as a whole, hence to the vendors.
(COMMA-22-P) => T
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
On 21 Jul 1999 10:49:42 +0200,
Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
>
>Not an easy thing to do. It would still require the vendors to agree
>on *one* thing and then have them both ship it as standard. This is
>very unlikely to happen and in the long run harmful to the (small)
>Lisp community as a whole, hence to the vendors.
OK, I'll bite. Why is it harmful to have one good standard instead of
several competing standards when you have a _small_ Lisp community. It
would seem that competing standards divide an already limited mindshare.
--
Kenneth P. Turvey <·······@SprocketShop.com>
----------------- http://www.tranquility.net/~kturvey
Every country has the government it deserves.
-- Joseph de Maistre
·······@pug1.sprocketshop.com (Kenneth P. Turvey) writes:
> On 21 Jul 1999 10:49:42 +0200,
> Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> >
> >Not an easy thing to do. It would still require the vendors to agree
> >on *one* thing and then have them both ship it as standard. This is
> >very unlikely to happen and in the long run harmful to the (small)
> >Lisp community as a whole, hence to the vendors.
>
> OK, I'll bite. Why is it harmful to have one good standard instead of
> several competing standards when you have a _small_ Lisp community. It
> would seem that competing standards divide an already limited mindshare.
That is exactly my point. "Divide et impera" works with (single) watermellons,
not with (single) peas :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> Since when using "loss leaders" is considered bad business practice?
>
> I am *not* asking CLIM for free. I am asking why Franz and
> Harlequin keep distributing Common Windows and CAPI *bundled* (read:
> almost "gratis") with their systems (even the "free" editions
> downloadable from the net), instead of phasing them out and start
> shipping CLIM in the *same* fashion instead (i.e. with no extra
> charge). (Alright, Harlequin seems to be doing something like that
> when you by their Professional Edition).
What I always find amazing is that MCL has massive amounts
of UI code available. There are a lot of contributions by
users. Complete Quicktime interfaces for multimedia stuff,
video digitizers, speech recognition and generation, ...
Then look what for the other platforms is available
as usable UI code.
Compare the contributions directory for MCL in CL-HTTP
with those for other implementations. Compare that
to the size of the MCL platform: the few remaining Macs.
They must have done something right:
MCL ships with almost complete source code for the
user interface stuff:
Editor, Tools, Interface Designer,
Menus, Windows, Dialogs, Widgets, IPC, Processes,
Read-Eval-Print loop, networking, some stuff from Common Lisp
itself, ... It's a bit like Genera (where you have
much of the source for the OS). You can
type "process-run-function" and press Meta-. and
you get the source.
On the other hand, LispWorks ships with no source.
CLIM ships with no source. Does ACL come with source?
I would like a more open approach to delivery of
source code. Let people read and learn, let them
change it, let them write new versions, let them
improve things, ... - if you fear that users will
break things, then you are already dead.
Everything that helps application writers must be of
high priority.
From: Erik Naggum
Subject: Re: Free Lisp Responsibilities Was: Is LISP dying?
Date:
Message-ID: <3141793934910677@naggum.no>
* ······@lavielle.com (Rainer Joswig)
| On the other hand, LispWorks ships with no source.
| CLIM ships with no source. Does ACL come with source?
Allegro CL comes with a lot of source for paying licensees who send in an
additional license agreement. it allows local modifications, but not in
any way redistribution to non-licensees.
| I would like a more open approach to delivery of source code. Let people
| read and learn, let them change it, let them write new versions, let them
| improve things, ... - if you fear that users will break things, then you
| are already dead.
I wonder why you ignore the existence of the many really destructive
people out there. there are people who are not going to be constructive
no matter what you say or give or do to them, and you can't require a
psychological profile of your customers before you give them source,
either. obviously, protecting yourself from an unknown enemy will always
look like you're casting unknown people as enemies, but the onus of proof
that he is no enemy is on the unknown person, who should easily be able
to make himself sufficiently well known. failure to do so would be a
reason not to divulge that which could harm.
| Everything that helps application writers must be of high priority.
I consider the survival of the company who provides the application
writer with his tools to be a higher priority, not just for the company,
but for the next application writer who wants the same tools.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Christopher R. Barry wrote: [1999-07-20 00:17 +0000]
> Erik Naggum <····@naggum.no> writes:
[...]
> > my suggestion is to write software that is completely independent of its
> > graphic user interface, using protocols and very abstract programming
> > interfaces between the user interface module and the functionality that
> > enables a protection of investment in the functionality even while the
> > user interface keeps changing. sadly, this is not a programming style
> > that "modern" programmers know how to write, because they have been
> > reduced to deal with user interfaces that invade the entire system.
>
> Have you _used_ CLIM?
>
> This abstract approach works between GUI tools that work
> similarly. For example, with GTK, Motif, QT, Swing or 99% of other
> tools out there you basically begin by creating a window, then layout
> basic areas of your app using the GUI tools' implementation of the
> layout manager concept, then add a menubar and menus, buttons,
> scrollbars and myriad other widgets and gizmos, and then you finally
> associate mouse and keyboard events with these objects with your
> program's control-flow.
>
> With CLIM you don't spend your time laying out widgets and then set
> them up to handle "low-level" keyboard and mouse events. (Though it
> supports this paradigm kinda like Lisp supports the BASIC/flowchart
> control-flow paradigm via TAGBODY/GO, but I digress....) CLIM actually
> has very few widgets; it doesn't even have pull-down menus and
> menubars that 99% of GUI apps nowadays have. (Though it has all the
> primitive functionality you need to implement them and I think there
> is a free implementation floating around the net like at the AI
> Repository or something....)
>
> Anyways, saying that you can write an application with a graphical
> user interface using abstract protocols and abstract programming
> interfaces and then using Motif or Emacs as the tool to the
> realization of your application's GUI is as meaningful as saying that
> you can write a program using abstract concepts of OO and control-flow
> so as to be independant of the implementation language and then
> writing it in C.
I think this is missing the point. (Note: I am not writing this on Erik
Naggum's `behalf,' as it were, but to show that somebody else also
understands this issue in such a way.)
The point about the abstract protocol and interface is this. An
application with a user interface should not be built as one
homogeneous whole. In other words, many (or most) GUI
applications are built as a `single agent,' where the part that
does the actual work is intertwined (in an inseparable way) with
the part that takes care of interacting with the user. (Very roughly
speaking, the `work loop' of the application and the `UI loop' handling
GUI events are one and the same loop.)
A much better approach is to build the application as a system of at
least two separate agents, one being the `work horse' taking care of
the working functionality and the other being the `front end' taking
care of the user. The interaction between the two agents is done
according to a protocol that is, among other things, independent of
the particular nature of the user interface. Thus, for example, one
could substitute a GUI for a command-line interface just by replacing
the second agent, and both versions would have the same user
functionality (though they would differ in ease of use, user productivity,
etc. (note that I just say `differ': I am not going here into details which
one is better, and in what aspects)).
This is not something new, of course. Client-server systems are a
particular case of this architectural principle. Consider, for example,
that the interaction between an FTP server and an FTP client is based
upon an abstract protocol that can express the functionality of file
transfer, and the client can be controlled by a command line or
a GUI and the user can run any kind of client at will. (The case with
HTTP is more complicated as some of the UI functionality is
represented in the content being exchanged, i.e. in the HTML tags
in the pages, possibly containing JavaScript or Java code, etc.)
(What I have written above is essentially repeating Erik Naggum's
point in more words.)
[...]
> Lisp is a good language for creating, for example, a
> real-time news distribution system for a financial news agency and
> CLIM is a good GUI tool for creating an intuitive, natural and
> powerful monitoring and control application for a real-time news
> distribution system that facilitates the exploration of and recovering
> from error conditions in a very efficient and natural way and lets you
> quickly pick out what you are looking for from 30MB of logging
> information and enables you to generate different kinds mouse
> sensitive information displays and reports from real-time and log
> information in a very efficient, cool and attractive way (not to
> mention printer-friendly), without needing 6 menus on a menubar each
> containing their own nested menus and about 15 buttons and widgets and
> text entry fields and a help menu giving documention on what all that
> crap does, or needing to type in forms into a listener after figuring
> out what it is you need to type and painstakingly writing a custom
> parser to check errors at read time or some other way if you plan on
> giving your users some control and customization ability via typing in
> forms directly.
Just for the record, this sentence contains 193 words (and no indentation).
[...]
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
In article <·····················@195.138.129.92>, Vassil Nikolov <········@poboxes.com> wrote:
> The point about the abstract protocol and interface is this. An
> application with a user interface should not be built as one
> homogeneous whole.
But, this is *exactly* the point of CLIM. That's the big
difference between CLIM and ***all*** the other UIMS
out there. It has the presentation system.
CLIM makes it possible to decouple your user interface
from your application logic as max as possible.
All your UI code works on the real objects. CLIM
manages to keep the connections between screen
pixels and application objects.
Additionally it provides the abstractions to
change the command invocations as you like.
CLIM provides a very abstract interface to UIs,
on top of its lower levels.
Simplified strategy for a CLIM UI:
1) write you application (classes, methods, ...)
2) declare an application frame
3) define presentation classes based on your application classes
4) write present methods for the presentation classes
5) write accept methods for the presentation classes
6) write commands that interface to your application
logic
7) write special UI code called by these commands
8) determine how you would like to invoke those commands
······@lavielle.com (Rainer Joswig) writes:
> In article <·····················@195.138.129.92>, Vassil Nikolov <········@poboxes.com> wrote:
>
> > The point about the abstract protocol and interface is this. An
> > application with a user interface should not be built as one
> > homogeneous whole.
>
> But, this is *exactly* the point of CLIM. That's the big
> difference between CLIM and ***all*** the other UIMS
> out there. It has the presentation system.
>
> CLIM makes it possible to decouple your user interface
> from your application logic as max as possible.
> All your UI code works on the real objects. CLIM
> manages to keep the connections between screen
> pixels and application objects.
>
> Additionally it provides the abstractions to
> change the command invocations as you like.
>
>
> CLIM provides a very abstract interface to UIs,
> on top of its lower levels.
>
>
> Simplified strategy for a CLIM UI:
>
> 1) write you application (classes, methods, ...)
Fine.
>
> 2) declare an application frame
Ok.
>
> 3) define presentation classes based on your application classes
Now. This is the sticky point. It turns out that when I did some GUI
work, I ended up with writing quote - presentation classes -
unquote. (I was not using CLIM). My understanding is that one of the
major "advantages" about CLIM is that all of this things already there
for you and you can extend it in an easy way.
>
> 4) write present methods for the presentation classes
>
> 5) write accept methods for the presentation classes
>
> 6) write commands that interface to your application
> logic
This is another very sticky point IMHO. I never quite understood why
"commands" ought to be that different from "functions" (parsing and
completion apart). My experience with CLIM is very limited, but it
really seemed to me that there was something "too much", once you got to
commands and the like.
> 7) write special UI code called by these commands
Like popping up a menu?
>
> 8) determine how you would like to invoke those commands
By selecting a menu item?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> > 3) define presentation classes based on your application classes
>
> Now. This is the sticky point. It turns out that when I did some GUI
> work, I ended up with writing quote - presentation classes -
> unquote. (I was not using CLIM). My understanding is that one of the
> major "advantages" about CLIM is that all of this things already there
> for you and you can extend it in an easy way.
Usual CLOS classes can be used as presentation classes.
But sometimes you want to extend the CLASS hierarchy.
An integer is an integer. But what purpose has it?
Is it a year, a bank account number, your age in years, ...
A bank account number should be translateable to
the actual bank account object, ...
> > 6) write commands that interface to your application
> > logic
>
> This is another very sticky point IMHO. I never quite understood why
> "commands" ought to be that different from "functions" (parsing and
> completion apart). My experience with CLIM is very limited, but it
> really seemed to me that there was something "too much", once you got to
> commands and the like.
No, commands are something more complex. They are abstractions
about what the user can do in your application and
how he can do it.
- You need type information for the parameters
- You want to provide completion facilities
- You want to say how a command can be invoked (menu, key, command line,
click on an object, ...).
- you want to provide help, defaults, output redirection, ...
- you want to organize them in command tables
- ...
> > 7) write special UI code called by these commands
>
> Like popping up a menu?
Maybe, or like drawing graphs and presenting your
application objects in these graphs.
> > 8) determine how you would like to invoke those commands
>
> By selecting a menu item?
Pressing a keyboard accelerator, from the mouse-right click context
sensitve menu, via a command translator, ...
Then you might want to invoke commands via an speech interface or
over the web ...
From: Lars Bj�nnes
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <m3emi3rzgs.fsf@enterprise.gdpm.no>
······@lavielle.com (Rainer Joswig) writes:
[snip]
> Then you might want to invoke commands via an speech interface or
> over the web ...
(I've little knowledge of CLIM, but this got me interested)
Is there a 'web-gateway' for CLIM? I've seen similar solutions (4D),
but many of them are using non-standard HTML, Javascript-hell etc.
HTML 4.0 opens up a wide range of possibilities for creating more
professional UIs than with the earlier standards. Features like
grouping of fields, access-keys, labels etc. are very useful and
much of it will be supported by the new browsers[0].
We're currently using CL-HTTP in a project[1], but the opportunity of
supporting a wider range of clients with CLIM is very tempting.
Please tell me I'm not dreaming. :-)
[0] Mozilla, Opera, IE 5.x
[1] we're very happy with CL-HTTP so far
--
Lars
From: Robert Monfera
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <3794EA8A.DFB7F31A@fisec.com>
"Lars Bj�nnes" wrote:
...
> Is there a 'web-gateway' for CLIM? I've seen similar solutions (4D),
Maybe someone could comment on W3P, which is distributed with CL-HTTP.
> but many of them are using non-standard HTML, Javascript-hell etc.
What's wrong with javascript? If you need dynamic behavior on the client
side (e.g., you have dial-in users), what else are you going to use?
Say, how are you going to insert a new row in a table without having to
reload the whole table? Javascript is, by the way, closer to lisp than
Java or VB anyway.
By the way: does someone know if it is possible to use the Document
Object Model using CORBA? With which browser? (CORBA DOM bindings are
specified in the recommendations).
> HTML 4.0 opens up a wide range of possibilities for creating more
> professional UIs than with the earlier standards. Features like
> grouping of fields, access-keys, labels etc. are very useful and
> much of it will be supported by the new browsers[0].
Yes, and DOM and CSS are also significant standards/recommendations.
From: Lars Bj�nnes
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <m3zp0qri18.fsf@enterprise.gdpm.no>
Robert Monfera <·······@fisec.com> writes:
> What's wrong with javascript? If you need dynamic behavior on the client
> side (e.g., you have dial-in users), what else are you going to use?
> Say, how are you going to insert a new row in a table without having to
> reload the whole table?
And commit the transaction to the server? [0]
Off-topic: What's wrong with javascript?
I spent 3 years of my life struggling with javascript. Why?
My incompetence and reluctance to quit a job could be one reason, but
there are certainly others:
1. No standard implementation what-so-ever from any vendor.
(With ECMAScript, this is hopefully _about_ to change, but don't
expect anything soon. I put my faith in Opera and Mozilla.)
2. For the time being, no DOM that complies to the standards.
That is, not a (broad) selection of browsers which support the
same DOM. Layers? DIV?
Even something as simple as referring to the current location of an
HTML-document in JS has been implemented in several incompatible
ways. (Even from the same vendor, if my memory serves me right.)
3. Many users have javascript turned off or it's stripped by a
proxy-server.
4. Security.
</rant>
> By the way: does someone know if it is possible to use the Document
> Object Model using CORBA? With which browser? (CORBA DOM bindings are
> specified in the recommendations).
A tough one. I'd guess you could use a COM->CORBA bridge and access
IE's DOM that way. It is possible that Netscape, in a politically correct
moment, has implemented a pure CORBA solution, but I've never heard
of it.
> Yes, and DOM and CSS are also significant standards/recommendations.
Agreed. It would have been wonderful if it would've been an easy
way to generate standard client/server-apps which also was 'web-aware'
without too much work. An ordinary two/three-tier approach can do
a lot, but IMHO, nothing beats an 'automatic' one.
I don't hate Javascript, but I certainly dislike the way it's implemented.
In a year or so, the technology will hopefully be mature and it'll be
possible to develop an application with a good Javascript based UI and not
get ulcers. :-)
[0] Actually, it can be done with IE and 'remote scripting', but it
is Windows only and not included in the standard distribution.
--
Lars
From: Lars Marius Garshol
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <wkn1wq8rdb.fsf@ifi.uio.no>
* Robert Monfera
|
| By the way: does someone know if it is possible to use the Document
| Object Model using CORBA?
Some of the server-side DOM implementations allow this.
| With which browser?
I don't think any of the browsers implement CORBA access to the DOM,
and it doesn't seem immediately useful anyway since you normally
download code to run inside the browser.
And none of the browsers implement the DOM recommendation anyway.
(Well, Opera and Mozilla will.)
| (CORBA DOM bindings are specified in the recommendations).
Well, I'd rather say that the API is defined in CORBA IDL, since that
provides automatic mappings to most languages.
* Lars Bj�nnes
|
| HTML 4.0 opens up a wide range of possibilities for creating more
| professional UIs than with the earlier standards. Features like
| grouping of fields, access-keys, labels etc. are very useful and
| much of it will be supported by the new browsers[0].
* Robert Monfera
|
| Yes, and DOM and CSS are also significant standards/recommendations.
Not to forget the really interesting part: XML and its hangers on.
--Lars M.
In article <··············@enterprise.gdpm.no>, ······@gdpm.no (Lars Bj�nnes) wrote:
> Is there a 'web-gateway' for CLIM? I've seen similar solutions (4D),
> but many of them are using non-standard HTML, Javascript-hell etc.
>
> HTML 4.0 opens up a wide range of possibilities for creating more
> professional UIs than with the earlier standards. Features like
> grouping of fields, access-keys, labels etc. are very useful and
> much of it will be supported by the new browsers[0].
>
> We're currently using CL-HTTP in a project[1], but the opportunity of
> supporting a wider range of clients with CLIM is very tempting.
>
> Please tell me I'm not dreaming. :-)
There are some building blocks:
- W3P is a portable presentation system (part of CL-HTTP)
- CWEST
S. M. Paley and P. D. Karp, "Adapting CLIM applications for use on
the world wide web," in Proceedings of the
Association of Lisp Users Meeting and Workshop, pp. 1--9, 1995.
Abstract: The World Wide Web (WWW) offers the potential to deliver
specialized information to an audience of unprecedented size. Along
with this exciting new opportunity, however, comes a challenge for
software developers: instead of rewriting our software applications
to operate over the WWW, how can we maximize software reuse by
retrofitting existing applications? We have developed a Web server
tool, written in Common Lisp, that allows any existing graphical user
interface application written using the Common Lisp Interface Manager
(CLIM) to hook easily into the WWW. This tool --- CWEST (CLIM-WEb
Server Tool, pronounced ``quest'') --- has been developed to operate
with EcoCyc, an electronic encyclopedia of genes and metabolism of
the bacterium E. coli. EcoCyc consists of a database of objects
relevant to E. coli biochemistry and a sophisticated interface,
implemented in CLIM, that runs on the local host window system and
generates graphical displays appropriate to each type of object. Each
query to our server is passed as a command to the EcoCyc program,
which responds by dynamically generating an appropriate local
drawing. That drawing, which can be a mixture of text and graphics,
is then translated into the HyperText Markup Language (HTML) and/or
the Graphics Interchange Format (GIF) and returned to the client.
Sensitive regions embedded in the CLIM drawing are converted to
hyperlinks with Universal Resource Locators (URLs) that generate
further EcoCyc queries. This tight coupling of CLIM output with Web
output makes CLIM an ideal high-level programming tool for Web
applications. The flexibility of Common Lisp and CLIM made
implementation of the server tool surprisingly easy, requiring few
changes to the existing EcoCyc program. The results can be seen at
URL http://www.ai.sri.com/ecocyc/browser.html. We plan to make CWEST
available to the CLIM community at large, with the hope that it will
spur other software developers to make their CLIM applications
available over the WWW.
- HTTP-CLIM is a experimental library that we have been using in presenting
applications objects and invoking commands via the web.
From: Lars Bj�nnes
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <m3wvvurhvh.fsf@enterprise.gdpm.no>
······@lavielle.com (Rainer Joswig) writes:
[snip useful information]
> - HTTP-CLIM is a experimental library that we have been using in presenting
> applications objects and invoking commands via the web.
Is to be used with CL-HTTP?
--
Lars
······@lavielle.com (Rainer Joswig) writes:
> > This is another very sticky point IMHO. I never quite understood why
> > "commands" ought to be that different from "functions" (parsing and
> > completion apart). My experience with CLIM is very limited, but it
> > really seemed to me that there was something "too much", once you got to
> > commands and the like.
>
> No, commands are something more complex. They are abstractions
> about what the user can do in your application and
> how he can do it.
>
> - You need type information for the parameters
> - You want to provide completion facilities
> - You want to say how a command can be invoked (menu, key, command line,
> click on an object, ...).
> - you want to provide help, defaults, output redirection, ...
> - you want to organize them in command tables
> - ...
This is actually a very common design pattern. Most systems that are
written in their own extension language (like e.g. Emacs) make this
distinction. Not only do you need more information for commands, but
this also serves the purpose of restricting the end-user interface to
those functions that are at the right abstraction level for
end-users.
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
In article <··············@orion.dent.isdn.cs.tu-berlin.de>, ····@acm.org (Pierre R. Mai) wrote:
> This is actually a very common design pattern.
Sure, this has been introduced by Dynamic Windows when?
1987, I'd guess.
From: Erik Naggum
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <3141797317529216@naggum.no>
* ······@lavielle.com (Rainer Joswig)
| But, this is *exactly* the point of CLIM. That's the big difference
| between CLIM and ***all*** the other UIMS out there. It has the
| presentation system.
I think we all understand this, but if you think CLIM is sufficient to
describe the abstract protocol, why do you need the CLIM _implementation_
of that abstract protocol to use CLIM? the published interface to CLIM
is out there. as with many small applications, you can probably "fake"
the underlying framework. I'll be mean and say if CLIM is so good, how
come people don't use it for their design and abstract work? back when I
couldn't use Lisp for some projects, I still wrote most of the code in
Lisp and played with several ideas and then hand-translated it to C. I
have done the same thing with assembler, actually. low-level languages
like assembler and C are very hard to sit down and chat with the system,
and almost _require_ the "traditional" design phases, whereas Lisp lets
me think in code on screen. if CLIM offers that kind of service to its
programmers, it should survive and thrive independent of actual source
code or implementations. it appears to me that it doesn't.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
From: Erik Naggum
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <3141890244101266@naggum.no>
* ······@lavielle.com (Rainer Joswig)
| How do you know people don't use CLIM for their design and abstract work?
I'm asking _you_, Rainer, because the incessant whining strongly implies
that if you can't have it all (for free, to boot), you can't use _any_ of
it, which I have learned to recognize as the identifying mark of losers.
your getting so damn defensive about all this keeps telling me something
about CLIM that I really didn't want to know.
in less than a week, most of which was spent nosediving into manuals and
specifications, I implemented a very small Emacs read-eval-redisplay loop
and multiple buffers and a bunch of non-trivial stuff, which used CLIM to
update the display automagically and all. I found that CLIM made a whole
lot of stuff real easy, that it caused an enormous amount of X traffic,
that its redisplay code was horribly slow, and I needed to get below CLIM
to get control of the stuff that an Emacs would need. it couldn't cover
my needs and disappointed me greatly, but I readily admit that Emacs is a
bad test case and that I didn't have a chance to play much with it at the
time. now that Franz Inc supports CLIM for Linux, maybe I can get back
to play with it, but it seems to depend very heavily on a particular
MOTIF implementation (even though I have full access to the entire MOTIF
source base, I never got building it for Linux to complete successfully).
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
From: Howard R. Stearns
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <37A1C270.A988639E@elwood.com>
I've been working on a portable implementation of CLIM, a "port" of it
to CL-HTTP, and some LDAP/RDF type database applications that use it
(html presentation of commercial catalogs, etc.)
The work is in-progress, and this is NOT a release anouncement.
However, having been too busy to look at mail or newsgroups lately, I
suddenly see subjects like the above, so I wanted to let people know
that this was happening.
Anybody interested in these subjects who would like to chat, should
contact me directly. (Make sure any email is directly To: me, or it
might not get seen.)
Howard R. Stearns
······@elwood.com
1-414-764-7500 (8:30-5:00 U.S Central timezone)
From: Christopher R. Barry
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <87u2qzmcp6.fsf@2xtreme.net>
Vassil Nikolov <········@poboxes.com> writes:
> The point about the abstract protocol and interface is this. An
> application with a user interface should not be built as one
> homogeneous whole. In other words, many (or most) GUI
> applications are built as a `single agent,' where the part that
> does the actual work is intertwined (in an inseparable way) with
> the part that takes care of interacting with the user. (Very roughly
> speaking, the `work loop' of the application and the `UI loop' handling
> GUI events are one and the same loop.)
>
> A much better approach is to build the application as a system of at
> least two separate agents, one being the `work horse' taking care of
> the working functionality and the other being the `front end' taking
> care of the user. The interaction between the two agents is done
> according to a protocol that is, among other things, independent of
> the particular nature of the user interface.
I'm familiar with using this approach to, for example, use both a
JavaScript/HTML GUI for an application and a Java/Swing one. The
application could be made to use Motif or GTK as well. But not
CLIM. At least not correctly.
With CLIM you _have_ to tightly integrate the GUI with its underlying
application. I feel uncomfortable even using the terminology
"underlying application" because there shouldn't even be a distinction
between a CLIM application and its UI, or any application with a
sophisticated UI. Think of Photoshop. You couldn't really smack a
command-line interface onto it. The interface helps to define the
application, if that seems clear. (Photoshop is _not_ the best example
of what I'm trying to express....)
If you do a sophisticated "CLIM interface to an application", then
it's not a "CLIM interface to an application" because you'll have to
program a lot of the parts of your application with CLIM in mind to
take advantage of it and do really cool stuff.
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> If you do a sophisticated "CLIM interface to an application", then
> it's not a "CLIM interface to an application" because you'll have to
> program a lot of the parts of your application with CLIM in mind to
> take advantage of it and do really cool stuff.
This sounds like a _huge_ disadvantage, and seems to me to be another
barrier to CLIM's success: In effect, to use it correctly, you have
to totally commit yourself to using it. And when you find out in the
end, that CLIM won't be as stable or available or suitable than you
had imagined, or some unforseen event forces you to retarget, or
whatever, you're screwed? Compare this to the usual GUIs, where I can
switch without touching my main application.
While I agree that there are applications that are defined by ther
GUI, I'd venture that there are many more, which are defined by their
application domain, and where the UI can take many forms, and more
importantly, you don't know at the outset (or even after delivery),
which UI might best serve the user's needs, and/or fit the other
requirements that exist...
So should this be true, then I think CLIM is a step in the wrong
direction for many...
Actually I don't know much about CLIM (besides reading the spec a
couple of times), since all the CLIM implementations I could get my
hands on where in such a bad state, that even the supplied demos often
didn't run correctly. That's not something you want to base your
application on...
Oh, and this is not a blow against the vendors. I can understand
pretty well, why really supporting CLIM would be a problem for
them...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
From: Christopher R. Barry
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <87r9m3m30o.fsf@2xtreme.net>
····@acm.org (Pierre R. Mai) writes:
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> > If you do a sophisticated "CLIM interface to an application", then
> > it's not a "CLIM interface to an application" because you'll have to
> > program a lot of the parts of your application with CLIM in mind to
> > take advantage of it and do really cool stuff.
>
> This sounds like a _huge_ disadvantage, and seems to me to be another
> barrier to CLIM's success: In effect, to use it correctly, you have
> to totally commit yourself to using it. And when you find out in the
> end, that CLIM won't be as stable or available or suitable than you
> had imagined, or some unforseen event forces you to retarget, or
> whatever, you're screwed? Compare this to the usual GUIs, where I can
> switch without touching my main application.
Why commit to using a powerful language like Lisp to write an
application when doing so pretty much fully commits you to it and your
vendor and negates any possibility of a mostly trivial rewrite to a
lesser language like Java? Because there are advantages to doing it in
Lisp, and Lisp may be the only sane way to do it, or at least 10 times
easier even if doing it in the lesser language wasn't going to be
_that_ hard anyways.
> While I agree that there are applications that are defined by ther
> GUI, I'd venture that there are many more, which are defined by their
> application domain, and where the UI can take many forms, and more
> importantly, you don't know at the outset (or even after delivery),
> which UI might best serve the user's needs, and/or fit the other
> requirements that exist...
Often it's the case with Lisp that you're not writing anything _too_
complicated, maybe just doing some boring SQL stuff for a payroll or
accounting system. Yet, you use Lisp to do it anyways because you are
more productive in Lisp and like it better, even if it means creating
your own Lisp SQL bindings when you could have just used Java which
gives you package java.sql _standardly_ and pretty much all the SQL
stuff you could ask for for free.
That said, there is a specific class of GUIs that have interactive
display panes that change very dynamically and require sophisticated
processing of user interactions within these panes that CLIM really
excels at letting you create such as a web browser, CAD system,
graphics program, editor, etc....
And that said, a major problem with todays GUIs are that they are all
the same and really boring and redundant and inefficient with their
damn File pulldown menu in the upper-left corner and their damn Help
pulldown menu in the upper right. People are just clueless about how
to make a _real_ interaction system to their functionality between the
human and machine using the monitor, mouse and keyboard. Maybe there's
a business opportunity for me here....
> So should this be true, then I think CLIM is a step in the wrong
> direction for many...
Maybe Java and not Lisp is better for many too....
> Actually I don't know much about CLIM (besides reading the spec a
> couple of times)
Like most people that seem to have a lot to say about it....
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> Why commit to using a powerful language like Lisp to write an
> application when doing so pretty much fully commits you to it and your
> vendor and negates any possibility of a mostly trivial rewrite to a
> lesser language like Java? Because there are advantages to doing it in
> Lisp, and Lisp may be the only sane way to do it, or at least 10 times
> easier even if doing it in the lesser language wasn't going to be
> _that_ hard anyways.
This comparisson is IMHO missing the point. Programming means using
programming languages, just like UIs means using a UI toolkit, and
somewhere along the line you'll have to choose one, and implement
things in it. I have no problem with that. What you claimed was that
the choice of CLIM as a UI toolkit should heavily influence the
_design_ of the _core_ application, i.e. that the only way to do
proper CLIM interfaces was to totally intertwine the application
code's and the CLIM code's design.
This would be like saying that using Lisp forces you to do your whole
application design in a Lisp-specific way, thereby rendering your
high-level design (not just your low-level design and code) useless,
should you ever undertake to rewrite the application in a lesser (or
different) language. This is generally not the case, IMHO. Although
I do certain things quite differently in Lisp applications than I'd do
them in C or Ada or whatever, this doesn't really invalidate my
high-level design.
And there is my (as yet undisputed) claim, that most (domain-specific)
applications are governed more by the domain-specific aspects than by
their user-interfacing needs, which would make me quite uneasy with
the fact that secondary issues (user interfacing) should govern the
choices of my plattform from the outset.[1]
> Often it's the case with Lisp that you're not writing anything _too_
> complicated, maybe just doing some boring SQL stuff for a payroll or
> accounting system. Yet, you use Lisp to do it anyways because you are
> more productive in Lisp and like it better, even if it means creating
> your own Lisp SQL bindings when you could have just used Java which
> gives you package java.sql _standardly_ and pretty much all the SQL
> stuff you could ask for for free.
If the same application could be written in another language _without
problems_, and writing the SQL bindings would make writing the Lisp
version take more time to develop and maintain than the "Java" or C
version, then I wouldn't do it in Lisp, unless I expected my initial
investment here to pay off in the future.
For really trivial, boring and non-critical database client stuff on
Windows I continue to use Borland's Delphi (or any of the miriad of
similar RAD environments out there, with the exception of VB ;).
Doing this stuff in Lisp would take me a non-trivial investment of
time and effort to create the necessary plumbing first, which I don't
consider to be worth it. I don't specialize in this market, so why
bother?
Things change of course, if the application starts to get critical
or non-trivial (which can happen fairly quickly)...
As things stand, the work I'm currently doing is neither trivial nor
non-critical, but just happened be in need of an SQL interface.
> That said, there is a specific class of GUIs that have interactive
> display panes that change very dynamically and require sophisticated
> processing of user interactions within these panes that CLIM really
> excels at letting you create such as a web browser, CAD system,
> graphics program, editor, etc....
I don't dispute the fact that user-interfacing may be a very important
factor in a number of applications (such as those listed above). And
in those cases I'd be quite willing to accept that the UI toolkit be
choosen at the outset (or written from scratch), and that the UI will
determine the overall design. I'm just claiming that this isn't the
case for a large number of applications out there.
> And that said, a major problem with todays GUIs are that they are all
> the same and really boring and redundant and inefficient with their
A large number of people in the HIC area would argue that the fact
that todays GUIs are all the same is not a huge problem, but would be
a major benefit, if only it were true (especially on Windows!).
That said, I agree that current user interfaces aren't all that great,
and I have great sympathy with anyone who wants to explore novel and
not-so novel ways of improving GUIs. I just don't buy the fact that
we have to be innovative in UI design for every silly little
application...
> damn File pulldown menu in the upper-left corner and their damn Help
> pulldown menu in the upper right. People are just clueless about how
> to make a _real_ interaction system to their functionality between the
> human and machine using the monitor, mouse and keyboard. Maybe there's
> a business opportunity for me here....
> > Actually I don't know much about CLIM (besides reading the spec a
> > couple of times)
>
> Like most people that seem to have a lot to say about it....
Well, we have you and a couple of others who are constantly telling us
all about it, don't we? It was your claim about CLIM's impact on
application development that got us here, not any claim on my part.
And pardon me for taking your claims to be true...
Regs, Pierre.
Footnotes:
[1] I know I'm going to be hanged by HIC people for this... ;)
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
In article <··············@orion.dent.isdn.cs.tu-berlin.de>, ····@acm.org (Pierre R. Mai) wrote:
> things in it. I have no problem with that. What you claimed was that
> the choice of CLIM as a UI toolkit should heavily influence the
> _design_ of the _core_ application, i.e. that the only way to do
> proper CLIM interfaces was to totally intertwine the application
> code's and the CLIM code's design.
How many lines of CLIM code has he written?
This is what drives me really crazy.
People (not you, but Christopher R. Barry -
http://x22.deja.com/getdoc.xp?AN=448003247&search=thread&CONTEXT=932514670.262865043&HIT_CONTEXT=932514670.262865043&HIT_NUM=1&hitnum=244)
claim that Lisp machines are **several** magnitudes slower then modern
Lisp systems. Which is unfortunately plain wrong.
Others are writing long web pages about the Lisp
machine, why it failed and why its documentation sucked -
without ***ever*** having used one nor even seen one -
and then they post here about Lisp and why they
write their code in whatever losing language.
Now we have people telling us about how CLIM sucks,
people who have never written a significant amount of code
in it - nor even understood the papers about its foundations
(Ciccarelli, E.C., Presentation Based User Interfaces, MIT Artificial Intelligence Laboratory, Technical Report 794, August 1984.).
Then we have others who are writing 10k text
of flamage for every loser who dares to show his ignorance.
This is why comp.lang.lisp really sucks - and I won't post here anymore.
Sorry.
From: Christopher R. Barry
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <87g12in1uy.fsf@2xtreme.net>
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@orion.dent.isdn.cs.tu-berlin.de>, ····@acm.org (Pierre R. Mai) wrote:
>
> > things in it. I have no problem with that. What you claimed was that
> > the choice of CLIM as a UI toolkit should heavily influence the
> > _design_ of the _core_ application, i.e. that the only way to do
> > proper CLIM interfaces was to totally intertwine the application
> > code's and the CLIM code's design.
>
> How many lines of CLIM code has he written?
Plenty. You probably remember me whining about using Garnet and not
having a CLIM to use ages ago. Getting a copy a CLIM was one of the
things I looked forward to the most about getting a LispM (which I've
pretty much nothing but praised by the way).
> This is what drives me really crazy.
>
> People (not you, but Christopher R. Barry -
> http://x22.deja.com/getdoc.xp?AN=448003247&search=thread&CONTEXT=932514670.262865043&HIT_CONTEXT=932514670.262865043&HIT_NUM=1&hitnum=244)
> claim that Lisp machines are **several** magnitudes slower then modern
> Lisp systems. Which is unfortunately plain wrong.
The overall feel is that it's maybe 6 times slower then my 200MHz
Linux box (minus floating point since mine doesn't have an FPA, and of
course 2D graphics since I have a Millenium on the Linux box which
provides all kinds of acceleration features for drawing and windowing
systems), except for the compiler which _REALLY IS_ dog slow. Of
course, you don't need it that often and only in short bursts since
the LispM is _the_ incremental development platform, but I don't know
why CL-HTTP takes an entire night to compile (and perhaps is thus why
the last official compile was in 1997 and the patch level is 138) when
it runs maybe 6 times slower after compilation when it only takes 3
minutes to compile on the Linux box. If the compiler performance
scaled similarly with the rest of the LispM performance difference
then it should take 20-30 minutes, not something like 15-20 times
that.
> Others are writing long web pages about the Lisp
> machine, why it failed and why its documentation sucked -
> without ***ever*** having used one nor even seen one -
Where are these web pages, Rainer?
> Now we have people telling us about how CLIM sucks, people who have
> never written a significant amount of code in it - nor even
> understood the papers about its foundations
I've never said CLIM sucks, so who are you talking about?
Christopher
From: Friedrich Dominicus
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <379564F0.468C90C@inka.de>
> Then we have others who are writing 10k text
> of flamage for every loser who dares to show his ignorance.
>
> This is why comp.lang.lisp really sucks - and I won't post here anymore.
This is not typically for c.l.l but it holds too for comp.lang.eiffel,
the discussion there is about libraries and standardization. I guess
this is not the theme here. But if anyone who is pro Lisp or pro s.th.
does not post here any longer it's getting worse and worse.
I guess there are good points pro Lisp good points against it and I
guess this holds for libraries too. So I suggest standing up for you
point of view. And possibly show where LISP is a good or the best choice
and where problems may lie.
I don't very much about lisp and I was ignorant enough refusing learning
it because of the syntax. What an idea. It's quite unusual for my
background (C, Modula-2 and especially Eiffel), but if I can convince
myself it's worth learning other can surely follow. And you have had
your part to convince me that it's worth learning.
Just my 2 (Euro) cents ;-)
Regards
Friedrich
From: Tim Bradshaw
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <nkjogh6b97b.fsf@tfeb.org>
······@lavielle.com (Rainer Joswig) writes:
> People (not you, but Christopher R. Barry -
> http://x22.deja.com/getdoc.xp?AN=448003247&search=thread&CONTEXT=932514670.262865043&HIT_CONTEXT=932514670.262865043&HIT_NUM=1&hitnum=244)
> claim that Lisp machines are **several** magnitudes slower then modern
> Lisp systems. Which is unfortunately plain wrong.
>
Depends what you measure and what you measure it on. My 3630 is
several hundred times slower than my other Lisp platform for some
code, I guess an ivory would then be perhaps several 10s of times
slower. I think cbarry has a 36xx but I'm not sure.
I would post precise figures but the lispm is currently in bits, but
these figures are right +/- a factor of 2, and no-one can accuse me of
having some anti lispm bias. The particular example was reading a
larg(ish) data structure (specified as a list) from a (local) file and
then converting it into something else. and doing some indexing
operations.
The LispM was a symbolics 3630 with 8MW of memory and ESDI disk. The
other system was CMUCL on a 330MHz SUn Ultra 10 with 640Mb of memory.
Symbolics performance was dominated by I/O.
This was kind of bad because of the I/O load (Unix machines were a lot
faster than symbolics at file I/O in the same time frame (until
recently I had a Unix machine of the same era so I'm speaking from
some recent knowledge here not just old memory) and are *much* faster
now. My guess generally is that the Unix box (which is really just a
not-very-high-end PC with somewhat more memry than people typically
buy) is about 100x faster for general code (perhaps 10x faster than an
ivory?).
Which means the symbolics was a rather fast machine for its day,
though 36xx machines were being beaten by general purpose Unix boxes
by 1987/1988 (which was when we got an advert from our vendor with their
new machine beating a 36xx on the Gabriel benchmarks, in kcl even!),
and I don't think they ever caught up after that.
What is interesting of course is not that they were fast in raw speed
-- that's like worrying whether a cray 1 is a fast machine by today's
standards -- but that they were *astonishingly* good as development &
exploratory environments. Fast enough that I for one still like to
have one around.
So I guess, what I'm trying to say is, let's not get hung up on how
fast or not they were. That's just irrelevent, what is interesting is
how *good* (or not) they were and what, if anything, we can learn from
that.
--tim
From: Christopher R. Barry
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <874sivm7tu.fsf@2xtreme.net>
Tim Bradshaw <···@tfeb.org> writes:
> ······@lavielle.com (Rainer Joswig) writes:
>
>
> > People (not you, but Christopher R. Barry -
> > http://x22.deja.com/getdoc.xp?AN=448003247&search=thread&CONTEXT=932514670.262865043&HIT_CONTEXT=932514670.262865043&HIT_NUM=1&hitnum=244)
> > claim that Lisp machines are **several** magnitudes slower then modern
> > Lisp systems. Which is unfortunately plain wrong.
> >
>
> Depends what you measure and what you measure it on. My 3630 is
> several hundred times slower than my other Lisp platform for some
> code, I guess an ivory would then be perhaps several 10s of times
> slower. I think cbarry has a 36xx but I'm not sure.
XL1201, 20MHz rev. 4A Ivory (fastest Lisp chip made).
Christopher
From: Christopher R. Barry
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <87d7xmmycc.fsf@2xtreme.net>
····@acm.org (Pierre R. Mai) writes:
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> > Why commit to using a powerful language like Lisp to write an
> > application when doing so pretty much fully commits you to it and your
> > vendor and negates any possibility of a mostly trivial rewrite to a
> > lesser language like Java? Because there are advantages to doing it in
> > Lisp, and Lisp may be the only sane way to do it, or at least 10 times
> > easier even if doing it in the lesser language wasn't going to be
> > _that_ hard anyways.
>
> This comparisson is IMHO missing the point. Programming means using
> programming languages, just like UIs means using a UI toolkit, and
> somewhere along the line you'll have to choose one, and implement
> things in it. I have no problem with that. What you claimed was that
> the choice of CLIM as a UI toolkit should heavily influence the
> _design_ of the _core_ application, i.e. that the only way to do
> proper CLIM interfaces was to totally intertwine the application
> code's and the CLIM code's design.
>
> This would be like saying that using Lisp forces you to do your whole
> application design in a Lisp-specific way, thereby rendering your
> high-level design (not just your low-level design and code) useless,
> should you ever undertake to rewrite the application in a lesser (or
> different) language. This is generally not the case, IMHO. Although
> I do certain things quite differently in Lisp applications than I'd do
> them in C or Ada or whatever, this doesn't really invalidate my
> high-level design.
Design is a multi-leveled thing. An application design that is
high-level enough so as to be equally valid between
non-object-oriented Algol-descendant languages and Lisp must specify
very little about its code. Only issues of input, output, some
algorithmic and complexity issues, etc. At the next lower-level there
is probably a sharp branching between the OO and non-OO
languages. After that, in my view, there is a sharp branch between
Lisp and everything else. So when you say
This would be like saying that using Lisp forces you to do your
whole application design in a Lisp-specific way, thereby rendering
your high-level design (not just your low-level design and code)
useless.
I'd say that Lisp forces not your top-level design - like whether your
code is going to print "hello world" or "shutup world" - but from the
highest levels of your design down to be coded in a Lisp-specific way.
I'd also say that using Lisp allows you to try a different, more
powerful, risky, challenging, versatile or unique design then what
would otherwise be the only sane choice with something like C. You can
actually go after bigger game than "hello world" in Lisp, to follow
from earlier, in other words.
I'm trying to say the same thing about CLIM.
[And to do so you you design your objects and your class-hierarchy and
data-structures with awareness of how things are going to interplay
with all the presentation, interaction and rendering stuff.]
> And there is my (as yet undisputed) claim, that most (domain-specific)
> applications are governed more by the domain-specific aspects than by
> their user-interfacing needs, which would make me quite uneasy with
> the fact that secondary issues (user interfacing) should govern the
> choices of my plattform from the outset.[1]
I think that your consideration of user-interfacing as a "secondary
issue" can pretty much account for the differences in our views. (Gee,
I'm starting to sound like a Mac user....)
> I don't dispute the fact that user-interfacing may be a very important
> factor in a number of applications (such as those listed above). And
> in those cases I'd be quite willing to accept that the UI toolkit be
> choosen at the outset (or written from scratch), and that the UI will
> determine the overall design. I'm just claiming that this isn't the
> case for a large number of applications out there.
Okay, this seems to be of a different tone then the above, and I guess
I agree that there are both a huge number of applications out there
where the interface doesn't matter if it's command-line or GUI or what
as long as it's there and working (if the app is only used/modified 2
minutes a week or something or only when something goes wrong then it
shouldn't matter how the heck you interface to it) and that there are
also a huge number of applications out there with critical
user-interfacing needs.
> > And that said, a major problem with todays GUIs are that they are all
> > the same and really boring and redundant and inefficient with their
>
> A large number of people in the HIC area would argue that the fact
> that todays GUIs are all the same is not a huge problem, but would be
> a major benefit, if only it were true (especially on Windows!).
>
> That said, I agree that current user interfaces aren't all that great,
> and I have great sympathy with anyone who wants to explore novel and
> not-so novel ways of improving GUIs. I just don't buy the fact that
> we have to be innovative in UI design for every silly little
> application...
I, for one, have never said this. And exploring novel ways of
improving GUIs or writing really powerful software that exploits
totally different paradigms of interaction or totally more natural and
efficient usage naturally leads one to write the application with the
GUI a forethought, and to use a language like Lisp and a tool like
CLIM....
Christopher
In article <··············@orion.dent.isdn.cs.tu-berlin.de>, ····@acm.org (Pierre R. Mai) wrote:
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> > If you do a sophisticated "CLIM interface to an application", then
> > it's not a "CLIM interface to an application" because you'll have to
> > program a lot of the parts of your application with CLIM in mind to
> > take advantage of it and do really cool stuff.
>
> This sounds like a _huge_ disadvantage,
But it is wrong.
> and seems to me to be another
> barrier to CLIM's success: In effect, to use it correctly, you have
> to totally commit yourself to using it. And when you find out in the
> end, that CLIM won't be as stable or available or suitable than you
> had imagined, or some unforseen event forces you to retarget, or
> whatever, you're screwed? Compare this to the usual GUIs, where I can
> switch without touching my main application.
Huh? How do you switch between PowerPlant and MFC? How
do you switch between CLUE and Common Windows and Garnet?
I mean I have seen very sophisticated applications that
are using MacApp as its UIMS toolkit. Rewriting it?
Forget it.
> So should this be true, then I think CLIM is a step in the wrong
> direction for many...
How about reading a bit about CLIM before believing bullshit?
> couple of times), since all the CLIM implementations I could get my
> hands on where in such a bad state, that even the supplied demos often
> didn't run correctly.
How about rewriting the demos and fixing bugs?
> That's not something you want to base your application on...
I have seen several applications written in CLIM. Research
and commercial.
······@lavielle.com (Rainer Joswig) writes:
> Huh? How do you switch between PowerPlant and MFC? How
> do you switch between CLUE and Common Windows and Garnet?
How do you switch between CLUE, CW, Garnet, CAPI and a simple
batch-oriented interface? Simply! You rewrite the UI portion of the
application, without touching the core parts of the application. This
might entail more work than one would like, depending on the
complexity of the UI, but as long as the complexity of the UI
outweighs the complexity of the domain-specific core, this is done
readily.
If the application was of course designed with UI and core totally
intermingled, or when the UI complexity far exceeds the core
complexity, you're mostly out of luck, though.
> > So should this be true, then I think CLIM is a step in the wrong
^^^^^^^^^^^^^^^^^^^^^^
> > direction for many...
>
> How about reading a bit about CLIM before believing bullshit?
I've read the spec, and I snatched the idea of presentation types
from CLIM for a project. But since I've never written an application
that uses CLIM, I can't argue either way whether applications need to
be written especially for CLIM to use CLIM correctly or not...
> > couple of times), since all the CLIM implementations I could get my
> > hands on where in such a bad state, that even the supplied demos often
> > didn't run correctly.
>
> How about rewriting the demos and fixing bugs?
And what then? The state of the demos seem to me indicative of the
state of CLIM support by (some of the) vendors (we are talking
commercial implementations here). Me fixing bugs and rewriting
demos is not going to change that. I also don't have any pressing
need for CLIM (nor for most of the GUI toolkits). So I choose to put
my time and money to other uses, and I can understand if vendors do
the same (based on their perception of their user's needs).
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> If you do a sophisticated "CLIM interface to an application", then
> it's not a "CLIM interface to an application" because you'll have to
> program a lot of the parts of your application with CLIM in mind to
> take advantage of it and do really cool stuff.
Which is bullshit and shows only your complete ignorance.
First, every sophisticated UI will mean you have to program
a lot of the code using the UIMS. Second,
CLIM is different, because it uses the application
objects directly. It records the drawings, does
the refresh, handles the command loop, connects the
application objects to its presentations, ...
CLIM is the UIMS which least forces your application
to note the presence of an UIMS.
I have myself written an application which we've ported
to five different Lisps. This application runs nightly
without any GUI. I then have attached a dynamic
UI via CLIM without even touching the rest of the source.
The graphics are running on my Mac and my Lisp machine.
From: Christopher R. Barry
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <87lncan5og.fsf@2xtreme.net>
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
>
> > If you do a sophisticated "CLIM interface to an application", then
> > it's not a "CLIM interface to an application" because you'll have to
> > program a lot of the parts of your application with CLIM in mind to
> > take advantage of it and do really cool stuff.
>
> Which is bullshit and shows only your complete ignorance.
If you wrote an application completely ignorant of the fact that you
were going to be doing the GUI using CLIM, and the did the GUI using
CLIM, I'm sure the results will be unimpressive and boring at
best. You could only do a pretty customary GUI this way, and the
advantages of using CLIM in this case would be minimalized. Nothing I
think I couldn't do in Swing, and better, in other words. (Might take
a good bit longer depending on the devil in the details, but it would
be prettier and sexier, more portable, and many more properties of its
look could be portably "guaranteed" to. Additionally, it would have
all kinds of image handling facilities for modern graphics formats
like JPEG without expensive licensing among myriad other benefits by
going with Swing.)
> First, every sophisticated UI will mean you have to program
> a lot of the code using the UIMS. Second,
> CLIM is different, because it uses the application
> objects directly.
If your just layering it on top then who cares? You're only saving a
little time now, but costing yourself in the long run given the state
of CLIM.
> It records the drawings, does the refresh,
In my experience the automatic refresh is kinda buggy and performance
is a good bit slower than doing it yourself. I guess it's nice for
prototyping and more in the Lisp spirit, but you want to customize the
repainting in the end anyways as with other tools. (Maybe the MCL
implementation of the automatic refreshing is better, but I can at
least say with certainty that you can't rely on this working well
portably across implementations.)
> handles the command loop, connects the application objects to its
> presentations, ...
>
> CLIM is the UIMS which least forces your application
> to note the presence of an UIMS.
How CAN YOU SAY THAT??? You are subconsciously writing your
application class-hierarchy, objects and state in a CLIM-friendly
way then.
> I have myself written an application which we've ported
> to five different Lisps. This application runs nightly
> without any GUI. I then have attached a dynamic
> UI via CLIM without even touching the rest of the source.
> The graphics are running on my Mac and my Lisp machine.
Yeah, I bet it's really something unique to.
Christopher
From: Andrew Cooke
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <7n46c5$o81$1@nnrp1.deja.com>
In article <·······················@194.163.195.67>,
······@lavielle.com (Rainer Joswig) wrote:
> In article <··············@2xtreme.net>, ······@2xtreme.net
(Christopher R. Barry) wrote:
>
> > If you do a sophisticated "CLIM interface to an application", then
> > it's not a "CLIM interface to an application" because you'll have to
> > program a lot of the parts of your application with CLIM in mind to
> > take advantage of it and do really cool stuff.
>
> Which is bullshit and shows only your complete ignorance.
Maybe you have already taken your ball home, so this will go unread,
but...
1. The separation between GUI and code is (IMHO) a serious problem
in software development with no obvious widely accepted answer.
2. This is probably at least slightly connected with the wide range of
software - from libraries that need no GUI, to applications that may,
depending on use, to products where the GUI is "everything."
3. I am reading this thread with interest to see if CLIM offers useful
new ideas - depending on what I read I may try using it (and Lisp, in
general - I started this thread). I suspect there are others in a
similar position.
4. Open agression, name calling, and a ghetto-like mentality that seems
to assume that all non-Lisp users are idiots is not just depressing, but
could actively discourage someone from using software that may, in fact,
be useful (not all these features are in your posts, but they have all
been appeared in this thread).
5. If you care about the language and the GUI, why not try and convert
people rather than make enemies? This thread, and this group, need not
be like this. The Python group, for example, has a core of friendly,
helpful experts. As traffic has grown there they have faded into the
background, but you can still see witty, intelligent, thought-provoking
discussion. Surely Python programmers aren't fundamentally more decent
people that Lisp users?
Andrew
(I am at my work's main offices this week, so email to
my home account will not be read before the weekend - sorry).
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
From: Erik Naggum
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <3141912853026521@naggum.no>
* Andrew Cooke <······@andrewcooke.free-online.co.uk>
| 4. Open agression, name calling, and a ghetto-like mentality that seems
| to assume that all non-Lisp users are idiots is not just depressing, but
| could actively discourage someone from using software that may, in fact,
| be useful (not all these features are in your posts, but they have all
| been appeared in this thread).
I've spent all week trying to catch up with news after a couple week's
vacation, but when I see how hostile Andrew Cooke is to participants in
this newsgroup (how is accusing people of "ghetto-like mentality" going
to help things?), I start to wonder whether he actually prefers lingering
and suppressed aggression, scheming, and backstabbing to open aggression.
I prefer people who speak their mind instead of waiting for a long time
to make a really big issue out of individual issues that normal people
would have a normal reaction to that let others know they were annoyed,
but those who have to suppress their emotions would have to accumulate
every time they suppressed them. you see, Andrew, those who speak their
mind immediately DON'T accumulate their anger, so when you see open
aggression, it is not because someone who has suppressed his anger for
years got mad, it's a genuinely useful way to AVOID ever getting mad in
the face of a lot of stupidity and annoyances in open fora.
in a suppressed-emotion world, you're supposed to grin and bear it, which
means that the thresholds are so high that only if one did in fact view
non-Lisp users as idiots would the behavior you don't understand become
applicable, but this is not so. instead of reacting severely only to
major crimes, people say "hey! you!" at every contact with people who do
the wrong thing. you interpret that as people being loudmouths and rude
and whatnot, without understanding that anyone could be so culturally
challenged (in your view) as to care about these small things.
suppression of emotion and the "grin and bear it" mentality don't scale
very well, and people tend to get a lot more upset with the scheming,
backstabbing bastards whose anger has lingered for so long they have been
completely blinded by it and can no longer see anything but that which
annoys them -- in brief, they actually do get depressed by it all. you
see, Andrew, that's just what happens to people who _don't_ speak their
mind in time.
so, what you see is a healthy discourse among people who aren't so
uptight they fear that someone might see they are hurt or annoyed in
public. being so uptight that such fear rules one's life probably works
in very small communities where everybody thinks and acts this way, but
it fails miserably in large communities, and especially open communities,
such as the Internet.
| 5. If you care about the language and the GUI, why not try and convert
| people rather than make enemies?
people don't make enemies, the react to actions they don't like. people
who make enemies because of their interaction in a newsgroup are mentally
disturbed and should seek counseling. those who look at others as if
that is what they do are probably even more in need of counseling because
they are obviously unable to cope with anything but suppressed emotions.
and let's talk about Lisp, not eachother, OK? people are most intersting
to people who keep accumulating annoyances do until they have to burst,
but people you don't intend to relate to are not interesting, even though
their actions and ideas might be worthy of notice, so unplug and relax,
Andrew. you'll feel better and we won't have to listen to your whining
every time your buffers run full.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
······@lavielle.com (Rainer Joswig) writes:
> In article <·····················@195.138.129.99>, Vassil Nikolov <········@poboxes.com> wrote:
>
> > But having now read a few other posts on this issue, I still don't
> > know if the CLIM way is or is not to separate the `application'
> > part from the UI part. (I should RTFLiterature about CLIM---RSN.)
>
> Since CLIM works directly on the domain objects, there
> is no visible layer between your application and the UI.
> Ideally you write your application code - without caring
> that you need an UI later. Additionally you can build
> varying degrees if UIness with CLIM, starting from
> complete default behaviour - the Lisp Listener gives you mouse
> sensitve output...
That's the impression I got from my studies on CLIM, and which has
been expounded here by various proponents of CLIM. That is also what
got me interested in CLIM in the first place many years ago. But
contrast this to Barry's recent claim, that:
······@2xtreme.net (Christopher R. Barry) writes:
> I'm familiar with using this approach to, for example, use both a
> JavaScript/HTML GUI for an application and a Java/Swing one. The
> application could be made to use Motif or GTK as well. But not
> CLIM. At least not correctly.
>
> With CLIM you _have_ to tightly integrate the GUI with its underlying
> application. I feel uncomfortable even using the terminology
> "underlying application" because there shouldn't even be a distinction
> between a CLIM application and its UI, or any application with a
> sophisticated UI. Think of Photoshop. You couldn't really smack a
> command-line interface onto it. The interface helps to define the
> application, if that seems clear. (Photoshop is _not_ the best example
> of what I'm trying to express....)
>
> If you do a sophisticated "CLIM interface to an application", then
> it's not a "CLIM interface to an application" because you'll have to
> program a lot of the parts of your application with CLIM in mind to
> take advantage of it and do really cool stuff.
It seems to me I'm missing something here...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
In article <··············@orion.dent.isdn.cs.tu-berlin.de>,
····@acm.org (Pierre R. Mai) writes:
> ······@lavielle.com (Rainer Joswig) writes:
>
>> In article <·····················@195.138.129.99>, Vassil Nikolov <········@poboxes.com> wrote:
>>
>> > But having now read a few other posts on this issue, I still don't
>> > know if the CLIM way is or is not to separate the `application'
>> > part from the UI part. (I should RTFLiterature about CLIM---RSN.)
Well, no UI is totally independant of the app. Given that, every CLIM, and
before that Dynamic Windows, app I've written, the CLIM interface is almost an
after thought. CLIM just naturally works with Lisp objects. OK, that is a
requirement. You DO have to write the app in Common Lisp. Contrasted to every
X app I've written, the CLIM apps are FAR more decoupled from the UI than teh
C/C++ ones.
>> If you do a sophisticated "CLIM interface to an application", then
>> it's not a "CLIM interface to an application" because you'll have to
>> program a lot of the parts of your application with CLIM in mind to
>> take advantage of it and do really cool stuff.
>
> It seems to me I'm missing something here...
>
> Regs, Pierre.
No, you're not missing something. The quoted description is inaccurate in my
experience.
Mike McDonald
·······@mikemac.com
In article <············@spitting-spider.aracnet.com>, ·······@mikemac.com wrote:
> >> If you do a sophisticated "CLIM interface to an application", then
> >> it's not a "CLIM interface to an application" because you'll have to
> >> program a lot of the parts of your application with CLIM in mind to
> >> take advantage of it and do really cool stuff.
> >
> > It seems to me I'm missing something here...
> >
> > Regs, Pierre.
>
> No, you're not missing something. The quoted description is inaccurate in my
> experience.
>
> Mike McDonald
> ·······@mikemac.com
Let's cite the abstract from a paper (CACM Vol.34, No. 9 (Sept. 1991), pp. 58-59 )
presented by Scott McKay:
McKay presents CLIM, the Common LISP Interface Manager.
Using CLIM, programmers describe the user interface of an
application in a high-level language independent of any
particular window substrate. The programmers indicate
their intent, and CLIM hides the details of how the tasks
are performed. CLIM provides a number of basic
facilities, including geometric modeling, affine
transformations, text with multiple fonts, and graphics.
It has a presentation facility that remembers not only
the output to a stream, but also the underlying
application object it represents and the presentation
type associated with the output. It also has facilities
for input, with a translator that coerces objects of one
presentation type into objects of another type. Thus,
since the objects and commands used in the interface are
built on objects and operations in the application, the
user interface becomes a by-product of the application
rather than an artifact of graphic design.
From: Erik Naggum
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <3141913498252914@naggum.no>
* ······@lavielle.com (Rainer Joswig)
| Let's cite the abstract from a paper (CACM Vol.34, No. 9 (Sept. 1991),
| pp. 58-59 ) presented by Scott McKay:
|
| McKay presents CLIM, the Common LISP Interface Manager. Using CLIM,
| programmers describe the user interface of an application in a
| high-level language independent of any particular window substrate. The
| programmers indicate their intent, and CLIM hides the details of how
| the tasks are performed. CLIM provides a number of basic facilities,
| including geometric modeling, affine transformations, text with
| multiple fonts, and graphics. It has a presentation facility that
| remembers not only the output to a stream, but also the underlying
| application object it represents and the presentation type associated
| with the output. It also has facilities for input, with a translator
| that coerces objects of one presentation type into objects of another
| type. Thus, since the objects and commands used in the interface are
| built on objects and operations in the application, the user interface
| becomes a by-product of the application rather than an artifact of
| graphic design.
you're missing the point, Rainer. at issue is not the coupling to the
actual user interface code, like X windows or whatever. at issue is how
much the application code needs to be prepared to produce a by-product.
it appears to me that your anger at critics of CLIM is misplaced because
you don't understand what they are criticizing and they think they
criticize something that isn't wrong with CLIM. maybe this is because
you don't see problem other people see and think CLIM has solved a
serious problem that other people don't see. I don't know. but I have
tried to get you, as an too ardent defender of CLIM, to answer some of my
questions and issues, which, in particular, are to which degree CLIM
offers means of abstraction that would be useful even without CLIM in the
system. again, it appears to me, from what _you_ say, that it doesn't,
meaning that CLIM is good provided that you accept a non-trivial amount
of design methodology that doesn't work too well without CLIM support.
could you calm down and try to answer such questions?
I'll make a parallel: we all know that CORBA solves a whole bunch of
problems in distributed processing, but if that means we have to buy into
the CORBA philosophy first, it may not be possible to use CORBA if the
philosophy doesn't fit the application model. in my view, CORBA is good
_only_ if you accept that philosophy, and sucks if you don't. to those
who don't recognize that there _is_ a "CORBA philosophy", this would be
an attack on CORBA in areas where it does work and is valuable, because
they automatically express every problem in terms of the philosphy.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
From: Christopher R. Barry
Subject: Re: application architecture for UI (Ex: Re: Is LISP dying?)
Date:
Message-ID: <87iu7en2y9.fsf@2xtreme.net>
····@acm.org (Pierre R. Mai) writes:
> > Since CLIM works directly on the domain objects, there
> > is no visible layer between your application and the UI.
> > Ideally you write your application code - without caring
> > that you need an UI later. Additionally you can build
> > varying degrees if UIness with CLIM, starting from
> > complete default behaviour - the Lisp Listener gives you mouse
> > sensitve output...
>
> That's the impression I got from my studies on CLIM, and which has
> been expounded here by various proponents of CLIM. That is also what
> got me interested in CLIM in the first place many years ago. But
> contrast this to Barry's recent claim, that:
>
> ······@2xtreme.net (Christopher R. Barry) writes:
>
> > I'm familiar with using this approach to, for example, use both a
> > JavaScript/HTML GUI for an application and a Java/Swing one. The
> > application could be made to use Motif or GTK as well. But not
> > CLIM. At least not correctly.
> >
> > With CLIM you _have_ to tightly integrate the GUI with its underlying
> > application. I feel uncomfortable even using the terminology
> > "underlying application" because there shouldn't even be a distinction
> > between a CLIM application and its UI, or any application with a
> > sophisticated UI. Think of Photoshop. You couldn't really smack a
> > command-line interface onto it. The interface helps to define the
> > application, if that seems clear. (Photoshop is _not_ the best example
> > of what I'm trying to express....)
> >
> > If you do a sophisticated "CLIM interface to an application", then
> > it's not a "CLIM interface to an application" because you'll have to
> > program a lot of the parts of your application with CLIM in mind to
> > take advantage of it and do really cool stuff.
>
> It seems to me I'm missing something here...
I guess the only thing that can be said with certainty is that one
will have to use CLIM to see for oneself whether one thinks Rainer's
or my view is more in line with what reality is, and that doing so
given the current state of CLIM availability is inconvenient and not
without cost at best.
That said, in my actual experience, and I've written thousands upon
thousands of lines of Swing code among other stuff [not including Lisp
listener interaction I've probably written more Java than Lisp in my
life; Certainly the largest program I ever wrote was in Java], CLIM
forces a particular mindfulness when choosing things like an
application class-hierarchy and application objects/structures/data.
If I write an application without thinking it will need a GUI or only
with a generic, vague idea of what the GUI will be, and then I put a
CLIM UI on it, I'm going to go back and move things around and change
things and rename classes and types and do other stuff.
If I write an application, and then I then I slap Swing atop it, I
don't care whether I'm using arrays or variables or classes or what
the types of my data are, because I just write/extend/override methods
to handle "low-level" key and mouse events to modify/create whatever
value of whatever data of whatever representation. With CLIM, I am
acutely aware of representational details within the application. I'll
perhaps find that I want to do something like define a class and use
an instance of it instead of using an array like originally, for
example. Even nit-pickish things like just renaming a lot of
stuff. (Which actually really isn't necessarily nit-picking at all.)
You end up with really beautiful, clear code in the end. It's much
better if you design your application to have a GUI from the beginning
though and plan your application objects accordingly. I don't see what
the big deal is.
Now, CLIM fully supports the Swing development paradigm of just
leaving everything alone and layering atop, but this is not the
"optimal" way to use CLIM, unless you happen to be subconciously
writing your app to mesh well with CLIM. I think doing things this way
will only lead to boring UIs like everything else out there.
Christopher
In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> given the current state of CLIM availability is inconvenient
You can get CLIM from Franz, Harlequin, Symbolics and Digitool.
> and not without cost at best.
Nothing is without cost.
> life; Certainly the largest program I ever wrote was in Java], CLIM
> forces a particular mindfulness when choosing things like an
> application class-hierarchy and application objects/structures/data.
Pardon? You model/implement your application domain directly
in Common Lisp. It's been called object-oriented programming.
Than you attach the CLIM interface.
The CLIM interface works ***directly*** with your application
objects.
> If I write an application without thinking it will need a GUI or only
> with a generic, vague idea of what the GUI will be, and then I put a
> CLIM UI on it, I'm going to go back and move things around and change
> things and rename classes and types and do other stuff.
For what? You just use the presentation types.
> If I write an application, and then I then I slap Swing atop it, I
> don't care whether I'm using arrays or variables or classes
Again, CLIM uses the presentation types. How you
implement them is not necessarily important for CLIM.
> or what
> the types of my data are, because I just write/extend/override methods
> to handle "low-level" key and mouse events to modify/create whatever
> value of whatever data of whatever representation. With CLIM, I am
> acutely aware of representational details within the application.
Wrong again, you write commands for the presentation types.
How the get invoked, the application doesn't care.
> You end up with really beautiful, clear code in the end. It's much
> better if you design your application to have a GUI from the beginning
> though and plan your application objects accordingly. I don't see what
> the big deal is.
This is ***not*** the CLIM way. You write code for creating
and maniputlating your data. Then you write CLIM
code to present it. You can write several methods for
different view types who render things differently.
Then you may want to write accept methods, accepting
values dialogs, etc... Then you write commands for your
presentation types, ...
The result is: you get a highly interactive and direct
manipulative graphical user interface.
Rainer Joswig wrote: [1999-07-20 13:46 +0200]
> In article <·····················@195.138.129.92>, Vassil Nikolov <········@poboxes.com> wrote:
>
> > The point about the abstract protocol and interface is this. An
> > application with a user interface should not be built as one
> > homogeneous whole.
>
> But, this is *exactly* the point of CLIM. That's the big
> difference between CLIM and ***all*** the other UIMS
> out there. It has the presentation system.
> CLIM makes it possible to decouple your user interface
> from your application logic as max as possible.
I am sorry for forgetting to note in my previous post that I don't
know CLIM and can't make any judgements about it in particular.
But having now read a few other posts on this issue, I still don't
know if the CLIM way is or is not to separate the `application'
part from the UI part. (I should RTFLiterature about CLIM---RSN.)
Vassil Nikolov
Permanent forwarding e-mail: ········@poboxes.com
For more: http://www.poboxes.com/vnikolov
Abaci lignei --- programmatici ferrei.
In article <·····················@195.138.129.99>, Vassil Nikolov <········@poboxes.com> wrote:
> But having now read a few other posts on this issue, I still don't
> know if the CLIM way is or is not to separate the `application'
> part from the UI part. (I should RTFLiterature about CLIM---RSN.)
Since CLIM works directly on the domain objects, there
is no visible layer between your application and the UI.
Ideally you write your application code - without caring
that you need an UI later. Additionally you can build
varying degrees if UIness with CLIM, starting from
complete default behaviour - the Lisp Listener gives you mouse
sensitve output...
Vassil Nikolov <········@poboxes.com> writes:
> The point about the abstract protocol and interface is this. An
> application with a user interface should not be built as one
> homogeneous whole.
[...]
> A much better approach is to build the application as a system of at
> least two separate agents, one being the `work horse' taking care of
> the working functionality and the other being the `front end' taking
> care of the user.
I have been following this thread a bit, and can observe that in my experience,
the best-designed, maintainable, and robust applications were those that had a
clear separation of concerns, and in particular, where the UI has a layer that
could be altered without changing the rest of the system.
Consider, for example, a distributed system, that could have multiple UIs on
different machines with different operating systems.
Or consider if a portion of a system is dedicated to, say, parsing input
strings, that portion had better not be aware at all of the UI. The UI had also
better not be parsing strings from text input GUI messages directly, but had
better be passing them off to the parser component (or
class/package/module/unit whatever -- I am *not* implying anything OLE!).
Good separation with clear public interfaces on how to use each component
allows the different parts to be developed and tested independently. Of course,
integration discovers all sorts of problems gluing things together, but the
point is that if there is mixing of UI/problem domain layers, things can get
unmaintainable real fast. Even if one is not planning to change the UI
technology, one might want to change the presentation method of a piece of the
system (e.g. from some sort of logging output to a dynamic visual
representation). If UI manipulation is mixed up with the problem domain, one
cannot change things around that easily, since essentially the whole
component/application needs to be rewritten. Additionally, the domain logic is
harder to understand since it gets mixed up with unrelated code -- this means
more bugs.
The point is that systems that are broken down into orthognonal, understandable
pieces, each with clear and separate responsibilities, do better by all sorts
of metrics.
So, given CLIM (of which I know nothing about, and would like a knowledgeable
person to inform me), does it encourage good design as I described above, or
does it require "CLIM awareness" throughout the application?
Or is its real advantage that it just does UI stuff in a fundamentally more
cool way, maybe one that allows programmers to be less concerned with the
tedious parts, freeing them to concentrate on the real problem at hand?
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
In article <··············@blight.transcend.org>,
Ray Blaak <·····@infomatch.com> writes:
> So, given CLIM (of which I know nothing about, and would like a knowledgeable
> person to inform me), does it encourage good design as I described above, or
> does it require "CLIM awareness" throughout the application?
>
> Or is its real advantage that it just does UI stuff in a fundamentally more
> cool way, maybe one that allows programmers to be less concerned with the
> tedious parts, freeing them to concentrate on the real problem at hand?
In my experience, CLIM does encourage that for every "glyph" on the screen,
there's one object. My objects are almost always CLOS instances. If you use
arrays or lists for representing your objects, then yes, you're going to have
to do more work to interface them to CLIM. CLIM fundamentally relies on the
type of the object for determining what to do with it. If all of your objects
are of type (ARRAY *) or CONS, CLIM's going to have trouble distinguishing
them on its own.
Now, I wouldn't necessarily recommend CLIM for every type of application.
For instance, I probably wouldn't use CLIM if I was writting a pixmap editor.
You could do it but I think all the advantages of CLIM would go unused. But
for apps that consist of "nodes" and "links", I find CLIM to be a great
solution. So for things like SNMP network monitors, electronic CAD, hypertext
documentation, CLIM works great.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> In my experience, CLIM does encourage that for every "glyph" on the screen,
> there's one object. My objects are almost always CLOS instances. If you use
I'd like to modify that to say "an object", rather than "one object". It is
quite easy to have multiple representations for an object on screen at the
same time. However, I didn't find a good way to ensure that redisplay
happened reliably across all the representations. I attribute that to not
finding enough information on the matter, rather than an inherent weakness
in CLIM.
Unless you choose to call the lack of documentation a weakness, that is.
Sunil
On 19 Jul 1999 14:12:47 +0000, Erik Naggum <····@naggum.no> wrote:
> my suggestion is to write software that is completely independent of its
> graphic user interface, using protocols and very abstract programming
> interfaces between the user interface module and the functionality that
Do you mean something like using HTTP and Web browsers as a user interface?
Paolo
--
Paolo Amoroso <·······@mclink.it>
* ·······@mclink.it (Paolo Amoroso)
| Do you mean something like using HTTP and Web browsers as a user interface?
I mean specifically the complete and utter absence of user interface --
but instead a powerful protocol interface (no, this is not the "API").
when I was young, this was called "modularization". today, it's called
"client/server", but the idea is the same: don't even think in terms of
user interfaces. think instead in terms of network protocols, as in: a
set of states and variables and how to move from state to state and set
variables. however, since both your software and the user interface do
their best when they are both in control, a protocol "hub" would be very
useful between them. I tend to call them "slaves" and give them the
non-trivial task to present a sane and nice world to the "master".
personally, I don't think HTTP is powerful enough to do anything that is
really useful as a user interface goes, but most browsers would have been
with a better protocol. Java might be used to implement just that.
I wrote some time ago in answer to "what do you use to format documents"
that I let somebody else do it, because I find it too hard to be good at
contents and formatting at the same time. the same principle applies to
user interface stuff: there are people who are good at that kind of task,
and I say let's use people's best set of skills. if they really are good
at it, they will also be able to explain exactly what a user interface
thus created needs to communicate with the server -- and that's what I
think is lacking in most user interface system design: people don't
_really_ know what the program and the user interface need to share.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
Erik Naggum <····@naggum.no> writes:
> * Hartmann Schaffer
> | You really can't learn CLIM in a free environment, and one of the posts
> | in this thread mentioned a pretty high $ figure to get a version with
> | CLIM.
>
> so people who can't use Lisp for free won't know that they should use it
> because they don't know what it is, but people know they should use CLIM
> and can't because it isn't free? I don't get it. how did they discover
> the need to use CLIM to begin with?
Sadly, this last sentence is the real point. Many people developing
Lisp GUIs _do_ need CLIM but don't realize it. Anything you write in
Lisp must have some sort of interface to its functionality, and
anything other than a library which uses Lisp as its interface will
require a command-line/file-stream or graphical interface. (Unless you
want the listener as your interface, which can give you all kinds of
error-checking headaches and other problems if you plan on doing it
robustly and correctly.)
> my suggestion is to write software that is completely independent of its
> graphic user interface, using protocols and very abstract programming
> interfaces between the user interface module and the functionality that
> enables a protection of investment in the functionality even while the
> user interface keeps changing. sadly, this is not a programming style
> that "modern" programmers know how to write, because they have been
> reduced to deal with user interfaces that invade the entire system.
Have you _used_ CLIM?
This abstract approach works between GUI tools that work
similarly. For example, with GTK, Motif, QT, Swing or 99% of other
tools out there you basically begin by creating a window, then layout
basic areas of your app using the GUI tools' implementation of the
layout manager concept, then add a menubar and menus, buttons,
scrollbars and myriad other widgets and gizmos, and then you finally
associate mouse and keyboard events with these objects with your
program's control-flow.
With CLIM you don't spend your time laying out widgets and then set
them up to handle "low-level" keyboard and mouse events. (Though it
supports this paradigm kinda like Lisp supports the BASIC/flowchart
control-flow paradigm via TAGBODY/GO, but I digress....) CLIM actually
has very few widgets; it doesn't even have pull-down menus and
menubars that 99% of GUI apps nowadays have. (Though it has all the
primitive functionality you need to implement them and I think there
is a free implementation floating around the net like at the AI
Repository or something....)
Anyways, saying that you can write an application with a graphical
user interface using abstract protocols and abstract programming
interfaces and then using Motif or Emacs as the tool to the
realization of your application's GUI is as meaningful as saying that
you can write a program using abstract concepts of OO and control-flow
so as to be independant of the implementation language and then
writing it in C.
The real problem with CLIM is that people don't "get" CLIM (many don't
even get the chance to "get" it) kinda like you might say that the
problem with Lisp is that people don't "get" Lisp and its "unsane"
syntax that "wears out the top row of your keyboard." Lisp isn't for
"hello world" applications and CLIM isn't for tic-tac-toe
players. Lisp is a good language for creating, for example, a
real-time news distribution system for a financial news agency and
CLIM is a good GUI tool for creating an intuitive, natural and
powerful monitoring and control application for a real-time news
distribution system that facilitates the exploration of and recovering
from error conditions in a very efficient and natural way and lets you
quickly pick out what you are looking for from 30MB of logging
information and enables you to generate different kinds mouse
sensitive information displays and reports from real-time and log
information in a very efficient, cool and attractive way (not to
mention printer-friendly), without needing 6 menus on a menubar each
containing their own nested menus and about 15 buttons and widgets and
text entry fields and a help menu giving documention on what all that
crap does, or needing to type in forms into a listener after figuring
out what it is you need to type and painstakingly writing a custom
parser to check errors at read time or some other way if you plan on
giving your users some control and customization ability via typing in
forms directly.
> what happens when CLIM is available for free? hey, it might need
> MOTIF. whine, whine, MOTIF isn't free
There is Lesstif, a free Motif clone.
> what's hugely important in the free software world is to distinguish
> those who will not stop asking for more from those who can make do
> with whatever they get and return something useful to the community.
[...]
> make take on this is: just fucking do it. we're programmers, damn
> it! the whole _point_ is to bring stuff into existence that exist
> merely in our dreams and on our wish lists.
If your implying something along the lines of a Free CLIM effort, then
understand that CLIM is a very large and hugely complex system, and
it's in the same league as a Common Lisp system in terms of
implementation and maintenance difficulty. Mikemac is making progress
on one, but it will be some time before the simple address book demo
runs and he considers it releasable as alpha-quality software that the
rest of us can begin to work on once the basic source infrastructure
is in place.
I don't see what vendors risk by letting people get a copy of CLIM to
learn to use it with. Sure, we're not entitled to it, but I only see
it helping Lisp and the vendors and community in general. I'd rather
have a CLIM from a commercial vendor that works with a free Lisp then
have a free version of their Lisp without CLIM. Lisp isn't dying nor
on the way out, and it is possible to get good information and books
on it and decent free implementations, making free versions of
commercial Lisps really nice to have but not essential if you just
want to learn the language, but CLIM seems to be on the way out and
you can't learn to use it for free nor get your general questions
about working with it and learning it answered anywhere and it's
really sad and frustrating.
Christopher
On Tue, 20 Jul 1999 00:17:18 GMT, Christopher R. Barry
<······@2xtreme.net> wrote:
>Erik Naggum <····@naggum.no> writes:
>
>> * Hartmann Schaffer
>> | You really can't learn CLIM in a free environment, and one of the posts
>> | in this thread mentioned a pretty high $ figure to get a version with
>> | CLIM.
>>
>> so people who can't use Lisp for free won't know that they should use it
>> because they don't know what it is, but people know they should use CLIM
>> and can't because it isn't free? I don't get it. how did they discover
>> the need to use CLIM to begin with?
>
>Sadly, this last sentence is the real point. Many people developing
>Lisp GUIs _do_ need CLIM but don't realize it. Anything you write in
>Lisp must have some sort of interface to its functionality, and
>anything other than a library which uses Lisp as its interface will
>require a command-line/file-stream or graphical interface. (Unless you
>want the listener as your interface, which can give you all kinds of
>error-checking headaches and other problems if you plan on doing it
>robustly and correctly.)
This leads to the killer question:
Who ought to be paying for the considerable investment required in
order to determine whether or not using CLIM represents a worthwhile
exercise?
Three answers come to my mind:
a) The Lisp vendor,
b) My employer,
c) Me.
Option a) is from whence comes the argument that "demo copies should
be free." There is a decent argument available in favor of this:
Lisp vendors should be interested in getting sales of licenses for
deployment, and should, for that reason, be interested in reasonably
wide dissemination of understanding of the relevant technologies.
And if, by giving away development licenses, they can get the $$$
from deployment, that should be a Good Deal for them.
The downside is that if this isn't planned carefully, it could turn
into a "tool giveaway," where the vendor winds up effectively
subsidizing another vendor. This is a significant risk with a
"standards-compliant" system, but far less so for proprietary
extensions. I would suggest that this explains the vendor disinterest
in CLIM; it has been more in their interests to invest in proprietary
graphical extensions than it has been to make CLIM work.
Option b) is a *bit* less satisfactory, as the "employer" winds up
investing in both the Lisp vendor and in the employee without
receiving any value until a system is created and sold. If the cost
is fairly low, nobody will care too much. I could readily "get away
with" getting my employer to pay $100-$200 for Java tools. But
getting them to pay $5000 for software tools, however powerful, would
be problematic.
Option c), where *I* buy and learn my own tools, puts the onus on me.
If it's my money, this can be a potent incentive for me to know what
I've invested in.
If the tool is priced at some "reasonable" level, on the scale of
$100-$200, I may well be willing to invest that. But as the price
goes up, my willingness will diminish more rapidly than in the other
scenarios, particularly when it is reasonably likely that this amount
will cost me more due to tax considerations than it would cost the
Lisp vendor or an employer.
It seems to me that Erik Naggum's position closely resembles c). It
appears that he works as an independent consultant, which means that
b) and c) get somewhat conflated.
My contention in the arena of "free software" is that it is critical
for those that depend on such to invest in the improvement of that
software, as opposed to being "free riders." My position is that
those that make significant use of free software *need* to invest
nontrivial amounts in their improvement, whether that be denominated
in dollars or in hours. (The .signature quote is highly relevant in
this regard.)
The view that I had ten years ago, when the GNU Project was new, was
that this could progress at a tremendous rate if programmers assumed
that they needed to spend $1K/year on the development of their tools,
and contributed that kind of money into free software projects. That
ignores that time has value, and that significant contributions of
time aren't as visible. But it seems pretty reasonable that a
programmer, billing out at perhaps $100K, would spend one percent of
that on "tool improvements." If that improves the performance of the
tools, and improves productivity, that can readily provide good value
for money.
Example: If there were a population of 10,000 people using CLISP or
CMU Lisp who were serious enough about their use that they were
willing to pay in a "mere" $100/year to support their improvement,
this could readily pay for there to be a "core team" of top notch
developers to maintain them. (Replace "CLISP" or "CMU Lisp" with the
name of any other piece of free software that is used to do important
things and the same applies.)
The problem is that there are a whole lot of "free riders." The
recent popularization of "open source" provides an extra model to
accomplish sponsorship of code production; if there are is a
sufficient group of people that have sufficient interest in the code
base, the availability of source code may allow some of the users to
do maintenance as part of their job, thereby adding more people into
that "core team" without the formality of hiring them by a new
employer.
We'll see how viable the model remains.
--
"If you are not willing to pay a meager $10 to support the development
of your operating system, you are too cheap to even own a computer."
-- David J. Owens <·······@home.net>
········@hex.net- <http://www.hex.net/~cbbrowne/freeecon.html>
* Christopher Browne
| Option c), where *I* buy and learn my own tools, puts the onus on me.
| If it's my money, this can be a potent incentive for me to know what
| I've invested in.
:
| It seems to me that Erik Naggum's position closely resembles c). It
| appears that he works as an independent consultant, which means that
| b) and c) get somewhat conflated.
even for hired labor they are conflated, because people tend to want to
advance, get higher pay, change to better jobs, etc, and these are not
usually in the best interest of employers: you will cost more to keep,
and it is not nearly certain that investing in someone who will turn
around and cost more to the company will yield a return on investment
during the rest of his employment, especially considering that there will
be more competitors for the same, but now better-skilled labor.
people go to school for an amazingly large fraction of their lives these
days, and it will only get worse. employers are paying people a _lot_ of
money simply to have them pre-educated by the time they hire them, as
opposed to hire people in kindergarten and cater to their education for
the next twenty years and then have them work for the same company for
the rest of their lives. this is not going to change any time soon,
which means that you are only as valuable to your employer as the next
best competitor for your time. and it behooves an employee to know his
value in such terms, too.
I must admit that I have never quite understood the "labor union" view
that employers are a necessary evil, to be fought and forced to pay for
all kinds of benefits. as an employee, you, too, are in a market,
selling your time and ability to work for others, and employers are
looking to buy your services at the lowest cost and highest benefits to
them. what I really don't understand is why employees don't recognize
that they are looking for the employer with the lowest costs and highest
benefits to them, too. this is an entirely reciprocal deal. it appears
to me that because employees are somehow "forced" to be employed (this
isn't true, either), they don't consider themselves assets, even to the
point where calling them assets is considered a negative. rather, it is
the exact reverse: people who want to make a lot of money are actually
forced to employ other people and hiring people is incredibly frustrating
in a market were most of the contenders are full of demands and of little
insight into the needs of employer. I regularly help companies screen
prospective employees and have matched up companies and people for the
past 20 years. and it pays much better than employing them myself. I
heard recently that some companies in Silicon Valley will pay an employee
USD�7,000 if they cause another person to come work for them. if that
doesn't tell you that employers are forced to employ people, nothing will.
in my view, therefore, it is in the best interest of an employee to make
himself better skilled, in order to receive better compensation for his
time, and the ability to find work he really enjoys. most educated
people are willing to go through a period of time that really isn't good
at all before they start working and earning money and realize that while
it looked great at the time to be a student, they have to pay for it for
so long, and people who didn't take an expensive education are frequently
better off than they are for a really long time. still, the desire to
have an interesting job that demands the most from you means you have to
be well educated. I really don't see why this has to stop after you find
some work. (unless, of course, you begin to realize just how hard it is
to be a student, again, and therefore want others to pay for that, too.)
you don't have to be an independent consultant to think and act as if
your employer is actually a buyer of your services. you don't have to be
a big business to think and act as if your city or state or country is
actually a buyer of your taxes, either. it even helps to realize that
those who sell groceries are actually in the market of buying your money
in exchange for their products. the surprising part in this picture is
that most good businesses already think this way, because they know that
you could take your money elsewhere and have a choice as to who you give
it to, but if their customers actually start thinking that way, instead
of thinking in terms of "needs" (which used to be the case a hundred
years ago, so it's very natural that most people continue to think as if
they are needy in some sense), they will view advertising differently
("the companies who advertise a lot must be _desperate_"), and customer
service is not something you have to accept, it's what makes you stay or
leave. now, most people believe you have to be financially independent
to think this way, but my experience is that not thinking this way is
sure way _not_ to become or stop being financially independent. (note
that while this is a strong argument against premature loyalty, loyalty
well deserved is perhaps the best reward you can get in a relationship,
be it between customer and vendor, employee and employer, or personally.)
| Example: If there were a population of 10,000 people using CLISP or CMU
| Lisp who were serious enough about their use that they were willing to
| pay in a "mere" $100/year to support their improvement, this could
| readily pay for there to be a "core team" of top notch developers to
| maintain them. (Replace "CLISP" or "CMU Lisp" with the name of any other
| piece of free software that is used to do important things and the same
| applies.)
as any business owner will tell you if you ask, it costs a lot of money
to accept money. in some cases, it even pays to give something out for
free instead of charging for it. in some cases, the vast majority of
what your customers are paying is swallowed up in the process of paying
for it. e.g., local telephone calls. in Norway in 1988, 95% of the cost
of a local telephone call paid for metering and otherwise collecting
accounting data, invoicing, and collecting the money. the single biggest
reason the price of local calls in Norway has fallen dramatically over
the past few years is in the computer systems used to collect data and
bill people, combined with better credit management and payment services
from the banks. the reason this has been so important is that human
labor in Norway is _incredibly_ expensive, so automation makes a lot more
business sense here than many other places in the world (Norway is also
the most automated society according to some Economist report). and then
there's taxation. I would be very much surprised if you would get more
than USD 200,000 in spendable money out of a million dollars of gross
revenue from 10,000 people, especially if you have to advertise, accept
credit card payments, bill people, etc, which I think you would have to.
that's not even enough to rent office space and hire one qualified expert.
| The problem is that there are a whole lot of "free riders." The recent
| popularization of "open source" provides an extra model to accomplish
| sponsorship of code production; if there are is a sufficient group of
| people that have sufficient interest in the code base, the availability
| of source code may allow some of the users to do maintenance as part of
| their job, thereby adding more people into that "core team" without the
| formality of hiring them by a new employer.
the Open Source model requires this expenditure of time to pay off to
whoever is doing it. one good way to pay people is to save them money
instead of giving them money. if everything is free to begin with, you
don't have that option. another important point is that money is the
universal means of exchange of values in our society -- it simply means
that if you can't get what you want from somebody, at least you can get
money so you can buy it someplace else. if everything is free to begin
with, you have to accept whatever you get directly. the model will work
as long as people are satifised with "internal rewards". the Open Source
model will work as long as people have a surplus of time, accept whatever
rewards they get in return for giving it to somebody else, and don't get
the impression they are being taken advantage of by those who don't give
anything but reap exactly the same rewards. at some point, the benefits
gained by those who do not give will outweigh the benefits gained by
those who do give, and that typically happens before 90% of the work has
been done. therefore, Open Source products will largely remain in what I
call "the laboratory quality stage" -- acceptable to engineers, but not
to regular users. Frederick P. Brooks wrote in his seminal work, The
Mythical Man-month, that if to make a product useful to its creator took
one unit of time, making it useful to others would take three units of
time, and integrating it into a system that others could build from would
take nine units of time. in this model, most Open Source code is still
shy of the "useful to others" stage, and a surprisingly small fraction of
the Linux software, for instance, is well integrated (almost only the GNU
tools, in my view).
I think Open Source is a reaction to the sluggishness of development of
real software tools. it is no surprise to me that mostly tools to build
new software are free, instead of real applications, nor that they are of
dubious quality. the (extended) Lisp world is in somewhat of a peculiar
situation in this regard, with almost as many Scheme implementations as
there are users, and people wanting to build their own Lisps instead of
realizing what a bargain it is to buy a commercial system and move on,
and I think Open Source will not work actually for the Lisp world. (it
is not likely to continue to work for Emacs, for instance, or much more
of the GNU repertoire of tools, both of which are so good that only
really stupid new features are easy enough to add that people do it for
free. it probably will continue to work for Linux for half a decade
more, because the chance of actually making money on it is non-zero, but
attempts to move applications into the Open Source space will fail just
as miserably as the Mozilla attempt: the investment necessary to make a
useful change will be too high for almost all the people who could get
their hands on the sources. incidentally, Common Lisp is also so good
that it takes real hard work to conjure up something worth-while adding
to the language. in other words: Open Source works well for immature,
low-quality products, just as DOS excited teenagers because it was
obviously broken yet obviously useful enough that minor rewards could be
had by fixing a small problem, and so lacking in useful applications that
even silly stuff like Norton Utilities could make loads of money.)
ironically, most programmers want to hack on programming tools, but don't
generally want to use advanced programming tools created by others,
unless it's really good or somehow manages to occupy a unique position.
I see this as the core reason why free software tools will continue to
lag behind commercial offerings, because in contrast to free software
where every addition has to be rewarding in itself, people who get paid
well for the entire system's performance and quality will tend to boring
details and also do the hard work. I also think this will be a lesson it
will take most other programmers a decade or so of their lives to learn,
just like it took me _way_ too long, in retrospect, of course.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
······@2xtreme.net (Christopher R. Barry) writes:
> I don't see what vendors risk by letting people get a copy of CLIM to
> learn to use it with.
They don't get it. Had they, Franz would have stopped developing
Common Windows and Harlequin would not have even started developing
CAPI (which, BTW, has some CLIM features).
> Sure, we're not entitled to it, but I only see
> it helping Lisp and the vendors and community in general.
Networks effects are something hard to understand for marketing/sales
people.
> I'd rather
> have a CLIM from a commercial vendor that works with a free Lisp then
> have a free version of their Lisp without CLIM. Lisp isn't dying nor
> on the way out, and it is possible to get good information and books
> on it and decent free implementations, making free versions of
> commercial Lisps really nice to have but not essential if you just
> want to learn the language, but CLIM seems to be on the way out and
> you can't learn to use it for free nor get your general questions
> about working with it and learning it answered anywhere and it's
> really sad and frustrating.
Wise words.
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: Fernando Mato Mira
Subject: [What's wrong with] CLIM (was: Is LISP dying?)
Date:
Message-ID: <379435F2.C467E975@iname.com>
"Christopher R. Barry" wrote:
> The real problem with CLIM is that people don't "get" CLIM (many don't
> even get the chance to "get" it) kinda like you might say that the
I don't know. Many years ago I tried CLIM but it was very slow [and `flat
looking', I know, I know..]
Although I got the idea, later exposure to constraint-based GUIs make me think
of it as old-style GUI
programming in some respects.
presentations+constraints. That's the ticket. CLIM 3 anyone?
Kent M Pitman <······@world.std.com> wrote:
>people should not lament the passing of things
>they are not willing to invest in. This newsgroup has a number of people
>who my sense is both want a lot of free things and want to debug why
>Lisp is in the trouble it's in.
Perl and Python seem to do fine without commercial language-processor
vendors. what is different about Lisp that makes it dependant on vendors?
evidence that Perl and Python are doing fine: we can estimate popular
interest in a language by measuring newsgroup traffic.
first # in each line is articles on Netcom's newsspool Jun 1998.
second # is articles on Best's newsspool today.
1438, 4135 in comp.lang.perl.misc
189, 690 in the other 3 perl ngps.
456, 1042 in the 2 python ngps.
198, 960 in scheme and lisp.
I hypothesize that the main reasons for the lack of programmer interest
in Lisp (CL, Scheme, etc) are technical: in particular,
Lisp is happiest when all processes share the same big memory space.
in contrast, as Martin Rogers said in this group almost 2 years ago,
>Whether right or wrong, the mainstream orthordoxy is to run each app in its
>own process and protected memory space. Is the Lisp orthordoxy to run code in a
>Lisp machine? If so, then this _may_ explain why it is that someone would ask
>about the "Limitations of Lisp" instead of the advantages.
this difference in "theory" of memory makes it difficult to interface
Lisp code with non-Lisp code. nowadays, interfacing with other code
written in languages over which one has no control (or written in C/C++)
is one of the programmer's most important functions.
--
Richard Enwol ·····@best.com
"Better to be wrong than to be vague" --Freeman Dyson
* Richard Enwol <·····@best.com>
| evidence that Perl and Python are doing fine: we can estimate popular
| interest in a language by measuring newsgroup traffic.
but what are they talking about? the reason MS-DOS became a success was
that all its users were dissatisfied with it and had to hack all sorts of
useless little trinket programs to make it approach usefulness. the
reason Perl has become a success is quite similar: it is obviously
useful, so people start using it, but it is fundamentall braindamaged, so
everbody has a good idea for some improvement, the acceptance of which
makes the system as a whole less useful, but boosts the ego of whoever
suggested the improvement and makes him a loyal user. the more bugs a
design has, the more visible it thus is. the more it just works and thus
how invisible it is, the more people don't talk about it. by such
measures, that which simply works right, does not get popular, and that
which is fundamentally broken so people keep complaining about it, gets
very popular.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
> the reason Perl has become a success is quite similar: it is obviously
> useful, so people start using it, but it is fundamentall braindamaged, so
> everbody has a good idea for some improvement
How is perl braindamaged? I am asking this honestly, and am not trying to start
a language war. I can think of some standard objections, along with some
standard responses, but some biting criticism would be good.
I am very big on pure, beautiful, orthogonal languages (so lisp/scheme is right
up there on my list), and yet perl is also one of my favourites. Am I being
inconsistent? In fact, if I was stuck on a desert island, and good only keep
one programming language, it would probably be perl, due to its infectious
usefulness.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: William Deakin
Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?)
Date:
Message-ID: <379EBCE1.14492BEC@pindar.com>
Ray Blaak wrote:
> In fact, if I was stuck on a desert island, and good only keep one programming
> language, it would probably be perl, due to its infectious usefulness.
I like perl too but would choose CL because you can do more with it.
:-) will
From: Erik Naggum
Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?)
Date:
Message-ID: <3142139654736946@naggum.no>
* Ray Blaak <·····@infomatch.com>
| In fact, if I was stuck on a desert island, and good only keep one
| programming language, it would probably be perl, due to its infectious
| usefulness.
hmmm. you got me thinking now.
I'd choose Common Lisp, because what Perl has that Common Lisp doesn't
have would keep me occupied for about six months, and then I'd have an
even more infectiously useful tool that'd last me a long time plus there
would be a good reason for people to save me. if you choose Perl, you
either set out to do useful stuff immediately and exhaust the offers of
the desert island in six months and go nuts, or you set out to write a
Common Lisp in Perl, but then it would also be most beneficial for
society not to save you.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
From: Lars Marius Garshol
Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?)
Date:
Message-ID: <wkwvvlp6i4.fsf@ifi.uio.no>
* Ray Blaak
|
| How is perl braindamaged? I am asking this honestly, and am not
| trying to start a language war. I can think of some standard
| objections, along with some standard responses, but some biting
| criticism would be good.
Here is my take on what is wrong with it:
<URL: http://www.stud.ifi.uio.no/~larsga/download/artikler/perl.html >
That article is unfortunately not 100% factual at the moment. I'll
fix it in a week or so, when I've finished my thesis.
--Lars M.
Lars Marius Garshol <······@ifi.uio.no> wrote:
><URL: http://www.stud.ifi.uio.no/~larsga/download/artikler/perl.html >
i want to add my vote for perl's following contras (and a view pros):
* forces unreadability (obscurity) in optimizations
(e.g. "schwartzian transform")
http://www.perl.com/CPAN/doc/manual/html/pod/perldsc.html
or http://www.perl.com/CPAN/doc/manual/html/pod/perllol.html
though this is nice for c kinda folks to make them feel brave
and clever, which is an important positive motivation, it makes it
impossible to maintain and it doesn't scale.
* arrays can hold only scalars, so you have to use references and
anonymous arrays, hashes.
* references have a impossible to learn/keep syntax.
i still don't know how to dereference right.
so complex data structures are not only hard to build,
remembering the syntax for "(" "[" or "{" initializers,
they are also hard to read.
* the object system feels like a hack or later addon.
i almost looks like a microsoft language.
the syntax is unreadable, a macro system is really missing
here.
* the module system is overly complicated. people should be forced to
write modules but only 2% (the top guns) actually do.
but on the other hand it has some nice lisp'ish features which made me
fall in love with perl. eval, closures, slices, world's best regex,
hashes, fast string processing, multiple namespaces per variable, easy
FFI,
automatic type coercion, which could remind one to the broken coercions
in visual basic, but perl's is really okay.
there's even a perl lisp module which can read and eval (interpret) gnus
emacs files.
documentation is excellent.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
From: Lars Marius Garshol
Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?)
Date:
Message-ID: <wkogguwgii.fsf@ifi.uio.no>
* Reini Urban
|
| * forces unreadability (obscurity) in optimizations
| * arrays can hold only scalars, so you have to use references and
| anonymous arrays, hashes.
| * references have a impossible to learn/keep syntax.
| * the object system feels like a hack or later addon.
| * the module system is overly complicated. people should be forced to
| write modules but only 2% (the top guns) actually do.
It's worth noting that none of these points apply to Python.
| but on the other hand it has some nice lisp'ish features which made me
| fall in love with perl. eval, closures, slices, world's best regex,
| hashes, fast string processing, multiple namespaces per variable, easy
| FFI, automatic type coercion,
Except for closures, multiple namespaces and automatic type
conversion, Python has all these as well, and the FFI is reputedly
much simpler than that of Perl.
In addition comes other advantages that stem from the fact that OO is
properly integrated and that modules are easy to make: the community
is small, but it spews out reusable and useful modules at an amazing
rate.
| documentation is excellent.
Ditto for Python.
In other words: if Perl annoys you I think you should consider dumping
it in favour of Python.
--Lars M.
Lars,
I went the same way as you with perl->python but my conclusio was
different.
Lars Marius Garshol <······@ifi.uio.no> wrote:
>* Reini Urban
>|
>| * forces unreadability (obscurity) in optimizations
>| * arrays can hold only scalars, so you have to use references and
>| anonymous arrays, hashes.
>| * references have a impossible to learn/keep syntax.
>| * the object system feels like a hack or later addon.
>| * the module system is overly complicated. people should be forced to
>| write modules but only 2% (the top guns) actually do.
>
>It's worth noting that none of these points apply to Python.
yes.
I compared perl to lisp and not perl to python as you did on your web
page. perl to python is a completely different thing. I also switched
for some time from perl to python, because of the very same arguments as
you noted. but somehow i'm still using perl and lisp and not python and
perl.
why? hmm, that's a tough question. my decision was probably not a
intellectual one, just a few thoughts:
perl is more "lisp'ish" than python, while python is cleaner in syntax,
style and object orientation.
perl is also more "hacker'ish" which makes me feel brave sometimes:
>> ... his is nice for c kinda folks to make them feel brave
>> and clever, which is an important positive motivation, ...
python has one of the best OO systems around, though it was still too
hard for me to use without any stupid error. i think i could try it with
smalltalk or eiffel but in general i don't care that much about objects.
i can live without.
for me lisp (with CLOS or KR from garnet or smaller OO's such as xlisp,
meroon, ...) has by far the easiest OO system to understand and use. and
its features are nice to have as well :)
so that's no plus for python, only a minus for perl.
FFI and bindings is a big plus for python, community efforts and culture
as well. perl became too important and Win32+CGI heavy in the last
years. I used it mainly in version 4, perl5 doesn't make me that happy
anymore. only CPAN. perl has the critical mass.
it must be my arguments for perl as written below:
>| but on the other hand it has some nice lisp'ish features which made me
>| fall in love with perl. eval, closures, slices, world's best regex,
>| hashes, fast string processing, multiple namespaces per variable, easy
>| FFI, automatic type coercion,
>
>Except for closures, multiple namespaces and automatic type
>conversion, Python has all these as well, and the FFI is reputedly
>much simpler than that of Perl.
yes.
>In addition comes other advantages that stem from the fact that OO is
>properly integrated and that modules are easy to make: the community
>is small, but it spews out reusable and useful modules at an amazing
>rate.
agreed. very amazing.
>| documentation is excellent.
>
>Ditto for Python.
python's is much better.
>In other words: if Perl annoys you I think you should consider dumping
>it in favour of Python.
if perl annoys me I use lisp or scheme not python :)
some anecdote:
some years ago I thought that python would be a better scripting, eh API
language for AutoCAD than AutoLISP, VisualBasic and C++.
I tried to persuade the Autodesk API boss to use python internally and
just provide some bindings for the currently popular languages.
(Marc Hammonds PythonWin) This would have solved a lot of problems,
mainly threads, GUI, dynamic objects, GC, security, COM but still being
platform independent and not so Microsoft dependent with all its risks
and bad reputation.
i thought that C++ programmers will embrace python much more than java,
imho python is much more the "better C++" than java.
but now, recalling that, i think it was a wise decision not to drop lisp
in favor of python, one language for everything.
we better improve our lisp and let the C++ folks go their own way.
this is politically correct (MS domination) and the existing C++
domination in school and companies gets the most people into the
spurious levels of a vendor proprietary API. (MFC and ARX, this must be
hell)
AutoLISP is also as nice as python for the average non-techie cad user,
but has a good tradition, a huge user base and better prospects (more CL
compatibility).
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
From: Erik Naggum
Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?)
Date:
Message-ID: <3142137697008791@naggum.no>
* Ray Blaak <·····@infomatch.com>
| How is perl braindamaged?
fundamentally. (I already said that.)
| I am asking this honestly, and am not trying to start a language war.
neither am I.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
> * Ray Blaak <·····@infomatch.com>
> | How is perl braindamaged?
> fundamentally. (I already said that.)
Right.
How is perl fundamentally braindamaged?
That is, in your opinion, what are the problems with the language? I can think
of a bunch, but given that you have had interesting insights in other posts, I
am interested in why *you* think it is fundamentally braindamaged.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: Erik Naggum
Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?)
Date:
Message-ID: <3142141968727880@naggum.no>
* Ray Blaak <·····@infomatch.com>
| That is, in your opinion, what are the problems with the language?
look, I have no intention of starting a language war, and I said so.
| I can think of a bunch, but given that you have had interesting insights
| in other posts, I am interested in why *you* think it is fundamentally
| braindamaged.
Perl aficionados will crawl out of the woodwork to counter any claim,
like have done every time in the past, and it just isn't worth anyone's
time to do that here. this is NOT a Perl newsgroup. (CLISP aficionados
get really upset with any mention of any sort of problem with it, but
that's at least on-topic.)
I nonetheless appreciate the compliment.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
From: William Deakin
Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?)
Date:
Message-ID: <379EE35D.F29540AE@pindar.com>
Erik Naggum wrote
> ... it just isn't worth anyone's time to do that here. this is NOT a Perl
newsgroup.
I agree.
Ray Blaak wrote:
> I can think of a bunch, but given that you have had interesting insights in
other posts, I am interested in why *you* think it is fundamentally
braindamaged.
I agree with this also. I would be interested in your insight in to these
problems. I have visited your website and have read, with interest, the
articles posted there and believe they deal intelligently with many issues
including those related to CL and other languages. Humbly, may I suggest that
a website or even your website may be a more appropriate place for a such a
disclosure.
Best Regards,
:-) will
From: William Deakin
Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?)
Date:
Message-ID: <379EEFC3.874A7C94@pindar.com>
Please ignore my previous posting. Having just read the answer about the
whether you would use perl, you have kindly provided the insight I wanted.
Thank you and Best Regards,
:-) will
From: William Deakin
Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?)
Date:
Message-ID: <379EC04C.DD653F08@pindar.com>
Erik Naggum wrote:
> * Ray Blaak <·····@infomatch.com>
> | How is perl braindamaged?
>
> fundamentally. (I already said that.)
OK, but would you ever use perl?
perl is a tool and like all tool is useful in what it does. Working where I
have to do some sys admin stuff under UNIX I find perl, (and sed, awk and
so on) useful. I also like the way that I can easily and quickly hack UI's
together using perl/Tk. perl makes it easy things to connect to a database
across a network. And so on. I believe perl to be a useful, albeit flawed,
tool .
If I then wanted to write a system for some natural language processing
(which is today's coding task) I would prefer to be nailed to a table than
implement this is perl (and if I had to write it in C++, shhush, flayed
alive or something) and would choose the Right Tool For The Job. And that
tool is CL.
This is an argument for some form of pragmatism. But what appears to be
language fundamentalism is very interesting, as is the fact that I have
probable missed the point....
:-) will
From: Erik Naggum
Subject: Re: How is perl braindamaged? (was Re: Is LISP dying?)
Date:
Message-ID: <3142145710427254@naggum.no>
* William Deakin <·····@pindar.com>
| OK, but would you ever use perl?
not if I could avoid it. (I have actually programmed a fair bit in Perl,
like I have C++ code published with my name on it. other things I have
tried and have no intention to do again if I can at all avoid it include
smoking, getting drunk enough to puke and waste the whole next day with
hang-over, breaking a leg in a violent car crash, getting mugged in New
York City, or travel with Aeroflot. such experiences lead me to assume
that Perl users bang their head against the flaws over and over just to
see if they are still there, like a dog that goes "wow! a ball! WOOF!
wow! a ball! WOOF! wow! a ball! WOOF!" (etc) all day.)
| Perl is a tool and like all tool is useful in what it does.
sure, but I still don't want to have any nuclear warheads stored in my
basement, no matter how good they are at what they do (despite being
evidence of a lot of really cool physics and engineering).
to abuse the koan style (paraphrased, not original):
a novice had a problem and could not find a solution. "I know", said
the novice, "I'll just use Perl!" the novice now had two problems.
watch someone using Perl, just about anyone. chances are they are trying
to make some _other_ tool behave correctly, and Perl offers the duct tape
and the chewing gum to make it hold together for a little while. this is
sometimes necessary, but the big problem with this approach is that Perl
people are _satisfied_ with duct-tape-and-chewing-gum solutions. instead
of going back to fix whatever the real problem was afterwards, they use
more and more duct tape and chewing gum.
bottom line is: Perl was designed to solve the wrong problem and does it
very well, which makes for MORE and frequently much harder problems, but
that is just fine with Perl people, because it goes to prove how useful
Perl is: it can solve _all_ the problems it creates. if the problem is
too hard, Perl people tend to dismiss them with "we just have to live
with that". this way, a simple problem in the format of a report from a
database can lead to serious problems that the whole organization just
has to live with. (I want to squeeze in something about Y2K here, too.)
I have done project firefighting for many years, and like firemen have
this amazing ability to locate where a fire started in the charcoal
carcass of a building by asking a few tough questions, I use the line
"show me the Perl scripts" when a manager calls on me to find a problem.
some laugh. most don't. I have done more to unemploy Perl than any
other programmer I know about. Perl mostly has a managerial solution:
give their programmers time to find and fight the real problem, don't
_ever_ let them get away with a short-term fix in the long run.
my biggest problem is that I can spot problems in Perl scripts much more
accurately that I can ever figure out what they are trying to do.
| This is an argument for some form of pragmatism. But what appears to be
| language fundamentalism is very interesting, as is the fact that I have
| probable missed the point....
well, I'm not a language bigot, but I sometimes play one on the Net, and
Perl and Scheme people are particularly entertaining the way the struggle
SO hard to convince themselves that their language of choice doesn't suck.
(please note that all of this is my experience and opinion, not something
there is any purpose in refuting, and I'm not going to swayed by other
people's experience or opinion, but if you think that's inconsistent, I
can apologize for the anecdotal arguments right away, as if that helps.)
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
>>>>> On 28 Jul 1999 10:15:10 +0000, Erik Naggum <····@naggum.no> said:
[I'm also not interested in a language war, but I am very interested
in many languages and am perfectly happy to engage in rational
discussion about features and problems present in various languages.]
Erik> well, I'm not a language bigot, but I sometimes play one on
Erik> the Net, and Perl and Scheme people are particularly
Erik> entertaining the way the struggle SO hard to convince themselves
Erik> that their language of choice doesn't suck.
Whilst no language is (completely) perfect, my own view of Perl's
utility is significantly less extreme. This might well be because my
experience is vastly different from Erik's, though I will readily
acknowledge that there are a great many environments that (mis)use
Perl, i.e., as a tool to allow them to do the Wrong Thing more easily.
I just happen to have had the good fortune to work in environments
where it was being used to do very interesting and useful things.
(And I don't mean this in some sort of "you're wrong" sense; I merely
wish to suggest--more for folks reading on the sidelines than for
Erik, whom I have no intention "to convert"--that there is anecdotal
evidence to the contrary of what has been offered so far.)
I have been working on a system to manage Unix and NT user accounts,
driven purely from an SQL-accessible database with information about
users, groups and projects to which they belong, resources in the
environment which various projects are allowed to use, etc. The idea
is that all state data is maintained in the database and that by
performing extracts of the database, we can determine exactly what a
user's account should look like, and be sure to configure them
appropriately, adding new folks, removing old folks, etc.
My language of choice for the project was Common Lisp. The project,
which is to begin its testing phase on Monday, ended up being written
in Perl. There were a number of reasons for this. I haven't the time
to enumerate a complete list, but a big issue was the need to write
foreign functions to handle much of the actual work that would take
place, or the need to implement libraries to interface to such things
as NIS, NFS, and NT system code. In Unix-land, this would have to run
setuid. In Lisp, I would have needed a setuid startup program that
would bring up the main program (implemented in Lisp), which would
then rely on functions written in other languages. Given that
simplicity and ease of code management were requirements, this (and
the lack of Lisp expertise in the environment) weighed against Lisp
heavily.
The whole thing would have been beautiful from the database right up
to the operating system interfaces. But things would have gotten very
nasty very quickly from that point, unless there are things about Lisp
(specifically CMU CL) that I don't know.
With Perl, interfaces to NT, Unix, and SQL were givens. The only big
stuff to implement was the handling of the data extraction and
resolution. With Perl's ability to build complicated data structures
and handle recursion, I was able to implement this part elegantly, in
a very Lispy style.
Perl's syntax is nothing to Lisp's--I greatly prefer the latter--but
it is quite possible to do the Right Thing with it.
Frankly, I think that making statements like "Perl is fundamentally
braindamaged" is silly and unproductive. Instead of "fighting" each
other all the time, I think we'd be a lot better off if we'd take that
energy to learn what we can from each other.
(If anyone could offer a better solution to my problem of interfacing
to NIS, NFS, and the like from Lisp than through potentially annoying
to maintain foreign functions, I'd be happy to hear it. Perhaps
libraries for this kind of thing exist someplace? I have threatened
to rewrite the whole thing in Lisp already... ;-)
--
Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
From: Lieven Marchand
Subject: Re: Why I chose Perl even though I wanted to use Lisp (was "braindead")
Date:
Message-ID: <m3k8rfelbn.fsf@localhost.localdomain>
Matt Curtin <········@interhack.net> writes:
> With Perl's ability to build complicated data structures and handle
> recursion, I was able to implement this part elegantly, in a very
> Lispy style.
Could you explain how to build data structures in Perl? I always used
to end up with a completely unmaintainable maze of hashes in hashes,
refs to these things etc. The web page someone earlier in the thread
quoted (http://www.stud.ifi.uio.no/~larsga/download/artikler/perl.html)
confirms my experience.
Nowadays, I do most of this stuff in CL and if I need to access a
protocol/device/... that I haven't written something in CL for and
that I don't foresee using enough to make it worth my time, I use just
enough lines perl to get the data and dump it in a Lisp readable
format.
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
Lieven Marchand <···@bewoner.dma.be> writes:
> Could you explain how to build data structures in Perl? I always used
> to end up with a completely unmaintainable maze of hashes in hashes,
> refs to these things etc. The web page someone earlier in the thread
> quoted (http://www.stud.ifi.uio.no/~larsga/download/artikler/perl.html)
> confirms my experience.
The trick with complex data structures in Perl is to stay disciplined. Don't
whip off such data structures on the fly (e.g. {"field1" => data1, ...} here
and {"field1" => data2, ...} there).
Instead, make yourself some constructor and accessor routines that implement
the representation once and for all, and stick to using only them. Your code
will be less buggy and more readable.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
·····@infomatch.com The Rhythm has my soul.
From: Tom Breton
Subject: Re: Why I chose Perl even though I wanted to use Lisp (was "braindead")
Date:
Message-ID: <m3oggrgp0l.fsf@world.std.com>
Lieven Marchand <···@bewoner.dma.be> writes:
> Matt Curtin <········@interhack.net> writes:
>
> > With Perl's ability to build complicated data structures and handle
> > recursion, I was able to implement this part elegantly, in a very
> > Lispy style.
>
> Could you explain how to build data structures in Perl? I always used
> to end up with a completely unmaintainable maze of hashes in hashes,
> refs to these things etc.
This would be a question for comp.lang.perl
But yes, that *is* how you generally build data structures in Perl.
1/2 }:) (OK, there's Perl classes, and tie, but this is really
off-topic)
--
Tom Breton, http://world.std.com/~tob
Ugh-free Spelling (no "gh") http://world.std.com/~tob/ugh-free.html
>>>>> On 01 Aug 1999 14:29:00 +0200,
Lieven Marchand <···@bewoner.dma.be> wrote on comp.lang.lisp:
[I'm crossposting to comp.lang.perl.moderated and redirecting
followups there, since I believe we have said all that we have to say
about Lisp.]
Matt> With Perl's ability to build complicated data structures and
Matt> handle recursion, I was able to implement this part elegantly,
Matt> in a very Lispy style.
Lieven> Could you explain how to build data structures in Perl?
In this particular case, I'm using hashes of hashes and arrays of
hashes. I pass everything from function to function by reference. I
dereference things as I catch things at the beginning of my functions.
How to do all of this is pretty well documented in the `perldsc'
manpage.
I have no problems with the syntax or maintainability of the code. I
prefer Lisp's simple elegance, but for someone well versed in Perl (or
willing to read the documentation and experiment a little in throwaway
programs to test his understanding of what he's read), this is
essentially a non-issue. It was certainly nothing by comparison to
what I believe I would have had to do in order to interface to Unix
disk quota interfaces, NIS, and other goodies.
--
Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
In article <··················@gold.cis.ohio-state.edu>, Matt Curtin <········@interhack.net> wrote:
> (If anyone could offer a better solution to my problem of interfacing
> to NIS, NFS, and the like from Lisp than through potentially annoying
> to maintain foreign functions, I'd be happy to hear it. Perhaps
> libraries for this kind of thing exist someplace? I have threatened
> to rewrite the whole thing in Lisp already... ;-)
We have been using Lisp/Scheme in several internal and
external projects where you might have chosen something like PERL.
- an interface to SMS (short message services)
- a distributed web log management system
- a firewall/DHCP configuration system getting its
user/group data from an SQL database
- and numerous other stuff
Tools we found useful on Unix: Clisp, GCL, scsh and SIOD.
For most "scripting" stuff we are now using Clisp whenever
it is possible - this is an internal guideline. Everybody
who wants to work in our ISP/sysadmin team
has eventually to learn and use Common Lisp.
If it comes to more "hardcore" shell programming,
I'd use scsh.
Btw., using a commercial Common Lisp like ACL or
LispWorks should be preferred (IMHO), but they
are simply too expensive for our purpose - to develop
Lisp-based tools under Unix. If you were working
with a company or university that has a site+maintenance
license for those, you may want to go that route.
From: Howard R. Stearns
Subject: Re: Why I chose Perl even though I wanted to use Lisp (was "braindead")
Date:
Message-ID: <37A8702E.1B7A7998@elwood.com>
Matt Curtin wrote:
> ...
> (If anyone could offer a better solution to my problem of interfacing
> to NIS, NFS, and the like from Lisp than through potentially annoying
> to maintain foreign functions, I'd be happy to hear it. Perhaps
> libraries for this kind of thing exist someplace? I have threatened
> to rewrite the whole thing in Lisp already... ;-)
Do I correctly understand that the issue with Lisp is that you need to
frequently call small operating system utilities that must themselves
run with a particular user id (e.g, as root)?
What would be wrong with calling them through some external interface --
either as a reference to a "shell command", or by using ILU or your
vender's CORBA interface to communicate with some "root daemon slave" to
your Lisp "main program"?
>>>>> On Wed, 04 Aug 1999 11:54:06 -0500,
"Howard R. Stearns" <······@elwood.com> said:
Howard> Do I correctly understand that the issue with Lisp is that you
Howard> need to frequently call small operating system utilities that
Howard> must themselves run with a particular user id (e.g, as root)?
Yes.
Howard> What would be wrong with calling them through some external
Howard> interface -- either as a reference to a "shell command", or by
Howard> using ILU or your vender's CORBA interface to communicate with
Howard> some "root daemon slave" to your Lisp "main program"?
Nothing would be wrong with this approach, per se, but it would cause
a bit of an issue with one of my driving requirements: simplicity and
maintainability. One of the unfortunate consequences of these
requirements is that implementing systems where different pieces are
written in different languages is a pretty big "no-no".
(It's a university CIS department, where turnover is high, and
expertise, on average, is not. Writing something where I have little
programs written in C or Perl to run as various users to do the work
of the core part of the system written in CL would require quite a lot
of fighting against an argument--"lack of maintainability in this
environment" that isn't completely lacking in merit.)
--
Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
* Richard Enwol
|
| evidence that Perl and Python are doing fine: we can estimate popular
| interest in a language by measuring newsgroup traffic.
Perl and Python _are_ doing fine, especially Perl, but Python is
definitely on the rise.
The reason they are doing fine is mainly that they have been hyped a
little (although nowhere near as much as Java) and are associated with
the web. Another is the basic 'coolness' factor.
| I hypothesize that the main reasons for the lack of programmer interest
| in Lisp (CL, Scheme, etc) are technical: [...]
How could they be when hardly anyone knows Lisp? Very few people have
just a passing knowledge of Lisp, although Scheme has been gaining
somewhat due to use in open source projects.
I think part of the problem here is that Lisp users hardly have a web
presence to speak of, there are no repositories of Lisp code, few Lisp
applications available on the web and when Lisp is used nobody seems
to dare mention it. (For example, I tried to look at the NASA remote
agent site to see if the word Lisp was mentioned anywhere. As far as I
could see it was not.)
Marketing-wise Lisp is a stealth language and I think this contributes
to keep the myths from the past alive.
Another problem was pointed out to me by a manager who had actually
programmed Common Lisp at a research institute. Hiring someone to
program in Common Lisp is very different from hiring someone to
program in Python or Java.
Finding someone who knows Java is easy. Finding someone who knows
Python is difficult, but if you know a mainstream language it only
takes a couple of days before you can start to program, so there's no
real problem. Finding someone who knows Common Lisp is hard and it
takes months to train someone to use it.
--Lars M.
In article <··············@ifi.uio.no>, ······@ifi.uio.no says...
> I think part of the problem here is that Lisp users hardly have a web
> presence to speak of, there are no repositories of Lisp code, few Lisp
> applications available on the web and when Lisp is used nobody seems
> to dare mention it. (For example, I tried to look at the NASA remote
> agent site to see if the word Lisp was mentioned anywhere. As far as I
> could see it was not.)
Well, a number of frequent posters here have some fine web pages
devoted to Lisp. Since we've had some figures for newsgroup activity,
perhaps we could count the number of pages, of the number of K of
text, or even a link count for Lisp resources.
I'll the matter of comparing these figures with those for other
languages as an exercise for the reader. ;) Any figures I could give
would be incomplete, and therefore misleading.
As for mention Lisp, I know of an HTML editor that is apparently
written Scheme, but alas the vendor doesn't advertise this fact.
I think I can understand why. While this particular editor may be more
powerful and friendly than most other HTML editors that I know, it can
also be a _little_ bit slower. The last version that I saw had a
tendency to crash, but that was more likely related to the use of
various components written in C++, rather than anything Lisp-related.
However, critics of Lisp will focus on the negative points rather than
the positive. These negatives would be dismissed if the software was
entirely written in, say, C++. After all, everyone "knows" how fast
and reliable C++ is...All that heavy marketing pays off.
> Marketing-wise Lisp is a stealth language and I think this contributes
> to keep the myths from the past alive.
In the past, this ng has seen a fair number of C++ displaying their
ignorance of Lisp and their firm belief in those myths. Hopefully,
each and every one of them gained some enlightenment as a result of
the friendly re-education they received from Lisp programmers.
Even so, that still leaves a huge number of clueless programmers.
More recently, Paul Graham did something with a higher profile, by
creating a business with Lisp at the heart of it. Each time I've
looked, I could find no mention of Lisp on the Viaweb site, but then
most people using that service won't want to read about Lisp.
So, if Perl and Python can benefit imagewise from "sexy" app domains
like the web, then so can Lisp. The barriers are not technical.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
* Lars Marius Garshol <······@ifi.uio.no>
| Finding someone who knows Common Lisp is hard and it takes months to
| train someone to use it.
this isn't my experience. perhaps your manager was looking for Common
Lisp programmers in the mainstream section of the market? I also have a
hard time believing the training period.
on the other hand, finding a _good_ programmer is damn hard in today's
market, no matter which language you're targeting, but you can find
people who claim to know any hyped-up, popular language. as I have said
previously, people lie about their Java skills all the time, but still
get hired. you can't lie about Common Lisp skills. perhaps this keeps
eager newbies out, since a lot of the training you imply would be needed
for Common Lisp is spent writing production code in Java.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
* Lars Marius Garshol
|
| Finding someone who knows Common Lisp is hard and it takes months to
| train someone to use it.
* Erik Naggum
|
| this isn't my experience. perhaps your manager was looking for
| Common Lisp programmers in the mainstream section of the market?
He was. Like it or not, but that is where the majority of programmers
are. And that company is currently struggling to hire anyone at all,
although I don't really know why.
| I also have a hard time believing the training period.
That was his experience, and from learning it myself and seeing others
struggle to 'get it', I would readily believe his estimate.
| on the other hand, finding a _good_ programmer is damn hard in
| today's market, no matter which language you're targeting,
True.
--Lars M.
* Lars Marius Garshol <······@ifi.uio.no>
| He was. Like it or not, but that is where the majority of programmers
| are.
this reminds of the drunk who staggered around a lamppost and seemed like
he looked for something. a helpful man asks him "are you looking for
something?" "yes, my watch!" the helpful man looks, too, and there's no
watch to be seen. "did you lose it here?" "no, I lost it over there",
the drunk says and points to a dark doorway. "but why are you looking
here?" "because there's better light here!"
(I'm not insinuating that your manager was drunk.)
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
> * Lars Marius Garshol <······@ifi.uio.no>
> | Finding someone who knows Common Lisp is hard and it takes months to
> | train someone to use it.
>
> this isn't my experience. perhaps your manager was looking for Common
> Lisp programmers in the mainstream section of the market? I also have a
> hard time believing the training period.
>
I feel I can speak with some authority here. Given a reasonable level
of background competence in the trainee, it's possible to train people
in CL in a week, to the level where they are probably already useful,
and are capable of progressing under their own steam the rest of the
way. Of course, they are not fluent CL programmers at the end of that
time, but no-one, other than perhaps very gifted people, is fluent in
any non-trivial language after a week.
That week is a fairly exhausting experience (for the trainers too!),
and a couple of week-long courses spread over a month or so is
probably better in the abstract, but it is possible to do in a week.
If anyone wants more information they should probably contact me by
mail as any more detail would be perilously close to advertising.
--tim
Tim Bradshaw wrote:
> ... it's possible to train people in CL in a week, to the level where they are
> probably already useful, and are capable of progressing under their own steam
> the rest of the way.
I wish I had a better memory because I cannot remember the reference. Yesterday
I was reading something that was banging on about the fact that a freshly
trainned C/C++ programmer maybe able to start coding immediately but will be
producing poor quality code. A CL programmer with help can almost immediately
start producing good quality code.
This is also backed up with my experience of learning C++ and learning CL. Both
involved a weeks intensive course. Both are used by me to code stuff. I can now
look at the cack code that I wrote straight after the C++ course which I have
had to rewrite or the hammy code after the CL course most of which I still think
looks ok. But then again ignorance is bliss....
> Of course, they are not fluent CL programmers at the end of that time, but
> no-one, other than perhaps very gifted people, is fluent in any non-trivial
> language after a week.
I would like meet anybody who is fluent in any computer language after a weeks
training and shake their hand :-o
Cheers,
:-) will
* ·······@dyn.com (George Neuner)
| The reason C/C++, and before that Pascal, took off was because forward
| looking companies [I'm thinking of Borland in particular, but others were
| also involved] took chances and sold their systems at well below cost
| hoping to create their markets. It is true that these systems were
| typically stripped down relative to "professional" development systems
| available, but they introduced people to the language at affordable cost
| and built a base of programmers familiar with both the language in
| general and the company's products in particular.
the same has been done in the marketing and production of wines. those
who sell dirt cheap wine continue to thrive, and we see the same effect
as we do in programming languages: large masses of people get intoxicated
and dependent and contine to devour cheap wine, while a few people get
seriously interested in great wines and easily spend 100 times more money
on a bottle of a great wine than regular consumers do. yet, for some
bizarre reason, expensive wines make a respected market, nobody in their
right mind wants them to be free, and it is not considered a good thing
to turn people into alcoholics just to be able to sell more cheap wine.
| Curious newcomers who lack the ability to set up a shareware/freeware
| system may be willing to try a low cost commercial system which is easy
| to install and use. Commercial Lisp implementors, for the most part,
| either didn't offer low cost intro packages or didn't advertise that they
| did. Out of sight, out of mind.
right. the commercial Lisp vendors offer anyone who ask a reasonable
question a simple and easy way to try their software, completely for
free, and free or extremely low-cost systems somehow is not enough to
make people interested in serious Common Lisp implementations, in some
people's minds. so obviously your analogy doesn't hold at all.
I started with CMUCL myself, but found that Allegro CL offered so much
more that the work I would need to put into CMUCL would make it all but
impossible to do well-paid work in Common Lisp in CMUCL: after pretty
serious exposure to C++, I had come to conclude that I needed to get
myself into a position where I would never ever have to write any C++
again, so I set out on a path that removed me almost completely from the
mainstream, and if I were to recover the cost of that, only commercial
Lisps supported by someone other than myself could work for me. (I would
like a commercial Emacs, too, for exactly the same reasons. perhaps I'm
just getting old.)
I'd argue that what has kept Common Lisp from wide-spread success is its
free implementations -- not only are the implementations that students
normally see low quality as development environments go, all the crappy
Schemes out there that try really hard to call themselves "Lisp" destroy
the name recognition of Lisp completely (why can't they just stick to
calling their toys "Scheme"?), and any student who didn't question his
professors and peers would have to conclude that Lisp is a bad joke.
the reason C succeeded is that Unix succeeded, and Unix succeeded because
of the coolness factor among early 70's computer science students, and
that was a coolness factor unrelated to overall technical merits, but
very much related to _some_ brilliant ideas. DOS succeeded because it
was so broken that any 14-year-old idiot could fix it and brag about it
to his peers, causing kids everywhere to "get involved". C++ is riding
on the DOS wave that Windows rode in on, too -- most Microsoft victims
have _always_ used Microsoft products. Pascal succeded because it was
the language of choice on the Apple, which was also "cool", and Macintosh
fans don't wander off the narrow path, either. there was a market for
these languages completely unrelated to the languages themselves, but
these are consumer languages. winning is being stronger than your
competition, but as with any relation, becoming "stronger than" either
means you get stronger or you find a competition you are already stronger
than. Lisp is stronger than any competition in lots of places. it is
not stronger than languages optimized for dummies who, inexplicably,
believe that they can learn them in 21 days. it is, however, much
stronger than professional C/C++.
now, if you think C/C++ is cheap in the professional market, that using
professional class libraries is as easy as bragging to some manager that
you know C++, and that you can be unskilled in all C++ jobs, you are way
out of your mind. there is a professional market for C++ work that costs
much more than Common Lisp systems cost, but because this market does as
little advertising as Common Lisp does, you never see it, either. and
when you hear that a project has moved from Common Lisp to C++, it is
_not_ moved from Allegro CL to MSVC++ with MFC -- they move to a language
that most C++ programmers wouldn't even know how to begin to understand,
using stuff from the language that _actually_ supports large-scale work,
not the silly stuff that C++ is sold on at the consumer level. this
usage of C++ is much harder than doing the same kind of thing in Common
Lisp, as most managers find out as soon as they have made the stupid
decision to use C++, only they don't know how to undo their bad decision,
so they continue down the very expensive road, probably adding a lot of
manpower in the process. (the opportunity for most project managers to
learn from their mistakes is severely limited: they get fired and spend a
lot of time looking for new work. because of this, languages with large
"people bases" are preferred over what will more likely succeed, because
managers are people people and most of them are insufficiently technical
to assess risks even if they might be risk takers to begin with.)
Lisp's perception in the market has also been rocked by some spectacular
cases of bad company. when Lucid folded on its C++ project, its Common
Lisp had been a cash cow for a long time, and it continued to produce
money enough that it was worth salvaging -- I never heard more about the
C++ effort. of course, Lucid was best known for its Common Lisp, so
those who already didn't like Lisp got an easy opportunity to knock Lisp
again. when Harlequin was in danger of folding recently, it was wholly
unrelated to its Lisp business, which appears healthy but out of vogue
with venture capitalists and investors, but their problems has already
caused people to become scared about Lisp's future.
I think it works like this: if you're clearly better than the rest, you
get credit when you win, and you get blamed if you lose. ("if you are so
good, how come you don't make a lot of money?" is a typical instance of
this sorry situation, as if certain things are inevitably connected.) if
you are no better than the rest, you can take credit if you win, but you
don't get blamed if you lose. if you are worse than the rest, whoever
chooses you and wins did something spectacular, but if you fail, they
were just dumb who chose a loser. I think it works this way in many
aspects of life, and I think it does so because most people don't
actually _like_ winners unless they are certain they'll never be beaten
by them themselves. I think that's why watching sports is so popular,
too. in my view, fad languages that get all the attention are just like
the sports dudes who are very much _temporary_ winners in their fields,
earning a lot of money so they can retire to oblivion after a few years
of fame. the only way you can actually _win_ is to stay completely away
from the mass audiences and above all not depend on popular votes for
popularity, not beat the crap out of anyone in a competition (because
those that happened to will be certain to try to beat the crap out of
you, too), and not even get into fields where the short-term profits are
enormous, because that only means a lot of people lose a lot of money and
want to recover it, trying again and again.
I'm not sure I'm helping, but I'm willing to say that a project I have
worked on succeeded because of Common Lisp, mostly because I'm sure it
won't fail for any other reason. I'd be damned cautious to mention a
Common Lisp project that succeeded technically, but was in danger of
failing for any other reason, however, simply because there are so many
stupid people out there who wouldn't know what this meant.
what makes a success is not, has never been, and will never be that the
entry to it is free. what makes it a success is that people stick with
it. if you can't make people stick with something unless they get the
first dose for free, I'd say you have something that people really
shouldn't stick with at all. I think people start using stuff because
they hear about it, and it really doesn't matter to a lot of people that
it may cost money. after all, most people pay for their cars and won't
give them up no matter what environmentalists and politicians do to stop
them, and don't tell me it's because they got free rides as kids. in my
view, access to source code is only a question of education -- it can
never be a question of market penetration. Linux did _not_ win because
it is free, but because people wanted an alternative to Microsoft on the
dirt-cheap computers they could get their hands on. and if you look at
all the incredibly crappy software that people actually pay good money
for, being free is _obviously_ not necessary for success. nor is being
free sufficient, since lots of free software fails, too.
so why the clamoring about stuff being free? and why do I keep hearing
"you have a duty to provide me with the tools I need to make a living"
from so many of the free software proponents? this can only mean that
there are way more people who _believe_ they will never ever write any
software that others will want to use, and I'm sure they're right,
because anyone who argues that others should give him everything must of
necessity be open to similar requests to himself. Free Software has
_never_ been about any duty to provide anyone with anything at no cost.
it's all about making it possible to learn from the experiences of others
-- it's an education thing, not some anti-commercial crap. I, too, want
programmers to be able to share in the experiences of the entire trade,
much as medical doctors are expected to share their findings and their
methods, but I can't for the life of me understand why that means you
want the right to _refuse_ to pay for software. something got seriously
wacked in the communication.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
> I'd argue that what has kept Common Lisp from wide-spread success is its
> free implementations -- not only are the implementations that students
> normally see low quality as development environments go, all the crappy
> Schemes out there that try really hard to call themselves "Lisp" destroy
> the name recognition of Lisp completely (why can't they just stick to
> calling their toys "Scheme"?), and any student who didn't question his
> professors and peers would have to conclude that Lisp is a bad joke.
I don't think that Scheme destroyed the good name of Lisp, as it never
had one. Lisp isn't known for Generas and all that innovative stuff,
Lisp is the 'interpreted AI language with the funny syntax'. I tend to
make the observation that languages get judged by the way the're used
in the first years after their 'conception'. FORTRAN is a tool for
mumbling mathematicians, never mind Fortran9x, COBOL is the reason
for Y2K, nothing more, BASIC is a language for bitty boxes and nobody
outside the DOD would use Ada.
I don't think the Scheme interpreters used in CS curricula made this
any worse. Without them you'd probably have even fewer Lisp programmers
today and a bigger Modula-2 crowd who'd use "#define BEGIN {" to get
any work at all...
> what makes a success is not, has never been, and will never be that the
> entry to it is free. what makes it a success is that people stick with
> it. if you can't make people stick with something unless they get the
> first dose for free, I'd say you have something that people really
> shouldn't stick with at all. I think people start using stuff because
> they hear about it, and it really doesn't matter to a lot of people that
> it may cost money. after all, most people pay for their cars and won't
> give them up no matter what environmentalists and politicians do to stop
> them, and don't tell me it's because they got free rides as kids. in my
> view, access to source code is only a question of education -- it can
> never be a question of market penetration. Linux did _not_ win because
> it is free, but because people wanted an alternative to Microsoft on the
> dirt-cheap computers they could get their hands on. and if you look at
> all the incredibly crappy software that people actually pay good money
> for, being free is _obviously_ not necessary for success. nor is being
> free sufficient, since lots of free software fails, too.
Linux wouldn't have been a success without a free development environment.
If the GNU C compiler wouldn't have been available for free and you
couldn't get the sources to make a port for you toy Unix, then the
development base would have been several orders of magnitude smaller.
It doesn't matter if you can get a 386 for less then 2000$ if you have
to pay at least an equal amount for your Linux cross-compiler..
We can argue 'til the Second Coming scheduled in a few months, but all
this 'open-source' think is the hype of the moment and I guess it will
stay that way for quite a long time. All this idle chatter about Apple
supporting open-source while Microsoft doesn't, the fanatic marketing
of Linux by its rabid supporters. etc shows that there's something going
on. Hey, if guys like RMS, ESR or Linus Torvalds manage to get into the
mainstream press it shows how important computers get and how a basically
nice thing gets blown up beyond proportion.
Remember when Java came out and every new project had to be written in
it, even if the manager just read the name in his Wall Street Journal?
Open-Source(tm) is in the same league right now.
If you're a independent 'consultant', hired to solve a problem on
you own, it doesn't matter what language, environment or even
operating system you're using ("We need a high-performance web
server!" "Ok, I'll use CP/M and my hand-crafted Tarantula
web-server written in FooForth" "Erm, okay, just go ahead...").
But that isn't the only breed of programmer out there. And sometimes
the choice what language to use isn't up to you. You're more likely
to sell Lisp to your local pointy-haired boss if you say it's
"object-oriented", "open-source" and "provides increased synergy
for leveraging client-server paradigms". Besides, for a large
group of developers the money you save can add up to a relevant
sum.
And don't forget the hobbyist camp. Just a few years ago, it
wasn't very likely that the new programmer you just hired could
play with the environment you're using in the comfort of his
own home. Then there came PCs and all those nice Borland compilers
and now you have a huge bunch of 'Unix worksations' around
somewhere. If the new employee already knows how to handle
Makefiles, CVS or other C crutches, you save quite some training
time.
One might argue, that this is even more important for Common
Lisp environments. The Lisp portion might be 'common', the
rest isn't...
...Michael...
In article <···············@world.std.com>,
Kent M Pitman <······@world.std.com> wrote:
> Btw, there are a LOT of users of Lisp who do not buy its products and
> prefer to use freeware; if you ask me, it is that practice which hurts
> the community most of all. People need to either contribute money (or
> public effort, if they insist on using publicware) but they should not
> expect to just "consume" without putting something back and have the
> community survive.
I hear this in the Forth community (which is also "dying" with
increasing traffic for 10 years now ;-), too, but IMHO, that's bull.
*If* freeware products are good enough (or better) than commercial
offerings, commercial offerings aren't worth the price. And since one of
the most popular C/C++ compiler also is freeware (GCC), I suppose C is
dying rapidly, too, eh? Ok, I must admit that the community there works:
they give back a lot of C code. But they also give back Lisp and Scheme
code, and encourage the use of these languages by embedding them as
macro languages in killer applications like Emacs or the Gimp (although
the latter is now getting a Perl interface to have a "more popular" and
"widely known" language it it - urgh. I'd take Scheme over Perl any
day).
IMHO the situation as it is - we see generations of inferiour languages
hyped and passing away, replaced by another inferiour language, while we
know what the "one real true thing" is - this situation has a cause. The
masses aren't intelligent. Not above average - that's why they are
called masses. They want authorities and follow rules (think of the
"Life of Brian" scene of the masses in front of his house). That's how
mass-market languages are created: they have rules (strong typing!
static checks!), and they have restrictions (no run-time generated code!
not extensible by the user - at least not in creative ways!!).
People don't want to think. They don't want to choose one of 23
user-level implementations of OOP, or even decide to write their own
one. They want to have a single standard OOP. Everybody will request
that his feature need of the day is included in the single standard. And
finally, they'll realize that they need to start over again, because
this particular language converted to an unmaintainible mess. But
they'll never come to the point to allow the user to add his feature of
the day. That would be chaos. And that would be just like the dying
languages, Lisp, etc. ...
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
In article <············@nnrp1.deja.com>, Bernd Paysan <············@gmx.de>
wrote:
[snipped]
> I hear this in the Forth community (which is also "dying" with
> increasing traffic for 10 years now ;-), too, but IMHO, that's bull.
[snipped]
I'm a bit sad to see one of the most creative clf contributor
under the light of the most narrowly minded guy:
> People don't want to think. They don't want to choose one of 23
> user-level implementations of OOP, or even decide to write their own
> one. They want to have a single standard OOP. Everybody will request
> that his feature need of the day is included in the single standard. And
> finally, they'll realize that they need to start over again, because
> this particular language converted to an unmaintainible mess. But
> they'll never come to the point to allow the user to add his feature of
> the day. That would be chaos. And that would be just like the dying
> languages, Lisp, etc. ...
If what you are alluding to is that "people" (whoever they are, since
no qualification is given) don't want to think about how implementing
the division each time they want to compute some ratio, then I guess
they are right. If those same people don't want to think about how
to implement an array each time they want...err! an array! I still do
think they are right. Not even speaking about anything more clever
having passed the darwinian selection: records, lists, nodes...
Maybe "People" want to think with _abstractions_ something that Forth
can deliver, but that Forthers have consistently failed to deliver over
the past 25 years. It doesn't matter whether we have the choice of
23 OOP system, if none of them is either good or documented enough to
attract the interest of a wide audience, which, in turn, would promote
more attention.
This attitude, "The Users Are Just Stupid Idiots" is so well encroached
these days, that I'm wondering if you're not more a Linux geek (Damn
the user!) than a Forther (Damn the abstraction!).
Too bad to see talents blinded by selfish, elitist considerations.
--
·······················@virgin.net
Early answers are...early answers
Wrong answers are...wrong answers
Jean-Francois Brouillet wrote:
> This attitude, "The Users Are Just Stupid Idiots" is so well encroached
> these days, that I'm wondering if you're not more a Linux geek (Damn
> the user!) than a Forther (Damn the abstraction!).
>
> Too bad to see talents blinded by selfish, elitist considerations.
This is really getting political. I think the elitism of my generation
is a counter-reaction to the egalitarism of the '68 generation. It was a
nice idea, but it didn't work. Men are not equal - they are not even
created equal (different genes, different upbringing, different
teaching, etc.). There are brights and stupids. Talents are rare, and
worse, they all limit themselves to one or a few areas. You can't talk
to all people using the same language.
There is nothing wrong with the users being "stupid idiots" (compared to
the gurus). They may have other talents, and then, we know that they
need just a lot of hand-holding. There aren't just as many natural born
kernel hackers out. It just works better if your model of the world
reflects reality instead of an ideal state.
In fact, the Linuxer's attitude stems from assuming that the users
aren't just stupid idiots. That's why Linux is "difficult" to install
and has that load of "cryptic" commands, and all the man pages are so
hard to read.
I'm not doing MINOS because I need a self-explaining, dumped down GUI to
program. I'm doing it because I know that other people need that. You
can only reach the masses if you have some of Dogbert's cynicm.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
On 1999-07-17 ············@gmx.de said:
:This is really getting political. I think the elitism of my
:generation is a counter-reaction to the egalitarism of the '68
:generation. It was a nice idea, but it didn't work. Men are not
:equal - they are not even created equal (different genes, different
:upbringing, different teaching, etc.). There are brights and
:stupids. Talents are rare, and worse, they all limit themselves to
:one or a few areas. You can't talk to all people using the same
:language.
I think perhaps you're out on your own on this one, Bernd. Whilst there
are a wide range of differences that prohibit any Marxian definition of
equality from holding - after all, that view was routed in the cotton
mills of the 1800s, where to a large extent people did droid jobs and
were interchangeable - and there are a range of intelligences in the
world, one thing that has persisted from the 60s is the concept of
people being of equal worth, provided they try hard. The last 20 years
have seen an expansion of the technology that allows people to utilise
their whole head-space, if you like; bounds such as work or upbringing
are no longer a bar to a fulfilling life.
And if I may be indelicate, fifty years ago the world had a *big*
disincentive to assigning different values to people put in front of it.
--
Communa -- you know soft spoken changes nothing
·········@bigwig.net wrote:
> And if I may be indelicate, fifty years ago the world had a *big*
> disincentive to assigning different values to people put in front of it.
You are makeing the same fault these people and the writers of the
declaration of independence did, you equate unequality with unequal
values. This lead to many discriminations (e.g. women are obviously
unequal to men, and therefore it took quite a while to get them the same
rights. Same as black/indian people obviously were unequal to white
people, and therefore completely left out of the original DoI, by
declaring "all white men are born equal". Hm, me thinks they didn't have
a midwife in the team ;-).
I also beg to not depend on the "try hard enough". There are simply
people out there that can try as hard as they can, and still cannot
achieve something that seems normal to the ordinary people (handicap).
It should not reduce their value.
BTW: The idea of equal value of all humans is originated by Mencius, a
follower of Confuzius. Mencius assumes that humans are good by nature
and get bad by outer violence, and he derives the equal value of all men
by weighting their (potential) virtue. One cannot lessen the ethical
principles Confuzius and his followers have worked out, and that came to
our culture during the age of enlightenment. Equal value doesn't result
in boring equality, it just requires that you should use the same rules
for everybody.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
On 1999-07-23 ············@gmx.de said:
··········@bigwig.net wrote:
:> And if I may be indelicate, fifty years ago the world had a *big*
:> disincentive to assigning different values to people put in front
:> of it.
:You are makeing the same fault these people and the writers of the
:declaration of independence did, you equate unequality with unequal
:values.
Unfortunately you snipped the bit where I drew that exact distinction,
between inequality and unequal worth. What I am saying is that this is
the way the world tends to work, and believe me, I have ample reason for
saying that this is the case. The real world, real human nature, is not
and never will be some kind of Objectivist utopia, until humanity is
able to grow up and see the distinction. *That* is what I am saying.
:Equal value doesn't result in boring equality, it
:just requires that you should use the same rules for everybody.
Precisely, but just as you propose that most humans are rather thick, I
will state that most humans are not capable of dealing with difference
to such a degree as awarding it equal value; they will assign weight to
those most like themselves.
I got quite the opposite sense from your post, and from what you have
said on the issue before, interestingly; I thought you came across as
explicitly devaluing those who didn't have the neat "intelligence" skill
that some of us found almost as burdensome as convenient in our
schooldays. (Can you imagine growing up in an environment where being too
bright earns you contempt?)
--
the desk lisard communa time's taught the killing game herself
Net-Tamer V 1.11.2 - Test Drive
······@cwcom.net wrote:
>
...
>
> I got quite the opposite sense from your post, and from what you have
> said on the issue before, interestingly; I thought you came across as
> explicitly devaluing those who didn't have the neat "intelligence" skill
> that some of us found almost as burdensome as convenient in our
> schooldays. (Can you imagine growing up in an environment where being too
> bright earns you contempt?)
> --
> the desk lisard communa time's taught the killing game herself
>
> Net-Tamer V 1.11.2 - Test Drive
Sure; I immagine that many of us did. "Nerd" was originally "knurd"
(drunk spelled backward), i.e. one of those who study instead of
partying. If you can't match them, despise them.
Jerry
--
Engineering is the art | Let's talk about what
of making what you want | you need; you may see
from things you can get. | how to do without it.
---------------------------------------------------------
······@cwcom.net wrote:
> I got quite the opposite sense from your post, and from what you have
> said on the issue before, interestingly; I thought you came across as
> explicitly devaluing those who didn't have the neat "intelligence" skill
> that some of us found almost as burdensome as convenient in our
> schooldays. (Can you imagine growing up in an environment where being too
> bright earns you contempt?)
Last first: I learned that there's one thing they hate more than a
bright buddy; that's a bright and diligent buddy. So I compensated by
being lazy. I must also note that the German school system has a kind of
elitary touch by dividing into three different levels. Thus you separate
the more stupid ones after the fourth grade (the original idea was to
separate the masses, but with today's education requirements, it works
out only partly).
If you think that describing most people as looking for authority and
(mindlessly) following trends as devaluating, it's because you value
intelligence and independance. I don't think your buddies valued
anything of that.
I mean, we design our tools ourself. It's designed for us. We see that
other people simply don't like our tools, and they use tools that are
obviously inferiour (and which are subject to fashions). With "obviously
inferiour" I mean that I can master them better than any one of those
who refuse to have a look at Forth (or Lisp, it's the same). They just
don't come close to my favourite tool.
Saying "code monkey" to a VB programmer is easy, but it works out to be
bidirectional. I once interviewed (more for fun, it was a neighbor) as
admin of a VB shop that writes database applications (mostly front-ends)
and has a relatively demanding back office (Oracle, Suns, Linux boxes;
that's they were seeking skills). My interview partner concluded the
interview with the words that I wouldn't fit in the team because of too
many skills (I can't translate the German word he used, "�berflieger",
which means someone who flies over the others, and has a somewhat
negavite touch).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
On Tue, 27 Jul 1999 23:28:15 +0200, Bernd Paysan wrote:
>······@cwcom.net wrote:
>Last first: I learned that there's one thing they hate more than a
>bright buddy; that's a bright and diligent buddy. So I compensated by
>being lazy. I must also note that the German school system has a kind of
I'm just lazy. I can't blame the system; I was homeschooled.
>Saying "code monkey" to a VB programmer is easy, but it works out to be
>bidirectional.
Good point.
>that's they were seeking skills). My interview partner concluded the
>interview with the words that I wouldn't fit in the team because of too
>many skills (I can't translate the German word he used, "�berflieger",
>which means someone who flies over the others, and has a somewhat
>negavite touch).
A possibly more insulting term in English might be primadonna.
Overflier, huh? Cool. (I assume that that character you used would
transliterate as 'u' to make the word look like 'uberflieger'. I can't
see accent marks or other 'special chars' on this setup.)
>Bernd Paysan
--
-William "Billy" Tanksley
On Tue, 27 Jul 1999 22:00:02 GMT, William Tanksley <········@dolphin.openprojects.net> wrote:
>Overflier, huh? Cool. (I assume that that character you used would
>transliterate as 'u' to make the word look like 'uberflieger'. I can't
>see accent marks or other 'special chars' on this setup.)
It's your choice of fonts. I can see those characters with no problem.
PHBTPHT!! ;)
Seriously, though -- try changing your font to something that does NOT use
the PC extended graphics character set. That may help in seeing the
extended Latin character set.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
Oceanside, CA |......................................................
In article <·······················@dolphin.openprojects.net>,
········@dolphin.openprojects.net says...
> A possibly more insulting term in English might be primadonna.
Another term that I often hear is "tall poppy syndrome", which means
that some English people don't like anyone who stands out. It starts
at school and continues with advise like, "Keep your head down", "know
your station", and terms rather much more insulting than "primadonna".
> Overflier
I like that. ;)
--
Remove insect from address | You can never browse enough
will write code that writes code that writes code for food
Bernd Paysan wrote:
>
...
>
> Saying "code monkey" to a VB programmer is easy, but it works out to be
> bidirectional. I once interviewed (more for fun, it was a neighbor) as
> admin of a VB shop that writes database applications (mostly front-ends)
> and has a relatively demanding back office (Oracle, Suns, Linux boxes;
> that's they were seeking skills). My interview partner concluded the
> interview with the words that I wouldn't fit in the team because of too
> many skills (I can't translate the German word he used, "�berflieger",
> which means someone who flies over the others, and has a somewhat
> negavite touch).
>
> --
> Bernd Paysan
> "If you want it done right, you have to do it yourself"
> http://www.jwdt.com/~paysan/
I still feel outrage at all the jobs I was turned down for because I was
"overqualified". Then I landed at Andrea Radio (where I helped build the
Mercury audio box) and after that RCA Labs. It the labs, some might say
I was barely qualified, but I hung on for 25 years, so maybe not.
Jerry
--
Engineering is the art | Let's talk about what
of making what you want | you need; you may see
from things you can get. | how to do without it.
---------------------------------------------------------
On 1999-07-27 ············@gmx.de said:
:> I got quite the opposite sense from your post, and from what you
:>have said on the issue before, interestingly; I thought you came
:>across as explicitly devaluing those who didn't have the neat
:>"intelligence" skill that some of us found almost as burdensome
:>as convenient in our schooldays. (Can you imagine growing up in
:>an environment where being too bright earns you contempt?)
:Last first: I learned that there's one thing they hate more than a
:bright buddy; that's a bright and diligent buddy. So I compensated
:by being lazy.
What I learned was that a bright, independent-minded and different
person has to suffer all kinds of shit. Not much I can do about this. :>
I was lazy, too, at least after I'd turned 14 - but nobody noticed...
(Also, I'd begun to exhibit signs of depression by then, and that was
partially, although ineffectively, picked up on.)
:I must also note that the German school system has a
:kind of elitary touch by dividing into three different levels. Thus
:you separate the more stupid ones after the fourth grade (the
:original idea was to separate the masses, but with today's
:education requirements, it works out only partly).
It's interesting that you mention this; the German school system is
occasionally held up here in the UK as a model of how to stream kids
without discriminating against the academic ones. Feel free to tell me
more via email. (Be nice to find out if it works...)
:If you think that describing most people as looking for authority
:and (mindlessly) following trends as devaluating, it's because you
:value intelligence and independance. I don't think your buddies
:valued anything of that.
They weren't "buddies". I grew up in Norfolk, which is frankly the UK's
equivalent of America's Deep South (you know, where they dig trenches in
the side of the road so the natives don't scuff their knuckles, and a
virgin is defined as a 9 year old who can outrun her brother?). I was
out of there soooooo fast... And yes, I suppose I do value intelligence
and independence, but they aren't the only things to be valued - and I
can't believe that you think they are.
:I mean, we design our tools ourself. It's designed for us. We see
:that other people simply don't like our tools, and they use tools
:that are obviously inferiour (and which are subject to fashions).
:With "obviously inferiour" I mean that I can master them better
:than any one of those who refuse to have a look at Forth (or Lisp,
:it's the same). They just don't come close to my favourite tool.
"Forth (or Lisp, it's the same)" almost exactly sums up my attitude to
Forth. :> You're right.
:Saying "code monkey" to a VB programmer is easy, but it works out
:to be bidirectional.
Woah! My commercial life is forcing me to use VB (well, Access) at work.
I can do many other things in many other languages, but I'm the only guy
who finds this application at all penetrable, and half our client base
depends on this... (Take it from me, some kinds of job security you just
don't need.)
:I once interviewed (more for fun, it was a
:neighbor) as admin of a VB shop that writes database applications
:(mostly front-ends) and has a relatively demanding back office
:(Oracle, Suns, Linux boxes; that's they were seeking skills). My
:interview partner concluded the interview with the words that I
:wouldn't fit in the team because of too many skills (I can't
:translate the German word he used, "Uberflieger", which means
:someone who flies over the others, and has a somewhat negavite
:touch).
"Overqualified"?
--
the desk lisard communa time's taught the killing game herself
Bernd Paysan wrote:
>
> ······@cwcom.net wrote:
> > I got quite the opposite sense from your post, and from what you have
> > said on the issue before, interestingly; I thought you came across as
> > explicitly devaluing those who didn't have the neat "intelligence" skill
> > that some of us found almost as burdensome as convenient in our
> > schooldays. (Can you imagine growing up in an environment where being too
> > bright earns you contempt?)
>
> Last first: I learned that there's one thing they hate more than a
> bright buddy; that's a bright and diligent buddy. So I compensated by
> being lazy. I must also note that the German school system has a kind of
> elitary touch by dividing into three different levels.
You don't know the German school system do you? Yes we have different
levels, but some of our governments thought it would be a good idea to
put all on the same school. Unfortunatly it turned out for them that
this lowers the level. And even the politicians who were responsible for
that won't send their childrend to such a school. So the levels seem to
be quit e a fine idea. Men are different.
> Saying "code monkey" to a VB programmer is easy, but it works out to be
> bidirectional. I once interviewed (more for fun, it was a neighbor) as
> admin of a VB shop that writes database applications (mostly front-ends)
> and has a relatively demanding back office (Oracle, Suns, Linux boxes;
> that's they were seeking skills). My interview partner concluded the
> interview with the words that I wouldn't fit in the team because of too
> many skills (I can't translate the German word he used, "�berflieger",
> which means someone who flies over the others, and has a somewhat
> negavite touch).
This does not have necessarily have a negative touch. It's on one side
admiration and on the other side envy not to be one. But we're way
off-topic so now futher discussion if this.
Regards
Friedrich
In article <·················@inka.de>,
···················@inka.de wrote:
> You don't know the German school system do you?
Well, I went to school in Germany. Actually in Bavaria, which makes
quite a difference to the northern part of Germany (as our politicians
don't like "socialist" ideas ;-).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
On 1999-07-28 ···················@inka.de said:
:> Last first: I learned that there's one thing they hate more than a
:> bright buddy; that's a bright and diligent buddy. So I
:> compensated by being lazy. I must also note that the German
:> school system has a kind of elitary touch by dividing into three
:> different levels.
:You don't know the German school system do you? Yes we have
:different levels, but some of our governments thought it would be a
:good idea to put all on the same school. Unfortunatly it turned out
:for them that this lowers the level. And even the politicians who
:were responsible for that won't send their childrend to such a
:school. So the levels seem to be quit e a fine idea. Men are
:different.
I am reminded for a second of that nice Mr Blair who is currently
running the country (with an iron grip). The rest of Europe should be
looking at Mr Blair and worrying, frankly. The grinning village idiot
who only wants to keep his friends happy and imagines everyone to be his
friend - that's the future of politics. It's only *starting* here.
:This does not have necessarily have a negative touch. It's on one
:side admiration and on the other side envy not to be one. But we're
:way off-topic so now futher discussion if this.
It would appear to be reasonably negative if you don't get the job. :>
--
the desk lisard communa time's taught the killing game herself
On Thu, 15 Jul 1999 14:48:00 GMT, Bernd Paysan <············@gmx.de> wrote:
>macro languages in killer applications like Emacs or the Gimp (although
>the latter is now getting a Perl interface to have a "more popular" and
>"widely known" language it it - urgh. I'd take Scheme over Perl any
>day).
Is "Getting" a perl interface? What's taking them so long? The Python
interface has already been out for quite some time. ;)
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
Oceanside, CA |......................................................
Samuel A. Falvo II wrote:
> Is "Getting" a perl interface? What's taking them so long? The Python
> interface has already been out for quite some time. ;)
They seem to have problems getting the Gtk.pm package compiled and
installed properly (although I must say that the last version I tried
worked fine - so at least for me, the unstable version of Gtk has a Perl
interface).
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
> From: Bernd Paysan [···················@gmx.de]
> IMHO the situation as it is - we see generations of inferiour
> languages
> hyped and passing away, replaced by another inferiour
> language, while we
> know what the "one real true thing" is - this situation has a
> cause. The
> masses aren't intelligent. Not above average - that's why they are
> called masses. They want authorities and follow rules (think of the
> "Life of Brian" scene of the masses in front of his house). That's how
> mass-market languages are created: they have rules (strong typing!
> static checks!), and they have restrictions (no run-time
> generated code!
> not extensible by the user - at least not in creative ways!!).
Come now, rules allow for communication to exist at all.
Rules create hierarchical organization which may have
efficiencies over a committee of geniuses. What you're
really implying is the Dilbert Effect...but what that implies
is simply the stratification of knowledge, I may know a lot
about what puts Lisp in a higher class than Java, but I
don't know squat about why my CFO won't pay for it.
I simply have no way of effectively targeting my arguments
in favor of Lisp.
To get beyond this we need to read Carlos Castenada. You
may be able to create your own rules in Lisp, but you can't
make yourself understood without a huge ramp-up time defining
all the terms...and then waiting for the other guy to define
all his/her terms, and then making sure we both understand the
translation mapping between terms which involves more mapping
of meta-terms etc. etc.
There are examples of successes that were community
collaborations
that involve the cooperation of users, domain experts, managers,
designers, and programmers all working together on realistically
scoped
projects (though the last time I was involved in anything like
this
was a Lisp system back in '91). Then there are those examples
which are done by lone programmers that fill a specific need
targeted to a specific platform that are huge successes. Take
TOAD, for example. The guy wrote a lean and mean tool for
Oracle
using Delphi and native Oracle drivers to get the footprint down
to under 1 meg and distributed as shareware. The tool was such
a
huge hit that he was bought out by some vendor and got some very
lucrative IPO deal I'm sure.
> they'll never come to the point to allow the user to add his
> feature of
> the day. That would be chaos. And that would be just like the dying
> languages, Lisp, etc. ...
Chaos is in the eye of the beholder. Would you really want
to be able to add features to Java? I don't think so, you'd
want to be able to use Lisp, right? There's not a
willingness
to look upon one's own creation and see the ugly parts...there
are failures in both camps.
Bernd Paysan wrote:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
> > Btw, there are a LOT of users of Lisp who do not buy its
> > products and prefer to use freeware; if you ask me, it is
> > that practice which hurts the community most of all.
> > People need to either contribute money (or public effort,
> > if they insist on using publicware) but they should not
> > expect to just "consume" without putting something back
> > and have the community survive.
> I hear this in the Forth community (which is also "dying"
> with increasing traffic for 10 years now ;-), too, but IMHO,
> that's bull.
> *If* freeware products are good enough (or better) than
> commercial offerings, commercial offerings aren't worth the
> price. And since one of the most popular C/C++ compiler also
> is freeware (GCC), I suppose C is dying rapidly, too, eh?
> Ok, I must admit that the community there works: they give
> back a lot of C code.
The GNU C/C++ compiler is carefully designed to prove a
political opinion. Those who created it know that coprighting
software and keeping source code secret is an impediment to the
use of computers. They turned the practice of commercial
software companies on its head. After many years of work, these
people are finally getting their point across. Eventually we'll
see the only software worth using comes with unencumbered source
code.
Progress is being made. Computers change things. Now we
have computers a thousand times more powerful than they used to
be and sitting on anybody's desk that wants one. A program that
used to tax the resources of IBM to write is now a term project
for a student.
[snip]
> IMHO the situation as it is - we see generations of
> inferiour languages hyped and passing away, replaced by
> another inferiour language, while we know what the "one
> real true thing" is - this situation has a cause. The
> masses aren't intelligent. Not above average - that's why
> they are called masses. They want authorities and follow
> rules (think of the "Life of Brian" scene of the masses in
> front of his house). That's how mass-market languages are
> created: they have rules (strong typing! static checks!),
> and they have restrictions (no run-time generated code!
> not extensible by the user - at least not in creative
> ways!!).
> People don't want to think. They don't want to choose one
> of 23 user-level implementations of OOP, or even decide to
> write their own one. They want to have a single standard
> OOP. Everybody will request that his feature need of the
> day is included in the single standard. And finally, they'll
> realize that they need to start over again, because this
> particular language converted to an unmaintainible mess. But
> they'll never come to the point to allow the user to add his
> feature of the day. That would be chaos. And that would be
> just like the dying languages, Lisp, etc. ...
People who write programs do like to think and even solve
puzzles. Right now we keep changing things because we keep
thinking of new ways to compute. Extensible languages like Lisp
and Forth are particularly troublesome because they let you do
things differently easily. It would be nice to learn a few ways
of writing programs and just keep using them. But there is
always a new way to connect bits together waiting to be
discovered. And nobody has tried enough possibilities yet to
find the ones that have lasting value. There's one discovery
that I think is becoming clear. It is no longer desirable to
have programming languages and systems written by a business
corporation and covered by contracts, licenses, copyrights and
trade secrets. The best programs are going to be done with open
source by programmers communicating over the Internet. This is
simply doing things the way mathematicians do; after all
computing is part of mathematics. It no longer makes sense (if
it ever did in the first place) to write programs with the
business model of book publishing. On the other hand, it might
still make sense to write computer books with the business model
of book publishing. At least until the world wide web changes
the rules of publishing. And it will always make sense to hire
and pay experts who understand the computer programs a business
needs to use. How to know who these people are? Who wrote the
open source program that looks the best? Better yet, who wrote a
book or article telling you how to choose one of 23 user-level
implementations of OOP, and showed you how to write your own?
--
Michael Coughlin ··········@ne.mediaone.net Cambridge, MA USA
>>>>> "Michael" == Michael Coughlin <··········@ne.mediaone.net> writes:
Michael> Progress is being made. Computers change things. Now we
Michael> have computers a thousand times more powerful than they used to
Michael> be and sitting on anybody's desk that wants one. A program that
Michael> used to tax the resources of IBM to write is now a term project
Michael> for a student.
I suppose this is true if you mean "computing resources of IBM". If
you mean programmers, then I don't see how this is possibly true
unless 99.9...9% of the term project has already been written for the
student. I don't think capabilities of programmers have quite scaled
in the same proportion as the speed of computers.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Michael" == Michael Coughlin <··········@ne.mediaone.net> writes:
>
>
> Michael> Progress is being made. Computers change things. Now we
> Michael> have computers a thousand times more powerful than they used to
> Michael> be and sitting on anybody's desk that wants one. A program that
> Michael> used to tax the resources of IBM to write is now a term project
> Michael> for a student.
>
> I suppose this is true if you mean "computing resources of IBM". If
> you mean programmers, then I don't see how this is possibly true
> unless 99.9...9% of the term project has already been written for the
> student. I don't think capabilities of programmers have quite scaled
> in the same proportion as the speed of computers.
The speed and memory of computers has enabled professional teams or
programmers to design and implement languages like ANSI Common Lisp
that students can do their term projects in, instead of assembler
functions on OS/360 like IBM guys in the 60s had or whatever. If you
give one programmer with X capability a tool of Y power and a team of
20 programmers, each with the same X capability, a tool of Y/50 power,
the single programmer could come up with a better solution,
faster. The single programmer by using modern languages and tools is
leveraging the work of thousands of programmers and decades of design
and evolution and refinement. So it's not as though the solitary
programmer is really on their own.
Consider what writing a real-time display editor in the early 1970s
took. Nowadays with Java and Swing you can write one in 10 minutes
that supports rich text and embedded images in the document and can
save and restore files with this stuff in HTML format. (See the Java
tutorial at java.sun.com for an example of how easy this is to do.)
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> Consider what writing a real-time display editor in the early 1970s
> took. Nowadays with Java and Swing you can write one in 10 minutes
> that supports rich text and embedded images in the document and can
> save and restore files with this stuff in HTML format. (See the Java
> tutorial at java.sun.com for an example of how easy this is to do.)
And it has the dubious property of breaking when Java's marketing
people decide they want some other half-baked "feature" to compete
with VB. Or, when Sun decides to sell Java to somebody who really
breaks it.
Would I trust Lisp to be nominally stable? Yes- it has the potential
to be enhanced in a technically honest and nominally open manner.
That possibility doesn't exist with Java. Sun MIGHT make good
technical decisions on its enhancement this month- but they aren't
accountable and are only open to the point their PHBs want to be.
Thats not to say Java sucks- I can't say, BUT I can say I'd rather use
a language based (however erratically) on an open standard. To
paraphrase someone's quote, "..sucky open standards beat great closed
standards every time".
Gregm
Greg <······@erols.com> writes:
> ······@2xtreme.net (Christopher R. Barry) writes:
...
> Would I trust Lisp to be nominally stable? Yes- it has the potential
> to be enhanced in a technically honest and nominally open manner.
> That possibility doesn't exist with Java. Sun MIGHT make good
> technical decisions on its enhancement this month- but they aren't
> accountable and are only open to the point their PHBs want to be.
>
> Thats not to say Java sucks- I can't say, BUT I can say I'd rather use
> a language based (however erratically) on an open standard. To
> paraphrase someone's quote, "..sucky open standards beat great closed
> standards every time".
So, what do you (plural) think? Is Java going to stay "relatively"
"open" or not?
What part of the Java library do you think are going to change without
"public consent"?
Just curious to see what reaction I stir. :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
* Michael Coughlin <··········@ne.mediaone.net>
| The GNU C/C++ compiler is carefully designed to prove a political
| opinion. Those who created it know that coprighting software and keeping
| source code secret is an impediment to the use of computers. They turned
| the practice of commercial software companies on its head. After many
| years of work, these people are finally getting their point across.
| Eventually we'll see the only software worth using comes with
| unencumbered source code.
yeah, and written in languages and sub-languages so hard to understand
that it doesn't matter that the source is free, or written in special
dialects that can only be compiled by the compiler itself, or written
using so much magic that nobody dares touch it, however open it is.
remember, if people are going to get paid to offer commercial support
instead of for the product or the license to the product, they'll make
sure you need the support and that the authors are the only people who
can make any useful contributions.
| And nobody has tried enough possibilities yet to find the ones that have
| lasting value.
why are you so sure abou this? it is in the best interest of people who
desire users to make something _appear_ new, and if you need programmers
to get excited about your new free software project, what better way to
get them interested than to re-package some old stuff in maringally new
ways that can't be used with the rest of the old stuff? take a good look
at what the industry accepts as "invention" these days, and shudder.
free software will not change this, it will only redirect the efforts to
and the means of appearing new and attractive.
the problem with all these fancy predictions about how new technology and
a slight change in licensing terms will change the world is that they
ignore the mediocre people and anyone out to make a quick buck. and the
really the sad thing is that you don't allow mediocre people and quick
bucks, you won't get the system booted. most of the hype about what will
happen in the future of free software and free access to everything is
based on the pipe dream that in the future, the stupid people have ceased
to provide the bread and butter of a society, and only smart, idealistic
people remain. but we still need people to farm the land, dig wells,
keep all the electric wires and fibers operational, and take care of the
refuse of human society, and they will want computers, too. as long as
this mass market of non-programmers exists, there will be providers who
think in terms of units sold. even with his shadowy soul and psychotic
paranoid destructiveness, Bill Gates has at least got that part right.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
Erik Naggum <····@naggum.no> writes:
> * Michael Coughlin <··········@ne.mediaone.net>
> | The GNU C/C++ compiler is carefully designed to prove a political
> | opinion. Those who created it know that coprighting software and keeping
> | source code secret is an impediment to the use of computers. They turned
> | the practice of commercial software companies on its head. After many
> | years of work, these people are finally getting their point across.
> | Eventually we'll see the only software worth using comes with
> | unencumbered source code.
>
> yeah, and written in languages and sub-languages so hard to understand
> that it doesn't matter that the source is free, or written in special
> dialects that can only be compiled by the compiler itself, or written
> using so much magic that nobody dares touch it, however open it is.
How is this different from closed source "proprietary" stuff? It's
of potential value to have all the warts exposed- at least you know
what you're getting (or at least its possible to know).
>
> remember, if people are going to get paid to offer commercial support
> instead of for the product or the license to the product, they'll make
> sure you need the support and that the authors are the only people who
> can make any useful contributions.
Only if they can control the source. I'm not saying what you propose
is impossible, only somewhat less likely relative to closed systems.
If the source is open, a wrecked architecture can more easily be
reborn because none of the clean-room reverse engineering foolishness
is required.
>
> | And nobody has tried enough possibilities yet to find the ones that have
> | lasting value.
>
> why are you so sure abou this? it is in the best interest of people who
> desire users to make something _appear_ new, and if you need programmers
> to get excited about your new free software project, what better way to
> get them interested than to re-package some old stuff in maringally new
> ways that can't be used with the rest of the old stuff? take a good look
> at what the industry accepts as "invention" these days, and shudder.
> free software will not change this, it will only redirect the efforts to
> and the means of appearing new and attractive.
But again, if the software architecture is open its more likely the
Emperor's new clothes will be detected or not. We should be careful
of talking too much about the lack of progress/creativity- I remember
in the 1980s some columnist or other said all the applications had
been written; we had word processors, spreadsheets and database apps-
what else was there?
>
> the problem with all these fancy predictions about how new technology and
> a slight change in licensing terms will change the world is that they
I don't think the particular licensing terms are worth a hill of beans
in themselves. I believe the significance of the open source stuff is
in the mass opening of apps to public scrutiny and input. It
certainly won't prevent the darker aspects of human nature from taking
advantage, but it allows people to choose their poison.
> ignore the mediocre people and anyone out to make a quick buck. and the
> really the sad thing is that you don't allow mediocre people and quick
> bucks, you won't get the system booted. most of the hype about what will
> happen in the future of free software and free access to everything is
I agree its hyped at this point, but "public" open source isn't but a
year or so old. Once the "Next Thing" comes around, I think things
will settle down a little- and this movement will assume its place in
the ever more complicated computer infrastructure we're surrounding
ourselves with.
> based on the pipe dream that in the future, the stupid people have ceased
> to provide the bread and butter of a society, and only smart, idealistic
> people remain. but we still need people to farm the land, dig wells,
> keep all the electric wires and fibers operational, and take care of the
> refuse of human society, and they will want computers, too. as long as
> this mass market of non-programmers exists, there will be providers who
> think in terms of units sold.
The presumption of open source being the End All has about as much
weight as Java being the End All- mere line noise. When Java was new,
it was the next generation, now its more like just another language with
its own tradeoffs.
> even with his shadowy soul and psychotic
> paranoid destructiveness, Bill Gates has at least got that part right.
I hope Bill tastes ashes seeing the industry slip from his unbridled
control- drawing away just out of reach ever further the harder he
tries to grab it again.
Gregm
* Greg <······@erols.com>
| How is this different from closed source "proprietary" stuff?
that's the point. any company will want to protect its assets, and if
you can only sell support, you will only protect different assets than if
you could sell licenses, although in both cases, internal cultures would
grow that would protect and sustain themselves.
| It's of potential value to have all the warts exposed- at least you know
| what you're getting (or at least its possible to know).
no, sorry, you won't. immersing yourself in free software takes much
more time than immersing yourself in the published interfaces of some
commercial system, and if you immerse yourself too deeply and start to
use stuff that was never intended to be used from the outside, which
happens all the time in Emacs, for instance, you can't upgrade when new
versions come out and you can't necessarily install packages. that's
what one would call adding _new_ warts to your use of the system, if not
to the system itself. I used to think that I needed to walk through the
sources of stuff that I put on my machine, but it became impossible after
only a few years: it's too much work, and it has no direct rewards. I
also used to modify my Emacs quite a bit, and since I excised MULE from
20.3, it took too much effort to keep track of changes (it turns out that
semantic collisions are much more important than syntactic collisions,
which CVS could take care of -- code you haven't changed could be changed
incompatibly with other changes you have made, wreaking serious havoc),
so now I haven't been able to upgrade to 20.4-sans-MULE, even though 20.4
has been released.
| > remember, if people are going to get paid to offer commercial support
| > instead of for the product or the license to the product, they'll
| > make sure you need the support and that the authors are the only
| > people who can make any useful contributions.
|
| Only if they can control the source.
really? do you argue that others who want to offer commercial support
should rewrite the whole system in a better way or language, only to
splinter the development teams and make it wholly impossible to keep
track of each other's developments? that's, uh, brilliant.
| If the source is open, a wrecked architecture can more easily be reborn
| because none of the clean-room reverse engineering foolishness is
| required.
if it's reborn, you get feature wars between the two architectures, and
both waste a lot of time and effort, meaning: a lose-lose competition.
(remember: people get their money from implementing features and
providing support, not from selling licenses, but nobody will pay two
different providers for the same feature, meaning that whoever don't get
paid need to replicate the efforts of others for free, or if they have
enough loyal users: may be paid to replicate _some_ of the features.)
| But again, if the software architecture is open its more likely the
| Emperor's new clothes will be detected or not.
sure, but what happens? you get a splinter group every time someone
thinks he's spotting some Emperor skin. look what happened when MULE hit
the fan: a whole bunch of people stayed put at 19.34, many developers and
testers left because they couldn't get it to work, and didn't have time
to deal with the incompetents who broke everything that used to work
outside of Japan, and RedHat included my "MultiByte Survival Kit" in
their distribution of Emacs 20.2. and while 20.2 MBSK .elc files could
be loaded into 20.2 pure, a change was made so that 20.2 MBSK .elc files
could not be loaded into 20.3, but 20.2 pure .elc files could, obviously
only to discourage further branching.
| We should be careful of talking too much about the lack of progress/
| creativity-
huh? I'm talking about the consequences of _unbridled_ creativity. most
creative people discover that they need to channel their creativity into
areas where it can bear fruit. or put it another way: anyone can be both
creative and "creative" if there is no demand to be productive, too.
some would argue that the problem most cities have with some of their
youth stems from the utter lack of useful avenues to express youthful
creativity.
| I remember in the 1980s some columnist or other said all the applications
| had been written; we had word processors, spreadsheets and database apps-
| what else was there?
I'm sure it's helpful for your own position to pretend that this is what
you are up against, but it isn't. please stop being stupid and listen to
the criticism instead of dismissing it out of hand, OK?
| I believe the significance of the open source stuff is in the mass
| opening of apps to public scrutiny and input.
I fully agree that public scrutiny of software is a good thing, but I
don't think "input from the public" will ever work any better than it has
for all the "features" that Microsoft keep adding under pretense of
"customer demand".
| I hope Bill tastes ashes seeing the industry slip from his unbridled
| control- drawing away just out of reach ever further the harder he tries
| to grab it again.
this will happen if software is seen as works of art, visible out in the
open, but not for random people to "modify" or "improve" at will. art is
copyrighted for a multitude of reasons: I want software to be similarly
protected from the onslaught of the unschooled masses, but I also want
them to appreciate it and learn from it so as to be better prepared to
create their own works of art. in other words, I think this open source
stuff will work provided that people can still charge money for licensing
use and can still protect their works, _and_ we also get a realistic
means to pay for the benefits we receive from using other people's works,
because it will be harder to steal large amounts of source code when it
is open than when it is closed, and if people can't get paid and they
still can see that their source was stolen or used, they will simply stop
making source available as a means of self-preservation.
now, to reiterate my positive position: I think source access is good,
but it has to be seen as an investment on the part of whoever gets it,
and it appears beneficial that it be given out on a personal basis, not
to the public in general. on the other hand, there is a use for some
sort of "public library" model of source code, too, or perhaps "museums
of modern code" or whatever it would be cool to call it. letting people
in general at source for the express purpose of letting them modify it
and redistribute their modifications seems like a genuinely bad idea to
me, but it took me many years to realize that the benefits do not need to
be thrown out with the bathwater just because some aspects of open source
are clearly counter-productive. I suspect it will take others some time
to figure out why free software isn't the solution, but was an argument
that had to be made, why open source isn't the answer, but exposed the
question that needed to be asked, and why the computing society still
need to work on ways to accomplish its goals, especially as they get
clearer as goals and not only political mission statements for particular
solutions.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
> | It's of potential value to have all the warts exposed- at least you know
> | what you're getting (or at least its possible to know).
>
> no, sorry, you won't. immersing yourself in free software takes much
I'll agree you can't know ALL of what you're getting, but its POSSIBLE
to know more if the source is open.
> more time than immersing yourself in the published interfaces of some
> commercial system, and if you immerse yourself too deeply and start to
> use stuff that was never intended to be used from the outside, which
> happens all the time in Emacs, for instance, you can't upgrade when new
> versions come out and you can't necessarily install packages. that's
> what one would call adding _new_ warts to your use of the system, if not
> to the system itself. I used to think that I needed to walk through the
> sources of stuff that I put on my machine, but it became impossible after
> only a few years: it's too much work, and it has no direct rewards. I
> also used to modify my Emacs quite a bit, and since I excised MULE from
> 20.3, it took too much effort to keep track of changes (it turns out that
> semantic collisions are much more important than syntactic collisions,
> which CVS could take care of -- code you haven't changed could be changed
> incompatibly with other changes you have made, wreaking serious havoc),
> so now I haven't been able to upgrade to 20.4-sans-MULE, even though 20.4
> has been released.
I think I didn't make myself clear- I don't believe open source is the
solution, but only a better state of affairs. The degree of which is open to
discussion- ranging from worse to lots better.
>
> | > remember, if people are going to get paid to offer commercial support
> | > instead of for the product or the license to the product, they'll
> | > make sure you need the support and that the authors are the only
> | > people who can make any useful contributions.
> |
> | Only if they can control the source.
>
> really? do you argue that others who want to offer commercial support
> should rewrite the whole system in a better way or language, only to
> splinter the development teams and make it wholly impossible to keep
> track of each other's developments? that's, uh, brilliant.
That is entirely at their discretion, a high degree of splintering
would be unfortunate- but to me, that would mean the feature set just
isn't right. Thus, lots of people want to fix it, but they can't
agree. Fine, give everyone the opportunity and maybe one of the forks
will do the job better. To the degree that a "commercial fork" is
better- users may switch over. Or, their innovations may spark
improvements in the open source branch(s). Certainly its sometimes
ugly and inefficient, but I don't think its possible to have a large,
diffuse, complex piece of software improved without being such. You
can probably vary the degrees of "badness"....
Although a "commercial fork" might be contrary to the open source
license, I don't think that would stop a typical rapacious software
company. Microsoft could certainly do whatever they chose with Emacs
source they might download- BUT they can't control the original source.
Their proprietary release will have to compete with the others.
>
> | If the source is open, a wrecked architecture can more easily be reborn
> | because none of the clean-room reverse engineering foolishness is
> | required.
>
> if it's reborn, you get feature wars between the two
> architectures, and
Good- that means feature competition, the version which suits more
users better wins. INMO, this is an improvement- even if some
efficiency is lost.
> both waste a lot of time and effort, meaning: a lose-lose competition.
> (remember: people get their money from implementing features and
> providing support, not from selling licenses, but nobody will pay two
> different providers for the same feature, meaning that whoever don't get
> paid need to replicate the efforts of others for free, or if they have
> enough loyal users: may be paid to replicate _some_ of the
> features.)
If the commercial version is so far ahead, people will buy it. If
Windows really did its job right, Linux would still be an unnoticed
hobby. It doesn't, so we see competitors now (small, but growing...)
If the commerical version isn't much of an improvement, it gets
dropped by the wayside. Take the commerical Lisp community- there are
open versions of Lisp, but they don't offer the fully blown
environments that the commerical ones do- thus the commercial people
have a market. If XLisp or something stole a march, the commerical
Lisps would be rightly under pressure.
>
> | But again, if the software architecture is open its more likely the
> | Emperor's new clothes will be detected or not.
>
> sure, but what happens? you get a splinter group every time someone
> thinks he's spotting some Emperor skin. look what happened when MULE hit
> the fan: a whole bunch of people stayed put at 19.34, many developers and
> testers left because they couldn't get it to work, and didn't have time
> to deal with the incompetents who broke everything that used to work
> outside of Japan, and RedHat included my "MultiByte Survival Kit" in
> their distribution of Emacs 20.2. and while 20.2 MBSK .elc files could
> be loaded into 20.2 pure, a change was made so that 20.2 MBSK .elc files
> could not be loaded into 20.3, but 20.2 pure .elc files could, obviously
> only to discourage further branching.
Again, open source isn't a perfect fix. Bad decisions are made
everywhere and all groups of people suffer from pathologicals among
them.
>
> | We should be careful of talking too much about the lack of progress/
> | creativity-
>
> huh? I'm talking about the consequences of _unbridled_ creativity. most
> creative people discover that they need to channel their creativity into
> areas where it can bear fruit. or put it another way: anyone can be both
> creative and "creative" if there is no demand to be productive, too.
> some would argue that the problem most cities have with some of their
> youth stems from the utter lack of useful avenues to express youthful
> creativity.
Which is why the ability to fork projects is useful. It might be
viewed as analgous to a mutation- some succeed, some fail- and
sometimes the sucesses improve the state of the art.
>
> | I remember in the 1980s some columnist or other said all the applications
> | had been written; we had word processors, spreadsheets and database apps-
> | what else was there?
>
> I'm sure it's helpful for your own position to pretend that this is what
> you are up against, but it isn't. please stop being stupid and listen to
> the criticism instead of dismissing it out of hand, OK?
Did you get up on the wrong side of the bed or something? You
asserted that the software community was suffering from a lack of
innovation/creativity- please substantiate it then. I'm proposing
that innovation and creativity are alive and well. Maybe we're in a
plateau on the curve- but consider the improvements in the state of
the art in the last 5 years alone.
>
> | I believe the significance of the open source stuff is in the mass
> | opening of apps to public scrutiny and input.
>
> I fully agree that public scrutiny of software is a good thing, but I
> don't think "input from the public" will ever work any better than it has
> for all the "features" that Microsoft keep adding under pretense of
> "customer demand".
>
> | I hope Bill tastes ashes seeing the industry slip from his unbridled
> | control- drawing away just out of reach ever further the harder he tries
> | to grab it again.
>
> this will happen if software is seen as works of art, visible out in the
> open, but not for random people to "modify" or "improve" at will.
> art is
I don't believe public update access to offical source is very useful-
but having a development process where membership is based on
technical merit and energy improves the liklihood of advancement.
> copyrighted for a multitude of reasons: I want software to be similarly
> protected from the onslaught of the unschooled masses, but I also want
> them to appreciate it and learn from it so as to be better prepared to
> create their own works of art. in other words, I think this open source
> stuff will work provided that people can still charge money for licensing
> use and can still protect their works, _and_ we also get a realistic
> means to pay for the benefits we receive from using other people's works,
> because it will be harder to steal large amounts of source code when it
> is open than when it is closed, and if people can't get paid and they
> still can see that their source was stolen or used, they will simply stop
> making source available as a means of self-preservation.
A good point- I don't think a viable business case has been made for
companies selling software via open source. I don't think it has to
be. I think Open source will be useful for particular classes of
businesses- but not all.
>
> now, to reiterate my positive position: I think source access is good,
> but it has to be seen as an investment on the part of whoever gets it,
> and it appears beneficial that it be given out on a personal basis, not
> to the public in general. on the other hand, there is a use for some
> sort of "public library" model of source code, too, or perhaps "museums
> of modern code" or whatever it would be cool to call it. letting people
> in general at source for the express purpose of letting them modify it
> and redistribute their modifications seems like a genuinely bad idea to
> me, but it took me many years to realize that the benefits do not need to
> be thrown out with the bathwater just because some aspects of open source
> are clearly counter-productive. I suspect it will take others some time
> to figure out why free software isn't the solution, but was an argument
> that had to be made, why open source isn't the answer, but exposed the
> question that needed to be asked, and why the computing society still
> need to work on ways to accomplish its goals, especially as they get
> clearer as goals and not only political mission statements for particular
> solutions.
>
I still don't perceive why its bad for people to grab the source, make
changes and release them if they want to. I agree it could cause
confusion, but if the people keeping hold of the "official" source are
doing their job, confusion will be minimal. As far as mods to the
"official" source, I think thats best done by a group selected for
their commitment to the project and their skill.
I get sort of tired of the political side of the movement- I really
don't give much of a damn. What I care about is the source being
available and project decisions made in public view- even if
participation isn't. I think the GPL is a useful reference and
indicator of preference, but I doubt it would carry much of any legal
weight when the lawyers start feeding.
Gregm
* Greg Menke <······@erols.com>
| Which is why the ability to fork projects is useful. It might be viewed
| as analgous to a mutation- some succeed, some fail- and sometimes the
| sucesses improve the state of the art.
nature is the most inefficient selector of all possible selectors: the
mutation that moves on is simply the mutation hasn't died yet, but every
mutation dies, it's just a question of when. if you think we can afford
to wait for three billion development teams to sort themselves out over
the next 100 million years, feel free to think in terms of mutations and
natural selection. I'm concerned with the massive waste of human
intelligence and effort required to operate that way, and I'd like to see
something radically more efficient.
| Did you get up on the wrong side of the bed or something?
no, I'm always as pissed at people who try to impute a bunch of crap to
me only because they don't bother to engage their brain while reading.
| You asserted that the software community was suffering from a lack of
| innovation/creativity- please substantiate it then.
I'm also always pissed at people who claim that I "assert" what they have
read into what I have written, when they obviously aren't intellectually
honest enough to understand the difference between "you asserted" and "I
understood you to say". this may also explain the na�vit� of your views.
please quote what you understood to be an "assertion", and don't _ever_
ask people to substantiate what you misunderstand from what they say.
morons, bad journalists, and disgustingly dishonest politicians do that.
they should frankly be shot for it, especially if they are so dense as to
consider the victims of their lies to be at fault for reacting, too.
| I don't believe public update access to offical source is very useful-
| but having a development process where membership is based on technical
| merit and energy improves the liklihood of advancement.
there is no "official" source. nobody has the ability to claim that any
particular version is more official than any other version. there isn't
even any concept of "public update access" -- everybody who receives the
sources has the _right_ to make modifications and redistribute them.
| I still don't perceive why its bad for people to grab the source, make
| changes and release them if they want to.
I expect others to spend some time getting the necessary clues, too, and
I said so. I certainly haven't been thinking the same way for the past
20 years about people's access to computers or software, and I don't
expect to be thinking the same way a year from now. lots of things have
changed radically over these years, and I have found myself analyzing the
effects of several crucial decisions and several ideologies and beliefs
in what the right way is. I have watched the computer business go from
supplying lots of operating system and applications software for free
with the very expensive hardware, to the same software being sold
separately, to what was called "third-party" software vendors take over
and make fortunes, to the same operating system or languages becoming
available on many different computers. I have seen the world turn from
many users per machine, to one user per machine, to many machines per
user. I have seen the world turn from computers only working in
isolation, to not being useful at all in isolation. I don't expect that
I would have arrived at my views in a single discussion and I don't
expect anyone else to, either, but there's a difference between being
able to understand what somebody is saying even if one neither agrees or
disagrees with it right away, and trying to make it mean something that
one can agree or disagree with by making it look like something one
already understands.
free software _used_ to be how vendors gave their customers their
operating systems. the GNU operating system idea was born as a reaction
to the software hoarding of the Lisp Machine vendors who wasted a whole
bunch of effort in duplicating features by keeping their code bases
unavailable to eachother. Richard Stallman reimplemented features from
one of the major systems to the other and naturally thought this was a
huge waste of time and effort, and that those who made him do it were bad
people. I have the deepest sympathy for him with respect to the XEmacs
splinter group -- it's exactly the same kind of stupid duplication of
effort that he wanted to avoid by making the software free. I started to
realize that it would never work to stop duplicating the effort a few
years ago, but it took a long time to realize just how much worse it is
for free software than for proprietary software at this time, and in the
forseeable future. Open Source may, however, be just what the world
needs to topple Microsoft (which is necessary regardless of the quality
of Windows or Excel), and when the evil empire has fallen, we can go back
to working together more rationally _in_ a market place. I suspect that
this will happen, but also suspect that Microsoft must go belly up in a
very serious way first. freeing its software would kill it, just like
freeing other vendor's software kills them in today's climate. just
because killing Microsoft is good doesn't mean freeing any other software
is good. if there isn't anything worth killing, it is prudent to use the
poison and the heavy artillery sparingly.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
> free software _used_ to be how vendors gave their customers their
> operating systems. the GNU operating system idea was born as a reaction
> to the software hoarding of the Lisp Machine vendors who wasted a whole
> bunch of effort in duplicating features by keeping their code bases
> unavailable to eachother. Richard Stallman reimplemented features from
> one of the major systems to the other and naturally thought this was a
> huge waste of time and effort, and that those who made him do it were bad
> people. I have the deepest sympathy for him with respect to the XEmacs
> splinter group -- it's exactly the same kind of stupid duplication of
> effort that he wanted to avoid by making the software free.
My understanding is that duplication of effort was one of several
reasons for making software Free. Being able to share, modify it for
your own needs, and peer review being some of the others. Is this not
an accurate understanding of the motivations of Stallman and others
with regards to the origin of the GNU system?
In the XEmacs FAQ Stallman states that he does not regret making Emacs
free, despite the XEmacs fork, which he calls "unfair competition"
because they can use Emacs code, but GNU cannot use XEmacs code in
Emacs. So it seems that he is aware of the cost of this duplication
of effort, but does not think that it outweighs the benefits of Free
Software. Do you agree that the other benefits outweight the costs of
duplicated effort?
> I started to realize that it would never work to stop duplicating
> the effort a few years ago, but it took a long time to realize
> just how much worse it is for free software than for proprietary
> software at this time, and in the forseeable future.
I'm not sure I understand why you see the duplication of effort having
a worse effect on Free Software than proprietary software.
My understanding of your position so far, and please correct any
misunderstandings, is that the duplication of effort leads to a loss
of efficiency in the software production process. Free Software is
prone to even more innefficiency when there are forks and duplicated
effort. This inneficiency outweighs the benefits to the software
production process that Free Software brings. Presently Free Software
may be what is needed to unseat the present operating system
monopolies, but it is not a sustainabble production mode in the long
term because of it's overall innefeciency.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
I say woe unto those who are wise in their own eyes, and yet
imprudent in 'dem outside -Sizzla
* Craig Brozefsky <·····@red-bean.com>
| My understanding is that duplication of effort was one of several
| reasons for making software Free. Being able to share, modify it for
| your own needs, and peer review being some of the others. Is this not
| an accurate understanding of the motivations of Stallman and others
| with regards to the origin of the GNU system?
yes, it was. has it worked?
| Do you agree that the other benefits outweight the costs of duplicated
| effort?
invalid question. (1) there are benefits and costs of both free software
and regular licensing. (2) there is duplicated effort in both free
software and with regular licensing. my first observation is that there
are different parameters for when effort will be duplicated in these two
different models, and free software doesn't look like it can stem the
desire to split into several groups any better than regular licensing, on
the contrary: it looks like it's doing much worse. my second observation
is that the benefits of free software can be easily obtained within the
framework of regular licensing. in other words, the whole free software
package doesn't have enough weight to outweigh the alternative which it
was set up to be an alternative to. that doesn't mean software should
not be available to those who seek to learn and who seek to understand
issues that are not available to be understood without actual hands-on
experience in maintaining or building large systems, only that accepting
the free software package deal is counter-productive to this goal in the
long run.
| I'm not sure I understand why you see the duplication of effort having
| a worse effect on Free Software than proprietary software.
because the free software projects that have had a strong leader or voice
of authority have succeeded, but those where people have been free to add
whatever they like, have failed. since strong leaders tend to cause
strong disagreements with other potential strong leaders, splits will
occur, and have occurred, over issues that could have been resolved more
rationally in a commercial setting, having a much worse effect on the
free software "markets" than in commercial markets, because the cost of
entry for a competitor is miniscule. splits will therefore linger on and
be a drain on everybody's ability to fight for their own and their
collective survival. my favorites in this regard are: the Linux package
systems, the Linux distributions, and the many forms of BSD systems.
| My understanding of your position so far, and please correct any
| misunderstandings, is that the duplication of effort leads to a loss of
| efficiency in the software production process. Free Software is prone to
| even more inefficiency when there are forks and duplicated effort. This
| inefficiency outweighs the benefits to the software production process
| that Free Software brings. Presently Free Software may be what is
| needed to unseat the present operating system monopolies, but it is not a
| sustainable production mode in the long term because of it's overall
| ineffeciency.
pretty good summary. I'll only add that these are not absolute terms,
but relative to other production processes. also, I do not consider the
prime directive to be "produce software", but "produce good software",
and quality suffers much more from competition from splinter groups than
mere quantity. e.g., MULE would not have been as braindamaged had it not
been for XEmacs. RedHat would not have released their new versions so
early had it not been for their competitors. competition in general is a
really bad way to deal with diversity and conflict, since it means that
people will fight over issues that are deemed important for each brief
battle, but wholly irrelevant in the long run, and that decisions made in
a state of paranoid delusion are rarely possible to reverse without also
hurting yourself in the face of your customers. therefore, competition
needs to have a high cost of entry to have its bad effects curtailed, in
particular that one does not begin to compete over entirely frivolous
matters. normal business costs so much to start and build up that this
is not really a problem, but free software operations cost very little to
start up, and so the bad effects of competition tend to outweigh the good
effects.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> wrote:
+---------------
| free software _used_ to be how vendors gave their customers their
| operating systems.
+---------------
Yup!!! I learned a *lot* (in the early 1970's) from reading the
sources to TOPS-10, the operating system for the DEC PDP-10, which
was shipped with every PDP-10.
One of the lessons that would probably surprise the current generation
of coders: It *is* possible to write disciplined, cleanly-structured,
readable, supportable, and even *OBJECT-ORIENTED* code in assembler!
[Having an assembler with a macro system almost as good as Lisp's certainly
didn't hurt any, though the TOPS-10 kernel didn't stress the macrology all
that much. Well, except maybe in the defsystem-equivalent area...]
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
* ····@rigden.engr.sgi.com (Rob Warnock)
| Yup!!! I learned a *lot* (in the early 1970's) from reading the
| sources to TOPS-10, the operating system for the DEC PDP-10, which
| was shipped with every PDP-10.
funny you should say that. I "grew up" on PDP-10's, too, somewhat later
than you did, however, and worked with both TOPS-10 and TOPS-20, the
COMND JSYS of which is still a better way to do command-line interfaces
than anything implemented since then, not to mention the way the program
itself would be "half-started" in order to help complete its own command
line. in general, it's a real pity so little of what was done so well in
those systems were communicable to those who had not used them.
however, the sources to TOPS-10 were not availble to the public: you had
to purchase the computer first to get the operating system for "free".
since the demise of the TOPS-20 project at Digital, the sources for the
last version have been rumored to be about to be released about 20 times,
to my knowledge, and still nothing has happened. I don't know what is so
important to protect, but it is clearly not "free software" in the sense
we're discussing these days.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
On 24 Jul 1999 07:55:03 +0000, Erik Naggum <····@naggum.no> wrote:
> funny you should say that. I "grew up" on PDP-10's, too, somewhat later
> than you did, however, and worked with both TOPS-10 and TOPS-20, the
> COMND JSYS of which is still a better way to do command-line interfaces
> than anything implemented since then, not to mention the way the program
Could you please mention some of the main features of COMND JSYS?
Paolo
--
Paolo Amoroso <·······@mclink.it>
Erik Naggum <····@naggum.no> writes:
> * ····@rigden.engr.sgi.com (Rob Warnock)
> | Yup!!! I learned a *lot* (in the early 1970's) from reading the
> | sources to TOPS-10, the operating system for the DEC PDP-10, which
> | was shipped with every PDP-10.
>
> funny you should say that. I "grew up" on PDP-10's, too, somewhat later
> than you did, however, and worked with both TOPS-10 and TOPS-20, the
> COMND JSYS of which is still a better way to do command-line interfaces
> than anything implemented since then, not to mention the way the program
What about Command Processor/Dynamic Windows under Genera? COMND JSYS
is really nice, but I don't really think you can honestly say it
stands up to that. Command Processor alone is slightly better than
COMND JSYS; when combined with Dynamic Windows it is unbeatable.
Still, COMND JSYS is about 36 million times better than anything else.
··@NANOSTRUCTURE.UTDALLAS.EDU writes:
> Erik Naggum <····@naggum.no> writes:
>
> > * ····@rigden.engr.sgi.com (Rob Warnock)
> > | Yup!!! I learned a *lot* (in the early 1970's) from reading the
> > | sources to TOPS-10, the operating system for the DEC PDP-10, which
> > | was shipped with every PDP-10.
> >
> > funny you should say that. I "grew up" on PDP-10's, too, somewhat later
> > than you did, however, and worked with both TOPS-10 and TOPS-20, the
> > COMND JSYS of which is still a better way to do command-line interfaces
> > than anything implemented since then, not to mention the way the program
>
> What about Command Processor/Dynamic Windows under Genera? COMND JSYS
> is really nice, but I don't really think you can honestly say it
> stands up to that. Command Processor alone is slightly better than
> COMND JSYS; when combined with Dynamic Windows it is unbeatable.
>
> Still, COMND JSYS is about 36 million times better than anything else.
When I first read the post you replied to I also thought of the
Symbolics' Command Processor. But while it is natural, aesthetic,
extremely efficient and intuitive to use, a Unix shell with piping and
sed, awk, find, grep/egrep and all the other junk is more powerful -
once you've made the serious time-investment to learn it all. Lisp
Machines don't seem to have any kind of regular expression facility at
all, even like crusty old elisp has. (I can't even find any kind of
regexp facility used in the Zmacs sources on the LispM.)
This isn't to say that you couldn't create Command Processor commands
with all of the Unix functionality and also create a piping facility.
(Since most commands inherit the :Output Destination key, you could
use a similar mechanism for piping.) Just no one ever did.
Christopher
* Christopher R Barry wrote:
> When I first read the post you replied to I also thought of the
> Symbolics' Command Processor. But while it is natural, aesthetic,
> extremely efficient and intuitive to use, a Unix shell with piping and
> sed, awk, find, grep/egrep and all the other junk is more powerful -
> once you've made the serious time-investment to learn it all. Lisp
> Machines don't seem to have any kind of regular expression facility at
> all, even like crusty old elisp has. (I can't even find any kind of
> regexp facility used in the Zmacs sources on the LispM.)
Other than the regexp bit (zmacs does have some pattern stuff in fact,
though I think the sources are not distributed), this is really
confusing two ways of thinking. The LispM command processor doesn't
have pipes & awk & sed, but it doesn't need them, you use Lisp for
that level of functionality. Unix has a particular command style of
passing around streams of bytes, but not all systems are that way.
--tim
······@2xtreme.net (Christopher R. Barry) writes:
> ··@NANOSTRUCTURE.UTDALLAS.EDU writes:
>
> > Erik Naggum <····@naggum.no> writes:
> >
> > > * ····@rigden.engr.sgi.com (Rob Warnock)
> > > | Yup!!! I learned a *lot* (in the early 1970's) from reading the
> > > | sources to TOPS-10, the operating system for the DEC PDP-10, which
> > > | was shipped with every PDP-10.
> > >
> > > funny you should say that. I "grew up" on PDP-10's, too, somewhat later
> > > than you did, however, and worked with both TOPS-10 and TOPS-20, the
> > > COMND JSYS of which is still a better way to do command-line interfaces
> > > than anything implemented since then, not to mention the way the program
> >
> > What about Command Processor/Dynamic Windows under Genera? COMND JSYS
> > is really nice, but I don't really think you can honestly say it
> > stands up to that. Command Processor alone is slightly better than
> > COMND JSYS; when combined with Dynamic Windows it is unbeatable.
> >
> > Still, COMND JSYS is about 36 million times better than anything else.
>
> When I first read the post you replied to I also thought of the
> Symbolics' Command Processor. But while it is natural, aesthetic,
> extremely efficient and intuitive to use, a Unix shell with piping and
> sed, awk, find, grep/egrep and all the other junk is more powerful -
> once you've made the serious time-investment to learn it all.
I totally disagree. A Unix shell is an unacceptably barbaric
interface--even by 1970s standards (even the Multics command
processing system was superior, and it is much older. If you mention
COMND JSYS then you really begin to see what a loser Unix is). Just
to be fair, I will concede that the Unix shell is vastly preferable to
the MS-DOS shell. But really, any "power" you see in the Unix shell
is due to the completely inappropriate conflation of a command
processor with a programming language (and not even a particularly
good programming language)--and the user suffers badly for it.
CP is designed to be an extremely nice _command processor_, not a
programming language. If you want to do programmatic things, you have
all of Lisp readily accessible (from the command line--instead of
trying to be a programming language, CP does the right thing and gives
you extremely easy access to a programming language), which is far
better and more powerful than anything available under a Unix shell.
Lisp
> Machines don't seem to have any kind of regular expression facility at
> all, even like crusty old elisp has. (I can't even find any kind of
> regexp facility used in the Zmacs sources on the LispM.)
Yes, this is a problem. Noone seems to have ever written a really
efficient regexp matcher for lisp. The LispM does actually have a
sort-of regexp system (it uses special smbx characters instead of the
unix characters, and it doesn't have as many features), but it seems
to not really work right on moderately complex expressions. YMMV.
>
> This isn't to say that you couldn't create Command Processor commands
> with all of the Unix functionality and also create a piping facility.
> (Since most commands inherit the :Output Destination key, you could
> use a similar mechanism for piping.) Just no one ever did.
Thats because they realize that it is futile. If you want to do
things like that you can easily do them in Lisp.
>
> Christopher
Tim Bradshaw writes:
> Other than the regexp bit (zmacs does have some pattern stuff in
> fact, though I think the sources are not distributed)
The sources to the facility Kent Pitman described are on the CD. Try
Edit Definition ZWEI:COM-TAGS-SEARCH. (I've yet to not be able to find
the source code for anything once I know it exists.)
> this is really confusing two ways of thinking. The LispM command
> processor doesn't have pipes & awk & sed, but it doesn't need them,
> you use Lisp for that level of functionality. Unix has a particular
> command style of passing around streams of bytes, but not all
> systems are that way.
··@NANOSTRUCTURE.UTDALLAS.EDU writes:
> I totally disagree. A Unix shell is an unacceptably barbaric
> interface--even by 1970s standards (even the Multics command
> processing system was superior, and it is much older. If you mention
> COMND JSYS then you really begin to see what a loser Unix is). Just
> to be fair, I will concede that the Unix shell is vastly preferable to
> the MS-DOS shell. But really, any "power" you see in the Unix shell
> is due to the completely inappropriate conflation of a command
> processor with a programming language (and not even a particularly
> good programming language)--and the user suffers badly for it.
Okay, you, Tim and Kent have illuminated my view. It would be nice if
the Tags Search regexp capability were available in other
contexts. For example, the Command Processor Find String command
(which is kinda like the LispM's version of grep) should have the
facility as well. But I now agree that piping does not belong in the
CP, and that the Bourne/C shells are not in fact command processors at
all but rather interpreters for rather limited, unaesthetic
programming languages that only support a few features for interactive
use like tab-completion of executable-names in your PATH and
command-history, while with a LispM you have a _real_ command
processor _and_ a real programming language at your fingertips at the
same location.
Tim Bradshaw writes:
> Since when was most interesting data strings? Half the point of
> Lisp is that you get stuff into some rich structured format and then
> *keep it there*.
I never said that most interesting data is strings. However, there are
certainly a class of applications out there where at least mildy
involved if not truly sophisticated string processing is called for
(and certainly many more where it isn't that are done with Perl/Unix
string bashing tools anyways in the Worse Is Better world), and making
your own SPLIT (like we've seen plenty of floating around here) or
...TOKEN... functions and essentially using a filtering approach to
string processing rather than a pattern-matching approach is not the
ideal thing. Even the regexp facility that the LispM does have for
Tags Search is only a fraction as powerful as your basic Unix
utility's pattern-matcher, though for its specific purpose it is more
than adequate and satisfactory.
Speaking of COMND JSYS, could any of you with knowledge of it give a
brief description of how you go about doing a couple basic things and
a sample interaction or two? I understand that the only way to really
know it and understand it is to use it, but a little info like what
the prompt looks like and how the completion facility (if any, or even
necessary(?)) works and the keystrokes that invoke it as well as
command history and your interface to that.
Christopher
In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> When I first read the post you replied to I also thought of the
> Symbolics' Command Processor. But while it is natural, aesthetic,
> extremely efficient and intuitive to use, a Unix shell with piping and
> sed, awk, find, grep/egrep and all the other junk is more powerful -
The Lisp Machine has Lisp underneath - the philosophy of a
Lisp Machine is not to pipe text between processes - but
rather to invoke functions on objects.
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
>
> > When I first read the post you replied to I also thought of the
> > Symbolics' Command Processor. But while it is natural, aesthetic,
> > extremely efficient and intuitive to use, a Unix shell with piping and
> > sed, awk, find, grep/egrep and all the other junk is more powerful -
>
> The Lisp Machine has Lisp underneath - the philosophy of a
> Lisp Machine is not to pipe text between processes - but
> rather to invoke functions on objects.
Fine. Then the Lisp Machine doesn't give you a very rich set of
functions to invoke on STRING objects (roughly equivalent
functionality to ANSI CL except a few extras for dealing with the
Symbolics special characters), nor does it give you REGEXP objects to
invoke functions on.
Christopher
* Christopher R Barry wrote:
> Fine. Then the Lisp Machine doesn't give you a very rich set of
> functions to invoke on STRING objects (roughly equivalent
> functionality to ANSI CL except a few extras for dealing with the
> Symbolics special characters), nor does it give you REGEXP objects to
> invoke functions on.
Since when was most interesting data strings? Half the point of Lisp
is that you get stuff into some rich structured format and then *keep
it there*.
--tim
······@2xtreme.net (Christopher R. Barry) writes:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> >
> > > When I first read the post you replied to I also thought of the
> > > Symbolics' Command Processor. But while it is natural, aesthetic,
> > > extremely efficient and intuitive to use, a Unix shell with piping and
> > > sed, awk, find, grep/egrep and all the other junk is more powerful -
> >
> > The Lisp Machine has Lisp underneath - the philosophy of a
> > Lisp Machine is not to pipe text between processes - but
> > rather to invoke functions on objects.
>
> Fine. Then the Lisp Machine doesn't give you a very rich set of
> functions to invoke on STRING objects (roughly equivalent
> functionality to ANSI CL except a few extras for dealing with the
> Symbolics special characters), nor does it give you REGEXP objects to
> invoke functions on.
Regexps in the Unix sense are, relatively speaking, a geologically new
concept. Regexps as any kind of more-or-less-standard thing didn't really
achieve serious popularity until well after the Lisp Machine industry
was in trouble for reasons quite unrelated to regular expression
availability.
The Lisp Machine DOES have them, but its own version of them.
They are different--many thought better--certainly visually more intuitive
and less prone to require weird quotation since they use characters
not in the ordinary character set so can't get confused with the standard
characters you'd be searching.
They're probably only available in the editor--I don't think it was
factored back into the programming language, but I doubt it would be
serious work to do it. (Very little on the Lisp Machine is serious
work, compared to the way things are done elsewhere.) The UI involves a number
of special little characters that have "lozenges" (flat hexagons)
drawn around them and
say "(" or ")" or "AND" or "OR" as the character name, so that when you
type in a search string to Zmail or to Zmacs tags search, you type something
like this sequence of characters:
<(> F O O <OR> B A R <)>
--- - - - ---- - - - ---
where each of those underlined items is a single character. The
cue that they are available is the words "Extended Search Characters"
at the top right of the minibuffer. They are on the dispatch char
Control-H, so that
Control-H ( F O O Control-H Control-O B A R Control-H )
will get you that search string, if memory serves me. (It's late and
I'm too lazy to move to the other chair and check... :-)
··@NANOSTRUCTURE.UTDALLAS.EDU writes:
> Erik Naggum <····@naggum.no> writes:
>
> > * ····@rigden.engr.sgi.com (Rob Warnock)
> > | Yup!!! I learned a *lot* (in the early 1970's) from reading the
> > | sources to TOPS-10, the operating system for the DEC PDP-10, which
> > | was shipped with every PDP-10.
> >
> > funny you should say that. I "grew up" on PDP-10's, too, somewhat later
> > than you did, however, and worked with both TOPS-10 and TOPS-20, the
> > COMND JSYS of which is still a better way to do command-line interfaces
> > than anything implemented since then, not to mention the way the program
>
> What about Command Processor/Dynamic Windows under Genera? COMND JSYS
> is really nice, but I don't really think you can honestly say it
> stands up to that. Command Processor alone is slightly better than
> COMND JSYS; when combined with Dynamic Windows it is unbeatable.
>
> Still, COMND JSYS is about 36 million times better than anything else.
Well, you can get the rubout-processing part (minus a bit of UI) from
my http://world.std.com/~pitman/Ambitious.html
I think somewhere I have the code from a Maclisp command processor
that I wrote using a mechanism similar in look to the TOPS-20 style
one time... (I have no idea if the internals were the same or not,
but the result was similar. I vaguely recall that my tool might have
been offered as "prior art" to the patent office when someone later
tried to patent the relevant [obvious] techniques. Sigh.) I had
context-dependent completion in Maclisp long before the Lisp Machine
did. (I received a note of apology a couple years later from one of
the Symbolics folks, sad that he had ignored my original feature
request to add the relevant stuff to support it. Took them a while to
reinvent the ideas.) Maclisp was kind of a naive tool in some ways,
but it was a testbed of some extremely cool stuff that got lost when
better things came along. Ah, sniff, sniff, for the good old days,
when programming was fun and anyone could find something fun and just
do it because no one ever had.
Erik Naggum <····@naggum.no> writes:
> free software _used_ to be how vendors gave their customers their
> operating systems.
Back when this was done the vendor of the operating system was also
the hardware vendor and the operating system was written in an
assembler specific to the architecture. Nowadays, you can still obtain
the source for pretty much any OS for some kind of cost via source
licensing. Even Microsoft has licensed the NT sources to different
companies and has made them available for free to students enrolled in
certain courses at select universities under an NDA.
> the GNU operating system idea was born as a reaction to the software
> hoarding of the Lisp Machine vendors who wasted a whole bunch of
> effort in duplicating features by keeping their code bases
> unavailable to eachother.
Often two companies will work out cross-source licensing or share
patent portfolios if a business case can be made that it will be
mutually beneficial. If they kept their code bases unavailable to each
other, then it was likely that a strong business case for code sharing
could not be made.
> Richard Stallman reimplemented features from one of the major
> systems to the other and naturally thought this was a huge waste of
> time and effort, and that those who made him do it were bad people.
Sounds like feature reimplementation was a one-sided thing. A source
licensing scheme must be mutually beneficial. What did the LMITI
machines _seriously_ have to offer Symbolics?
And they didn't "make" him do it, as in put a gun to his head or
anything. So the're not "bad people" because of that.
> I have the deepest sympathy for him with respect to the XEmacs
> splinter group -- it's exactly the same kind of stupid duplication
> of effort that he wanted to avoid by making the software free.
And what about your Multi-Byte Survival Kit GNU Emacs??? The GNU Emacs
people didn't do MULE right. The XEmacs people did. And XEmacs has
supported really nice features for ages now still not present in any
version of GNU Emacs.
XEmacs and EGCS are great examples of the GPL's allowance of
source-forking at work. The GCC people were similarly stubborn, and
now years later EGCS has been officially adopted by GNU, after the
Linux kernel team and everyone else had already been using it for
quite some time and its superiority and pervasiveness was a
non-issue. XEmacs is now in a position similar to that of EGCS not
long ago, with Altrasoft releasing InfoDock, Hyperbole and the
OO-Browser as free software and charging for support.
[InfoDock is a commercially supported XEmacs. I'm using it right
now. About a week ago you said:
only commercial Lisps supported by someone other than myself could
work for me. (I would like a commercial Emacs, too, for exactly
the same reasons. perhaps I'm just getting old.)
Well, knock yourself out:
http://www.altrasoft.com/products.html
(I like it a lot more than the XEmacs from xemacs.org)]
Now go ranting on and on Erik about how XEmacs users are a bunch of
lunatics that attack GNU Emacs users, and how any technical problems
within GNU Emacs can be blamed on XEmacs. Just understand who is
really to blame for any "stupid duplication of effort."
Christopher
* ······@2xtreme.net (Christopher R. Barry)
| Now go ranting on and on Erik about how XEmacs users are a bunch of
| lunatics that attack GNU Emacs users, and how any technical problems
| within GNU Emacs can be blamed on XEmacs.
could you _please_ consult a drug rehabilitation center? your weird
hallucinations are making communication with you very difficult. until
you're clean, there's no point even in asking you what you were thinking
you would get out of such evidence of serious braindamage.
attack me for what I have done, if you are so inclined, but if you have
to invent stuff that I haven't done so you can have something to attack
me for, you don't do a very good job of portraying XEmacs users as other
than lunatics, if that was your intended mission. sheesh.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
> * ······@2xtreme.net (Christopher R. Barry)
> | Now go ranting on and on Erik about how XEmacs users are a bunch of
> | lunatics that attack GNU Emacs users, and how any technical problems
> | within GNU Emacs can be blamed on XEmacs.
>
> could you _please_ consult a drug rehabilitation center? your weird
> hallucinations are making communication with you very difficult. until
> you're clean, there's no point even in asking you what you were thinking
> you would get out of such evidence of serious braindamage.
I expected as much from you.
> attack me for what I have done, if you are so inclined, but if you have
> to invent stuff that I haven't done so you can have something to attack
> me for, you don't do a very good job of portraying XEmacs users as other
> than lunatics, if that was your intended mission. sheesh.
Less than 24 hours ago you wrote in <················@naggum.no>:
and quality suffers much more from competition from splinter groups than
mere quantity. e.g., MULE would not have been as braindamaged had it not
been for XEmacs.
So I'm not the one "inventing" anything here.
Christopher
* ······@2xtreme.net (Christopher R. Barry)
| I expected as much from you.
of course you did. you _did_ realize that poking people in the eye
generally has predictable results. I'm sure that in your perverted
ethics it is also the victim's fault when you poke them in the eye.
| Less than 24 hours ago you wrote in <················@naggum.no>:
|
| and quality suffers much more from competition from splinter groups than
| mere quantity. e.g., MULE would not have been as braindamaged had it not
| been for XEmacs.
|
| So I'm not the one "inventing" anything here.
yes, you are, and like the raving paranoid, of course you don't see that
you're matching your hallucinations up with the scantiest piece of fact.
the above is not blaming the MULEshit in Emacs on XEmacs per se, but on
the _competition_ from XEmacs that led to the perceived need to have a
feature that the competition did, and the quality thus suffered. the
problem isn't XEmacs, it is the perceived need to compete with it. this
need is not causally linked t XEmacs at all -- XEmacs just exposes it.
_any_ similar competition would have caused Richard Stallman to jump too
soon and add immature features for no other reason than to try to keep up
with the competition -- MULE happened this way, and numerous other really
bad decisions have been made in the name of competition. but making this
into _blaming_ them on XEmacs is so deranged only you could have thought
it up. now, do you want me to spell it out for you and spoonfeed you
with the obvious context that your hallucinations made you "overlook", or
are you able to understand what I'm saying without more hallucinations?
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
> * ······@2xtreme.net (Christopher R. Barry)
> | I expected as much from you.
>
> of course you did. you _did_ realize that poking people in the eye
> generally has predictable results. I'm sure that in your perverted
> ethics it is also the victim's fault when you poke them in the eye.
No, what I realized is that when one's otherwise decent class is in a
slump, as yours is Erik Naggum, this is the kind of drivel that can be
expected.
> | Less than 24 hours ago you wrote in <················@naggum.no>:
> |
> | and quality suffers much more from competition from splinter groups than
> | mere quantity. e.g., MULE would not have been as braindamaged had it not
> | been for XEmacs.
> |
> | So I'm not the one "inventing" anything here.
>
> yes, you are, and like the raving paranoid, of course you don't see that
> you're matching your hallucinations up with the scantiest piece of fact.
I'm not sure why I honor posts containing such drivel a reply. There
certainly exist more productive uses of my time.
> the above is not blaming the MULEshit in Emacs on XEmacs per se, but on
> the _competition_ from XEmacs that led to the perceived need to have a
> feature that the competition did, and the quality thus suffered. the
> problem isn't XEmacs, it is the perceived need to compete with it.
The GNU Emacs developers have free will. The're not living in prisons
in China and forced to program what they are told to program with guns
to their heads. They have the freedom to make their own decisions.
If a group of boys are doing bicycle stunts after school in front of a
group of girls, and another boy that's inexperienced at bicycle stunts
feels a need to also perform bicycle stunts so as to similarly get
attention from the girls, and then he brakes his neck and remains
crippled the rest of his life, the "_competition_" from the boys that
"led to the perceived need to have a feature that the competition did"
was of the boy's own mental fabrication. To sympathize with the boy
and his foolish decision would not be the right thing to do. The boy
should have worked with the other boys and been patient and learned
how to do stunts with his bike the proper way. Instead he rushed out
in all his incompetence and broke his neck of his own free will
because he felt he had to compete with the boys who knew what they
were doing when he was in fact clueless and incompetent.
Christopher
Christopher R. Barry wrote:
>> | I expected as much from you.
>>
>> of course you did. you _did_ realize that poking people in the eye
>> generally has predictable results. I'm sure that in your perverted
>> ethics it is also the victim's fault when you poke them in the eye.
>
> No, what I realized is that when one's otherwise decent class is in a
> slump, as yours is Erik Naggum, this is the kind of drivel that can be
> expected.
It's sad to see two intelligent people being so childish.
[Erik:]
>> the above is not blaming the MULEshit in Emacs on XEmacs per se, but on
>> the _competition_ from XEmacs that led to the perceived need to have a
>> feature that the competition did, and the quality thus suffered. the
>> problem isn't XEmacs, it is the perceived need to compete with it.
..
> If a group of boys are doing bicycle stunts after school in front of a
> group of girls, and another boy that's inexperienced at bicycle stunts
> feels a need to also perform bicycle stunts so as to similarly get
> attention from the girls, and then he brakes his neck and remains
> crippled the rest of his life, the "_competition_" from the boys that
> "led to the perceived need to have a feature that the competition did"
> was of the boy's own mental fabrication. To sympathize with the boy
> and his foolish decision would not be the right thing to do. The boy
> should have worked with the other boys and been patient and learned
> how to do stunts with his bike the proper way. Instead he rushed out
> in all his incompetence and broke his neck of his own free will
> because he felt he had to compete with the boys who knew what they
> were doing when he was in fact clueless and incompetent.
Which is, in fact, exactly what Erik was saying. Note: "the
*perceived* need". The problem with this boy's behaviour isn't
the other boys as such, but his perceived need to compete with
them; but the fact that there are these groups that feel they
need to compete causes trouble.
Erik said "_any_ similar competition would have caused Richard
Stallman to jump too soon and add immature features for no other
reason than to try to keep up with the competition". Exactly
the behaviour you're ascribing to the boy in your story, and
for essentially the same reasons. Remind me what you're disagreeing
about?
--
Gareth McCaughan ················@pobox.com
sig under construction
Erik Naggum <····@naggum.no> writes:
<snip rant>
>
> please quote what you understood to be an "assertion", and don't _ever_
> ask people to substantiate what you misunderstand from what they say.
> morons, bad journalists, and disgustingly dishonest politicians do that.
> they should frankly be shot for it, especially if they are so dense as to
> consider the victims of their lies to be at fault for reacting, too.
Perhaps I'm misinterpreting your statement
why are you so sure abou this? it is in the best interest of people who
desire users to make something _appear_ new, and if you need programmers
to get excited about your new free software project, what better way to
get them interested than to re-package some old stuff in maringally new
ways that can't be used with the rest of the old stuff? take a good look
at what the industry accepts as "invention" these days, and shudder.
free software will not change this, it will only redirect the efforts to
and the means of appearing new and attractive.
as meaning the software industry isn't being particularly creative.
If so, I retract my comments based upon that interpretation.
And as far as the rest of your tirade- beyond the good points you do
make- go soak your head. However I haven't seen any convincing
arguments amidst the venom. You want a better model, fine- so do we
all. I'll be happy to agree to disagree about the means towards that
end.
Gregm
* Greg <······@erols.com>
| Perhaps I'm misinterpreting your statement
|
| why are you so sure abou this? it is in the best interest of people who
| desire users to make something _appear_ new, and if you need programmers
| to get excited about your new free software project, what better way to
| get them interested than to re-package some old stuff in maringally new
| ways that can't be used with the rest of the old stuff? take a good look
| at what the industry accepts as "invention" these days, and shudder.
| free software will not change this, it will only redirect the efforts to
| and the means of appearing new and attractive.
|
| as meaning the software industry isn't being particularly creative.
I'm frankly amazed. this was a response to the line
||And nobody has tried enough possibilities yet to find the ones that have
||lasting value.
from Michael Coughlin. I was trying to explain to him why his point of
view is formed by what he has seen publicly.
for the purpose of trying to explain the obvious to you, let's partition
the industry into two fields: (1) the people who write software and are
creative in that field, and (2) the people who write marketing drivel for
the mass markets and are creative in that field. group (1) do lots of
cool stuff that nobody see outside of their small groups of developers,
as it true of all technical creativity, and they would easily find stuff
of lasting value. group (2) hype up lots of trivialities and repackage
old ideas as new because that's how the mass market works, and do their
very best to make nothing have lasting value, because lasting value means
reduced sales of new trinkets.
| If so, I retract my comments based upon that interpretation.
I consider it done.
| However I haven't seen any convincing arguments amidst the venom.
open your eyes, then. they appear to have been closed after you had
decided you had seen enough to make your unfounded judgments of others.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
> this will happen if software is seen as works of art, visible out in the
> open, but not for random people to "modify" or "improve" at will. art is
> copyrighted for a multitude of reasons:
In the U.S. there is only one reason for copyrights on works: the
advancement of the sciences and the arts. This purpose is important
enough to be stated explicitly in the U.S. constitution. I'm not sure
what reasoning is behind the IP laws of other countries. In the
U.S. art is copyrightable because the intention is to give the author
a limited monopoly on the use and distribution of that work as an
incentive for them to produce works for the public.
Copyright law also allows people to modify and improve a work of art,
provided it qualifies as Fair Use. I do not think that copyright
would make software be treated as a work of art. Works of art do not
attain their status as pristine "objets d'art" because of their
status as copyrightable works. The "work of art" preceeds copyright
law and the concept of intellectual property as we know it today.
> I want software to be similarly protected from the onslaught of
> the unschooled masses, but I also want them to appreciate it and
> learn from it so as to be better prepared to create their own
> works of art.
Copyright is not the way to do this. After all, copyright is
explicitely for a limited term only, your lifetime + some number of
years, or a set number of years if the copyright is owned by an
organization and not an individual. This is the situation in the
U.S. at least, may differ elsewhere. To rely on copyright to do this
would be short-sighted.
I also think that it is not possible to produce pristine works of
software which can maintain their identity and usefulness thru time
without allowing them to be modified to fit the context of their use.
I'm assuming that their primary importance is their ability to solve
problems, not only as static objects for contemplation. Obviously
this is not the case for all software, but I think it's the case for a
large portion of the software being produced.
In other words, I do not subscribe to the "uberprogrammer" theory,
where some immensly well-educated and meticulous being or organization
is able to hand down to the world a perfectly usable work of software
which has been designed with every possible environment and problem in
mind. This has never been the case in software engineering, and I do
not think it ever will be. It's a problem that has plagued philosophy
itself for millenia.
Software works better as a dialog than it does as a monolog, and for
this reason I see no reason to make it diffcult for others to
participate in the conversation.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
I say woe unto those who are wise in their own eyes, and yet
imprudent in 'dem outside -Sizzla
* Craig Brozefsky <·····@red-bean.com>
| In other words, I do not subscribe to the "uberprogrammer" theory,
well, do you believe that artists are �bermensch since you bring this up?
in my view, if they were, their works wouldn't need protection. it's
because fairly normal people sometimes do outstanding work that we need
to ensure that we are not taking away their ability to profit from and
live by the few outstanding things each person can do in his lifetime.
I continue to be amazed by the arguments people actually appear to
believe are opposite to mine, or useful in whatever other way to argue
against what I have said. something here is clearly incomprehensible to
people who still believe in free software as a solution, but I don't ask
you to agree, I only ask you to think. fools agree or disagree before
they have thought, brilliant people think without considering agreement.
freeing software is a means to an end, not an end in itself. if the end
needs different means at different times, the old means will work towards
different ends. but most people think in terms of what they see today,
not in terms of what they want to help come true in the long run. today
we have some free software and some serious problems, and some problems
have gone away because we have some free software, but tomorrow, we will
have more serious problems because we have some more free software. if
the goal is to remove some more serious problems, are we still doing the
right thing? I think not, and I don't think the effects will be seen for
many years to come, just like the Internet bonanza will kill a whole
bunch of previously profitable companies and industries so thoroughly
that we may see a decade of unhealthy growth by those who have the guts
to hold out for what worked and wasn't hyped. when the world didn't end
with the commencement of the new millennium, people will return to their
senses and again start behaving as if they were going to live for 30 more
years at least, which most of them are. well, maybe I have time to earn
a degree in curing post-fin-de-si�cle-depression, as in "shit, it didn't
all blow up. _now_ what do we do?"
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
> * Craig Brozefsky <·····@red-bean.com>
> | In other words, I do not subscribe to the "uberprogrammer" theory,
>
> well, do you believe that artists are �bermensch since you bring this up?
No.
> in my view, if they were, their works wouldn't need protection. it's
> because fairly normal people sometimes do outstanding work that we need
> to ensure that we are not taking away their ability to profit from and
> live by the few outstanding things each person can do in his lifetime.
I might agree with this. This is much different than your last post
tho, where you talked about protecting the work from modification and
copying by the unwashed masses. How is the notion of ensuring that
people can profit from their outstanding works tied to the notions in
your previous post of protecting the work from the unwashed masses?
> I continue to be amazed by the arguments people actually appear to
> believe are opposite to mine, or useful in whatever other way to argue
> against what I have said.
I think I presented a good argument why copyright may not be the best
way to accomplish what you want to accomplish. I have not expressed
an argument against what it is you are trying to accomplish. Is your
statement above directed at me or at someone else?
> something here is clearly incomprehensible to people who still
> believe in free software as a solution, but I don't ask you to
> agree, I only ask you to think.
And I only ask for your patience in explaining the nuances of your
point of view. I will give you my attention and make a
well-intentioned effort to read you closely. I can see that there are
other participants in the thread tho, so feel free to post where you
think it would be most fuitful.
> fools agree or disagree before
> they have thought, brilliant people think without considering
> agreement.
Well, I did not present the "uberprogrammer" theory as yours when I
expressed my disagreement with it. I think the "uberprogrammer" is
just another name for the Romantic notion of "Author" as it moves thru
computer programming. This notion of "Author" is central to the
notion of the "objet d'art" which you presented as mode for treating
software. So I expressed my disagreement with this notion, hoping
that you would clarify how your suggestion for treating software as a
work of art differed from the "objet d'art", becuase I could not
really find the difference in your post.
I am attempting to understand your position, and also exploring some
of it's implications. I'm particularly intrigued by the way you talk
about software as an art work. My opinions differ from yours on
several notes so far in this thread, but I'm not prepared to declare
this an argument.
> freeing software is a means to an end, not an end in itself. if the end
> needs different means at different times, the old means will work towards
> different ends.
From your previous posts I understand that you see the ends as
increased efficiency in software production, to allow civilization to
move forward. Could you clarify this if it is wrong? If it's
accurate, what is it that we should be rushing towards?
I see Free Software as a means towards increased diversity in the type
of software that is produced. I think that Free software will result
in more diverse applications and capabilities in software, because
there is a more direct relationship between the desires of a
user/programmer and the production of the software. It need not be
mediated bya market and preciated on the users status as a "consumer".
I think that desire drives creation, and that it should be the
organizing principle around which we build our resource distribution
mechanisms.
Also, I see Free Software as an end in itself. The mode of production
of Free Software, based largely on collaboration and cooperation is
better. I'm not sure it is more efficient, or competitive, I simply
prefer to have my relationships with others organized that way.
Can you still converse with someone who does not share your
understanding of what the "ends" are? I've had alot of good thinking
inspired by your posts so far, so I hope you can.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
I say woe unto those who are wise in their own eyes, and yet
imprudent in 'dem outside -Sizzla
* Craig Brozefsky <·····@red-bean.com>
| I might agree with this. This is much different than your last post tho,
| where you talked about protecting the work from modification and copying
| by the unwashed masses. How is the notion of ensuring that people can
| profit from their outstanding works tied to the notions in your previous
| post of protecting the work from the unwashed masses?
consider that some work of art (including a piece of software for the
sake of discussion). it has been the result of much work and, say, all
the creativity of someone, at least for some significant amount of time.
I say it and the authors needs protection so they can reasonably expect
to earn a life's worth of money since the put it all on the line. that
can not happen if the unwashed masses are able to take their work and
modify it slighly and profit from it instead. however, if there are
other artists in the crowd who get their life's one successful brilliant
idea from studying this work of art, we could have lost a brilliant idea
if he could not study this work of art, and that would be "really sad"
(for lack of a less emotive motivation ;). that is, I want there to be a
significant hurdle to be cleared before a work of art is admitted as a
new work of art, worthy of individual protection instead of contributing
to the profitability of the first work of art of which it was a derived
work that the first author(s) should benefit from. in particular, I see
it more beneficial that contributions be funneled back to the authors,
than that there be a right to modify and redistribute, but I recognize
that those who make contributions should continue to own them. in brief,
I want sharing source code to make good business sense for everyone. the
free software movement makes it good business sense only for the users.
| From your previous posts I understand that you see the ends as increased
| efficiency in software production, to allow civilization to move forward.
I consider the furtherance of the state of the art in programming to be
much more valuable than the products. this means that my "efficiency"
argument is one level removed from the production. I don't believe
people will create better software if they can copy from others at will
and nobody really owns the sources. I believe people will create better
software if they (1) can learn from available source code, and (2) know
that they need to make a significant contribution themselves before they
can expect to reap any meaningful benefits from it.
| I see Free Software as a means towards increased diversity in the type of
| software that is produced.
if I understand you correctly, this is because more people's voices may
be heard than a mass market can ever cater to? if so, I agree that this
is a likely consequence of the availability of source code, but I don't
see the restrictions placed on free software to help this end at all. as
it is today, you cannot take what you have gleamed from free software
with you if you want to recover your investments and get enough money to
fund the next.
| Also, I see Free Software as an end in itself. The mode of production of
| Free Software, based largely on collaboration and cooperation is better.
| I'm not sure it is more efficient, or competitive, I simply prefer to
| have my relationships with others organized that way.
which alternatives have you considered?
| Can you still converse with someone who does not share your understanding
| of what the "ends" are?
of course. I believe any point of view is worth heard as long as it is
not actively trying to or in favor of suppressing other points of view.
or, put it another way: as long as people respect a framework of open
discussion and don't start being "terrorists" because they feel they
aren't heard enough otherwise, sharing ideas can only be profitable.
(this incidentally means it's more important to make extreme ideas heard
than generally acceptable ideas, because the need to be heard is so
strong with people that they'll all to often do dangerous and destructive
things if they aren't heard, but I digress.)
| I've had alot of good thinking inspired by your posts so far, so I hope
| you can.
thanks, and, again, sure.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
Erik Naggum <····@naggum.no> writes:
I'm only gonna respond to this post, and not the other. I think this
one is more directly related to what I'm trying to figure out.
> consider that some work of art (including a piece of software for the
> sake of discussion). it has been the result of much work and, say, all
> the creativity of someone, at least for some significant amount of time.
> I say it and the authors needs protection so they can reasonably expect
> to earn a life's worth of money since the put it all on the line.
It seems that what you are describing is "the masterpiece",
particularly since the artist is expected to earn a life's worth of
money from it. I don't think it's a good idea to take this one
extremely rare type of work, and base an analysis of artistic modes of
production entirely on it.
Perhaps we should start an analysis by looking at some of the modes of
production, and even types of "author" which we see today, rather than
with a highly reified and Romantic notion of the "artistic work" and
the "Author" as you describe above. I am struggling presently to find
an example of the "work" that you describe above, could you give us an
instance of it, and perhaps an estimate on how applicable this model
is to the software that we see around us today?
When I look at the tools I am using today, to write this post for
instance, I see a different model for the "work" as well as "Author".
Emacs - Collaborative effort, difficult at best to name a set of
authors, built up over years of small contributions from users.
Gnus - Significant rewrite of GNUS, borrowed many concepts from it.
Lars is the present maintainer, but there are over 140 contributors
listed in it's info pages, including you. Reads like a who's who of
emacs headz.
SCWM - Maciej and Greg are recognizable as primary authors, but large
parts of it's functionality were contributed by others, a total of 8
people listed in the AUTHORS file. Also uses Guile.
Guile - Jim Blandy is the current maintaner, large parts of code base
from SCM by Aubrey Jaffer, and 12 other people listed in AUTHORS file
with significant contributions.
Debian - 400+ developers. Most of it packaging up of software from
various sources, but a significant toolset for managing those packages
and building/maintaining them was built. Saves oodles of time for the
user, allows them to concentrate on their work and not administrating
a unix box.
What I see is fruitful plagiarism benefitting from the unprecedented
capabilities for communication and collaboration that electronic
networks allow. A network of authors who use freely the work of one
another, allowing them to benefit from the resources others have put
into the network, and at the same time benefitting themselves; always
recieving more than they put in.
This differs from your model in several ways. First, the relationship
of the participants to one another is more involved. My benefit is
directly tied to the benefit of other participants. Second, my
relationship to the software produced is different. I may start a
project, nurture it thru the first release, but then my users and
developers may take over the maintenance work, or add their own
features to it, while I move on to something else.
This is the way every tool I listed above was created. This does not
anwser the question of wether this model is the most fruitful one of
all possible models, in terms of producing good software, but it does
mean that we should prolly be aware of this model when thinking about
that question.
> I consider the furtherance of the state of the art in programming to be
> much more valuable than the products. this means that my "efficiency"
> argument is one level removed from the production. I don't believe
> people will create better software if they can copy from others at will
> and nobody really owns the sources. I believe people will create better
> software if they (1) can learn from available source code, and (2) know
> that they need to make a significant contribution themselves before they
> can expect to reap any meaningful benefits from it.
I don't think this jives with my understanding of the software
development process. But I'm definetly the junior when it comes to
experience in this group. I'm speaking my mind here, but don't intend
to pass it off as the gospel truth. If I'm missing something, I hope
you can fill me in.
In regards to point (1):
More then just the ability to look at others work and learn from it is
needed. Building on top of the time and effort it requires to debug a
program is much more efficient than looking at it's API, or design and
building it yourself (although that can be a fruitful learning
experience itself).
Also, if there is a need to track who is the owner of what, and see
who gets a penny here and a penny there, then the majority of our time
is going to be spent tracking down and getting in touch with owners.
This is the problem that many hip-hop artists face presently. It's
similiar to the problems with software patents, where you cannot do
your research and innovate without very expensive searches into who
owns this or that. Even determining what is or is not a "derivative"
of a particular piece of code and therefor sould be covered by it's
copyright is a complicates issue. You yourself have pointed that out
to me in this group before. I believe you even said that is is better
to not look at source code because that is the only way to guarantee
you would not be liable to violation of copyright. How do you
reconcile your present idea about making source available, but still
controlled by it's "author" with your previous comments?
In regards to point (2):
This cost-benefit analysis only covers a single work, and a single
type of profit one can get from that work. As such, I don't think
it's adequate for thinking about cultural production at large.
> if I understand you correctly, this is because more people's voices may
> be heard than a mass market can ever cater to? if so, I agree that this
> is a likely consequence of the availability of source code, but I don't
> see the restrictions placed on free software to help this end at all. as
> it is today, you cannot take what you have gleamed from free software
> with you if you want to recover your investments and get enough money to
> fund the next.
Well, obviously you cannot "take" but you can certainly fund your next
contribution. RH is funding contriutions, as is Cygnus. My employer
is funding contributions as well. All have benefitted from Free
Software, and turned part of that "profit" into a tool for funding
more contributions, from which they will benefit, as well as everyone
else. I actually find that this is a good argument for the GPL in
terms of business sense, and that is why all of those companies,
including my employer release their works under the GPL.
> | Also, I see Free Software as an end in itself. The mode of production of
> | Free Software, based largely on collaboration and cooperation is better.
> | I'm not sure it is more efficient, or competitive, I simply prefer to
> | have my relationships with others organized that way.
>
> which alternatives have you considered?
Most of the common political-economic models: consumer, market
participant, citizen, competitor.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
I say woe unto those who are wise in their own eyes, and yet
imprudent in 'dem outside -Sizzla
Greg wrote in message ...
[snip]
> I remember
>in the 1980s some columnist or other said all the applications had
>been written; we had word processors, spreadsheets and database apps-
>what else was there?
I remember a program from the mid '80s called "The Last One". It appeared to
be a kind of applications generator and was advertised as "the only program
you will ever need". The hype must have worked because a year or so later
the same company published "The Last One - Version 2" :(
Philip.
Member of FIG-UK http://www.users.zetnet.co.uk/aborigine/forth.htm
* Andrew Cooke <······@andrewcooke.free-online.co.uk>
| I get the impression that Lisp is on the way out.
something important happens when a previously privileged position in
society suddenly sees incredibly demand that needs to be filled, using
enormous quantities of manpower. that happened to programming computers
about a decade ago, or maybe two. first, the people will no longer be
super dedicated people, and they won't be as skilled or even as smart --
what was once dedication is replaced by greed and sometimes sheer need as
the motivation to enter the field. second, an unskilled labor force will
want job security more than intellectual challenges (to some the very
antithesis of job security). third, managing an unskilled labor force
means easy access to people who are skilled in whatever is needed right
now, not an investment in people -- which leads to the conclusion that a
programmer is only as valuable as his ability to get another job fast.
fourth, when mass markets develop, pluralism suffers the most -- there is
no longer a concept of healthy participants: people become concerned with
the individual "winner", and instead of people being good at whatever
they are doing and proud of that, they will want to flock around the
winner to share some of the glory.
Lisp is not the kind of language that insecure losers would use. people
do not want to learn Lisp because they stand a better chance of beating
another unskilled fool in the job race. fact is: you don't get a job by
lying about your Lisp skills. all of this means that there is very
little activity at the front gate, where all the journalists and the
media are. there are no people struggling like mad to get into the Lisp
world. they don't have to. if you want to learn Lisp, you go learn Lisp
and talk to nice people who probably have time for you, and you make
yourself good at it. then you go do complex stuff that insecure losers
who lie about their Java skills can't even imagine, and therefore do not
consider part of the competition.
neurosurgery is another field that requires an actual investment and lots
of dedication to get into, is really rewarding to those who get good at
it, but whose jobs are not advertised in regular newspapers. there is a
shortage of neurosurgeons, but very little advertising in the media that
the patients read. programming is both similar and different. whether
you are a user or a programmer these days is often hard to tell (this has
good qualities to it, too), but some programming tasks are still reserved
to highly skilled people who are not afraid to take huge risks. ignoring
for a moment the power of the American Medical Association, we still
wouldn't see a huge amount of books on neurosurgery for dummies in 21
days or whatever. it's just plain inappropriate, and it's intentionally
out of people's reach. Lisp is somewhat like that. people can get lots
of medicines at the drugstore, but they can't be trusted to carve out a
malignant tumor in their child's brain. all sorts of users can do lots
of customization and cool stuff in their "apps", but they really can't be
trusted to run actual flight control systems, configure the telephone
network, write software for video-synchronized magnetic-resonance imaging
for brain surgery, or write automated stock-trading systems. at some
point, the risk of letting unskilled people do the task becomes too
high. that's when you can't trust more than 1% of the programmers out
there, and a surprisingly large number of them know and use Lisp and
tools that are can be trusted. (consider an ATM that gets one of those
frequent Windows crashes, or a naval warfare vessel that has to cold-boot
because a certain display suddenly goes all blue, or any other story in
comp.risks that would have been hilarious if it had been a joke.)
another way to look at this is to see that software in today's society
has a number of diseased elements, to consider that maggots eat only
diseased or dead tissue, that dead or dying software projects lie around
all over the place, like a horrible war zone between ignorant users and
frightened managers, and pretend that you're a maggot. you wouldn't care
about the living and the healthy who prosper outside the war zone, you'd
rush to the war zone to join the feeding frenzy, right? so, to complete
the grim picture, software in our society is diseased, the activity you
read about are all about cleaning up the disasters and surviving the
equivalent of plagues, and it just takes a tremendous amount of people
and work to keep the whole system from dying, like the incredibly stupid
year-2000 problem.
to take but one simple example: suppose you thought of the new millennium
when you wrote your application back in 1972 -- not only wouldn't you be
invited to the party, those who knew you had done it right from the start
and who probably laughed at you at the time would positively hate you
now, and they sure as hell wouldn't tell people about you. and the more
stupid they are, the more important it would be to pretend that nobody
was smart enough to see the next millennium coming.
Lisp is a little too much out of the reach of the masses, and this needs
fixing, but the professional markets are not into language-of-the-week
contests and feeping creaturism in whatever won last week. when your
application takes longer to create than three versions of the JDK, you
don't use Java. the same applies to other long-term stuff. when you
write manuals for naval or air force vessels, you don't use MS Word and
hope Microsoft doesn't come out with yet another incompatible disservice
pack and/or upgrade, you use CALS and enterprise-wide publishing systems.
put yet another way, even though aviation has become a commodity and ever
more people fly around the country for the fun of it (well, maybe not,
but it's certainly not for the food), you don't see people complaining
that business class is in the decline. instead, you notice that there is
fierce competition in the cheaper tickets, but routes are set up mainly
to accomodate business travelers, and if you're willing to pay for it,
all sorts of amenities are available and life in the air is a lot better.
Lisp is not only object-oriented, it's the business class programming
language. (it really is the first-class programming language, but let's
talk about that when you have enough mileage.)
now, since you're worried about Lisp "dying", consider this: Lisp is used
a lot of places where all else has failed. some people are smart enough
(or have been burned enough) to use Lisp from the start, but just as you
can't expect people to pay for insurance until they have a reasonable
idea about the risks that exist around them, most people have to get
burned before they understand the value of investing in not failing.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
> From: Erik Naggum [···········@naggum.no]
> * Andrew Cooke <······@andrewcooke.free-online.co.uk>
> | I get the impression that Lisp is on the way out.
>
> for a moment the power of the American Medical Association, we still
> wouldn't see a huge amount of books on neurosurgery for
> dummies in 21 days or whatever. it's just plain inappropriate, and
it's
> intentionally out of people's reach. Lisp is somewhat like that.
Yeah, had the opportunity to work with a couple Lisp experts a decade
ago, those guys were brilliant and remote. I was and am a
"mass-educated"
type, and failed to see the opportunity to pick their brains for all
it was worth, and though I was good at Lisping and got Flavors, was
consumed by the Unix/C market after the project ended. Can't complain,
was lucky for a while.