I was reading the thread about "Lisp or Scheme", and I noted that Erik
pointed out something to the effect that it was a shame that students
didn't start out with good commercial lisps.
This undertone has been running in this newsgroup for quite some
time. I think it should be explored a bit more in depth. Does it
matter which type of lisp you learn with?
In my own experience, I initially started programming with fortran
(mid 1960's), then when desktops hit, moved to basic. Somewhere down
the line, I discovered a fourth generation ide called Clarion. It was
fantastic! It wrote gui code (you just drew), setup databases,
compiled, debugged, edited code all in one. The clarion language
interface made sql look like mush. Applications could be started
simply, then gradually made more complex. I paid $1200 for the base
package and was extremely satisfied.
And if clarion had written a unix package, I'd probably still use
it. But there were other problems. Clarion short-circuited my
programming knowledge. Since it wrote most of the code, I never
learned enough to understand the principles of programming so that I
could evaluate and appreciate other methods of doing things. Yes, the
commercial package made me efficient, but it also made me limited. If
clarion didn't have it, I couldn't improvise or rather wouldn't
improvise. Even though clarion had plugs for C programming, I was
loathe to learn C and use it because being in the clarion environment
was so satisfying.
Discovering lisp was an eye-opener for me. I've learned things about
programming that I can pretty much take anywhere. But I learned on the
free Clisp and Cmucl and yes, Xemacs. Would I have learned as much on
a commercial version with all the perks, I don't know. Would lisp have
been harder or easier to learn with a commercial version, I don't
know.
I do know that newbies, students should go from easy to hard, simple
to complex. I also know that the majority of students will keep with
the simple to avoid challenges that may in fact eventually make their
life simpler. And I also know that if the perception of using a
language like Lisp is that it's hard and unwieldy, very few new people
will approach it.
So I guess the question is, what's the best learning environment for
new students interested in lisp? A side question to that would be,
should you use or learn lisp to the exclusion of other programming
models?
i.b.
IBMackey wrote:
>
> So I guess the question is, what's the best learning environment for
> new students interested in lisp? A side question to that would be,
> should you use or learn lisp to the exclusion of other programming
> models?
>
Re the side question: if you expect to be allowed to use Lisp in
whatever passes for "the real world" these days, knowledge of other more
mundane programming models is vital, for several reasons:
* Knowledge of more than one way to program makes you a better
programmer in general.
* Displaying such knowledge makes people more likely to respect your
opinion when you say "I want to do this in Lisp, and here's why".
* Sometimes close integration with other tools is unavoidable, and if
you don't know how to do it, you will be forced to abandon Lisp in favor
of them.
One of the reasons I am able to use Lisp in my work is that I know C
well enough to drag stuff up from it into Lisp when I need to.
I've also done enough hacking around with some of the other languages du
jour (tcl/tk, Java, Perl) that I know when it's appropriate to use them
and when to run the other way. Before I used those other tools for
non-trivial code, I had ill-informed reasons to dislike them, and would
have sounded stupid defending choosing Lisp over them. Afterwards, I
had very specific, easily defended reasons to avoid them in the future.
--
Remove obvious stuff to e-mail me.
Bob Bane
IBMackey wrote:
>
> I was reading the thread about "Lisp or Scheme", and I noted that Erik
> pointed out something to the effect that it was a shame that students
> didn't start out with good commercial lisps.
I would agree with Erik on this point.
> In my own experience, I initially started programming with fortran
> (mid 1960's), then when desktops hit, ...
Your experience seems somewhat similar to mine, although I never met
Clarion. And I had to program at the very lowest machine level,
quite literally, since our processors were used in machine tool
control systems.
> Discovering lisp was an eye-opener for me. I've learned things about
> programming that I can pretty much take anywhere. But I learned on the
> free Clisp and Cmucl and yes, Xemacs. Would I have learned as much on
> a commercial version with all the perks, I don't know. Would lisp have
> been harder or easier to learn with a commercial version, I don't
> know.
I think it would have been much easier. The perks are there to help
the programmer, and newbies need much more assist from the system
than the seasoned old hand.
> I do know that newbies, students should go from easy to hard, simple
> to complex. I also know that the majority of students will keep with
> the simple to avoid challenges that may in fact eventually make their
> life simpler. And I also know that if the perception of using a
> language like Lisp is that it's hard and unwieldy, very few new people
> will approach it.
I would say that it's not Lisp that is unwieldy. It's the
programming environment of the Lisps you mentioned. On top of
learning Lisp, the newbie must learn the tricks needed to perform
the "think - write code - consult manuals - run code - understand
what went wrong" loop. A dedicated newbie will tolerate an inferior
environment. A not so enthusiastic student will not.
> So I guess the question is, what's the best learning environment for
> new students interested in lisp? A side question to that would be,
> should you use or learn lisp to the exclusion of other programming
> models?
Oh, that's easy. The best environment is the teacher, and the good
examples and programming assignments he has prepared.
I had no teacher, and discovered Lisp on my own, long ago. Later,
when I managed to get an Interlisp-D (Xerox) machine, just to play
with, my first reaction was *wow* and *wow* again. Moving from a
primitive, line-based, non-documented environment, with primitive
tools, to this wonderworld was ... well *wow*.
I cannot say that the primitive environment I started with, made
Lisp easier to learn. I rather feel that would-be Common Lispers
will benefit from rich environments, and that Common Lisp itself
would then be even more attractive than people seem to perceive it
is today.
Lars
In article <·················@era.ericsson.se>, "Lars Lundb?ck"
<·············@era.ericsson.se> wrote:
> I cannot say that the primitive environment I started with, made
> Lisp easier to learn. I rather feel that would-be Common Lispers
> will benefit from rich environments, and that Common Lisp itself
> would then be even more attractive than people seem to perceive it
> is today.
You need to learn about programming environments, too.
Look at some of the modern C++ environments. Having
seen InterLisp D is sure a help, too. Then see the
canonical Smalltalk IDE, Self, XEmacs-based stuff,
Genera, Unix+C+Make+..., Prograph, ...
Knowing that there is more to programming than just
typing language expressions to an editor is a big help.
Unfortunately Universities don't talk much about
the interactive development environments and their
role in programming (exploring code, debugging,
visualization, ...).
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
>>>>"RJ" == Rainer Joswig schrieb am Thu, 18 Jan 2001 21:53:19 +0100:
RJ> You need to learn about programming environments, too.
Indeed. One can easily get lost in modern IDEs with tons of
possibilities offered which some- or most of the time are mainly
irrelevant to the problem that needs to be solved.
RJ> Knowing that there is more to programming than just typing
RJ> language expressions to an editor is a big help. Unfortunately
RJ> Universities don't talk much about the interactive development
RJ> environments and their role in programming (exploring code,
RJ> debugging, visualization, ...).
But I'm sure happy that universities (at least German ones) don't let
one conclude that an IDE and a mouse is all you need to do
programming.
FWIW, I would also like to know which benefits Erik actually sees of
using, say ACL, over CMUCL. I'm currently using ACL (Prof) with XEmacs
(under Ilisp, not with fi) and I can't say I feel that much added
value over CMUCL.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Eight Megabytes And Constantly Swapping ?"
"You left out the `X'. It's X+Eight Megabytes And Constantly Swapping,
and X + Eight = 18, which is about right, actually ..."
-- SL Baur on xemacs-beta
Holger Schauer wrote:
>
> Indeed. One can easily get lost in modern IDEs with tons of
> possibilities offered which some- or most of the time are mainly
> irrelevant to the problem that needs to be solved.
The teacher, or tutorial package, hopefully interactive, should take
care of that. And the main problem to be solved here is related to
teaching and learning the language.
> FWIW, I would also like to know which benefits Erik actually sees of
> using, say ACL, over CMUCL. I'm currently using ACL (Prof) with XEmacs
> (under Ilisp, not with fi) and I can't say I feel that much added
> value over CMUCL.
Would that be because you have already learnt quite a lot about Common
Lisp? Anyway, Common Lisp under Emacs is very far from the environments
that Rayner and others have been telling about. Julian in his "longish"
thread gave a very good description of the feeling you get when you
encounter Emacs and a raw Common Lisp, having used superior systems long
ago.
Lars
>>>>"c" == ck schrieb am Fri, 19 Jan 2001 15:55:44 +0100:
>> I'm currently using ACL (Prof) with XEmacs (under Ilisp, not with
>> fi) and I can't say I feel that much added value over CMUCL.
c> Would that be because you have already learnt quite a lot about
c> Common Lisp?
Might be, I dunno. And although I'm certainly not clueless, I'm (after
four years research use) certainly not an expert either.
c> Anyway, Common Lisp under Emacs is very far from the environments
c> that Rayner and others have been telling about. Julian in his
c> "longish" thread gave a very good description of the feeling you
c> get when you encounter Emacs and a raw Common Lisp, having used
c> superior systems long ago.
I have used "superior" systems, too. I even started Common Lisp with
ACL 3 under Windows and I must say that after a while, I outright
*hated* it, because the integration was *IMHO* far worse than CL under
Emacs.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"You can't manage what you can't measure (unless you're managing
humans, in which case the reverse holds)."
-- Martin Buchholz in xemacs-beta
In article <··············@ipanema.coling.uni-freiburg.de>,
Holger Schauer <··············@gmx.de> wrote:
> RJ> You need to learn about programming environments, too.
>
> Indeed. One can easily get lost in modern IDEs with tons of
> possibilities offered which some- or most of the time are mainly
> irrelevant to the problem that needs to be solved.
Yeah, this is exactly the view from the past that is holding
us back. You are in pre-stone-age, where people
were not *building* tools. Progress starts when you
build tools and you use your capabilities (people have
a real strong ***visual*** input channel that is
waiting to be used). You are not even aware of
the limitations.
Emacs/ILISP and CMUCL (which is okay for some people
and you can get your work done) is not exactly a good
comfortable multi-threaded IDE for Lisp development.
MCL is so much better. MCL has the complete IDE
written in Common Lisp (source only
a keystroke away) and you can change/adapt/reuse components
easily, since the GUI toolkit is simple/effective and
it is nicely using the power of CLOS. There is no
mismatch/translation between the Lisp in the environment
and the Lisp you are using for programming. Why would
you want to program in a poorly structured and baroque
environment like Emacs, when you can have a clean, simple,
and nicely extensible graphical environment like MCL?
If you deny that, then you deny the power of a real
Common Lisp implementation over the Emacs Lisp engine.
MCL has a very speedy inspector (which works even speedy
for large datastructures), lot's of nice mouse bindings
and tons of extensions from users. Emacs forces you
to see everything as a buffer, forces you to use
arcane keybindings (you may need to change them to escape
RSI), forces you to use a poorer extension system,
forces you to slower response times, forces you to
use a non-threaded environment, forces you to a design
that is showing its age, ...
On my Lisp Machine, Zmacs (the editor part) is just *one*
in a whole bag of tightly integrated and highly effective
tools. MCL is not there, it is just an IDE - not an
OS with extensive support for developer workgroups
- like Genera, but for being just an IDE, MCL is
pretty damn effective.
(Sigh: Yeah, LispWorks does have an IDE - it can't
even update/move/raise the listener window, while it is active.)
> RJ> Knowing that there is more to programming than just typing
> RJ> language expressions to an editor is a big help. Unfortunately
> RJ> Universities don't talk much about the interactive development
> RJ> environments and their role in programming (exploring code,
> RJ> debugging, visualization, ...).
>
> But I'm sure happy that universities (at least German ones) don't let
> one conclude that an IDE and a mouse is all you need to do
> programming.
There is much more than a text editor, a prompt and a
Lisp system. If you don't tell people how to handle
complexity and how to work effectively, than you've
done them a disservice. Using visual tools is one
big way to improve productivity and software
understanding.
> FWIW, I would also like to know which benefits Erik actually sees of
> using, say ACL, over CMUCL. I'm currently using ACL (Prof) with XEmacs
> (under Ilisp, not with fi) and I can't say I feel that much added
> value over CMUCL.
ACL has not a particular good IDE under Unix. When they
introduced the ACL Windows IDE, a friend of mine said:
"with the new Windows IDE for ACL, MCL is no longer
twenty times more productive. Just seven." ;-)
It is that a big difference. I heard it from several real
Lisp **hackers**.
Sorry for some marketing, but sometimes people need to get
ideas communicated.
Rainer Joswig
Sent via Deja.com
http://www.deja.com/
Hi
I agree with Rainer about MCL. I have very fond memories of MCL from
10 years ago. I can only imagine what it has become in the meantime.
However, I do not have a Mac on my desk.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3u26vb3fp.fsf@cley.com>
* joswig wrote:
> Yeah, this is exactly the view from the past that is holding
> us back. You are in pre-stone-age, where people
> were not *building* tools. Progress starts when you
> build tools and you use your capabilities (people have
> a real strong ***visual*** input channel that is
> waiting to be used). You are not even aware of
> the limitations.
Do you have measurements that show these fancy gui systems are more
productive?
> "with the new Windows IDE for ACL, MCL is no longer
> twenty times more productive. Just seven." ;-)
Likewise.
What is in the pre-stone age here is the whole culture that can lead
to groups of people making claims like these being made without any
actual evidence that they are true, and other groups of people carping
on about so-called `metrics' like LOC without any evidence at all that
they measure anything useful at all, except they give them a nice
feeling about being all `scientific' (they know it's important to be
`scientific', though they're not quite sure what `scientific' is,
they've seen `scientific' people spend lots of time measuring things,
so they want to measure lots of things too, like the grown-ups do).
One day software culture will advance to the level of politics.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * joswig wrote:
> > Yeah, this is exactly the view from the past that is holding
> > us back. You are in pre-stone-age, where people
> > were not *building* tools. Progress starts when you
> > build tools and you use your capabilities (people have
> > a real strong ***visual*** input channel that is
> > waiting to be used). You are not even aware of
> > the limitations.
>
> Do you have measurements that show these fancy gui systems are more
> productive?
It has nothing to do with being "fancy". GUI systems are
everywhere. The few people who are still on the CLI
or on the Emacs terminal side are just dinosaurs. ;-)
Even the Xemacs crowd moves in the direction to
add modern GUI functionality to XEmacs:
William Perry integrates Gtk in Xemacs, wait and
see what happens.
http://www.cs.indiana.edu/elisp/gui-xemacs/
> > "with the new Windows IDE for ACL, MCL is no longer
> > twenty times more productive. Just seven." ;-)
>
> Likewise.
This is experience from people who use both styles. In day to day
programming over several years.
When I was working in an lab which did a lot Lisp stuff *many* years
ago, people had mainly SUNOS/SPARC/ACL and MCL on their desktop -
that means they had both a SPARCstation and a Mac. It
was also possible to use stuff like Goldworks, ACL on PC,
Lucid, LispWorks, actually most of the Lisp stuff at that time, ...
I'm pretty sure that most of the software actually got written
in MCL and always synced over to ACL. Even though they used
the same libraries on both sides and they had their
own special Unix network.
> What is in the pre-stone age here is the whole culture that can lead
> to groups of people making claims like these being made without any
> actual evidence that they are true,
It is not true that there is no evidence.
> One day software culture will advance to the level of politics.
Sure.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3itnbawjp.fsf@cley.com>
* Rainer Joswig wrote:
> It is not true that there is no evidence.
Well, where is it? Popularity is not evidence -- that something is
popular tells you only that it's good at being popular: heroin is
pretty good at being popular, so is C++ [1].
Note I'm not arguing that interfaces do influence productivity, or
that metrics for programs are impossible to have, I'm arguing that
people have *no idea* what they are doing because we're living in the
stone age, and so end up with things that look ever so cool (stone age
people like pretty pictures), and are ever so easy to use with no
training (hard to come by in the stone age), but help experienced
people not at all.
For the record, and to be deliberately contrarian, I'll say that --
having used both extensively -- I find xemacs/eli/acl with a decent
Unix window manager (and perhaps a few hundred lines of personal hacks
to eli) a significantly more productive tool than the Genera
environment (with a similar amount of hacks). This is mostly because
Genera has this whole select-x/activity nightmare which makes it very
hard to multiplex lots of things, and also because there's no
realistic source control system in Genera, while CVS or clearcase
provide pretty good tools on Unix, and integrate with Emacs (CVS
better than clearcase, I admit). As for windows environments, well
I've never worked out how anyone can live with click-to-type, which is
in many ways worse than what Genera does. I've not used macs
significantly for 10 years, but when I did they made me want to hit
them about as much as Windows machines do[2].
But have I measured this? No. Has anyone? I doubt it. Does anyone
even know *how* to measure it? No, because we're software `engineers'
and we don't do that science stuff, we do religion.
--tim
Footnotes:
[1] I could add something else that was *very* good at being popular
but then I'd have to invoke Godwin's law...
[2] Actually, not as much. I have actually got sufficiently angry
with Windows on one occasion that I physically broke the
machine...
In article <···············@cley.com>,
Tim Bradshaw <···@cley.com> wrote:
> * Rainer Joswig wrote:
>
> > It is not true that there is no evidence.
>
> Well, where is it? Popularity is not evidence
Why not? Sure popularity is an evidence. If everybody
else uses some other tools, I'd better start looking
why it is that way and what one can learn from those
other guys.
For me it is pretty clear that Lisp has only a fraction
of the possible "market share" and "mind share".
> -- that something is
> popular tells you only that it's good at being popular: heroin is
> pretty good at being popular, so is C++ [1].
Actually a *lot* more useful applications are coded in C++,
than there are in Common Lisp. There is no reason to look
down on C++. I wish we were having a fraction of the
libraries and tools available for C++. And if you look closely,
Visual C++ and similar systems aren't that bad and some
excellent applications have been written with it in the
last decade. How many interesting Common Lisp applications have been
written in the last decade (besides academia)? Ten? Twenty?
> Note I'm not arguing that interfaces do influence productivity, or
> that metrics for programs are impossible to have, I'm arguing that
> people have *no idea* what they are doing because we're living in the
> stone age, and so end up with things that look ever so cool (stone age
> people like pretty pictures), and are ever so easy to use with no
> training (hard to come by in the stone age), but help experienced
> people not at all.
You need to look at humans, their abilities and their
input/output channels, their cognitive capabilities, etc.
and design the tools appropriately. Emacs is a grotesque
mismatch.
> For the record, and to be deliberately contrarian, I'll say that --
> having used both extensively -- I find xemacs/eli/acl with a decent
> Unix window manager (and perhaps a few hundred lines of personal hacks
> to eli) a significantly more productive tool than the Genera
> environment (with a similar amount of hacks). This is mostly because
> Genera has this whole select-x/activity nightmare
a) I find the Select-x/Activity idea quite okay. A single
activity is one window and bundles all related information.
With simple keystrokes you move around.
b) To be really productive, you need to change the
UI to the task. Genera does allow you to build a custom
screen layout and a custom window layout. You might
even need one machine with three screens, or three
machines with one screen each, ...
c) some applications explored different interaction
styles on Genera (Plexi, KEE)
> which makes it very
> hard to multiplex lots of things, and also because there's no
> realistic source control system in Genera,
There is one. I don't know how "realistic" it is,
since I haven't used it and it is not distributed
with the OS software, but it did look very complete.
If the Genera development hasn't halted in the early
90s there would surely be one available.
> I've never worked out how anyone can live with click-to-type, which is
> in many ways worse than what Genera does. I've not used macs
> significantly for 10 years, but when I did they made me want to hit
> them about as much as Windows machines do[2].
There must be a reason why Lisp is so behind UI-wise on Unix.
Is there a single simple GUI CL-based toolkit for Unix:
- widespread on multiple Lisp platforms
- looks nice
- simple to program
- has an interface builder
- is fast
- does basic UI-handling tasks correctly
- and has a reasonable robust implementation?
Which is it? As an example, CLIM is neither widespread,
it doesn't necessarily
look nice, it is complicated to program, has no usable
interface builder, is not fast, has quirks everywhere
and the implementation makes it feel only 85% finished.
What else?
Is there non? How can that be? I'd say this is quite
shocking.
Is it the lack of interest and the lack of
talent to build one? There aren't that many Lisp
programmers left on Unix, it seems.
Sent via Deja.com
http://www.deja.com/
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3d7dibhh1.fsf@cley.com>
* joswig wrote:
> Is it the lack of interest and the lack of
> talent to build one? There aren't that many Lisp
> programmers left on Unix, it seems.
Maybe only a couple of orders of magnitude more than Lisp programmers
on Macs, I guess.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * joswig wrote:
>
> > Is it the lack of interest and the lack of
> > talent to build one? There aren't that many Lisp
> > programmers left on Unix, it seems.
>
> Maybe only a couple of orders of magnitude more than Lisp programmers
> on Macs, I guess.
I was talking about Common Lisp. So how many orders? 1? 2? 3 4?
Ten times more? Hundred? Thousand? Ten thousand?
Let's look at the user mailing lists as an indication of
activity. My ACL mailbox has since 1993 ca. 1000 messages.
The LispWorks mailing list has almost none. SLUG has about
1500. MCL has about 5500 messages.
Those couple orders of magnitude seem to hide very effective.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey33deebcqk.fsf@cley.com>
* Rainer Joswig wrote:
>> Maybe only a couple of orders of magnitude more than Lisp programmers
>> on Macs, I guess.
> I was talking about Common Lisp. So how many orders? 1? 2? 3 4?
> Ten times more? Hundred? Thousand? Ten thousand?
2 orders I'd guess, so a hundred (that's what I meant by a couple).
Perhaps only one order.
> Let's look at the user mailing lists as an indication of
> activity. My ACL mailbox has since 1993 ca. 1000 messages.
> The LispWorks mailing list has almost none. SLUG has about
> 1500. MCL has about 5500 messages.
I've been using ACL and other Unix lisps as part of my job since the
late 80s: I've never been on the ACL mailing list as far as I know.
Neither has anyone I know. I've certainly never mailed to it. I've
never used Genera in anger (I play with it), but I've been on the SLUG
since maybe 1995, and mailed to it on multiple occasions. From your
figures you'd say, I presume, that there are only 1.5 times as many
ACL programmers as Symbolics ones? This seems somewhat implausible!
I'd rather base it on the number of companies servicing the population
and the sales volume of those companies -- I don't have the sales
volume figures, obviously, but there are, I think, 2 Unix companies,
and I think only one Mac company, which I guess is smaller than either
of the Unix companies.
Or you could look at maintained-implementation count -- at least 5 for
unix/unixoid systems (acl, lispworks, liquid, cmucl, clisp), at least
3 for Windows (acl, lispworks, corman lisp), at least 2 for Mac (MCL,
powerlisp). This isn't so good though, because it can obviously fail
horribly (how many maintained Word-compatible word processors are
there...)
Obviously I don't *know* these figures, but then neither does anyone.
I'm just trying to infer from what I can see.
The point I'm trying to make is that the popularity of a thing is not
an indicator of quality, or anything other than how good something is
being at popular.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> 2 orders I'd guess, so a hundred (that's what I meant by a couple).
> Perhaps only one order.
Tim, I'm really not sure if it is that many. Given that the
number of Unix installations is not necessarily 100 times
larger compared to Macintosh installations. Though I think
more Unix installations might be used for programming.
The recent survey by ITTA (they have some results on their
web site) is not representative, IMHO.
> I've been using ACL and other Unix lisps as part of my job since the
> late 80s: I've never been on the ACL mailing list as far as I know.
> Neither has anyone I know.
Maybe you recognize a few people (looking at recent mails):
Erik Naggum, Luca Pisati, Clemens Heitzinger, Francis Leboutte,
Patrick A. O'Donnell, David McClain, Richard Fateman, Ken Forbus, ...
> I've certainly never mailed to it. I've
> never used Genera in anger (I play with it), but I've been on the SLUG
> since maybe 1995, and mailed to it on multiple occasions. From your
> figures you'd say, I presume, that there are only 1.5 times as many
> ACL programmers as Symbolics ones? This seems somewhat implausible!
I wouldn't say that with such exact numbers - since you can't
really relate the number of postings to the number of users
(one might also look for the number of individuals that have mailed).
There might be several reasons for these numbers, but atleast
they give an indication what the limits on the numbers might
be (numbers users of product foo compared to numbers of
users of product bar). Assuming that for example Unix-based CLs have,
say, a hundred times more users than MCL (let MCL have 5000 users,
this would bring Unix-based CLs to 500000 users) - this would generate
quite some traffic on the mailing lists - for sure.
> I'd rather base it on the number of companies servicing the population
> and the sales volume of those companies
Well, given the prices for ACL ;-) (and professional software
on the Unix platform in general) this is also not really fair.
> -- I don't have the sales
> volume figures, obviously, but there are, I think, 2 Unix companies,
> and I think only one Mac company, which I guess is smaller than either
> of the Unix companies.
>
> Or you could look at maintained-implementation count -- at least 5 for
> unix/unixoid systems (acl, lispworks, liquid, cmucl, clisp), at least
> 3 for Windows (acl, lispworks, corman lisp), at least 2 for Mac (MCL,
> powerlisp). This isn't so good though, because it can obviously fail
> horribly (how many maintained Word-compatible word processors are
> there...)
I'm not really sure how many people are using LispWorks on Unix
(more are using ACL, just my impression). I guess not that much.
Only a few are using Liquid (for legacy software mostly, I'd guess).
> Obviously I don't *know* these figures, but then neither does anyone.
> I'm just trying to infer from what I can see.
Yes, since there is no representative market study, we can
only look at indicators. It would be nice though, if the
ALU could try to get some more numbers by using their
web site (somebody mentioned that to me as an idea).
> The point I'm trying to make is that the popularity of a thing is not
> an indicator of quality, or anything other than how good something is
> being at popular.
Well, yes and no. For being popular you need to fullfil certain
(basic) needs. So even an average development system needs
to be "good enough" (-> worse is better) and often the users will
improve it over time ( a more evolutionary approach ).
What I think one needs to look at from time to time is,
does "CL" (in which specific a specific group is concerned
with) fulfill the needs of "the developers" (which includes
past users, current users and the prospective market).
What do those people expect and how can this be incorporated
into Common Lisp (if its not already there).
Let me finish with saying: Common Lisp has a big
potential that is not adequately mirrored in current usage
and presence on the "mainstream" platforms Unix and Windows. Just
my impression.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey34rypalfb.fsf@cley.com>
Sorry I used `sales volume' wrong, I meant `license count' or
something, not income!
--tim
Rainer Joswig wrote:
> In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
> wrote:
>
>> * joswig wrote:
>>
>> > Is it the lack of interest and the lack of
>> > talent to build one? There aren't that many Lisp
>> > programmers left on Unix, it seems.
>>
>> Maybe only a couple of orders of magnitude more than Lisp programmers
>> on Macs, I guess.
>
> I was talking about Common Lisp. So how many orders? 1? 2? 3 4?
> Ten times more? Hundred? Thousand? Ten thousand?
>
> Let's look at the user mailing lists as an indication of
> activity. My ACL mailbox has since 1993 ca. 1000 messages.
> The LispWorks mailing list has almost none. SLUG has about
> 1500. MCL has about 5500 messages.
My CMUCL Mailbox counts 6824 Messages since 1994 ;-)
Regards,
Jochen
--
http://www.dataheaven.de
In article <··············@ID-22205.news.dfncis.de>, Jochen Schmidt
<···@dataheaven.de> wrote:
> Rainer Joswig wrote:
>
> > In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
> > wrote:
> >
> >> * joswig wrote:
> >>
> >> > Is it the lack of interest and the lack of
> >> > talent to build one? There aren't that many Lisp
> >> > programmers left on Unix, it seems.
> >>
> >> Maybe only a couple of orders of magnitude more than Lisp programmers
> >> on Macs, I guess.
> >
> > I was talking about Common Lisp. So how many orders? 1? 2? 3 4?
> > Ten times more? Hundred? Thousand? Ten thousand?
> >
> > Let's look at the user mailing lists as an indication of
> > activity. My ACL mailbox has since 1993 ca. 1000 messages.
> > The LispWorks mailing list has almost none. SLUG has about
> > 1500. MCL has about 5500 messages.
>
> My CMUCL Mailbox counts 6824 Messages since 1994 ;-)
Implementation or Help - or both? ;-)
Rainer Joswig
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <··············@ID-22205.news.dfncis.de>, Jochen Schmidt
>> My CMUCL Mailbox counts 6824 Messages since 1994 ;-)
>
> Implementation or Help - or both? ;-)
>
> Rainer Joswig
>
My lisp folder has 4938 messages since 5/22/95. It contains both cmucl-imp
and slug mail with the vast majority of it being cmucl-imp (it looks like 3786
of them are for cmucl-imp). I guess that'd leave about 1200 for slug over that
period.
I have no idea what this is suppose to mean though.
Mike McDonald
·······@mikemac.com
Rainer Joswig <······@corporate-world.lisp.de> writes:
> > > Let's look at the user mailing lists as an indication of
> > > activity. My ACL mailbox has since 1993 ca. 1000 messages.
> > > The LispWorks mailing list has almost none. SLUG has about
> > > 1500. MCL has about 5500 messages.
> >
> > My CMUCL Mailbox counts 6824 Messages since 1994 ;-)
>
> Implementation or Help - or both? ;-)
My cmucl-help archives start around Sep 1997, and contain a total
count of 1293 messages. My cmucl-imp archives starting in Oct 1994
contain 5485 messages. Of course these numbers don't take into
account any crossposting between the two lists, which would reduce the
numbers. Note though that many advanced users post to cmucl-imp
instead of cmucl-help for their problems.
So, now that we've measured very precisely totally irrelevant
numbers, can we stop this, or do we have to write books about it?
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
<····@acm.org> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > > > Let's look at the user mailing lists as an indication of
> > > > activity. My ACL mailbox has since 1993 ca. 1000 messages.
> > > > The LispWorks mailing list has almost none. SLUG has about
> > > > 1500. MCL has about 5500 messages.
> > >
> > > My CMUCL Mailbox counts 6824 Messages since 1994 ;-)
> >
> > Implementation or Help - or both? ;-)
>
> My cmucl-help archives start around Sep 1997, and contain a total
> count of 1293 messages. My cmucl-imp archives starting in Oct 1994
> contain 5485 messages. Of course these numbers don't take into
> account any crossposting between the two lists, which would reduce the
> numbers. Note though that many advanced users post to cmucl-imp
> instead of cmucl-help for their problems.
>
> So, now that we've measured very precisely totally irrelevant
> numbers, can we stop this, or do we have to write books about it?
I don't think these numbers are irrelevant. They are one
possible indicator of activity of users of a certain
Lisp implementation. I was trying to give a feeling
that the idea of "several orders of magnitude more users"
does not correspond to "several orders of magnitude"
more activity on the mailing lists.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3snmdali5.fsf@cley.com>
* Rainer Joswig wrote:
> that the idea of "several orders of magnitude more users"
I don't really want to fight about this any more, but please note I
said `a couple', not `several'. I do appreciate this may be a
dialect-difference thing (so I'm not trying to flame you or
anything!), but to me `a couple' means quite specifically 2, or at
worst between 1 and 2, whereas `several' means more than 2 and less
than 4. Since these are exponents this makes a big difference, and to
be over-precise what I really meant was `between about 10 and about
100'.
--tim
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Rainer Joswig
> | Let's look at the user mailing lists as an indication of activity.
>
> "Newsgroup volume is a measure of discontent", I once said.
>
> But... why this incredible insistence on _counting_ people, Rainer?
>
> You seem to have been insulted by my
Erik, thanks for your effort - but I won't even read your
postings anymore. Sorry, the result of you constantly
insulting people.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> writes:
> It has nothing to do with being "fancy". GUI systems are
> everywhere.
Idiots are everywhere too. I don't think that means we should all run out
and join them.
> The few people who are still on the CLI
> or on the Emacs terminal side are just dinosaurs. ;-)
> Even the Xemacs crowd moves in the direction to
> add modern GUI functionality to XEmacs:
Not the Xemacs crowd. one guy! [OK, I see the Xemacs.org group is planning
on including it ver. 22.0. And, of course, everyone knows that 19.16 was the
last release of the REAL Xemacs. :-) ] Xemacs/GTK is just eye candy as far as
I can tell. And exactly how does "integrating" Gtk into Xemacs improve
everyone's efficiency? Does the ability to put jpegs in the background of the
scrollbars really improve your productivity?
> I'm pretty sure that most of the software actually got written
> in MCL and always synced over to ACL. Even though they used
> the same libraries on both sides and they had their
> own special Unix network.
Now MCL is a much better argument for GUI integration that Xemacs/GTK.
Mike "T Rex" McDonald
·······@mikemac.com
In article <····················@typhoon.aracnet.com>,
·······@mikemac.com wrote:
> In article <····························@news.is-europe.net>,
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > It has nothing to do with being "fancy". GUI systems are
> > everywhere.
>
> Idiots are everywhere too.
No, they aren't. This is just elite thinking.
If you look closer you'll find that Common Lisp has lost the
connection to the average programmer and his/her needs.
Common Lisp is a bit like the "emperor without clothes".
> Not the Xemacs crowd. one guy! [OK, I see the Xemacs.org group is planning
> on including it ver. 22.0. And, of course, everyone knows that 19.16 was the
> last release of the REAL Xemacs. :-) ] Xemacs/GTK is just eye candy as far as
> I can tell. And exactly how does "integrating" Gtk into Xemacs improve
> everyone's efficiency? Does the ability to put jpegs in the background of the
> scrollbars really improve your productivity?
If I have the choice between XEmacs and Emacs, I always
use XEmacs. Lucid Emacs was created, because Lucid wanted
to have a more visual Emacs to develop their IDE for
Energize in - this lead to XEmacs.
Adding a modern GUI toolkit to XEmacs
(and someone said that Gtk is quite good C quality
code), will enable the development of better
(easier to use, better looking, more direct manipulation,
more polishing of toolkit elements, widely used, ...) user
interfaces with XEmacs -> which will mean better IDEs on top
of XEmacs are possible.
>
> > I'm pretty sure that most of the software actually got written
> > in MCL and always synced over to ACL. Even though they used
> > the same libraries on both sides and they had their
> > own special Unix network.
>
> Now MCL is a much better argument for GUI integration that Xemacs/GTK.
Gtk for Xemacs is a building block.
Sent via Deja.com
http://www.deja.com/
In article <············@nnrp1.deja.com>,
······@corporate-world.lisp.de writes:
> If you look closer you'll find that Common Lisp has lost the
> connection to the average programmer and his/her needs.
Common Lisp never had a "connection" with the average programmer.
Mike McDonald
·······@mikemac.com
In article <····················@typhoon.aracnet.com>,
·······@mikemac.com wrote:
> In article <············@nnrp1.deja.com>,
> ······@corporate-world.lisp.de writes:
>
> > If you look closer you'll find that Common Lisp has lost the
> > connection to the average programmer and his/her needs.
>
> Common Lisp never had a "connection" with the average programmer.
This is another myth.
Sure it had and it should have.
Some points:
a) Common Lisp has constantly been a source of ideas and
people by diffusion and by genetic variation.
Lisp's (and Common Lisp's) genes live on Java, Smalltalk,
Lingo, Dylan, Curl, Scheme, Python, ... - you name it.
b) Common Lisp at the height of the AI time was pretty widespread.
Several Lisps are getting more CL-like and are very widespread.
The AutoCAD (AutoLisp moved on to be Visual Lisp) community
is in the millions. Emacs users are in the hundred thousands
(or more).
c) Lisp in systems like InterLisp-D and MCL proves that
you can develop usable and approachable implementations.
d) Dylan was supposed to be nothing more than a repackaged
Common Lisp for the masses.
e) The programming landscape is now ***much*** bigger than
twenty or even ten years ago. Especially when you count the amount
of people now working with software, develop software
or maintain software.
Common Lisp is in no way now more complicated than the
average C++ or Java landscape. It is actually easier.
Instead of giving away (ideas, people), the community
needs to be more selfish and to improve **their** tools.
There is no point anymore to create dumbed down
versions of it, create dumbed down new languages - we
had that already.
Use what's there and improve it. At the end of the day
it *is* KLOC, it is problems that have been solved,
it is applications that have been written, ... what counts.
And it is possible, you can compete with Visual Basic
(which *is* cool) to create applications. You just have
to do it. There is no need to stay in the ivory tower
and believe that Emacs+CL is it - it isn't ...
Sent via Deja.com
http://www.deja.com/
······@corporate-world.lisp.de <······@corporate-world.lisp.de> wrote:
>Use what's there and improve it. At the end of the day
>it *is* KLOC, it is problems that have been solved,
>it is applications that have been written, ... what counts.
>And it is possible, you can compete with Visual Basic
>(which *is* cool) to create applications. You just have
>to do it. There is no need to stay in the ivory tower
>and believe that Emacs+CL is it - it isn't ...
OK, calm down and step away from the keyboard, the men in the nice
white jackets will be comming in any minute now.
I cannot take anybody seriously who uses the words Visual Basic and cool
in the same sentence. About the best most VB advocates can honestly say
is that VB is mostly adiquate.
The only language/environment I've ever worked on that I would rank below
Visual Basic was RPG on an IBM 370 <ptui>.
And I'm not a big EMACS fan (I only use it while editing lisp code). But
not only is VB less likable that EMACS/CL, but its worse than ed/PERL!
OK, I'm done, flame away.
--
····@sierratel.com http://www.sierratel.com/dowe
---
There is a limit to how stupid people really are -- just as there's a limit
to the amount of hydrogen in the Universe. There's a lot, but there's a
limit.
--- David C. Barber
In article <···················@localhost.localdomain>,
····@krikkit.localdomain (Dowe Keller) wrote:
> ······@corporate-world.lisp.de <······@corporate-world.lisp.de> wrote:
> >Use what's there and improve it. At the end of the day
> >it *is* KLOC, it is problems that have been solved,
> >it is applications that have been written, ... what counts.
> >And it is possible, you can compete with Visual Basic
> >(which *is* cool) to create applications. You just have
> >to do it. There is no need to stay in the ivory tower
> >and believe that Emacs+CL is it - it isn't ...
> I cannot take anybody seriously who uses the words Visual Basic and cool
> in the same sentence. About the best most VB advocates can honestly say
> is that VB is mostly adiquate.
You are focusing on the technical side. What is cool and faszinating
is to see the number of users of Visual Basic and what happens
when you have literally millions of users (->programmers)
of a programming language (and a component model like in this example).
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> You are focusing on the technical side. What is cool and faszinating
> is to see the number of users of Visual Basic and what happens
> when you have literally millions of users (->programmers)
> of a programming language (and a component model like in this example).
That's not cool.
It's depressing.
--
(espen)
In article <··············@wallace.ws.nextra.no>,
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > You are focusing on the technical side. What is cool and faszinating
> > is to see the number of users of Visual Basic and what happens
> > when you have literally millions of users (->programmers)
> > of a programming language (and a component model like in this example).
>
> That's not cool.
> It's depressing.
What's depressing about a large marketplace (of components,
extensions, ...), that helps people solve their problems?
Sent via Deja.com
http://www.deja.com/
······@corporate-world.lisp.de writes:
> In article <··············@wallace.ws.nextra.no>,
> Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
> > Rainer Joswig <······@corporate-world.lisp.de> writes:
> >
> > > You are focusing on the technical side. What is cool and faszinating
> > > is to see the number of users of Visual Basic and what happens
> > > when you have literally millions of users (->programmers)
> > > of a programming language (and a component model like in this example).
> >
> > That's not cool.
> > It's depressing.
>
> What's depressing about a large marketplace (of components,
> extensions, ...), that helps people solve their problems?
- The language itself is unsuitable for producing quality
software
- Many of the extensions are low-quality
- Most of the people who end up using VB are incapable of
producing quality software
A generous view might be that VB has a niche :-)
--
Raymond Wiker
·············@fast.no
······@corporate-world.lisp.de wrote:
> In article <··············@wallace.ws.nextra.no>,
> Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
>> Rainer Joswig <······@corporate-world.lisp.de> writes:
>>
>> > You are focusing on the technical side. What is cool and faszinating
>> > is to see the number of users of Visual Basic and what happens
>> > when you have literally millions of users (->programmers)
>> > of a programming language (and a component model like in this example).
>>
>> That's not cool.
>> It's depressing.
>
> What's depressing about a large marketplace (of components,
> extensions, ...), that helps people solve their problems?
I think the real problem with VB is the same as with Windows at all.
It is the wrong way to design software for dull persons only to get a
bigger market-share. Where could we be today without the "cool" features MS
has thrown into the market?
MS' solutions and particularily their marketing-slogans let the people
think that complex systems can be made simple and usable without work and
without learning. Let's face it complex thinks ARE complex. But instead of
scaleable solutions (from simple to complex) MS offers one "simple"
solution for all problems. So most people can solve their Toy-Problems but
the people that need a bit more polished solution have to do it by
themselves.
VB is the most inconsequent language I ever have seen. The term that it is
easy to learn is pure nonsense (besides for toys).
The bitter pill is that a _huge_ mass of people have learned programming
with VB (coming mostly from Excel VBA) and use it now in production systems.
Last time I heard of a use of VB in production systems was the highspeed
CT-System developed at the "Fraunhofer Institute". I could not believe it -
It is like playing Mozart on the trompete.
Yes there are nowadays a lot more software-developers than there was some
years ago, but most of them IMHO don't deserve to be called so and the
reason are such "cool" tools like VB.
Regards,
Jochen
Jochen Schmidt wrote:
> MS' solutions and particularily their marketing-slogans let the people
> think that complex systems can be made simple and usable without work and
> without learning. Let's face it complex thinks ARE complex. But instead of
> scaleable solutions (from simple to complex) MS offers one "simple"
> solution for all problems. So most people can solve their Toy-Problems but
> the people that need a bit more polished solution have to do it by
> themselves.
To add a further point:
The most depressing fact is, that most employers don't know better than to
believe the "complex-goes-simple-by-using-MS-products" slogan and force
their employees to use inferior tools.
Regards,
Jochen
>>>>> "JS" == Jochen Schmidt <···@dataheaven.de> writes:
JS> ... But
JS> instead of scaleable solutions (from simple to complex) MS
JS> offers one "simple" solution for all problems. So most people
JS> can solve their Toy-Problems but the people that need a bit
JS> more polished solution have to do it by themselves. ...
If it were as you say, things would be just fine! At least in the US,
and as far as my experience goes, the problem is deeper and more
insidious. We have this certification and training industry basically
providing stamps of approval for people who learn, say, TCP/IP
administration from "text books" with pictures of mouse clicks! We have
various university programs (mostly called Information-<mumble>) watered
down to exclude much of the math and vendor independent programming.
People wielding such stamps of approval feel good about their proficiency,
people hiring them feel good about hiring them. People like myself, OTOH,
find their jaws dropping when they discover that highly trained and
certified admins do not understand the simplest things about protocols or
"experienced programmers" give you blank stares when told that their
"program too slow -> we need better hardware" mantra is actually caused
by their complete ignorance of anything remotely resembling big-O analysis.
I used to find "getting something to work quickly" a very useful motivator
for myself and people around me. I am now thinking maybe the ease of getting
something to work, in the absence of sane and knowledgeable authority
figures, leads to production of shit masquerading as software (*) and causes
a shift in the meaning of understanding and knowledge (consequently people
no longer expect learning to be hard and hard-to-learn things to be
worthwhile).
I have no problem whatsoever with toy languages end users use to make
their lives easier, nor do I have a problem with tools helping with
the tedium of programming. What bothers me and possibly others is
when crippled tools and toys begin to get taken seriously by virtue of
their pervasiveness and cause the professional culture to shift.
Why are we talking/ranting about this in cll?
cheers,
BM
(*) I probably didn't come up with this "shit masquerading as software"
bit myself. Did I pick it up from somebody here? Erik maybe?
Bulent Murtezaoglu wrote:
>>>>>> "JS" == Jochen Schmidt <···@dataheaven.de> writes:
> JS> ... But
> JS> instead of scaleable solutions (from simple to complex) MS
> JS> offers one "simple" solution for all problems. So most people
> JS> can solve their Toy-Problems but the people that need a bit
> JS> more polished solution have to do it by themselves. ...
>
> If it were as you say, things would be just fine! At least in the US,
> and as far as my experience goes, the problem is deeper and more
> insidious. We have this certification and training industry basically
> providing stamps of approval for people who learn, say, TCP/IP
> administration from "text books" with pictures of mouse clicks! We have
> various university programs (mostly called Information-<mumble>) watered
> down to exclude much of the math and vendor independent programming.
> People wielding such stamps of approval feel good about their proficiency,
> people hiring them feel good about hiring them. People like myself, OTOH,
> find their jaws dropping when they discover that highly trained and
> certified admins do not understand the simplest things about protocols or
> "experienced programmers" give you blank stares when told that their
> "program too slow -> we need better hardware" mantra is actually caused
> by their complete ignorance of anything remotely resembling big-O
> analysis.
This is not so much different than the situation here in Germany.
> I used to find "getting something to work quickly" a very useful motivator
> for myself and people around me. I am now thinking maybe the ease of
> getting something to work, in the absence of sane and knowledgeable
> authority figures, leads to production of shit masquerading as software
> (*) and causes a shift in the meaning of understanding and knowledge
> (consequently people no longer expect learning to be hard and
> hard-to-learn things to be worthwhile).
>
> I have no problem whatsoever with toy languages end users use to make
> their lives easier, nor do I have a problem with tools helping with
> the tedium of programming. What bothers me and possibly others is
> when crippled tools and toys begin to get taken seriously by virtue of
> their pervasiveness and cause the professional culture to shift.
I don't like terms like end-user and professionals in this topic. IMHO
there should be a continuous line from "end-user" to professional.
Today there is a _huge_ canyon between the land of end-users and the land
of "professional software developers". One reason I like Lisp is that there
is _no_ such canyon. Lisp is scaleable from console use over simple
scripting use up to complex applications. The problem is that Lisp is not
everyones thing and other people might have really good reasons to use
another language (like e. g. Scheme or Dylan ;-) ). So therefore much
effort should lied in building tools and protocols for easy language
interaction. CORBA seems to be much to complicated for the use it gains.
XMLRPC is probably to simple. If someone has tried the language REBOL - I
think this is a very good example how high-level network-capabilities could
be done.
Modern languages should easily communicate with other languages - going
over all borders including Processes, OS, Network. "Easily" means here that
easy things should be _easy_. IMHO it is time to abstract the "high-level"
Internet-Protocols like HTTP, FTP, SMTP, POP and so on. It should be as
easy to use resources over a network as it is to use local resources.
Modern Desktops like KDE2 offer this for the "end-user" - it's time to give
the same features to the "professional software developer".
> Why are we talking/ranting about this in cll?
-Because it describes the negative sides of todays software market
-Because it's a chance for alternative languages like CL to solve this
problems and so get more widespread.
-Because in cll are a lot of people with a very high grade of education
that might have good ideas to solve the problems (probably by using lisp).
I like cll but I often hear negative responses when talking on possible
tasks to get CL more widespread.
There are also a lot of people that are "talking/ranting" (as you said)
upon such topics but very few let their ideas grow into real actions.
Some people have very negative opinions on topics like "XML", "Java", "C++"
or "UNIX". I don't like some of these things too. But they are here and a
huge amount of people have chosen them to solve their problems. If we want
to increase Lisps usage we have to "communicate".
There seems to be very negative opinions on "Open Source" too:
Most hope here seems to lie in the commercial Lisps.
IMHO Lisp _will_ die out if there is no _more_ *active* community.
Now some will say "the community is too small":
This is not true: Look at the really little communities of new languages
like REBOL and what the momentum there is.
A lot of people will say that "they have no time":
Yes we all have few time. But all I want is that we try to combine our
strenghts to decide the common direction to choose and to offer the
community all code and facilities written that should not be used
commercially.
There are some people that try to do what I described above.
Particularily such efforts like CLOCC, CLiki, FreeClim, mk-defsystem...
are _very_ promising. But there is a lot of work to be done:
CLOCC really needs to be documented and cleaned up (IMHO).
I also heard from some people (I remember Rainer) that have no really good
opinions upon CLOCC at all. If there are other such people please speak out
your opinions.
CLiki needs IMHO a little bit more attention from community (as it's a
really good idea) and - sorry Daniel - a better look (To raw for my taste).
Language-Distributions like CMUCL and CLISP should be delivered optionally
with ready to start images containing things like CLOCC (particularily
CLOCC.PORT!!!!) and MK:DEFSYSTEM.
We have to work *together* not against.
Working and discussing should be _constructive_ not _destructive_.
I sometimes suppose the very complete and good CommonLisp Standard
is the real *obstacle*. A lot of people seems to fear forkings or whatever
(I dont know) so all efforts to enhance CommonLisp the Language are burned
down in the roots.
Regards,
Jochen
What are you doing? You're dragging the thread back on-topic! Stop it!
:-)
Jochen Schmidt <···@dataheaven.de> writes:
> CLiki needs IMHO a little bit more attention from community (as it's a
> really good idea) and - sorry Daniel - a better look (To raw for my taste).
Actually, "prettify CLiki" was on my TODO list for this weekend.
Unfortunately for it, it was underneath "SBCL/Alpha" and at 1am Monday
I haven't got bored of the latter yet.
But expect it to happen sometime in the next week or two, anyway. And
a search facility too (courtesy of Google)
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
From: Peter Van Eynde
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <6xwvbnq23g.fsf@lant.be>
Jochen Schmidt <···@dataheaven.de> writes:
...
> Language-Distributions like CMUCL and CLISP should be delivered optionally
> with ready to start images containing things like CLOCC (particularily
> CLOCC.PORT!!!!) and MK:DEFSYSTEM.
I'm in the final testing stage to get common-lisp-controller to
work. It just needs testing to that I avoid a disaster like the recent
lilo package for debian/testing...
It will provide a mean to shop CMUCL, sbcl, clisp with hooks, so that
they'll load mk:defsystem on startup. It will provide hooks for common
lisp source packages (like clocc) to call so that all available lisp
implementations recompile that package. In the end loading for
instance series on my machine is now as easy as typing "(require
:series)". Done.
But I expect a big fight with the other lisp hackers out there that
have problems understanding that restricting their liberty a bit can
make lisp packages easy to install for mere mortals... Cosi � la
vita...
> I sometimes suppose the very complete and good CommonLisp Standard
> is the real *obstacle*. A lot of people seems to fear forkings or whatever
> (I dont know) so all efforts to enhance CommonLisp the Language are burned
> down in the roots.
This is not true. The standard is the only thing that keeps the
community a bit together. Extending it is good and
easy. Non-conformance creates problems, even when the reasons are
semi-sound (for instance clisp, NOT acl6).
Groetjes, Peter (who changed motto to: less chatting, more hacking)
--
LANT nv/sa, Research Park Haasrode, Interleuvenlaan 15H, B-3001 Leuven
·····················@lant.be Phone: ++32 16 405140
http://www.lant.be/ Fax: ++32 16 404961
From: Peter Van Eynde
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <6xy9w3rh59.fsf@lant.be>
Jochen Schmidt <···@dataheaven.de> writes:
...
> Language-Distributions like CMUCL and CLISP should be delivered optionally
> with ready to start images containing things like CLOCC (particularily
> CLOCC.PORT!!!!) and MK:DEFSYSTEM.
I'm in the final testing stage to get common-lisp-controller to
work. It just needs testing to that I avoid a disaster like the recent
lilo package for debian/testing...
It will provide a mean to shop CMUCL, sbcl, clisp with hooks, so that
they'll load mk:defsystem on startup. It will provide hooks for common
lisp source packages (like clocc) to call so that all available lisp
implementations recompile that package. In the end loading for
instance series on my machine is now as easy as typing "(require
:series)". Done.
But I expect a big fight with the other lisp hackers out there that
have problems understanding that restricting their liberty a bit can
make lisp packages easy to install for mere mortals... Cosi � la
vita...
> I sometimes suppose the very complete and good CommonLisp Standard
> is the real *obstacle*. A lot of people seems to fear forkings or whatever
> (I dont know) so all efforts to enhance CommonLisp the Language are burned
> down in the roots.
This is not true. The standard is the only thing that keeps the
community a bit together. Extending it is good and
easy. Non-conformance creates problems, even when the reasons are
semi-sound (for instance clisp, NOT acl6).
Groetjes, Peter (who changed motto to: less chatting, more hacking)
--
LANT nv/sa, Research Park Haasrode, Interleuvenlaan 15H, B-3001 Leuven
·····················@lant.be Phone: ++32 16 405140
http://www.lant.be/ Fax: ++32 16 404961
Peter Van Eynde wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
> I'm in the final testing stage to get common-lisp-controller to
> work. It just needs testing to that I avoid a disaster like the recent
> lilo package for debian/testing...
>
> It will provide a mean to shop CMUCL, sbcl, clisp with hooks, so that
> they'll load mk:defsystem on startup. It will provide hooks for common
> lisp source packages (like clocc) to call so that all available lisp
> implementations recompile that package. In the end loading for
> instance series on my machine is now as easy as typing "(require
> :series)". Done.
This is good work! Will this package support other platforms than UNIX too?
(on CLISP?). It's not that I use other platforms but I think such an effort
can only be really successful if it is nearly globally available.
> But I expect a big fight with the other lisp hackers out there that
> have problems understanding that restricting their liberty a bit can
> make lisp packages easy to install for mere mortals... Cosi � la
> vita...
We theoretically would not need this other lisp-hackers but I agree that it
would be a lot easier if we are working together.
> Groetjes, Peter (who changed motto to: less chatting, more hacking)
Good motto - but I think it would be better to chat first on some topics ;-)
--
http://www.dataheaven.de
From: Peter Van Eynde
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <6xg0iaocuu.fsf@lant.be>
Jochen Schmidt <···@dataheaven.de> writes:
> > It will provide a mean to shop CMUCL, sbcl, clisp with hooks, so that
> > they'll load mk:defsystem on startup. It will provide hooks for common
> > lisp source packages (like clocc) to call so that all available lisp
> > implementations recompile that package. In the end loading for
> > instance series on my machine is now as easy as typing "(require
> > :series)". Done.
>
> This is good work! Will this package support other platforms than UNIX too?
It shouldn't be a problem, as the spec mandates using logical
pathnames, so it should all be protable. Actually using unix poses a
problem: you want to have the fasl's in a a public space (/usr/lib/) so they
need to be owned by root, but I don't want the compiler to run as
root. So at the moment I'm doing a lot of tricks to run the
compilation as nobody and then quickly re-chown the resulting files to
root.
I'm certain I'm breaking some debian guideline here, but I see no
other way...
> (on CLISP?). It's not that I use other platforms but I think such an effort
> can only be really successful if it is nearly globally available.
*nod* clisp, acl and lwl should follow. At the moment I'm just
concentrating on getting it to work, at least for CMUCL. But the basic
setup has no CMUCL-specific code (except bug-fixes).
> > Groetjes, Peter (who changed motto to: less chatting, more hacking)
>
> Good motto - but I think it would be better to chat first on some topics ;-)
I've been on the Lisp-OS mailing list... enough said.
Groetjes, Peter
--
LANT nv/sa, Research Park Haasrode, Interleuvenlaan 15H, B-3001 Leuven
·····················@lant.be Phone: ++32 16 405140
http://www.lant.be/ Fax: ++32 16 404961
In article <··············@lant.be>, Peter Van Eynde <·····@lant.be>
wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
> > > It will provide a mean to shop CMUCL, sbcl, clisp with hooks, so that
> > > they'll load mk:defsystem on startup. It will provide hooks for common
> > > lisp source packages (like clocc) to call so that all available lisp
> > > implementations recompile that package. In the end loading for
> > > instance series on my machine is now as easy as typing "(require
> > > :series)". Done.
> >
> > This is good work! Will this package support other platforms than UNIX too?
>
> It shouldn't be a problem, as the spec mandates using logical
> pathnames, so it should all be protable. Actually using unix poses a
> problem: you want to have the fasl's in a a public space (/usr/lib/)
Really? I don't think that is a good idea.
Would you create subdirectories if fasl-files have
conflicting names? Or rename the files?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <··············@lant.be>, Peter Van Eynde <·····@lant.be>
> wrote:
>
> > It shouldn't be a problem, as the spec mandates using logical
> > pathnames, so it should all be protable. Actually using unix poses a
> > problem: you want to have the fasl's in a a public space (/usr/lib/)
>
> Really? I don't think that is a good idea.
> Would you create subdirectories if fasl-files have
> conflicting names? Or rename the files?
I believe that the idea is that each (implementation,package) pair
gets its own space to scribble on (so, yes, and not just if fasl-files
have conflicting names).
There's an entry in cliki for Peter's design document.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
(FORMAT T "(·@{~w ········@{~w~^ ~})" 'FORMAT T "(·@{~w ········@{~w~^ ~})")
Peter Van Eynde <·····@lant.be> writes:
> Jochen Schmidt <···@dataheaven.de> writes:
>
> > > It will provide a mean to shop CMUCL, sbcl, clisp with hooks, so
> > > that they'll load mk:defsystem on startup. It will provide hooks
> > > for common lisp source packages (like clocc) to call so that all
> > > available lisp implementations recompile that package. In the
> > > end loading for instance series on my machine is now as easy as
> > > typing "(require :series)". Done.
> >
> > This is good work! Will this package support other platforms than
> > UNIX too?
>
> It shouldn't be a problem, as the spec mandates using logical
> pathnames, so it should all be protable. Actually using unix poses a
> problem: you want to have the fasl's in a a public space (/usr/lib/)
> so they need to be owned by root, but I don't want the compiler to
> run as root. So at the moment I'm doing a lot of tricks to run the
> compilation as nobody and then quickly re-chown the resulting files
> to root.
The choice of /usr/lib is not a good one for other unixalikes
(actually, I don't think it's a good choice for Linux either, but it
seems to be the standard there). Would it be possible to have a
different prefix for (e.g) FreeBSD (/usr/local instead of /usr)?
> I'm certain I'm breaking some debian guideline here, but I see no
> other way...
You're certainly breaking FreeBSD guidelines :-)
> > (on CLISP?). It's not that I use other platforms but I think such
> > an effort can only be really successful if it is nearly globally
> > available.
>
> *nod* clisp, acl and lwl should follow. At the moment I'm just
> concentrating on getting it to work, at least for CMUCL. But the basic
> setup has no CMUCL-specific code (except bug-fixes).
Should be easy to put in support for SBCL, then?
--
Raymond Wiker
·············@fast.no
From: Peter Van Eynde
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <6xpuhemolr.fsf@lant.be>
Raymond Wiker <·············@fast.no> writes:
> > It shouldn't be a problem, as the spec mandates using logical
> > pathnames, so it should all be protable. Actually using unix poses a
> > problem: you want to have the fasl's in a a public space (/usr/lib/)
> > so they need to be owned by root, but I don't want the compiler to
> > run as root. So at the moment I'm doing a lot of tricks to run the
> > compilation as nobody and then quickly re-chown the resulting files
> > to root.
>
> The choice of /usr/lib is not a good one for other unixalikes
> (actually, I don't think it's a good choice for Linux either, but it
> seems to be the standard there). Would it be possible to have a
> different prefix for (e.g) FreeBSD (/usr/local instead of /usr)?
The FHS requires me to put it into /usr/lib, but as all of this is
regulated by logical-pathnames you can actually place it almost
anywhere. You only have to change the implementation-side support and
the glue a bit. The packages itself should only use the logical
pathname, and so should not notice the change.
Also more advanced hackers can use this to have their own local copy
of a package in their homedirectory...
> > I'm certain I'm breaking some debian guideline here, but I see no
> > other way...
>
> You're certainly breaking FreeBSD guidelines :-)
/usr/local is only for software that is not part of the
distribution. As the packages are a part of the distribution they have
to go into
/usr/share/lib/common-lisp/
for the sources and other portable stuff, and
/usr/lib/common-lisp/
for the compiled fasls and other machine-specific information.
Caches etc should go into /var, but there has been no need for this
yet...
> > *nod* clisp, acl and lwl should follow. At the moment I'm just
> > concentrating on getting it to work, at least for CMUCL. But the basic
> > setup has no CMUCL-specific code (except bug-fixes).
>
> Should be easy to put in support for SBCL, then?
Except for a small problem with logical pathnames it worked last
time...
Groetjes, Peter
--
LANT nv/sa, Research Park Haasrode, Interleuvenlaan 15H, B-3001 Leuven
·····················@lant.be Phone: ++32 16 405140
http://www.lant.be/ Fax: ++32 16 404961
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3ae8halsr.fsf@cley.com>
* Raymond Wiker wrote:
> Peter Van Eynde <·····@lant.be> writes:
> The choice of /usr/lib is not a good one for other unixalikes
> (actually, I don't think it's a good choice for Linux either, but it
> seems to be the standard there). Would it be possible to have a
> different prefix for (e.g) FreeBSD (/usr/local instead of /usr)?
Yes, it should definitely be controlled by a prefix. It would be a
catastrophe for us and many other people if we had any significant
non-OS software in /usr/lib because we couldn't do upgrades then or
share it among machines.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Raymond Wiker wrote:
> > Peter Van Eynde <·····@lant.be> writes:
>
> > The choice of /usr/lib is not a good one for other unixalikes
> > (actually, I don't think it's a good choice for Linux either, but it
> > seems to be the standard there). Would it be possible to have a
> > different prefix for (e.g) FreeBSD (/usr/local instead of /usr)?
>
> Yes, it should definitely be controlled by a prefix. It would be a
> catastrophe for us and many other people if we had any significant
> non-OS software in /usr/lib because we couldn't do upgrades then or
> share it among machines.
I do not want to start a 'configuration' war, less than so with Peter,
but the CL-CONFIGURATION package (in the CLOCC), though needing
polishing, is built upon the idea that you give multiple prefixes
which have "standardized" defaults. :)
http://sourceforge.net/projects/clocc
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
From: Peter Van Eynde
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <6x1yttj83r.fsf@lant.be>
Marco Antoniotti <·······@cs.nyu.edu> writes:
> I do not want to start a 'configuration' war, less than so with Peter,
> but the CL-CONFIGURATION package (in the CLOCC), though needing
> polishing, is built upon the idea that you give multiple prefixes
> which have "standardized" defaults. :)
I looked at it (briefly I must admit), but the problem you where
trying to solve is another I think. I just wanted to get the system
working with the least amount of source involved, so that the number
of things that go wrong was limited. The stuff just has to bootstrap
a minimal functionality, just enough to find and load systems, that's
all.
Adding stuff from clocc is next on my agenda, and CL-CONFIGURATION
could/should offer a superset of the basic support given by
common-lisp-controller.
Groetjes, Peter
--
LANT nv/sa, Research Park Haasrode, Interleuvenlaan 15H, B-3001 Leuven
·····················@lant.be Phone: ++32 16 405140
http://www.lant.be/ Fax: ++32 16 404961
On Sun, 21 Jan 2001 20:57:28 +0100, Jochen Schmidt <···@dataheaven.de>
wrote:
> easy things should be _easy_. IMHO it is time to abstract the "high-level"
> Internet-Protocols like HTTP, FTP, SMTP, POP and so on. It should be as
> easy to use resources over a network as it is to use local resources.
If I understand correctly what I read in the past concerning Symbolics Lisp
Machines, Genera provided network-transparent resource access several years
ago.
> CLiki needs IMHO a little bit more attention from community (as it's a
> really good idea) and - sorry Daniel - a better look (To raw for my taste).
Have you used a modem lately? :) The CLiki pages can be accessed and
navigated quickly even with a modem, and I am personally happy with the
current CLiki look. What do you mean by "a better look"?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paolo Amoroso wrote:
> On Sun, 21 Jan 2001 20:57:28 +0100, Jochen Schmidt <···@dataheaven.de>
> wrote:
>
>> easy things should be _easy_. IMHO it is time to abstract the
>> "high-level" Internet-Protocols like HTTP, FTP, SMTP, POP and so on. It
>> should be as easy to use resources over a network as it is to use local
>> resources.
>
> If I understand correctly what I read in the past concerning Symbolics
> Lisp Machines, Genera provided network-transparent resource access several
> years ago.
I do not know very much about LispMs at all and never have used one. There
might be some really good insights here - has someone more info on this
topic?
>> CLiki needs IMHO a little bit more attention from community (as it's a
>> really good idea) and - sorry Daniel - a better look (To raw for my
>> taste).
>
> Have you used a modem lately? :) The CLiki pages can be accessed and
> navigated quickly even with a modem, and I am personally happy with the
> current CLiki look. What do you mean by "a better look"?
My critic should not say that the CLiki pages look "ugly" or so. My point
was that CLiki simply doesn't try to give the casual reader some eyecandy.
You're right that this approach has it's advantages.
On the other side I think it is not so important for CLiki to be amazingly
fast used over a modem-line. IMHO nowadays there should be enough bandwidth
so that CLiki could use a look like e. g. Freshmeat, Slashdot & Co.
IMHO CLiki should have it's own individual look, a little bit more color,
maybe some images and all that is small enough to cope with and nice enough
to hold the viewers look long enough.
This would lead to a "more complete" or "more professionally looking" site.
The reason why I think this is important is that I think CLiki will be a
central point in Lisp-Comunity that could and would be _one_ first place to
look for a newby.
Regards,
Jochen
On Wed, 24 Jan 2001 01:43:48 +0100, Jochen Schmidt <···@dataheaven.de>
wrote:
> I do not know very much about LispMs at all and never have used one. There
> might be some really good insights here - has someone more info on this
> topic?
This is a good starting point for information on Lisp Machines:
http://fare.tunes.org/LispM.html
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3puhc8tku.fsf@cley.com>
* Jochen Schmidt wrote:
> My critic should not say that the CLiki pages look "ugly" or so. My point
> was that CLiki simply doesn't try to give the casual reader some eyecandy.
> You're right that this approach has it's advantages.
> On the other side I think it is not so important for CLiki to be amazingly
> fast used over a modem-line. IMHO nowadays there should be enough bandwidth
> so that CLiki could use a look like e. g. Freshmeat, Slashdot & Co.
> IMHO CLiki should have it's own individual look, a little bit more color,
> maybe some images and all that is small enough to cope with and nice enough
> to hold the viewers look long enough.
> This would lead to a "more complete" or "more professionally looking" site.
> The reason why I think this is important is that I think CLiki will be a
> central point in Lisp-Comunity that could and would be _one_ first place to
> look for a newby.
I'm quoting this in full really so I can say I disagree with every
part of it. Better navigation features are definitely interesting,
eyecandy please, no. I realise this puts me in some kind of tiny
self-selected pretentious elite who everyone else can now happily
despise.
--tim (who reads slashdot in the low-bandwidth mode)
TimB> .... Better navigation features are definitely
TimB> interesting, eyecandy please, no. I realise this puts me in
TimB> some kind of tiny self-selected pretentious elite who
TimB> everyone else can now happily despise.
I agree with you wholeheartedly. (and I don't think it was Pierre's
intention to create a kind of PC-ness in cll wrt quoting, so I snipped
the original posting).
TimB> --tim (who reads slashdot in the low-bandwidth mode)
I think in a few years I'll need medication before I can read /. I
used to follow freshmeat through their nntp server. Can't use nntp for
wikis though.
cheers,
BM
"Bulent Murtezaoglu" <··@acm.org> wrote in message
···················@kapi.internal...
> >>>>> "JS" == Jochen Schmidt <···@dataheaven.de> writes:
and as far as my experience goes, the problem is deeper and more
> insidious. We have this certification and training industry basically
> providing stamps of approval for people who learn, say, TCP/IP
> administration from "text books" with pictures of mouse clicks! We have
> various university programs (mostly called Information-<mumble>) watered
Deleted for brevaty>>>>>
> by their complete ignorance of anything remotely resembling big-O
analysis.
Not true anyone earning any certificate for a Microsoft product must have,
an instinct for obfuscation analysis ;-)
> I used to find "getting something to work quickly" a very useful motivator
> for myself and people around me. I am now thinking maybe the ease of
getting
> something to work, in the absence of sane and knowledgeable authority
> figures, leads to production of shit masquerading as software (*) and
causes
> a shift in the meaning of understanding and knowledge (consequently people
> no longer expect learning to be hard and hard-to-learn things to be
> worthwhile).
>
> I have no problem whatsoever with toy languages end users use to make
> their lives easier, nor do I have a problem with tools helping with
> the tedium of programming. What bothers me and possibly others is
> when crippled tools and toys begin to get taken seriously by virtue of
> their pervasiveness and cause the professional culture to shift.
>
> Why are we talking/ranting about this in cll?
>
> cheers,
>
> BM
>
> (*) I probably didn't come up with this "shit masquerading as software"
> bit myself. Did I pick it up from somebody here? Erik maybe?
······@corporate-world.lisp.de writes:
> > That's not cool.
> > It's depressing.
>
> What's depressing about a large marketplace (of components,
> extensions, ...), that helps people solve their problems?
That's not depressing, it's that it had to be *VB* that is depressing.
(Just like the domination of Word (especially post 1995) is depressing,
because it's really neither causual-user-friendly nor suitable for
serious tasks)
Otherwise, I think that some of the IDE complaints here must come from
people that never tried MCL. One of the interesting things about MCL
is the splendid way in which it brings in advantages from several worlds,
it takes elements from IDEs, the Mac interface and Emacs and makes a
wonderful blend of it!
--
(espen)
On 24 Jan 2001 11:15:13 +0100, Espen Vestre
<·····@*do-not-spam-me*.vestre.net> wrote:
> people that never tried MCL. One of the interesting things about MCL
> is the splendid way in which it brings in advantages from several worlds,
> it takes elements from IDEs, the Mac interface and Emacs and makes a
> wonderful blend of it!
Incidentally, the Digitool site contains very few screen shots--if any. The
only ones I have seen were from links posted here by MCL users.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: David Combs
Subject: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <95dcua$sn3$1@news.panix.com>
In article <····························@4ax.com>,
Paolo Amoroso <·······@mclink.it> wrote:
>On 24 Jan 2001 11:15:13 +0100, Espen Vestre
><·····@*do-not-spam-me*.vestre.net> wrote:
>
>> people that never tried MCL. One of the interesting things about MCL
>> is the splendid way in which it brings in advantages from several worlds,
>> it takes elements from IDEs, the Mac interface and Emacs and makes a
>> wonderful blend of it!
>
>Incidentally, the Digitool site contains very few screen shots--if any. The
>only ones I have seen were from links posted here by MCL users.
To this ignorant lurker, please, what *is* MCL?
Thanks
David
In article <············@news.panix.com>,
·······@panix.com (David Combs) writes:
> To this ignorant lurker, please, what *is* MCL?
Mac Common Lisp (as in Apple Macs).
Mike McDonald
·······@mikemac.com
From: Xah Lee
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <B6A03624.55AB%xah@xahlee.org>
> To this ignorant lurker, please, what *is* MCL?
As a result of progress, you no longer needs to take a trip to library to
get dopes.
here's a few suggestion of resources:
google.com
m-w.com
britanica.com
www.foldoc.org
When reading newsgroups, for example, one might often have the question
"what the fuck is he talking about?". You can start a fruitful research
forthwith and speak with confidence. And if you know your stuff, you might
come back with "shuda fuck up", for the benefit of mankind and womankind.
This doesn't just apply to a term or word you don't understand. But to facts
and ideas as well. Your research time will be proportional to the difficulty
of the question, anywhere from few seconds to till you lost interest. And,
if your knowledge runs high, you can not only tell newsgroup slackers to
"shuda fuck up", but also to writers and publishers of all sorts. When you
are a pro at these things, we have a term for it: critics. (now, lookup that
word right now!)
Search the web might seem a trivial thing to mention in a grand way. Many
computing geeks take it for granted. Though, most of us don't realize that
the ability to find vast mount of knowledge instantaneously is possible only
in the last couple of years. This is progress, a progress that is more than
a leap to the moon. As an illustration, in a few months a bright college
student can do the research work on unix history more accurate and broad
than years of effort by professional historians doing unix history research
in the early 90s. *Exchange* of goods is the propeller of finance in
society. Exchange of information is the propeller of human progress. The
internet, facilitates this a myriad-fold.
Let's take a moment to thank the Internet, and the computing geeks like
ourselves that made it possible.
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
> From: ·······@panix.com (David Combs)
> Organization: Public Access Networks Corp.
> Newsgroups: comp.lang.lisp
> Date: 2 Feb 2001 04:26:50 GMT
> Subject: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
From: Martin Cracauer
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <95duu4$gco$1@counter.bik-gmbh.de>
·······@panix.com (David Combs) writes:
>In article <····························@4ax.com>,
>Paolo Amoroso <·······@mclink.it> wrote:
>>On 24 Jan 2001 11:15:13 +0100, Espen Vestre
>><·····@*do-not-spam-me*.vestre.net> wrote:
>>
>>> people that never tried MCL. One of the interesting things about MCL
>>> is the splendid way in which it brings in advantages from several worlds,
>>> it takes elements from IDEs, the Mac interface and Emacs and makes a
>>> wonderful blend of it!
>>
>>Incidentally, the Digitool site contains very few screen shots--if any. The
>>only ones I have seen were from links posted here by MCL users.
>To this ignorant lurker, please, what *is* MCL?
A Common Lisp implementation for Macintosh. Many say it has the
nicest development environment around. Another strength is the sheer
number of existing interfaces to C APIs. Never used it personally,
though, my 68030 Mac doesn't really cut it anymore :-(
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> ·······@panix.com (David Combs) writes:
>
> >In article <····························@4ax.com>,
> >Paolo Amoroso <·······@mclink.it> wrote:
> >>On 24 Jan 2001 11:15:13 +0100, Espen Vestre
> >><·····@*do-not-spam-me*.vestre.net> wrote:
> >>
> >>> people that never tried MCL. One of the interesting things about MCL
> >>> is the splendid way in which it brings in advantages from several worlds,
> >>> it takes elements from IDEs, the Mac interface and Emacs and makes a
> >>> wonderful blend of it!
> >>
> >>Incidentally, the Digitool site contains very few screen shots--if any. The
> >>only ones I have seen were from links posted here by MCL users.
>
> >To this ignorant lurker, please, what *is* MCL?
>
> A Common Lisp implementation for Macintosh. Many say it has the
> nicest development environment around. Another strength is the sheer
> number of existing interfaces to C APIs. Never used it personally,
> though, my 68030 Mac doesn't really cut it anymore :-(
It is made by Digitool (www.digitool.com). The environment was
beautiful in 1990. Better than the MS stuff of today.
Cheers
--
Marco Antoniotti =============================================================
NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
On 2 Feb 2001 04:26:50 GMT, ·······@panix.com (David Combs) wrote:
> In article <····························@4ax.com>,
> Paolo Amoroso <·······@mclink.it> wrote:
[...]
> >Incidentally, the Digitool site contains very few screen shots--if any. The
> >only ones I have seen were from links posted here by MCL users.
>
> To this ignorant lurker, please, what *is* MCL?
MCL is Macintosh Common Lisp by Digitool:
http://www.digitool.com/
To correct what I said in the message you quoted, the Digitool site does
include screen shots. They are in the introductory tutorial.
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
From: David Combs
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <95i85s$623$1@news.panix.com>
>On 2 Feb 2001 04:26:50 GMT, ·······@panix.com (David Combs) wrote:
>
>> To this ignorant lurker, please, what *is* MCL?
>
Thanks!
I will say that I am a bit surprosed that any *lisp* user
would use an apple.
Just shows how little I know :-)
Computers being cheap enough these days, I guess
you simply buy the computer that allows the software
that you want to use.
---
*Why* is there nothing as good under unix (or even
under M$)?
David
In article <············@news.panix.com>,
·······@panix.com (David Combs) writes:
>>On 2 Feb 2001 04:26:50 GMT, ·······@panix.com (David Combs) wrote:
>>
>>> To this ignorant lurker, please, what *is* MCL?
>>
>
> Thanks!
>
> I will say that I am a bit surprosed that any *lisp* user
> would use an apple.
Why do you think that?
Mike McDonald
·······@mikemac.com
From: Martin Cracauer
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <95lnkk$e3t$1@counter.bik-gmbh.de>
·······@panix.com (David Combs) writes:
>I will say that I am a bit surprosed that any *lisp* user
>would use an apple.
[...]
>*Why* is there nothing as good under unix (or even
>under M$)?
Lispworks and Allegro do not have as nice Interfaces and not as much
Interfaces to native APIs, but the have other advantages, especially
with regards to the compiler, so I wouldn't offhand dismiss them as
worse.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
From: David Thornley
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <tDEg6.402$a7.14194@ruti.visi.com>
In article <············@counter.bik-gmbh.de>,
Martin Cracauer <········@counter.bik-gmbh.de> wrote:
>·······@panix.com (David Combs) writes:
>
>>I will say that I am a bit surprosed that any *lisp* user
>>would use an apple.
>
>[...]
>
I have no idea either.
I don't see anything inherently lispy about the other popular
OSs (Windows and Unix), so I'd think that a lisp user would
work on a platform with a good Common Lisp implementation.
You know, like a Mac or a Sun or a Linux box or a Windows
machine.
If there were no good CL implementations on Macintoshes, then
obviously CL people would tend to avoid it, but there is.
>>*Why* is there nothing as good under unix (or even
>>under M$)?
>
>Lispworks and Allegro do not have as nice Interfaces and not as much
>Interfaces to native APIs, but the have other advantages, especially
>with regards to the compiler, so I wouldn't offhand dismiss them as
>worse.
>
Partly that's the nature of the Mac. Apple put a lot more money
and effort into human factors than anybody else, and so it should
be no surprise when the Mac interface is superior to others.
There's also an expectation of what a Mac programming language
should be, including access to all the Mac Toolbox routines.
It may be that Digitool was able to design a more coherent
product by going Mac-only. Lispworks and Allegro are
multi-platform, and may suffer slightly in some ways from
that.
It's also true that Digitool has done a very good job.
MCL isn't the One True Lisp, but it's a very nice one, and I
find it very comfortable. I have less experience with Allegro,
and none with Lispworks, so I can't compare it properly.
However, anybody who wants to buy a computer to hack Lisp could
do a whole lot worse than an iMac and Macintosh Common Lisp.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
From: Dave Seaman
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <96152r$m0l@seaman.cc.purdue.edu>
In article <··················@ruti.visi.com>,
David Thornley <········@visi.com> wrote:
>In article <············@counter.bik-gmbh.de>,
>Martin Cracauer <········@counter.bik-gmbh.de> wrote:
>>·······@panix.com (David Combs) writes:
>>>I will say that I am a bit surprosed that any *lisp* user
>>>would use an apple.
>>[...]
>I have no idea either.
>I don't see anything inherently lispy about the other popular
>OSs (Windows and Unix), so I'd think that a lisp user would
>work on a platform with a good Common Lisp implementation.
>You know, like a Mac or a Sun or a Linux box or a Windows
>machine.
MCL offers easy access to the MacOS Toolbox routines, using CLOS with
built-in classes to represent the windows, dialog items, menus and such
that are a part of the Mac GUI. It's a natural fit.
>Partly that's the nature of the Mac. Apple put a lot more money
>and effort into human factors than anybody else, and so it should
>be no surprise when the Mac interface is superior to others.
>There's also an expectation of what a Mac programming language
>should be, including access to all the Mac Toolbox routines.
>It may be that Digitool was able to design a more coherent
>product by going Mac-only. Lispworks and Allegro are
>multi-platform, and may suffer slightly in some ways from
>that.
Digitool is a comparative latecomer. The product that is now called MCL
was once "Coral Common Lisp" (CCL) and then "Allegro Comman Lisp" (ACL).
Then Apple took over the development effort and renamed it "Macintosh
Allegro Common Lisp" (MACL) and then MCL. Digitool took over from Apple
and did a fine job migrating the product to the PowerPC platform.
The "Coral Common Lisp" connection still exists in two ways:
(1) The icon for MCL and its program files contains a
representation of a piece of coral.
(2) The :ccl package is where Mac-specific functions and data
types (such as the GUI elements) are defined in MCL.
>It's also true that Digitool has done a very good job.
>MCL isn't the One True Lisp, but it's a very nice one, and I
>find it very comfortable. I have less experience with Allegro,
>and none with Lispworks, so I can't compare it properly.
>However, anybody who wants to buy a computer to hack Lisp could
>do a whole lot worse than an iMac and Macintosh Common Lisp.
If you want to write GUI-driven programs, I know of know platform or
programming language that makes it any easier than MCL.
--
Dave Seaman ·······@purdue.edu
Amnesty International calls for new trial for Mumia Abu-Jamal
<http://www.amnestyusa.org/abolish/reports/mumia/>
From: Christopher C Stacy
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <x8lofwbe33g.fsf@world.std.com>
When Lisp was a popular bandwagon thing, the Macintosh was the most
sophisticated personal computer (the other alternative being MS-DOS).
Engineers and academicians were much more likely to have a Mac rather
than an "IBM" or "IBM clone". MIT and Stanford relatde hackers personally
owned Macs, not DOS machines. The user-centric and innovative style
of the Macintosh was and is philosophically attractive to most Lisp hackers.
That historical perspective is the reason that the Mac was targeted as
a good platform for Lisp. As the PC grew up the marketing pitch was
that it was a "serious business" computer, and that the Mac was a toy
or kid's computer. And as PCs caught on more, and were lower in cost
than the Mac line, Lisp vendors strategically targetted the PC.
In the late 80s and early 90s, even Symbolics focused its embedded
Lisp Machine strategy on the Macintosh, rather than on the PC.
The MacIvory could offer you the Symbolics Genera development system,
as well as application delivery, including integration with Macintosh
applications. On the other hand, all that you could do on a Windows
machine was to deliver (slightly limited) applications using a cross-compiler.
Symbolics knew that Lisp hackers were more likely to favor the Macintosh
above the PC, and with good reason.
Since then, of course, the PC has become the standard platform in the
world, and with the advent of Windows NT the technical tables are also
turned towards the PC. Who would make serious use of an operating
system that doesn't have preemptive multitasking and protected virtual
memory? But despite that, it turns out that MCL is a first-class high
quality Lisp development environment, with excellent user-interface
and external calling; people even deploy MCL applications and servers.
When the new Mac OS is released, it will probably be even better.
You can see how it's no surprise that a "Lisp user would use an Apple".
For much of the relevent historical period, it was a superior platform,
and it continues to rival the capabilities of the Wintel world.
In article <···············@world.std.com>, Christopher C Stacy
<······@world.std.com> wrote:
> When Lisp was a popular bandwagon thing, the Macintosh was the most
> sophisticated personal computer (the other alternative being MS-DOS).
> Engineers and academicians were much more likely to have a Mac rather
> than an "IBM" or "IBM clone". MIT and Stanford relatde hackers personally
> owned Macs, not DOS machines. The user-centric and innovative style
> of the Macintosh was and is philosophically attractive to most Lisp hackers.
> That historical perspective is the reason that the Mac was targeted as
> a good platform for Lisp. As the PC grew up the marketing pitch was
> that it was a "serious business" computer, and that the Mac was a toy
> or kid's computer. And as PCs caught on more, and were lower in cost
> than the Mac line, Lisp vendors strategically targetted the PC.
Some other Lisps in the history of the Macintosh:
- MacScheme
- ExperLisp
- Exper Common Lisp
- Procyon Common Lisp (whose Windows version was later taken over by Franz)
- Apple Dylan (the prefix syntax one)
Also one should keep in mind that Apple's (now defunct) Advanced Technology
Group had quite a lot Lisp hackers (like Dave Moon).
> In the late 80s and early 90s, even Symbolics focused its embedded
> Lisp Machine strategy on the Macintosh, rather than on the PC.
> The MacIvory could offer you the Symbolics Genera development system,
> as well as application delivery, including integration with Macintosh
> applications. On the other hand, all that you could do on a Windows
> machine was to deliver (slightly limited) applications using a cross-compiler.
> Symbolics knew that Lisp hackers were more likely to favor the Macintosh
> above the PC, and with good reason.
Other Lisp machine boards for the Nubus Mac:
- TI MicroExplorer (a competitor to the Symbolics MacIvory)
- MacElis (a japanese system)
> Since then, of course, the PC has become the standard platform in the
> world, and with the advent of Windows NT the technical tables are also
> turned towards the PC. Who would make serious use of an operating
> system that doesn't have preemptive multitasking and protected virtual
> memory? But despite that, it turns out that MCL is a first-class high
> quality Lisp development environment, with excellent user-interface
> and external calling; people even deploy MCL applications and servers.
> When the new Mac OS is released, it will probably be even better.
>
> You can see how it's no surprise that a "Lisp user would use an Apple".
> For much of the relevent historical period, it was a superior platform,
> and it continues to rival the capabilities of the Wintel world.
If you ask me, a Cube or one of the new 733Mhz G4 Macs plus
the 22" Cinema Display (LCD) plus lots of RAM is still the sexiest
platform to run Lisp on.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
From: Xah Lee
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <B6AA6247.58C0%xah@xahlee.org>
* Christopher C Stacy <······@world.std.com>
>> You can see how it's no surprise that a "Lisp user would use an Apple".
>> For much of the relevent historical period, it was a superior platform,
>> and it continues to rival the capabilities of the Wintel world.
Erik Naggum wrote:
> How does the Lisa fit this story?
don't know the answer to you question exactly, but...
if you are not a dedicated Apple fan, you may not know this site:
http://www.apple-history.com/history.html
(which includes a page on Lisa)
For early history of Steve Jobs, I recommend this book:
Steve Jobs and the NeXT big thing by Randall E. Stross. 1993.
http://www.amazon.com/exec/obidos/ASIN/0689121350/103-0736217-4683845
I'm much of an Apple fan around the NeXT period. Since about 1995, Apple
everything is going downhill.
Apple hardware made a come back since Steve Jobs came onboard around 1997
with the birth of colorful computers iMac, and a sequence of fantastic
hardware innovations. Tough, i'm not so sure about software. Many geeks are
giddy with the upcoming Mac OS X, but in my opinion, Mac OS X looks like to
me one giant pretty unusable pretty fuck pretty up. I don't know for sure,
but I think Windows 2000 is technically superior in most aspects...
Xah
···@xahlee.org
http://xahlee.org/PageTwo_dir/more.html
> From: Erik Naggum <····@naggum.net>
> Organization: Naggum Software, Oslo, Norway
> Newsgroups: comp.lang.lisp
> Date: 10 Feb 2001 02:06:16 +0000
> Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
From: Rahul Jain
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <963gc8$op8$1@joe.rice.edu>
In article <················@naggum.net> on <················@naggum.net>,
"Erik Naggum" <····@naggum.net> wrote:
> How does the Lisa fit this story? All I know about it is what a
> friend of a friend who spent a sizable fraction of his college fund to
> get one told me, and he was just _raving_ about it, ecstatically. It
> seemed like one of those "too good to be true" and "eons before its
> time" things that would just _have_ to be crushed by the hype and the
> lies from Redmond.
From what I understand, the technology of that day just wasn't powerful
enough that Apple could both provide an OS that had preemptive
multitasking, protected virtual memory, etc, yet still be affordable to
their target market. The Mac was expensive enough, and the Lisa was
even higher priced, and it just didn't fit into their business plan to
market such a product.
--
-> -/- - Rahul Jain - -\- <-
-> -\- http://linux.rice.edu/~rahul -=- ·················@usa.net -/- <-
-> -/- "I never could get the hang of Thursdays." - HHGTTG by DNA -\- <-
|--|--------|--------------|----|-------------|------|---------|-----|-|
Version 11.423.999.220020101.23.50110101.042
(c)1996-2000, All rights reserved. Disclaimer available upon request.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> How does the Lisa fit this story? All I know about it is what a friend
> of a friend who spent a sizable fraction of his college fund to get one
> told me, and he was just _raving_ about it, ecstatically. It seemed
> like one of those "too good to be true" and "eons before its time" things
> that would just _have_ to be crushed by the hype and the lies from Redmond.
Very interesting question.
My first "Mac" was a Lisa, because when the Mac first came out you had
to have a Lisa to program it. It was in almost every way superior to the
Mac of the day: it had protected virtual memory, a hard drive,
preemptive multitasking, document stationery, etc. But it was way more
expensive. In some ways, the Lisa is _still_ superior to current Macs,
and this will only finally be remedied by Mac OS X.
http://www.dimensional.com/~djoew/lisa/lisa-retro.html
The Lisa was definitely ahead of its time. But it died because it was
slow and too expensive. Redmond would certainly try to kill something
that innovative today, but in those days Microsoft didn't even have
enough clout to keep Bill out of jail, like they do today :-)
http://TheSmokingGun.com/archive/gatesmug.shtml
AFAIK, there was no Lisp product available for the Lisa. There were very
few third-party software packages available for it at all--it didn't
live long enough. (It could run Mac software in compatibility mode, and
in that sense, you could "run" a Lisp on it if you really wanted to.)
The question is interesting for another reason. The chief instigator of
the Dylan project was Apple's Chief Scientist, Larry Tesler, who is
well-known as one of the designers of the Smalltalk environment. Dylan
was intended to be a "lightweight" Common Lisp for the Newton, among
other projects. And the reason Apple got involved with Coral Software
and developed Coral Common Lisp (CCL) into MACL was mainly that MACL was
an enabling technology for creating Dylan. (The first version of Dylan
was written in MACL, and the Wood object-oriented database, which still
ships with MCL, was written to enable the Dylan development environment.)
http://www.beanpaste.com/tree/dylan/prefix-dylan/book.annotated/foreword.
html
Later, Tesler decided that Dylan was "overdesigned" and ended up
scrapping the whole Dylan project. The Apple Cambridge facility was
closed down, Dylan was moved to Harlequin and other entities and MACL
was taken over by Digitool and renamed MCL.
http://www.nomodes.com/LinzmayerBook.html
And one of the chief architects of the Lisa was ... Larry Tesler.
Shannon Spires
·······@nmia.com
Shannon Spires <·······@nmia.com> wrote:
> The Lisa was definitely ahead of its time. But it died because it was
> slow and too expensive. Redmond would certainly try to kill something
> that innovative today, but in those days Microsoft didn't even have
> enough clout to keep Bill out of jail, like they do today :-)
> http://TheSmokingGun.com/archive/gatesmug.shtml
Incidentally, Microsoft is using that mug shot in whole-page ads in
german newspapers.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
From: ······@corporate-world.lisp.de
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <964r32$244$1@nnrp1.deja.com>
In article <·····························@news.nmia.com>,
Shannon Spires <·······@nmia.com> wrote:
> AFAIK, there was no Lisp product available for the Lisa. There were very
> few third-party software packages available for it at all--it didn't
> live long enough. (It could run Mac software in compatibility mode, and
> in that sense, you could "run" a Lisp on it if you really wanted to.)
The LISA was mostly a Pascal machine. At that time Apple was a Pascal
shop. Lisp did not play a role at all. Interesting Lisp implementations
and applications appeared in the mid 80s (later the famous NeXT Interface
Builder was for example built after Steve Jobs saw Hullot's interface
builder written in Lisp on the Mac).
The Pascal-Worlds at Apple (UCSD Pascal, Apple Pascal, Clascal,
Object Pascal, MacApp, MPW, ...) had almost no contact or
impact on the Lisp side it seems. Apple invested serious
money to create frameworks (from MacApp to Taligent), but
this had little impact on the Lisp side. Only the Newton
and Dylan got more complex frameworks - the Newton
itself is really easy to understand if you had previous
exposure to Object Lisp and the MCL framework. Later
Pascal mostly got replaced by C and C++ (and MacApp
got ported to C++). MCL sometimes was used inside
Apple for applications and for prototyping. So stuff
developed in MCL later appeared in the MacOS redone
in C or C++. Also, AppleScript - the scripting
language on MacOS is definitely Lisp-influenced.
> The question is interesting for another reason. The chief instigator of
> the Dylan project was Apple's Chief Scientist, Larry Tesler, who is
> well-known as one of the designers of the Smalltalk environment. Dylan
> was intended to be a "lightweight" Common Lisp for the Newton, among
> other projects. And the reason Apple got involved with Coral Software
> and developed Coral Common Lisp (CCL) into MACL was mainly that MACL was
> an enabling technology for creating Dylan. (The first version of Dylan
> was written in MACL, and the Wood object-oriented database, which still
> ships with MCL, was written to enable the Dylan development environment.)
Also don't forget that Apple introduced the Personal Digital Assistent
(PDA) and with it the vision of the "Knowledge Navigator". So,
the whole thing was very ambitious. I would really like to
see a remake of the Newton (in Lisp) - Apple's Newton is
in many ways much more revolutionary than the Lisa ever was.
The Newton is the only *new* system in the 90s that was based
on Lisp technology and it was a real big product.
Where the Lisa was programmed in Pascal (static language with
compile-time type checks, etc.) and had stuff like
protected memory, the Newton was programmed in a dynamic
language (NewtonScript - much like Lisp/Scheme/Self)
and had stuff like incremental compilation (on the machine!),
objects all the way down, garbage collection, a frame system,
a cool persistent/compressing/indexed object store, dynamic loading,
tags on all data, you name it. All the stuff we love.
> Later, Tesler decided that Dylan was "overdesigned" and ended up
> scrapping the whole Dylan project. The Apple Cambridge facility was
> closed down, Dylan was moved to Harlequin and other entities and MACL
> was taken over by Digitool and renamed MCL.
Apple had severe money problems and no vision (or tired of too
much vision). So they closed ATG, ATG East, and so on. Apple
was also willing to let MCL die, but they were hindered to do so
- see, the About dialog box of MCL has a Cancel button, but the
Cancel button does not work. ;-)
Actually I thought it then and I think it still, the Dylan project
was a big waste of time and talent. Like I was reading yesterday
a bit in Gabriel's "Patterns of Software", where Lucid
took the money and the intellectual capital from the Lisp side
to develop a C++ environment. How sad. Lisp as a cash cow.
Lisp as a gold mine where everybody steals his pieces and
forgets to pay back or even give credit.
Rainer Joswig
Sent via Deja.com
http://www.deja.com/
In article <············@nnrp1.deja.com>,
······@corporate-world.lisp.de wrote:
> ... Also, AppleScript - the scripting
> language on MacOS is definitely Lisp-influenced.
Unfortunately, not enough. IMHO, Applescript is a horrible language,
because it tries to be too much like a natural language. Which means for
everything you try to make it do, there are 20 ways to express the idea
that seem to make sense, 19 of which don't work. (This is a more extreme
example of the problem with Loop in Common Lisp.) Applescript is also
horrible because of its extreme flexibility. Much of the language is
determined by what application it's talking to, which means it's
virtually impossible to even write down a coherent description of the
language, much less a good BNF for it. Most of the time when I need
the functionality of Applescript, I end up using MCL to send raw
Appleevents because it's just easier. Maybe it's just me--there are
certainly people who are very good at Applescript.
> Actually I thought it then and I think it still, the Dylan project
> was a big waste of time and talent.
Yep. There are some good ideas in Dylan, but they screwed up the syntax
so Lispers weren't interested in it. And they didn't market it right to
C++ programmers. If they had, Dylan would be where Java is today. Not
that that would necessarily be a good thing, but as pandering
impoverished ripoffs of Common Lisp go, I'll take Dylan over Java any
day.
Shannon Spires
·······@nmia.com
In article <·····························@news.nmia.com>, Shannon
Spires <·······@nmia.com> wrote:
> In article <············@nnrp1.deja.com>,
> ······@corporate-world.lisp.de wrote:
>
> > ... Also, AppleScript - the scripting
> > language on MacOS is definitely Lisp-influenced.
>
> Unfortunately, not enough. IMHO, Applescript is a horrible language,
> because it tries to be too much like a natural language. Which means for
> everything you try to make it do, there are 20 ways to express the idea
> that seem to make sense, 19 of which don't work. (This is a more extreme
> example of the problem with Loop in Common Lisp.) Applescript is also
> horrible because of its extreme flexibility. Much of the language is
> determined by what application it's talking to, which means it's
> virtually impossible to even write down a coherent description of the
> language, much less a good BNF for it. Most of the time when I need
> the functionality of Applescript, I end up using MCL to send raw
> Appleevents because it's just easier. Maybe it's just me--there are
> certainly people who are very good at Applescript.
Hmm, I found it very easy and Lisp-like to use. I once
wrote some code to do updates in an image database.
Plain MCL AppleEvent stuff is a bit harder, since you have to
worry much more about the data types (unless you
would use a high-level library or when you get MCL to figure out
from the applications's description how to use the methods
and datatypes). Also look at Sk8Script - this is a bit
like an object-oriented AppleScript - but implemented in MCL.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Rainer Joswig <······@corporate-world.lisp.de> wrote:
> In article <·····························@news.nmia.com>, Shannon
> Spires <·······@nmia.com> wrote:
> > Unfortunately, not enough. IMHO, Applescript is a horrible language,
> > because it tries to be too much like a natural language. Which means for
> > everything you try to make it do, there are 20 ways to express the idea
> > that seem to make sense, 19 of which don't work. (This is a more extreme
> > example of the problem with Loop in Common Lisp.) Applescript is also
> > horrible because of its extreme flexibility. Much of the language is
> > determined by what application it's talking to, which means it's
> > virtually impossible to even write down a coherent description of the
> > language, much less a good BNF for it. Most of the time when I need
> > the functionality of Applescript, I end up using MCL to send raw
> > Appleevents because it's just easier. Maybe it's just me--there are
> > certainly people who are very good at Applescript.
>
> Hmm, I found it very easy and Lisp-like to use. I once
> wrote some code to do updates in an image database.
> Plain MCL AppleEvent stuff is a bit harder, since you have to
> worry much more about the data types (unless you
> would use a high-level library or when you get MCL to figure out
> from the applications's description how to use the methods
> and datatypes). Also look at Sk8Script - this is a bit
> like an object-oriented AppleScript - but implemented in MCL.
What makes AppleScript complicated is not the language in itself. But AS
by itself is not very useful, the power comes from "remote controlling"
applications that support AppleEvents. And there's the crux. Apple has
provided the AppleEvent Registry that contains suites of generic --
required suite, core suite -- and domain specific -- text suite, table
suite, ... -- functionality. Unfortunately, only few apps keep to these
suites; neither by the letter nor in spirit. In general, these suites
provide a simplified, object-oriented view at a specific domain. In
practice, applications often provide only procedural events, at worst,
they just map their menu items to events. This has resulted to an
inconsistent hodge-podge, despite the efforts of several vocal
AppleScript/AppleEvent evangelists such as Cal Simone.
With hindsight, this may be another case of "worse is better". Of
course, being able to control another application at all is infinitely
better than not being able to do it. In contrast, adding the icing of a
nice AppleEvent Object Model-compliant interface may have been
prohibitively costly, because common frameworks (MacApp, PowerPlant)
didn't offer enough support and not early enough after AS has been
available. One has to keep in mind that AS is pretty old by now. It's
been available since 1992 and hardly anyone has taken notice since then.
In the meantime, Apple's support for it has been less than shining --
apparently they didn't understand themselves the value of the
technology. Somehow, I'd like to say the same about OpenDoc, but that's
for another time.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
From: David Thornley
Subject: Re: What IS "mcl"? was: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <J0ji6.138$V6.14973@ruti.visi.com>
In article <················@naggum.net>, Erik Naggum <····@naggum.net> wrote:
>* Christopher C Stacy <······@world.std.com>
>> You can see how it's no surprise that a "Lisp user would use an Apple".
>> For much of the relevent historical period, it was a superior platform,
>> and it continues to rival the capabilities of the Wintel world.
>
> How does the Lisa fit this story? All I know about it is what a friend
> of a friend who spent a sizable fraction of his college fund to get one
> told me, and he was just _raving_ about it, ecstatically. It seemed like
> one of those "too good to be true" and "eons before its time" things that
> would just _have_ to be crushed by the hype and the lies from Redmond.
>
Sort of a proto-Mac, much too expensive to succeed, but astonishingly
easy to use at the time. (Epson tried a Z80-based system that was
at least superficially simila, and which was far too slow to sell.)
One thing to remember is that the early Macs simply didn't have
the resources to do anything fancy (128K memory and one 400K
floppy drive standard - or was that 64K memory?) and therefore
multitasking was not a high priority. Protecting anything from
the user made little sense: if the user backed up the floppy,
what could he or she lose? The API was extensive, and made heavy
use of global state. It's almost a classic case of premature
optimization on a system level.
Apple has made at least one previous attempt to make the OS more
modern, which failed expensively.
OSX looks like it's going to succeed, but there's been a lot
of questions about how the new user interface is to the user,
there being some reason to think that Apple is going over to the Dark
Side of glitziness and forsaking ease of use.
ObLisp: Digitool was quiet about their plans for OSX-compatible Lisp
for long enough to get some of us nervous. They're now planning to
issue one sometime around the general release, next month.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87y9w61tk0.fsf@frown.here>
·······@mikemac.com (Mike McDonald) writes:
> In article <············@nnrp1.deja.com>,
> ······@corporate-world.lisp.de writes:
>
> > If you look closer you'll find that Common Lisp has lost the
> > connection to the average programmer and his/her needs.
>
> Common Lisp never had a "connection" with the average programmer.
Now I'm exactly that an average programmer. And I have learned to
value Common Lisp. It's an approach I did not have encountered and/or
used before. Does that mean I'm now above average or below?
Regards
Friedrich
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87d7deceq1.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus <·····@q-software-solutions.com>
> | Does that mean I'm now above average or below?
>
> You'll know when you compare your LOC/month figures with other people.
>
> I think I'm beginning to realize that I have a serious problem with every
> quantitative approach to ideas and human relations, being increasingly
> annoyed by people who don't "get" any qualitative approach at all.
Feel free to think what you like. I have as much problems with people
denying all the valuable insight quantitative approaches have given
and will give. There is an old saying about the worth of quantitative
approaches, but I won't bother telling you. I guess you'll find out
yourself
Friedrich
Hello!
In article <··············@frown.here>,
Friedrich Dominicus <·····@q-software-solutions.com> wrote:
>[...]
>Feel free to think what you like. I have as much problems with people
>denying all the valuable insight quantitative approaches have given
>and will give. There is an old saying about the worth of quantitative
>approaches, but I won't bother telling you. I guess you'll find out
>yourself
Do you mean this: "There are lies, damn lies, and statistics"?
>Friedrich
SCNR
Kind regards,
Hannah.
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3vgr5965j.fsf@cley.com>
* Friedrich Dominicus wrote:
> Erik Naggum <····@naggum.net> writes:
> Feel free to think what you like. I have as much problems with people
> denying all the valuable insight quantitative approaches have given
> and will give. There is an old saying about the worth of quantitative
> approaches, but I won't bother telling you. I guess you'll find out
> yourself
Quantatitive approaches are pretty useful. *But* you uave to be sure
that what you measure has some useful correlation to the world. This
is what physicists understand and almost no non-hard-scientist does.
--tim
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87snm9pivq.fsf@frown.here>
Tim Bradshaw <···@cley.com> writes:
>
> Quantatitive approaches are pretty useful. *But* you uave to be sure
> that what you measure has some useful correlation to the world. This
> is what physicists understand and almost no non-hard-scientist does.
I fully agree. When do you know there is a useful correlation to the
programming world. I asked for suggestions in that area and espcecialy
Common Lisp.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Tim Bradshaw <···@cley.com> writes:
>> Quantatitive approaches are pretty useful. *But* you uave to be
>> sure that what you measure has some useful correlation to the
>> world. This is what physicists understand and almost no
>> non-hard-scientist does.
> I fully agree. When do you know there is a useful correlation to the
> programming world. I asked for suggestions in that area and espcecialy
> Common Lisp.
It appears that LOC measures may provide some degree of correlation
_if_ you are building applications with highly uniform sorts of
complexity and patterns in general.
The only place where this seems to actually hold true is when people
are constructing repetitive "bespoke" database applications where the
bulk of the time gets spent grinding out the code to connect
screens/forms to databases.
Any sort of application that actually requires a modicum of creativity
is liable to make correlations go away.
You seem to be assuming that the correlations will mean something
devoid of having any actual theory as to _why_ they should have
meaning.
You're basically behaving like the raving nuts that do technical
analysis of the stock market, looking for whatever numeric patterns
they can find, speculating that these patterns might have something to
do with reality.
You keep wondering why every thinks you're nuts when you haven't yet
presented a single reason why a LOC measure should be expected to
correlate to anything _useful_.
You're demanding that people believe that it's useful on the thin
evidence that someone wrote a book on the subject rather than
presenting compelling reasons that would _prove_ usefulness. It's
nobody's responsibility to prove usefulness to you; indeed, it's
pretty pointless to do so, as you clearly already have faith in this
claim.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://vip.hex.net/~cbbrowne/wp.html
"Usenet is like a herd of performing elephants with diarrhea; massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
-- Gene Spafford (1992)
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87r91tnya4.fsf@frown.here>
········@hex.net writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
> > Tim Bradshaw <···@cley.com> writes:
> >> Quantatitive approaches are pretty useful. *But* you uave to be
> >> sure that what you measure has some useful correlation to the
> >> world. This is what physicists understand and almost no
> >> non-hard-scientist does.
>
> > I fully agree. When do you know there is a useful correlation to the
> > programming world. I asked for suggestions in that area and espcecialy
> > Common Lisp.
>
> It appears that LOC measures may provide some degree of correlation
> _if_ you are building applications with highly uniform sorts of
> complexity and patterns in general.
Ok.
>
> Any sort of application that actually requires a modicum of creativity
> is liable to make correlations go away.
Ok.
>
> You seem to be assuming that the correlations will mean something
> devoid of having any actual theory as to _why_ they should have
> meaning.
>
> You're basically behaving like the raving nuts that do technical
> analysis of the stock market, looking for whatever numeric patterns
> they can find, speculating that these patterns might have something to
> do with reality.
What drives a market? Noone knows for sure, but anyone has a slight
idea on why his decision may be usefule. And some have decided to
"base" their decisions on technical analysis. I do not claim that they
are more successfull nor that they are not. Anyway there was an
interesting "comparison" in a German magazin about the stock markets,
where a "fundamental" oriented and a "technical" oriented editor were
struggling in that year the fundamental oriented editor runs
havoc. The technical oriented were running quite well. So in this year
obeying the "technical" rules have worked? By chance, I can' tell.
>
> You keep wondering why every thinks you're nuts when you haven't yet
> presented a single reason why a LOC measure should be expected to
> correlate to anything _useful_.
Sorry I pointed out that Watts things counting LOC is useful, with a
lot of citations.
>
> You're demanding that people believe that it's useful on the thin
> evidence that someone wrote a book on the subject rather than
> presenting compelling reasons that would _prove_ usefulness. It's
> nobody's responsibility to prove usefulness to you; indeed, it's
> pretty pointless to do so, as you clearly already have faith in this
> claim.
Why don't you read through this thread again? I have pointed out that
LOC counting is one part of the approach. And you can find a bunch of
reports which try to find if the PSP is useful or not. Part of it is
LOC counting, which is used for size estimated. There are reports
stating that following the PSP is quite useful, just one report I know
of states it maybe not as useful as pointed out in the other
reports. I stated more than often that I try to find out for me. If I
do not follow the suggestions with some faith it would be useless to
do the excercises. So my assumption is amibious at the moment, but I'm
of course biased. I do think a "disciplined" process will give me some
gains. To find out if it's the PSP which "suits" my needs requires to
follow the guide lines there closely for now.
Part of it is if anyone likes it or not counting locs. And using
Object loc as base for time estimates.
Regards
Friedrich
From: Seth Gordon
Subject: measuring programmers by LOC considered harmful
Date:
Message-ID: <3A6F066F.12EEB2DB@kenan.com>
> ········@hex.net writes:
> > You keep wondering why every thinks you're nuts when you haven't yet
> > presented a single reason why a LOC measure should be expected to
> > correlate to anything _useful_.
Friedrich Dominicus wrote:
> Sorry I pointed out that Watts things counting LOC is useful, with a
> lot of citations.
I suspect a lot of people on this newsgroup are mumbling, "why should I care
what this Watts guy thinks is useful?"
A little work with Google revealed the Web pages of Carnegie-Mellon
University's Software Engineering Institute, the institution behind the
Personal Software Process (which is being discussed here), the Team Software
Process, and the Capability Maturity Model. Here's a link to a report showing
how a group of engineers improved after using the PSP:
http://www.sei.cmu.edu/pub/documents/97.reports/pdf/97tr001.pdf
This report says (among other things) that: engineers who went through the PSP
training were better able to estimate how many LOC a program would have before
writing it; they wrote software with fewer defects per LOC; and they removed
more defects per LOC. The report also measured their productivity as measured
by LOC/hour, but finds no significant improvement.
It seems, therefore, that the PSP's advocates *assume in advance* that LOC
measures something useful, and don't test or justify that assumption.
--
"The big dig might come in handy ... for a few project managers
whom I think would make great landfill." --Elaine Ashton
== seth gordon == ·······@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
From: Friedrich Dominicus
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <87u26og80d.fsf@frown.here>
Seth Gordon <·······@kenan.com> writes:
> > ········@hex.net writes:
> > > You keep wondering why every thinks you're nuts when you haven't yet
> > > presented a single reason why a LOC measure should be expected to
> > > correlate to anything _useful_.
>
> Friedrich Dominicus wrote:
>
> > Sorry I pointed out that Watts things counting LOC is useful, with a
> > lot of citations.
>
> I suspect a lot of people on this newsgroup are mumbling, "why should I care
> what this Watts guy thinks is useful?"
I agree, but hopefully some are among them who have read a bit more
from Watts and do think that he knows what he's taling about.
>
> It seems, therefore, that the PSP's advocates *assume in advance* that LOC
> measures something useful, and don't test or justify that
>assumption.
I do not fully understand where the assumption is that LOC are
useful. Other things are related to it. So "it's a base" on top of it they
build all the other Metrics. If they don't use LOC what else should
they relate the errors to?
What does it mean to have 10 Errors without a relationship to some
metric which indicates how large the progam is?
Any other article and or book I read about measurement relate them to
some "size". So if LOC counting is not useful what then?
Regards
Friedrich
From: Bulent Murtezaoglu
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <87puhcrf07.fsf@kapi.internal>
[...]
FD> I do not fully understand where the assumption is that LOC are
FD> useful. Other things are related to it. So "it's a base" on
FD> top of it they build all the other Metrics. If they don't use
FD> LOC what else should they relate the errors to?
Maybe they could come out and say, "we don't know how to characterize this"?
Just maybe, I am by no means knowledgeable in the subject.
FD> What does it mean to have 10 Errors without a relationship to
FD> some metric which indicates how large the progam is?
As it has been pointed out, "10 Errors" make as much sense as 10 KLOC.
What kind of errors?
FD> Any other article and or book I read about measurement relate
FD> them to some "size". So if LOC counting is not useful what
FD> then?
Maybe nobody figured out a good way to do this? Maybe this is a hard
problem? Sometimes, 'we just don't know [yet]' is a good answer.
I think the negative reaction you are getting from people is because (1)
both LOC counting and defects per KLOC measures admit clear-cut
counter-examples (as people pointed out), (2) I suspect some of
us had legal paperwork mentioning defects/KLOC shoved in front of them
and they resented it (I certainly did, and yes big companies do have
contracts mentioning such stuff).
There is absolutely nothing wrong with collecting data to see whether (or
under what conditions) something can be useful as a metric. It is dangerous,
however, to get trapped in this "we have to count something, no matter what"
mentality.
cheers,
BM
From: Friedrich Dominicus
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <87ofww5chq.fsf@frown.here>
Bulent Murtezaoglu <··@acm.org> writes:
> There is absolutely nothing wrong with collecting data to see whether (or
> under what conditions) something can be useful as a metric. It is dangerous,
> however, to get trapped in this "we have to count something, no matter what"
> mentality.
I agree with that. I found this in Peter
Gabriels book "Patterns of Software" (Chapter: Is there a silver
bullet?):
"
- We need to determine goals, which can include higher productivity,
higher quality, lower maintenance costs, better documentation, and
easier extension and improvement (habitability and piecemeal growth)
- We nee a reliably measured productivity baseline so we know whether
we are making progress - we need well documented numbers.
"
a lot of other needs and comments follow See page 127 ff from that
book
At the beginning he states: "Unfortunatly, to do this science requires
doing some simple but expensive and time-consuming things"...
Interesting is the point we need well documented numbers. Now one
advantage of the PSP excercises is to collect those numbers and anyway
if you decide for yourself that LOC/Defects is you measurement and
document this it seems to be a valid metric.
Which goes hand in hand with what you suggest. Anyway Gabriel too
suggests that this collecting needs time, anyway one have to start
somewhere ...
Regards
Friedrich
From: Seth Gordon
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <3A6F6BCF.7A7C4C5E@kenan.com>
Friedrich Dominicus wrote:
> >
> > It seems, therefore, that the PSP's advocates *assume in advance* that LOC
> > measures something useful, and don't test or justify that
> >assumption.
>
> I do not fully understand where the assumption is that LOC are
> useful. Other things are related to it. So "it's a base" on top of it they
> build all the other Metrics. If they don't use LOC what else should
> they relate the errors to?
Old joke: A man emerges from a bar and discovers a drunk crawling in the street,
underneath a lamp-post.
"What are you doing?" the man asks.
"I'm looking for my keys," the drunk replies.
"What happened to them?" the man asks.
"I dropped them on my way out of the bar."
"Where did you drop them?"
"Over there," the drunk says, pointing to a spot in the gutter about ten feet
away.
"If you dropped your keys over there, why are you looking for them over here?"
"Because there's more light here."
--
"The big dig might come in handy ... for a few project managers
whom I think would make great landfill." --Elaine Ashton
== seth gordon == ·······@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
From: Kent M Pitman
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <sfw66j42uzy.fsf@world.std.com>
Seth Gordon <·······@kenan.com> writes:
> [...]
> "If you dropped your keys over there, why are you looking for them
> over here?"
>
> "Because there's more light here."
Tried and true.
At MIT I was bugged that I had to take hardware courses to study
software. Then and now, I think it was a serious waste of my time.
One professor (wish I could remember who now, but I can't) opined to
me at the time (late 1970's) that it was probably because CS grew out
of the EE department there and everyone teaching there really only
knew how to teach and test hardware, which had been around much longer
as a discipline than software. They wanted to make sure I'd been
tested on some hard science before turning me loose on the world. Bleah.
I was never so glad as to switch out of there into the Philosophy
department, from which I eventually graduated (with a major kind of
split among Philosophy of minds and machines, Psychology, Linguistics,
and AI, with my CS courses as elective). Quantifying my progress and
giving me grades may have been harder in those other areas of study I
moved to, but at least they were trying to teach me stuff in areas I
was trying to learn about, not in others where there was more available
light...
--Kent (home miserably sick with a cold this week,
and feeling plenty philosophical...)
From: Tim Bradshaw
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <ey3ae8g8qi7.fsf@cley.com>
* Friedrich Dominicus wrote:
>> It seems, therefore, that the PSP's advocates *assume in advance* that LOC
>> measures something useful, and don't test or justify that
>> assumption.
> I do not fully understand where the assumption is that LOC are
> useful. Other things are related to it. So "it's a base" on top of it they
> build all the other Metrics. If they don't use LOC what else should
> they relate the errors to?
> What does it mean to have 10 Errors without a relationship to some
> metric which indicates how large the progam is?
> Any other article and or book I read about measurement relate them to
> some "size". So if LOC counting is not useful what then?
OK, I'll try and explain what I think is wrong with this kind of
argument. I'm typing this over a really slow line so please forgive
any typos, it's painful to fix them.
You basically want to be able to associate things with some quantity
that you care about in the real world -- it's of no interest
measuring something which doesn't have any correlation to anything you
care about.
Unfortunately you don't really know what all the things you care about
are -- things like `feature count' are pretty vague. But you do know
some of them, for instance you want to control the cost of the system,
and that goes like man-months to a pretty good approximation (actually
even this is non-trivial because you can discount man-months in the
future, but I'll ignore that).
So you'd like some measure of your program which correlates with
man-months, say. And you'd like it actually to be a computable property of
the program. You probably want something more than this, for instance
you want the mapping between your property of the program to have good
enough bounds that you can treat it as an approximate function
(monotonic, increasing).
Well, LOC is certainly a computable function of the program. And
since it's kind of easy to compute, and people are lazy and stupid,
they like to jump to the conclusion that it's actually linearly
related to cost, so things like defects/LOC make some kind of sense,
if you assume a constant cost per defect.
Here's an example that show how badly this can do. Imagine you have a
development strategy which consists of hiring n programmers and
chucking them in a room to write the program. There are no
constraints on what they can do, and there are no predefined
interfaces or design or anything. Each programmer is writing a bunch
of functions, and these functions go like LOC. Because there is no
structure larger than the function to this program, all the
programmers need to know the whole codebase. Assume it taker x times
as long to understand a function as write it, and time t to write it.
so for n functions the real time taken is t(1+xn-x), and the
person-time is nt(1+nx-x). If n>>1 then the person-time is about
n^2tx. So the time per function is ntx. So the cost per function
goes like n, and thus the cost per LOC goes like n.
Obviously this is a catastrophically bad approach to programming (I've
ignored maintenance costs for this which are likely even worse). But
it makes the point that LOC does not have to be linearly related to
cost. You need to find *some other property* of the program which is
interesting.
There's additional evidence that LOC is not very useful when you
consider the well-known fact (meaning, I am going to randomly quote
this in the standard bogus usenet way) that professional programmer
productivity, when measure in LOC per unit time, varies enormously.
Because people are so blinded by LOC they often assume that this means
that programmer *talent* varies enormously. Well, it probably does,
but it may also be that the `slow' programmers are producing stuff
that is enormously better quality. Certainly I'm aware that I'm a
pretty slow programmer, *but* stuff I produce tends to actually work
and be a bit comprehensible, whereas I've come across people who write
perhaps 10x as fast as me, except that I then have to walk along
behind them making it work (and probably reducing the size of it by a
factor of 5 or something...). Of course there are also people 10x as
fast as me who produce really good code...
So you want to look at some other property of programs, because LOC
just isn't interesting except for the warm fuzziness quotient.
Unfortunately these other properties are not so easy to measure,
because they involve things like how many bits of the program depend
on how many other bits, and things like that. The kind of thing you
want to do, I think is look at is the call graph of the program (both
static and dynamic) and try and associate some measure with it,
possibly by embedding it into some kind of space which you can then
measure the size of. Things like VC dimension or something might be
interesting (except I don't really have a feel for how you embed the
graph into a space).
But the trouble is that these kinds of things require some serious
mathematical sophistication (much more than I have), and the LOC
people aren't up to it.
This is very incoherent, I'm sorry.
--tim
From: Friedrich Dominicus
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <87k87k5az8.fsf@frown.here>
Tim Bradshaw <···@cley.com> writes:
>
> OK, I'll try and explain what I think is wrong with this kind of
> argument. I'm typing this over a really slow line so please forgive
> any typos, it's painful to fix them.
Don't bother ;-)
>
> Unfortunately you don't really know what all the things you care about
> are -- things like `feature count' are pretty vague. But you do know
> some of them, for instance you want to control the cost of the system,
> and that goes like man-months to a pretty good approximation (actually
> even this is non-trivial because you can discount man-months in the
> future, but I'll ignore that).
Just to restate what the base line was.
- It's for personal use
- Object LOC is part is the base for estimates for the Excercises in
Watts Book.
>
> Well, LOC is certainly a computable function of the program. And
> since it's kind of easy to compute, and people are lazy and stupid,
> they like to jump to the conclusion that it's actually linearly
> related to cost, so things like defects/LOC make some kind of sense,
> if you assume a constant cost per defect.
The defects are put in categories and the time is recorded to fix the
bugs. So there is no assumption of an constant cost per defect.
>
> Here's an example that show how badly this can do. Imagine you have a
> development strategy which consists of hiring n programmers and
> chucking them in a room to write the program. There are no
> constraints on what they can do, and there are no predefined
> interfaces or design or anything. Each programmer is writing a bunch
> of functions, and these functions go like LOC. Because there is no
> structure larger than the function to this program, all the
> programmers need to know the whole codebase. Assume it taker x times
> as long to understand a function as write it, and time t to write it.
> so for n functions the real time taken is t(1+xn-x), and the
> person-time is nt(1+nx-x). If n>>1 then the person-time is about
> n^2tx. So the time per function is ntx. So the cost per function
> goes like n, and thus the cost per LOC goes like n.
This is a very nice example.
>
> Obviously this is a catastrophically bad approach to programming (I've
> ignored maintenance costs for this which are likely even worse). But
> it makes the point that LOC does not have to be linearly related to
> cost.
I won't argue that LOC are linearly correlated with the size. My
"feeling" is that ther is some exponentiell growth in it. But I can
not quantifiy it.
>
> There's additional evidence that LOC is not very useful when you
> consider the well-known fact (meaning, I am going to randomly quote
> this in the standard bogus usenet way) that professional programmer
> productivity, when measure in LOC per unit time, varies enormously.
I agree, but what about a single programmer?
> Because people are so blinded by LOC they often assume that this means
> that programmer *talent* varies enormously. Well, it probably does,
> but it may also be that the `slow' programmers are producing stuff
> that is enormously better quality.
I'm as sure as can be that talent varies. Otherwise programming would
be the only professon without variation ;-). The point is anything are
LOC usefule as a base line for an individual programmer?
>Certainly I'm aware that I'm a
> pretty slow programmer, *but* stuff I produce tends to actually work
> and be a bit comprehensible, whereas I've come across people who write
> perhaps 10x as fast as me, except that I then have to walk along
> behind them making it work (and probably reducing the size of it by a
> factor of 5 or something...). Of course there are also people 10x as
> fast as me who produce really good code...
Very nice stated ;)
>
> So you want to look at some other property of programs, because LOC
> just isn't interesting except for the warm fuzziness quotient.
> Unfortunately these other properties are not so easy to measure,
> because they involve things like how many bits of the program depend
> on how many other bits, and things like that. The kind of thing you
> want to do, I think is look at is the call graph of the program (both
> static and dynamic) and try and associate some measure with it,
> possibly by embedding it into some kind of space which you can then
> measure the size of. Things like VC dimension or something might be
> interesting (except I don't really have a feel for how you embed the
> graph into a space).
I've spend a bit more time thinking about the mails in this thread and
have some other ideas.
>
> But the trouble is that these kinds of things require some serious
> mathematical sophistication (much more than I have), and the LOC
> people aren't up to it.
Don't you think this is a bit too harsh?
> This is very incoherent, I'm sorry.
what is very incoherent?
Regards
Friedrich
From: Tim Bradshaw
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <ey31ytr8iu3.fsf@cley.com>
* Friedrich Dominicus wrote:
> [ I wrote]
>> But the trouble is that these kinds of things require some serious
>> mathematical sophistication (much more than I have), and the LOC
>> people aren't up to it.
> Don't you think this is a bit too harsh?
No. I think that a huge amount of the software engineering literature
describes work which is second rate, at best, done by people who are
second rate, at best.
--tim (second rate, and proud of it!)
From: Friedrich Dominicus
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <87wvbix141.fsf@frown.here>
Tim Bradshaw <···@cley.com> writes:
> * Friedrich Dominicus wrote:
> > [ I wrote]
> >> But the trouble is that these kinds of things require some serious
> >> mathematical sophistication (much more than I have), and the LOC
> >> people aren't up to it.
>
> > Don't you think this is a bit too harsh?
>
> No. I think that a huge amount of the software engineering literature
> describes work which is second rate, at best, done by people who are
> second rate, at best.
So probably you can point out which books about SE you found better
than second rate?
Regards
Friedrich
From: Tim Bradshaw
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <ey3ae8b7sku.fsf@cley.com>
* Friedrich Dominicus wrote:
> So probably you can point out which books about SE you found better
> than second rate?
I haven't read any that isn't.
--tim
From: Friedrich Dominicus
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <87puh7ahhw.fsf@frown.here>
Tim Bradshaw <···@cley.com> writes:
> * Friedrich Dominicus wrote:
> > So probably you can point out which books about SE you found better
> > than second rate?
>
> I haven't read any that isn't.
May I suggest a few which I do think are quite good
McConnel
-Code comple
-rapid development
weinberg
- the psychology of computer programming
more ancedotal
- Macro: The deadline
- Gabriel: Pattersn of software
The ranking that this books are "first rate" are if course just my
opinion.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> wrote:
> Tim Bradshaw <···@cley.com> writes:
>
> > * Friedrich Dominicus wrote:
> > > So probably you can point out which books about SE you found better
> > > than second rate?
> >
> > I haven't read any that isn't.
>
> May I suggest a few which I do think are quite good
> McConnel
> -Code comple
> -rapid development
>
> weinberg
> - the psychology of computer programming
>
> more ancedotal
> - Macro: The deadline
> - Gabriel: Pattersn of software
>
> The ranking that this books are "first rate" are if course just my
> opinion.
This is a very non-representative selection of SE books. Even more so,
if I add the already mentioned books by Watts Humphrey to it. These are
mostly books concerned with the development process and management
issues. This is not bad in itself, of course.
There are other books that cover very different areas: requirements
gathering, analysis, sw architecture, design, testing, usability... I'd
consider these areas to be well within the field of software
engineering.
Michael
--
Michael Schuerig
···············@acm.org
http://www.schuerig.de/michael/
From: Friedrich Dominicus
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <87r91mq34n.fsf@frown.here>
········@acm.org (Michael Schuerig) writes:
>
> This is a very non-representative selection of SE books. Even more so,
> if I add the already mentioned books by Watts Humphrey to it.
I agree, it was a list of choices. I found worthwhile to read.
>
> There are other books that cover very different areas: requirements
> gathering, analysis, sw architecture, design, testing, usability... I'd
> consider these areas to be well within the field of software
> engineering.
Agreed, so feel free to add books of your favourite field. It was
anyway just thought to point out books I grade higher then second
grade.
But we are off-topic, aren't we? ;-)
Regards
Friedrich
From: Tim Bradshaw
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <ey3g0i16fws.fsf@cley.com>
* Friedrich Dominicus wrote:
> - Gabriel: Pattersn of software
Actually I'd have mentioned this (except I'm not sure it's an SE
book), and I'd add the mythical man month, which kind of has to be
there even though it's so old.
However it's interesting that what Gabriel seems to me to be saying is
that we should really give up and go back to treating SW as a craft
skill. If so I actually agree: I've had enough time being a failed
scientist, and I'd like to spend more time being a skilled craftsman.
--tim
From: Will Deakin
Subject: Re: measuring programmers by LOC considered harmful
Date:
Message-ID: <3A7699E3.6000406@pindar.com>
Tim wrote:
> ...and I'd add the mythical man month, which kind of has to be
> there even though it's so old.
There is the twentieth anniversary edition -- which has a four or
five extra chapters of varying vintage (1985-1995) and some
interesting commentary on how the M-MM has fared over the 30-40
years of experience over which the book is based.
> However it's interesting that what Gabriel seems to me to be saying is
> that we should really give up and go back to treating SW as a craft
> skill.
... and Brooks is seems to be saying that sucessful SW is based
on people, the management of people and systems that are put in
place to enable SW people to practice their craft.
:)will
In article <······················@news2.giganews.com>,
<········@hex.net> wrote:
>
>It appears that LOC measures may provide some degree of correlation
>_if_ you are building applications with highly uniform sorts of
>complexity and patterns in general.
>
>The only place where this seems to actually hold true is when people
>are constructing repetitive "bespoke" database applications where the
>bulk of the time gets spent grinding out the code to connect
>screens/forms to databases.
>
>Any sort of application that actually requires a modicum of creativity
>is liable to make correlations go away.
>
Yeah, but it doesn't seem to me that it makes the idea useless. Let
me describe a scenario in which I'd be interested in LOC.
Suppose we have one person who writes portable Common Lisp code
with MCL some of the time and Emacs/CMUCL some of the time, with
no particular task-related reason to use one or the other. Suppose
that the stuff he wrote wound up being of similar unit size on
each platform, and another observer, familiar with his style,
couldn't tell which platform any given code was written in.
Now, given that setup, I would be very interested in LOC/day or
similar count, because the comparison would be likely to be useful.
(If we compare different people using the environments, forget it.
The individual differences could account for all the difference,
whatever that was.)
Personally, I think that a Lisp programmer is likely to be about
as productive with Emacs/CMUCL as with MCL, although given
equal familiarity with each environment they might well prefer
to work with MCL. (It's a very nice environment.) However,
people tend to be very bad at estimating how various factors
affect their own productivity whenever the productivity can
be clearly measured.
>You keep wondering why every thinks you're nuts when you haven't yet
>presented a single reason why a LOC measure should be expected to
>correlate to anything _useful_.
>
Bigger and more complex programs generally have more LOC than simpler
programs. I think this obvious. Therefore, LOC is a measure of
how hard it is to write a program. It's not a good measure, and
easily screwed up. Like any measure, if you reward people based
on LOC it will cease to measure anything useful.
There is also, I believe, a certain amount of experimental results
suggesting that the time required to write a program increases
with LOC in a way that's statistically predictable.
If you don't have reliable measures, you can do a lot with unreliable
ones, provided you keep the unreliability firmly in mind and know how
much you can trust any given conclusion. It's not as easy or
pleasant, and it's always tempting to trust the data more than
you should.
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
Erik Naggum wrote:
> Just what _is_ it with you Germans?
Hm... maybe I'am really dull because I do not know why it is so important
to discuss such IMHO unimportant topics so emotionally like in the last
posts. (and yes I mean all - Erik, Friedrich and Rainer!!!)
I think it is really important to have an own opinion and it is equally
important to communicate it but I do _not_ find any good thing in personal
attacks. Critic is good, but it should be *constructive*.
Could you all _please_ find to a normal tone of communication?
P.S: Erik: Please do not begin to follow the way of the above quoted
statement any further. This time I take it for a joke ;-)
Regards,
Jochen
--
http://www.dataheaven.de
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87wvblpiyr.fsf@frown.here>
Jochen Schmidt <···@dataheaven.de> writes:
> Erik Naggum wrote:
> > Just what _is_ it with you Germans?
>
> Hm... maybe I'am really dull because I do not know why it is so important
> to discuss such IMHO unimportant topics so emotionally like in the last
> posts. (and yes I mean all - Erik, Friedrich and Rainer!!!)
> I think it is really important to have an own opinion and it is equally
> important to communicate it but I do _not_ find any good thing in personal
> attacks. Critic is good, but it should be *constructive*.
Please point out where I'm going personal.
>
> Could you all _please_ find to a normal tone of communication?
Why do you care?
Regards
Friedrich
Friedrich Dominicus wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> Erik Naggum wrote:
>> > Just what _is_ it with you Germans?
>>
>> Hm... maybe I'am really dull because I do not know why it is so important
>> to discuss such IMHO unimportant topics so emotionally like in the last
>> posts. (and yes I mean all - Erik, Friedrich and Rainer!!!)
>
>
>> I think it is really important to have an own opinion and it is equally
>> important to communicate it but I do _not_ find any good thing in
>> personal attacks. Critic is good, but it should be *constructive*.
>
> Please point out where I'm going personal.
You have criticized Rainer in having a bad quoting-style - this is ok
but it is IMHO (!!!) _not_ ok to make any assumptions on any intentions of
him or maybe his *honor*- this is not constructive.
>> Could you all _please_ find to a normal tone of communication?
> Why do you care?
Because I ...
1) ...don't like the amount of mails on that particular topic written so
far in relation to the amount of interesting mails.
2) ...think that everyone here said and will say something useful in this
list, so that it would perhaps be no good thing if future discussions
would all lead to this situation.
Regards,
Jochen
In article <··············@ID-22205.news.dfncis.de>, Jochen Schmidt
<···@dataheaven.de> wrote:
> Friedrich Dominicus wrote:
>
> > Jochen Schmidt <···@dataheaven.de> writes:
> >
> >> Erik Naggum wrote:
> >> > Just what _is_ it with you Germans?
> >>
> >> Hm... maybe I'am really dull because I do not know why it is so important
> >> to discuss such IMHO unimportant topics so emotionally like in the last
> >> posts. (and yes I mean all - Erik, Friedrich and Rainer!!!)
> >
> >
> >> I think it is really important to have an own opinion and it is equally
> >> important to communicate it but I do _not_ find any good thing in
> >> personal attacks. Critic is good, but it should be *constructive*.
> >
> > Please point out where I'm going personal.
>
> You have criticized Rainer in having a bad quoting-style
This was not Friedrich. Jochen, I think you are wrong on that.
> Because I ...
> 1) ...don't like the amount of mails on that particular topic written so
> far in relation to the amount of interesting mails.
> 2) ...think that everyone here said and will say something useful in this
> list, so that it would perhaps be no good thing if future discussions
> would all lead to this situation.
The problem is that we had this in the past (with different persons)
and it always leads to the same result. I'm not accepting
this.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig wrote:
> In article <··············@ID-22205.news.dfncis.de>, Jochen Schmidt
> <···@dataheaven.de> wrote:
>
>> Friedrich Dominicus wrote:
>>
>> > Jochen Schmidt <···@dataheaven.de> writes:
>> >
>> >> Erik Naggum wrote:
>> >> > Just what _is_ it with you Germans?
>> >>
>> >> Hm... maybe I'am really dull because I do not know why it is so
>> >> important to discuss such IMHO unimportant topics so emotionally like
>> >> in the last
>> >> posts. (and yes I mean all - Erik, Friedrich and Rainer!!!)
>> >
>> >
>> >> I think it is really important to have an own opinion and it is
>> >> equally important to communicate it but I do _not_ find any good thing
>> >> in personal attacks. Critic is good, but it should be *constructive*.
>> >
>> > Please point out where I'm going personal.
>>
>> You have criticized Rainer in having a bad quoting-style
>
> This was not Friedrich. Jochen, I think you are wrong on that.
Yes I seriously confused the things today. I wanted to post something to
Friedrich that sounds a bit more like that i said in my last answer to him.
But I confused that with that I wanted to say to Pierre.
>> Because I ...
>> 1) ...don't like the amount of mails on that particular topic written so
>> far in relation to the amount of interesting mails.
>> 2) ...think that everyone here said and will say something useful in this
>> list, so that it would perhaps be no good thing if future
>> discussions would all lead to this situation.
>
> The problem is that we had this in the past (with different persons)
> and it always leads to the same result. I'm not accepting
> this.
IMHO some of the things Erik said are _really_ not ok. But both - you and
Erik did not try to offer each other a backdoor to escape when argumenting
against. IMHO it is important to let the other side cleanly leave the
terrain. I tried to make sure that I do not give anyone of you any fault
because I think it is neither my duty nor my right to do so.
Regards,
Jochen
In article <··············@ID-22205.news.dfncis.de>, Jochen Schmidt
<···@dataheaven.de> wrote:
> IMHO some of the things Erik said are _really_ not ok. But both - you and
> Erik did not try to offer each other a backdoor to escape when argumenting
> against. IMHO it is important to let the other side cleanly leave the
> terrain.
Usually you are right, but in this case I wanted to bring it to
the point - so one has to make up her/his mind. I'm a long time
reader of c.l.l (ten years or more) - but how does it
look to someone who is newly coming to c.l.l - see your
own surprise. This discussion style happened with some
people, more or less innocently looking into c.l.l, last year.
It also happened with some long-time Lisp experts, whose
expertise I rate much higher than Erik's and whose participation
here is extremely valuable to me and maybe to others.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Rainer Joswig
> | Usually you are right, but in this case I wanted to bring it to the point
> | - so one has to make up her/his mind. I'm a long time reader of c.l.l
> | (ten years or more) - but how does it look to someone who is newly
> | coming to c.l.l - see your own surprise.
>
> It looks really odd to anyone to see you nutballs continue to behave as
> if this newsgroup is about yourself and your relation to me, not about
> the programming language (Common ) Lisp.
>
> You can do your part, Rainer, and stop pretending that if you only talk
> about me in different words, it'll be OK. This newsgroup is _not_ your
> personal therepist, however, and you should take that up with someone who
> cares about you personally. Your _abuse_ of this newsgroup for such
> personal therapy sessions is a fundamental part of the problem, and only
> you can readjust your attitude to this newsgroup and refrain from going
> personal and telling stories about what personal mail you received years
> ago that causes you to react irrationally today.
You do remember your last mail to me, do you?
From: Erik Naggum <····@naggum.net>
Date: 04 Nov 2000 14:39:51 +0000
If you don't have it anymore I can send it to you. Then you can see who is
patronizing whom.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Erik Naggum wrote:
> * Rainer Joswig
> | Usually you are right, but in this case I wanted to bring it to the
> | point
> | - so one has to make up her/his mind. I'm a long time reader of c.l.l
> | (ten years or more) - but how does it look to someone who is newly
> | coming to c.l.l - see your own surprise.
>
> It looks really odd to anyone to see you nutballs continue to behave as
> if this newsgroup is about yourself and your relation to me, not about
> the programming language (Common ) Lisp.
As I remember _you_ continued to talk upon non- (Common) Lisp topics when
sharing *your* personal opinions about Rainer with us all. IMHO this is ok
if we could find rather quickly to the core-topics in this newsgroup. But
you cannot forbid _us_ (anyone!) to talk about you in this forum if *you*
continue to talk about us.
I personally have nothing against you and hope I've done nothing that would
hurt you in any way.
> You can do your part, Rainer, and stop pretending that if you only talk
> about me in different words, it'll be OK. This newsgroup is _not_ your
> personal therepist, however, and you should take that up with someone
> who
> cares about you personally. Your _abuse_ of this newsgroup for such
> personal therapy sessions is a fundamental part of the problem, and only
> you can readjust your attitude to this newsgroup and refrain from going
> personal and telling stories about what personal mail you received years
> ago that causes you to react irrationally today. It is your irrational
> acts today that is the problem. Just quit them, and don't blame anyone
> else for it on your way out. As long as you think you're not part of
> the problem, you _are_ the problem.
And the same counts for *everone* in this newsgroup including _you_ and
_me_.
P.S: please it is enough. Each new word on this topic is useless.
Regards,
Jochen
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87elxtnxpi.fsf@frown.here>
Jochen Schmidt <···@dataheaven.de> writes:
> > Please point out where I'm going personal.
>
> You have criticized Rainer in having a bad quoting-style - this is ok
> but it is IMHO (!!!) _not_ ok to make any assumptions on any intentions of
> him or maybe his *honor*- this is not constructive.
You may have to re-read my postings, you'll hardly find any mail in
which I criticized Rainer on his quoting style.
>
> >> Could you all _please_ find to a normal tone of communication?
> > Why do you care?
>
> Because I ...
> 1) ...don't like the amount of mails on that particular topic written so
> far in relation to the amount of interesting mails.
Me too. Anyway I do think I got a bunch of interesting mails regarding
the topic I opened.
Anyway for further comments I suggest using mail. So feel free to send
me a mail to point out any misbehaving from my side.
Regards
Friedrich
Friedrich Dominicus wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> > Please point out where I'm going personal.
>>
>> You have criticized Rainer in having a bad quoting-style - this is ok
>> but it is IMHO (!!!) _not_ ok to make any assumptions on any intentions
>> of him or maybe his *honor*- this is not constructive.
>
> You may have to re-read my postings, you'll hardly find any mail in
> which I criticized Rainer on his quoting style.
Oh.... please sorry this was really a quickshot...
I've really confused some things I wanted to say here.
Sorry.
But now as im a litlle bit more aware of me - I remember what my point to
you was yesterday:
You and Erik have some dispute about counting "quantities".
as I mentioned it is good to have a opinion, but I think this topic is
going too far now. It seemed very clearly like a little sidekick to Erik
which IMHO can and should have is own opinions on this topic. His opinion
seems to be pretty clearly discussed in another thread and I don't think it
would be any good to go any further here.
But the _real_ problem here in this thread was certainly _not_ your
postings.
The Person I should have "critizied for criticizing" Rainer in a
destructive way should be Pierre as I remember (and re-checked this time)
now.
Sorry for my confusion I will try to avoid such a faux pas in future.
>> >> Could you all _please_ find to a normal tone of communication?
>> > Why do you care?
>>
>> Because I ...
>> 1) ...don't like the amount of mails on that particular topic written so
>> far in relation to the amount of interesting mails.
>
> Me too. Anyway I do think I got a bunch of interesting mails regarding
> the topic I opened.
>
> Anyway for further comments I suggest using mail. So feel free to send
> me a mail to point out any misbehaving from my side.
IMHO all important things (from all sides) are said and we should find to a
normal way of discussing.
But thanks for the very polite answer on my wrong accusations - I don't
know if _I_ would have been so rational.
Regards,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> Friedrich Dominicus wrote:
> > Please point out where I'm going personal.
>
> You have criticized Rainer in having a bad quoting-style - this is ok
> but it is IMHO (!!!) _not_ ok to make any assumptions on any intentions of
> him or maybe his *honor*- this is not constructive.
It seems to me that you are confusing Friedrich and me. To the best
of my knowledge, in recent times only I took public exception to
Rainer's quoting (not style) in this forum.
Furthermore I don't know where "honor" came into this discussion at
all. We are not doing Klingon style inquisitions in here, where I
jump around and screem "You have no honor, you despicable excuse for a
warrior". What I did in fact say was (available under this Message-ID
at your favourite news archive: <··············@orion.bln.pmsf.de>):
> As long as you engage in misleading quoting tactics, I don't see how
> one can have intellectually honest discussions with you.
If you think that I thereby questioned his honor, you think in
different categories than I do[1].
What I do think is that precision in attributing the utterances of
others, is a necessary, though not sufficient condition to keeping
useful discussions alive, especially on Usenet.
Regs, Pierre.
Footnotes:
[1] Honor is much too often used in relation to persons, and not
deeds, which I think is the wrong way to think about both people
and deeds. Furthermore I find the term honor to have been much
too much abused in the course of mankind, so that I think that
other, much more specific terms might serve us much better.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Pierre R. Mai wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> Friedrich Dominicus wrote:
>
>> > Please point out where I'm going personal.
>>
>> You have criticized Rainer in having a bad quoting-style - this is ok
>> but it is IMHO (!!!) _not_ ok to make any assumptions on any intentions
>> of him or maybe his *honor*- this is not constructive.
>
> It seems to me that you are confusing Friedrich and me. To the best
> of my knowledge, in recent times only I took public exception to
> Rainer's quoting (not style) in this forum.
Yes I've confused two things I wanted to say - sorry to you too for the
confusion.
> Furthermore I don't know where "honor" came into this discussion at
> all. We are not doing Klingon style inquisitions in here, where I
> jump around and screem "You have no honor, you despicable excuse for a
> warrior". What I did in fact say was (available under this Message-ID
> at your favourite news archive: <··············@orion.bln.pmsf.de>):
>
>> As long as you engage in misleading quoting tactics, I don't see how
>> one can have intellectually honest discussions with you.
Yes it is not a direct attack against Rainers "honor" but IMHO you had
not the right to suppose a bad intention without provoking a _really_ bad
reaction. If it is really important to you then it would have been much
better to make a friendly and constructive critic without any assumptions.
I say it again if you don't give your "oponent" the chance to escape the
battlefield - he will stand and fight a hopeless battle.
And yes I think like you that it is important to be careful with quoting as
I'am thinking it is (probably more) important to ensure that a critic goes
to the right adress ;-)
But we all make failures and I hope nobody supposes any bad intention in
_my_ mistake.
Regards,
Jochen
--
http://www.dataheaven.de
In article <··············@ID-22205.news.dfncis.de>,
Jochen Schmidt <···@dataheaven.de> wrote:
> Erik Naggum wrote:
> > Just what _is_ it with you Germans?
>
> Hm... maybe I'am really dull because I do not know why it is so important
> to discuss such IMHO unimportant topics so emotionally like in the last
> posts. (and yes I mean all - Erik, Friedrich and Rainer!!!)
I'm not emotional. I'm calm. But I cannot accept Erik's
tone and his words. Nobody in this newsgroup ever
insulted somebody the way Erik does. I'm free to
quote a recent posting (this is a complete quote,
Pierre).
From: Erik Naggum <····@naggum.net>
Subject: Re: Commercial Lisp or Free Lisp
Date: 23 Jan 2001 00:00:00 GMT
Message-ID: <················@naggum.net>
References: <··············@mailandnews.com> <
·················@era.ericsson.se> <····························@news.is-
europe.net> <··············@ipanema.coling.uni-freiburg.de> <
············@nnrp1.deja.com> <···············@cley.com> <joswig-
·····················@news.is-europe.net> <
····················@typhoon.aracnet.com> <············@nnrp1.deja.com> <
················@naggum.net> <····························@news.is-
europe.net> <················@naggum.net> <joswig-
·····················@news.is-europe.net> <
··············@orion.bln.pmsf.de> <············@nnrp1.deja.com>
mail-copies-to: never
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: ··········@eunet.no
X-Trace: oslo-nntp.eunet.no 980291155 25011 195.0.192.66 (23 Jan 2001
23:05:55 GMT)
Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601;
gsm: +47 93 256 360; http://naggum.no; http://naggum.net
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
Mime-Version: 1.0
NNTP-Posting-Date: 23 Jan 2001 23:05:55 GMT
Newsgroups: comp.lang.lisp
* ······@corporate-world.lisp.de
| Pierre, I'm not responding to "amusing" - I'm respondig to
| the whole history of insults from Erik (including via personal
| email) over the years including this one. It is simply too much. It
| won't matter how much I quote...
Your years of hardship should be a suitable topic for therapy
sessions so
you can get over it, but it is entirely irrelevant here. This
newsgroup
is not about you and it's not about your prejudicial stupidity in
dealing
with people. Grow the fuck up, and discuss your opinions and ideas,
if
you _have_ any outside of your terrible personal experiences, which
by
all present accounts you are both resonsible for and deserve in full.
#;Erik
--
Performance is the last refuge of the miserable programmer.
Name **one** comparable posting from somebody else. He is accusing
me of "hardship", that I need "therapy sessions",
"prejudicial stupidity", need to grow up, a terrible
personal experiences, which I even "deserve in full".
Now, Jochen this tone is completely unacceptable to me.
How about you?
Show me a single posting in this style from another
member of the Lisp community. And this is not singular.
Erik has done it in the past. To multiple people.
I have little respect for people who are not making clear
that they are not accepting that. Anybody with a rest of
self-respect does not accept that. Instead we have
posts, where people complain about some minor quoting
issue (thanks, Pierre). Or others say: "I just
read the technical side" - this is also not a way
to deal with it. Next time he will insult you and
you will look puzzled.
Sorry Jochen, but either you are for an atleast basically
civilized tone - or not.
Rainer
Sent via Deja.com
http://www.deja.com/
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87n1chny63.fsf@frown.here>
······@corporate-world.lisp.de writes:
>
> Sorry Jochen, but either you are for an atleast basically
> civilized tone - or not.
I can not agree more. Rainer states it as clear as one can
expect. After clearing that let's come back to Lisp
Friedrich
······@corporate-world.lisp.de wrote:
> Sorry Jochen, but either you are for an atleast basically
> civilized tone - or not.
I do not know what you wanted to say me with that least sentence, but
fact is that I have not accusated you particularily but all people in this
heated discussion. The fact that I adressed my posting as an answer to Erik
is only because I first decided to say something on this topic after
reading his sidekick upon "Germans".
Please do not count this as a personal attack - I only do not think that it
would do any good to take this discussion any further.
I think too that Erik crosses the borders of good style by far with some of
his arguments or disarguments. I don't find all more "agressive" postings
of Erik "bad" or so - sometimes I like reading a good sidekick on a curious
formulated argument from one side - but this time it goes far to wide.
So IMHO we should try to forget that know and find some better topics to
discuss.
Regards,
Jochen
In article <··············@ID-22205.news.dfncis.de>, Jochen Schmidt
<···@dataheaven.de> wrote:
> ······@corporate-world.lisp.de wrote:
>
> > Sorry Jochen, but either you are for an atleast basically
> > civilized tone - or not.
>
> I do not know what you wanted to say me with that least sentence,
Sorry, I didn't mean you personally - but readers of c.l.l
in general. Sorry for the confusion.
> I think too that Erik crosses the borders of good style by far with some of
> his arguments or disarguments. I don't find all more "agressive" postings
> of Erik "bad" or so
Sometimes his "aggressive" style makes points very clear and
is refreshing. It get's bad when he crosses the line to
personal attacks.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Rainer Joswig
> | Sometimes his "aggressive" style makes points very clear and is
> | refreshing. It get's bad when he crosses the line to personal attacks.
>
> Now that you have posted just about everything you possibly can about
> your personal relationship to me and my "style", can you shut the fuck up
> about it? Are you so stupid you don't even understand how annoying you
> are and how destructive your continued babbling is? I think you do this
> on purpose to get back on top, but I don't accept taking the blame for
> _your_ transgressions. You have insulted and patronized me endlessly,
> and you are responsible for your own actions, all the time. Just accept
> it: You are not a person who should criticize others on behavior, quite
> the contrary, "prejudicial asshole" _still_ applies well to you, more so
> the longer you keep defending your right to attack and "describe" me.
Your continued disrepect of basic netiquette is telling.
"prejudicial asshole" - yep, another projection.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
······@corporate-world.lisp.de writes:
> I'm not emotional. I'm calm. But I cannot accept Erik's
> tone and his words. Nobody in this newsgroup ever
> insulted somebody the way Erik does. I'm free to
> quote a recent posting (this is a complete quote,
> Pierre).
I think you know that I don't insist on complete quotes. I insist on
quotes that do not mislead the casual reader, like taking one word
from a posting several paragraphs long, and quoting it on a single
line, without ellipses, in such a way that one could assume that that
was all Erik had written. Especially if this kind of quote selection
takes more work than a normal quote of the first line, which would
have indicated sufficiently that there was more to Erik's post than
this word, and that you only responded to the first one. A quote like
this:
> Amusing. That's spoken like a truly die-hard "consumer" type: That which
or like this:
> Amusing. [...]
would have been quite sufficient, and the first one would have been
less work, too.
> Name **one** comparable posting from somebody else. He is accusing
> me of "hardship", that I need "therapy sessions",
Just a minor point: I don't think one can accuse someone of hardship.
To quote:
Erik Naggum <····@naggum.net> writes:
> Your years of hardship should be a suitable topic for therapy sessions so
> you can get over it, but it is entirely irrelevant here. This newsgroup
This seems to be in reference to the suffering you have had to endure,
inflicted by Erik's "whole history of insults", to quote from you, a
couple of lines above:
Erik Naggum <····@naggum.net> writes:
> * ······@corporate-world.lisp.de
> | Pierre, I'm not responding to "amusing" - I'm respondig to
> | the whole history of insults from Erik (including via personal
> | email) over the years including this one. It is simply too much. It
> | won't matter how much I quote...
>
> Your years of hardship should be a suitable topic for therapy sessions so
> you can get over it, but it is entirely irrelevant here. This newsgroup
> self-respect does not accept that. Instead we have
> posts, where people complain about some minor quoting
> issue (thanks, Pierre). Or others say: "I just
If the issue would have seemed minor to me, I wouldn't have
complained.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>,
"Pierre R. Mai" <····@acm.org> wrote:
> I think you know that I don't insist on complete quotes. I insist on
> quotes that do not mislead the casual reader, like taking one word
> from a posting several paragraphs long, and quoting it on a single
> line, without ellipses, in such a way that one could assume that that
> was all Erik had written. Especially if this kind of quote selection
> takes more work than a normal quote of the first line, which would
> have indicated sufficiently that there was more to Erik's post than
> this word, and that you only responded to the first one. A quote like
> this:
>
> > Amusing. That's spoken like a truly die-hard "consumer" type: That which
>
> or like this:
>
> > Amusing. [...]
>
> would have been quite sufficient, and the first one would have been
> less work, too.
Pierre, please accept that I even could have quoted no word. In
no way my idea was to change the meaning (which is fruitless
anyway, since the original can be looked up). I didn't want
to quote any "content" - so I deleted as much as possible,
leaving an indication that Erik was writing someting.
I was purely trying to refer to style of discussion.
> > Name **one** comparable posting from somebody else. He is accusing
> > me of "hardship", that I need "therapy sessions",
>
> Just a minor point: I don't think one can accuse someone of hardship.
> To quote:
>
> Erik Naggum <····@naggum.net> writes:
>
> > Your years of hardship should be a suitable topic for therapy sessions so
> > you can get over it, but it is entirely irrelevant here. This newsgroup
>
> This seems to be in reference to the suffering you have had to endure,
> inflicted by Erik's "whole history of insults", to quote from you, a
> couple of lines above:
But I don't have any suffering to endure. This is all in his
imagination.
> > self-respect does not accept that. Instead we have
> > posts, where people complain about some minor quoting
> > issue (thanks, Pierre). Or others say: "I just
>
> If the issue would have seemed minor to me, I wouldn't have
> complained.
Compared to his abuse of c.l.l my oversight (see above)
is really minor.
Rainer
Sent via Deja.com
http://www.deja.com/
On Wed, 24 Jan 2001 07:29:48 GMT, ······@corporate-world.lisp.de wrote:
>Show me a single posting in this style from another
>member of the Lisp community. And this is not singular.
>Erik has done it in the past. To multiple people.
And he will keep doing it as long as he gets this kind of
attention. He's well beyond any help, so unless you're planing a trip to
Oslo, there's nothing you can do except ignoring him.
>I have little respect for people who are not making clear
>that they are not accepting that. Anybody with a rest of
>self-respect does not accept that. Instead we have
>posts, where people complain about some minor quoting
>issue (thanks, Pierre). Or others say: "I just
>read the technical side" - this is also not a way
>to deal with it.
Some people have the strange need to follow a guru, and it's a know fact
that will always choose the least suited person: Rev. Moon, Charles
Manson, Erik, you name it. Again, there's nothing you can do.
Forget him, plonk him and move on. :-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <··································@4ax.com>,
Fernando <·······@must.die> wrote:
> On Wed, 24 Jan 2001 07:29:48 GMT, ······@corporate-world.lisp.de wrote:
>
> And he will keep doing it as long as he gets this kind of
> attention.
This was my hope, too. But it is now going on for many
months. This used to be a place where
participants were not "assholes" or "fucks", no matter
what opinion they had.
> Forget him, plonk him and move on. :-)
Sigh. ;-)
Sent via Deja.com
http://www.deja.com/
In article <················@naggum.net>,
Erik Naggum <····@naggum.net> wrote:
> You can do your part in ensuring that I don't need to respond to your
> insane whining about what you cannto accept. Do something that _I_ can
> accept! That is clearly what you would have wanted me to do, right? So
> just _stop_ telling us about your hardships and personal problems.
I just ask you Erik, to behave like every other c.l.l participant
seems to be able to. Instead you are displaying your
whole collection of invectives multiple times now. Also
you are repeating your "therapy" crap and come up
with "wonderdrug" ideas.
Sent via Deja.com
http://www.deja.com/
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <871yttqxmd.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus <·····@q-software-solutions.com>
> | Feel free to think what you like.
>
> Oh, gee, thanks. I guess this is uncommon in your culture.
As uncommon as obviously in yours.
>
> | I have as much problems with people denying all the valuable insight
> | quantitative approaches have given and will give.
>
> And who might that be? Name the people who have denied more than just
> your abuse of the infinitely stupid LOC count.
You don't understand. I do not say LOC is the answer but say that
quantitative approaches can give you some valuable insight.
> Quantitative accuracy is
> not one of your strong suits, is it?
maybe, maybe not.
>
> Just what _is_ it with you Germans?
This is as idiotic as can be. I do not rant about Norwegians, but
probably you do not know better.
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <8766j5lyju.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus <·····@q-software-solutions.com>
> | You don't understand. I do not say LOC is the answer but say that
> | quantitative approaches can give you some valuable insight.
>
> Can you please _name_ the people who are DENYING ALL THE VALUABLE INSIGHT
> QUANTITATIVE APPROACHES HAVE AND WILL HAVE?
In one of you last mails you wrote:
>> I think I'm beginning to realize that I have a serious problem with every
>> quantitative approach to ideas and human relations, being increasingly
>> annoyed by people who don't "get" any qualitative approach at all.
>
> That's what you said you had
> a problem with, was it not? Have there been any such incidents here? If
> there have not and you're just shooting your mouth off with incredibly
> stupid insults, apologize for it, don't make it worse by defending your
> incredible stupidity.
I'm really stupid to discuss such stuff with you. But feel free to
ignore me, I do the same.
> It's people like you, who attack people for what
> they do not actually do, who make USENET so hard to live with, and you
> are consistently hung up in something that shows that you make up your
> own world instead of observing the real world in most other ways,
>too.
It's always nice to see you playing with words. Unfortunatly you don't
use this ability wisely.
Friedrich Dominicus wrote:
> Erik Naggum <····@naggum.net> writes:
>
> > * Friedrich Dominicus <·····@q-software-solutions.com>
> > | You don't understand. I do not say LOC is the answer but say that
> > | quantitative approaches can give you some valuable insight.
> >
> > Can you please _name_ the people who are DENYING ALL THE VALUABLE INSIGHT
> > QUANTITATIVE APPROACHES HAVE AND WILL HAVE?
>
> In one of you last mails you wrote:
>
> >> I think I'm beginning to realize that I have a serious problem with every
> >> quantitative approach to ideas and human relations, being increasingly
> >> annoyed by people who don't "get" any qualitative approach at all.
> >
The phrase "to ideas and human relations" is a restrictive qualifier. Therefore,
someone who says "I have a serious problem with every quantitative approach *to
ideas and human relations*" is not "denying *all* the valuable insight
quantitative approaches have and will have".
--
"The big dig might come in handy ... for a few project managers
whom I think would make great landfill." --Elaine Ashton
== seth gordon == ·······@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
>>>>> "Friedrich" == Friedrich Dominicus
>>>>> <·····@q-software-solutions.com> writes:
Friedrich> Erik Naggum <····@naggum.net> writes:
>> And who might that be? Name the people who have denied more than
>> just your abuse of the infinitely stupid LOC count.
Friedrich> You don't understand. I do not say LOC is the answer but
Friedrich> say that quantitative approaches can give you some valuable
Friedrich> insight.
The notion that "quantitative approaches can give you some valuable
insight" is nonsense if that quantity is not clearly based on a theory
that can be validated.
Sure, at the edges, there will be pathological LOC values that tell us
that "this program is really, really bad." But based on the steaming
scents that waft into one's nostrils whilst reading the code, that
outcome should already have been manifestly obvious.
But you've provided no evidence of there being theory any more sound
than the theory that lies behind astrology, namely _blind faith_.
>> Quantitative accuracy is not one of your strong suits, is it?
Friedrich> maybe, maybe not.
Ah, so your skills in this area lie in the same vein as with Technical
Analysis, (which does "quantitative analysis" to predict price moves,
devoid of any normative theory) and Astrology (which predicts the
future based the positions of stars in the sky, clearly a
"quantitative analysis"). And phrenology, the study of how the bumps
on your head determine your personality. ["After all, they're on your
head, and you can _count_ bumps, so _obviously_ there's useful insight
there!"]
Perhaps the best analogy would be that LOC is somewhat comparable, as
a measure, to an "Intelligence Quotient."
-> At one end of the scale, you've got people that are so many sigmas
off the mean that they're basically drooling morons.
-> At the other end of the scale, you've got people that are so many
sigmas off the mean that they find it troublesome to successfully
communicate with "more ordinary" human beings. [comp.lang.lisp
very likely has more than a few participants that fall into this
category.]
The extremes provide fairly obvious measures of "nonconformance;"
people with IQs on the Stanford-Binet scale between about 95 and 105
are "pretty normal," whilst those that diverge from those regions are
likely to see "some implications" from the divergence.
There is "great obviousness" to much of the interpretation:
-> IQs that are "way out there" tend to have massively noticeable
effects.
-> People that _appear_ massively stupid or massively intelligent
probably do have low/high IQs.
And in similar fashion, quantitatively interpreting anything other
than "massive" divergence from the mean is pretty much as meaningful
as reading tea leaves for your fortunes.
If one person has a measured IQ of 107 and another has a measured IQ
of 111, what we can imply from that about the way they think is Pretty
Much Nothing. IQ is measuring an aggregate of a bunch of things, and
the guy with IQ of 111 may be a "math whiz" who spells badly whilst
the IQ of 107 might have resulted from being "metaphorically above
average" as well as "math-challenged."
In other words, a "4 point" IQ difference just isn't terribly
meaningful for anything useful. It explicitly _doesn't_ provide you
with "meaningful insight." The _only_ things that can be said based
on the numbers are _statistical_ comments that don't actually provide
insight about the individuals involved.
And that's about what you get by counting lines of code. Something
involving a number that, devoid of clear _qualitative_ context, is
likely not to be terribly useful.
But it's quite clear that you'd rather read the tea leaves of LOC than
learn about programming.
--
(reverse (concatenate 'string ····················@" "454aa"))
http://vip.hyperusa.com/~cbbrowne/lisp.html
BDOS ERROR ON A:
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3wvbd6go3.fsf@cley.com>
* cbbrowne wrote:
> The notion that "quantitative approaches can give you some valuable
> insight" is nonsense if that quantity is not clearly based on a theory
> that can be validated.
I think that's not quite right. The discovery of some measurable
quantity can point you at a theory. One recent example is the
correlation between orbital velocities of stars at the edge of
galaxies and the mass of the black hole at the centre: people
discovered that there was quite good correlation, despite the fact
that the stars can not gravitationally `see' the black hole, and this,
I believe, has led to a theory of galaxy formation which explains the
figure.
In order for the quantitative approach to be useful you need, I think, to
demonstrate some statistically significant correlation between the
quantity you are measuring (here LOC) and some other quantity which is
not trivially the same thing (say character count, up to some fudge
factor). Actually I don't think that's enough, but you at least need
that.
(this is not to disagree with the rest of your post)
--tim
Tim Bradshaw <···@cley.com> writes:
> * cbbrowne wrote:
>> The notion that "quantitative approaches can give you some valuable
>> insight" is nonsense if that quantity is not clearly based on a
>> theory that can be validated.
> I think that's not quite right. The discovery of some measurable
> quantity can point you at a theory.
You're left with significant risk of creating a theory that merely
fits the facts rather than explaining them.
> In order for the quantitative approach to be useful you need, I
> think, to demonstrate some statistically significant correlation
> between the quantity you are measuring (here LOC) and some other
> quantity which is not trivially the same thing (say character count,
> up to some fudge factor). Actually I don't think that's enough, but
> you at least need that.
I agree that in physics, there tends to be some merit to "fitting
theory to facts" as this ultimately leads to having a theory that can
be further tested against further facts.
Software engineering is a mite fuzzier than physics...
--
(reverse (concatenate 'string ····················@" "454aa"))
http://vip.hyperusa.com/~cbbrowne/nonrdbms.html
Why is it that when you transport something by car, it's called a
shipment, but when you transport something by ship, it's called cargo?
From: Will Deakin
Subject: In the blue yonder of o.t. [was Re: Commercial Lisp or Free Lisp]
Date:
Message-ID: <3A795476.10209@pindar.com>
········@hex.net wrote:
> You're left with significant risk of creating a theory that merely
> fits the facts rather than explaining them.
Huh? My take on theories is that to be useful they must (1) fit
the facts are they are know and then (2) be useful to gain an
insight into what would happen given if applied to a different
set of facts.
This in no way would then go and `explain' what is happening.
Maybe this is due to my worry about using the word `explain'. The
reason why I say this is that e.g. in QM you can describe to a
painful accuracy the interaction between an electron and a proton
to form a hydrogen atom. However, although having studied this,
*I* would be damned if I could say that I could explain what is
going on.
> I agree that in physics, there tends to be some merit to "fitting
> theory to facts" as this ultimately leads to having a theory that can
> be further tested against further facts.
Cheers! :)
> Software engineering is a mite fuzzier than physics...
Sure. I realise there is some merit in have some kind of handle
and/or model that allows you to operate. If I didn't have some
kind of picture in my head that `explains' how a car works, say,
then it would be hard to drive to work[1].
But it seems to me that it is absurd to have a theory that
doesn't fit facts. Or that you don't try and modify the theory
when/where the theory fails. At least, in the last resort, try
and map problem areas.
Also, in my experience, physics is pretty fuzzy too. However,
one of the major tasks of `doing' physics is to try and put
numbers to show how fuzzy things are.
:)will
ps: To show how retentive this can be: whilst trying to time the
execution of a couple of pieces of code and the results seemed to
be inconclusive, I ran the old and new code 500-odd times and
with a quick bit of code I found that:
threadtest:
old 2.10233 +/- 0.00015
new 1.90717 +/- 0.00016
From the errors I am confident that the new threadtest runs
~1.10 times faster. If I was really, really sad I could then work
out the error on the ratio but life *really* is too short ;)
[1] as in `Wooo when I turn this wheel something strange happens.
Ahhhhrrrgh (sound of car horn dopplering past the window). That
was close. I wonder why my car lurched suddenly toward the
oncomming traffic.' :)
From: Tim Bradshaw
Subject: Re: In the blue yonder of o.t. [was Re: Commercial Lisp or Free Lisp]
Date:
Message-ID: <ey3itmo4sc6.fsf@cley.com>
* Will Deakin wrote:
> ········@hex.net wrote:
>> You're left with significant risk of creating a theory that merely
>> fits the facts rather than explaining them.
> Huh? My take on theories is that to be useful they must (1) fit the
> facts are they are know and then (2) be useful to gain an insight into
> what would happen given if applied to a different set of facts.
I think there's a difference between physics and software engineering
here. In physics there's some kind of idea that the model you
invent/discover for the world kind of *is* the world -- GR is the way
it is because that's how the world is in some sense for instance[1].
BUT SW engineering is clearly at the top of great pile of things,
in terms of which it can be explained. So for SW engineering it's
much more reasonable to expect that a theory should explain as well as
describe.
--tim
Footnotes:
[1] of course there are infinite philosophical arguments to be had
here, but I am not an academic so I will just ignore them as
being to silly to merit other even this footnote.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> But you'are a "consumer" kind of guy,
Well, this is obviously wrong, so I won't bother with the rest.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Erik Naggum <····@naggum.net> writes:
> you can no longer fathom the _existence_ of needs that cannot be covered
> by or in the mass market.
One such need, is the need for a development environment that is as
easy to use remotely as it is locally. It just doesn't register as a
feature in the mass market, because the dominant paradigm is one
luser, one machine in their face.
Even with X, most GUI IDEs are not really usable over anything but
fast LANs. I know that ACL and LW can be built so that one can use
the GUI or the Emacs interface, so it's not directly a issue for
Common Lisp.
--
Craig Brozefsky <·····@red-bean.com>
In the rich man's house there is nowhere to spit but in his face
-- Diogenes
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Erik Naggum
> | But you'are a "consumer" kind of guy,
>
> * Rainer Joswig
> | Well, this is obviously wrong, so I won't bother with the rest.
>
> Amusing.
Erik, a discussion with you is a waste of time. Sorry.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <················@naggum.net>, Erik Naggum <····@naggum.net>
> wrote:
>
> > * Erik Naggum
> > | But you'are a "consumer" kind of guy,
> >
> > * Rainer Joswig
> > | Well, this is obviously wrong, so I won't bother with the rest.
> >
> > Amusing.
>
> Erik, a discussion with you is a waste of time. Sorry.
As long as you engage in misleading quoting tactics, I don't see how
one can have intellectually honest discussions with you.
Regs, Pierre.
For the benefit of future readers, here's the first paragraph (of
several) of Erik's response (<················@naggum.net>) in its
unabbreviated entirety:
Erik Naggum <····@naggum.net> writes:
> * Erik Naggum
> | But you'are a "consumer" kind of guy,
>
> * Rainer Joswig
> | Well, this is obviously wrong, so I won't bother with the rest.
>
> Amusing. That's spoken like a truly die-hard "consumer" type: That which
> does not immediately match your obvious needs, is discarded unseen, like
> an idle browser in a bookstore lets an unfocused eye scan the backs of
> books that would dramatically change his life if he read them.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>,
"Pierre R. Mai" <····@acm.org> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > In article <················@naggum.net>, Erik Naggum <····@naggum.net>
> > wrote:
> >
> > > * Erik Naggum
> > > | But you'are a "consumer" kind of guy,
> > >
> > > * Rainer Joswig
> > > | Well, this is obviously wrong, so I won't bother with the rest.
> > >
> > > Amusing.
> >
> > Erik, a discussion with you is a waste of time. Sorry.
>
> As long as you engage in misleading quoting tactics, I don't see how
> one can have intellectually honest discussions with you.
Pierre, I'm not responding to "amusing" - I'm respondig to
the whole history of insults from Erik (including via personal
email) over the years including this one. It is simply too much. It
won't matter how much I quote...
If you don't understand the context, don't waste your
time. But you should atleast ask first and then
use the word "honest".
Sent via Deja.com
http://www.deja.com/
······@corporate-world.lisp.de writes:
> Pierre, I'm not responding to "amusing" - I'm respondig to
> the whole history of insults from Erik (including via personal
> email) over the years including this one. It is simply too much. It
> won't matter how much I quote...
You are operating in a public forum, and the purpose of quoting is to
provide enough context to your replies to give third parties at least
a chance to understand the items you are responding to. The selection
you did quote was not in any way conducive to that goal, but rather
sufficient to misrepresent the writing of Erik in such a way that a
casual reader would have got the impression that Erik's posting
consisted solely of this passage. Since it took a deliberate effort
to quote as you did (you could just as easily have left the first line
stand as a whole, thereby alerting readers to the fact that there was
more to Erik's message), one must assume that this was a deliberate
decission.
It is that sort of behaviour that I took exception to, and still do.
> If you don't understand the context, don't waste your
> time. But you should atleast ask first and then
> use the word "honest".
I understood the context quite well. No part of this context
justifies your actions in my opinion, nor would any of that context be
neccessarily apparent to third-parties.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>, "Pierre R. Mai"
<····@acm.org> wrote:
> ······@corporate-world.lisp.de writes:
>
> > Pierre, I'm not responding to "amusing" - I'm respondig to
> > the whole history of insults from Erik (including via personal
> > email) over the years including this one. It is simply too much. It
> > won't matter how much I quote...
>
> You are operating in a public forum, and the purpose of quoting is to
> provide enough context to your replies to give third parties at least
> a chance to understand the items you are responding to. The selection
> you did quote was not in any way conducive to that goal, but rather
> sufficient to misrepresent the writing of Erik in such a way that a
> casual reader would have got the impression that Erik's posting
> consisted solely of this passage.
Na, come on. Nobody is quoting whole messages when a single
word is enough. In the time of threaded newsreaders and
Dejanews it is easy to restore a bit of context. Long
time c.l.l readers know what the topic is. If I lost a
few newbies in this discussion - they better skip over it.
> It is that sort of behaviour that I took exception to, and still do.
Registered, but you can easily ask me he what I meant.
And then come up with some "honesty" stuff. This to
cheap, Pierre.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <················@naggum.net>,
Erik Naggum <····@naggum.net> wrote:
> * ······@corporate-world.lisp.de
> | Pierre, I'm not responding to "amusing" - I'm respondig to
> | the whole history of insults from Erik (including via personal
> | email) over the years including this one. It is simply too much. It
> | won't matter how much I quote...
>
> Your years of hardship should be a suitable topic for therapy sessions so
(remark for Pierre/etc.: Again I'm deliberately not quoting the
whole message. If you are interested, please look it up.)
It is clear to me that the Lisp community is very
diverse and that there won't be agreement over
all topics. I do also see heated discussions about
some topics not as bad. But there
is a line - and you are constantly crossing it.
I'm not even going into the details of your
argumentation, I'm still looking at the surface.
Look, Erik, the style of your response is exactly what I'm
talking about. Aren't you a member of the ALU Board? Weren't
you (trying to?) joining the ANSI CL committee? Aren't
you a highly visible poster on this newsgroup?
Shouldn't you be a *positive* example for the Lisp
community? Instead you are talking about "therapy"
and such. This is doing no good.
Erik, how should we go on?
Sent via Deja.com
http://www.deja.com/
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> No, you're talking about _your_ problems with my style, and I don't care
> one hoot about _your_ problems as long as you don't have _any_ problems
> with your own style, which allows just about anything destructive and
> indidious as long as you feel morally justified to abuse a newsgroup with
> your personal issues.
Erik, is it "projection"? Projecting yourself on other people?
You might find a lot about it in the literature.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Rainer Joswig
> | Erik, a discussion with you is a waste of time. Sorry.
>
> Geez. Prejudicial asshole, too?
It's experience with you.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Rainer Joswig <······@corporate-world.lisp.de>
> | It's experience with you.
>
> It's been a waste of time for _you_ to discuss anything with me because
> you make up your mind about the one thing that nobody can know -- the
> future --
Erik, it's mostly because of how you discuss with people and what
you are calling them. Everytime I get you out of my killfile and
try to see whether it is possible to enter a discussion
with you, stuff like "asshole" comes up (which is
harmless compared to some other stuff you pulished here
in this forum last year and which I just don't accept
for me). I'm trying to not insult you and I also don't give
you any advice - I'm just giving *you* (and not Pierre
or anybody else) a bit feedback. If this gets resolved sometime,
we can reenter discussion and I'd be happy to listen to
your opinions.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Erik Naggum <····@naggum.net> writes:
> [discussion about consumer vs infrastructure types]
Thank you for posting this article. It is one of the most intelligent
and thought-provoking things I've read of late. Needless to say, I
think you are right on target. To be clear, I think your _ideas_ are
on target - it is unimportant to me whom you believe is in which
category.
Perhaps with this distinction in mind, or some other suitable
distinction, people may realize that debates such as gui ide vs emacs
and free vs commercial really are religious in nature and that there
is no Truth which everyone could possibly agree upon.
Best,
-Jason
>>>>"EN" == Erik Naggum schrieb am 20 Jan 2001 10:10:21 +0000:
EN> | Common Lisp is a bit like the "emperor without clothes".
EN> Common Lisp is a bit like the invisible background industry
EN> that provides you with the cheap fabric and machinery to make
EN> your fancy clothes for the public.
Well, you seem to have suggested in some other postings that one of
the commercial available CL-implementations provide you with, umm,
err, what?, better? but still cheap fabric and machinery than the
freely available ones. Could you please describe in which points you
see these as superior? From your reaction to Rainers reactions, I
guess that you may have been thinking of some other points.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Und ja, es ist September im Netz." "Du meinst, es fallen wieder die
Luser vom Baum^W^Waus dem Usenet?" "Nee, eher in's Usenet - und dann
gleich `ein'. Aber es ist ja immer September im Netz."
-- A.Barth und J.Luster in de.alt.sysadmin.recovery
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> I have no goodwill left for this newsgroup, now, especially towards
> anything that has to do with that sick fuck Rainer Joswig.
That's good news.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Erik Naggum
> | I have no goodwill left for this newsgroup, now, especially towards
> | anything that has to do with that sick fuck Rainer Joswig.
>
> * Rainer Joswig
> | That's good news.
>
> I think people ought to remember that response for a long time.
> It is not the kind of thing that mentally healthy people say.
Erik, you simply will have some time to rethink your
rotten manners you display on c.l.l . That's a big
plus. Maybe you get a clue.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
On 24 Jan 2001 18:45:59 +0000, Erik Naggum <····@naggum.net> wrote:
> When one party, here Rainer Joswig, feels so morally justified in his
> completely unjustifiable behavior that he has the gall to give advice to
> someone he mistreats as badly as this sick fuck does me,
Do you really believe all this crap or is it just for the show? _You_ are the
only one showing an unjustifiable behavior. I've seen many net.jerks but man,
your cheek is amazing!
> no holds are barred once he feels he is sufficiently justified. (When
> this happens to a _German_, the world needs to be much more on guard than
This isn't the first time I see you insulting someone for the mere
fact of been a German. Please enlighten me: does this qualify you as a
"prejudicial ass hole" or not yet?
> For what is Rainer Joswig's response when he has killed something good in
> another person?
Something _good_????
> "That is good news."
Oh come on, he probably thought that were going to leave the ng alone for a
while. Don't be so touchy.
> This sick thing wants Common Lisp to be a mass-market product!
Wait a minute, he never said that, that's you own delirium. Don't take your
own hallucinations so seriously, you should know better by now. Having
trouble to tell the difference between reality and delusions lately?
Take your pills and enjoy life.
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <················@naggum.net>,
Erik Naggum <····@naggum.net> wrote:
> * Rainer Joswig
> | Erik, you simply will have some time to rethink your rotten manners you
> | display on c.l.l.
>
> Maybe I'll think this is sage advice the day you know what it means.
>
> Taking advice from people who work so hard to prove it doesn't work is
> not something I consider worth wasting my time on.
>
> When one party, here Rainer Joswig, feels so morally justified in his
> completely unjustifiable behavior that he has the gall to give advice to
> someone he mistreats as badly as this sick fuck does me, we no longer
> face a mentally healthy person. Rainer Joswig needs treatment for his
> inability to relate to his own actions and needs serious work to come to
> the point of mature adulthood where he can take responsibility for what
> he does. Failure to take such responsibility is a very strong signal to
> society that the person is dangerous -- nobody can be safe from this
> thing's willingness to blame them for his behavior, and as we have seen,
> no holds are barred once he feels he is sufficiently justified. (When
> this happens to a _German_, the world needs to be much more on guard than
> when it happens to people from cultures who do not have a long history of
> using such moral justification of prejudice to commit atrocities against
> homosexuals, to take but one of _many_ examples.)
>
> For what is Rainer Joswig's response when he has killed something good in
> another person? "That is good news." This sick thing wants Common Lisp
> to be a mass-market product! Consider why propaganda is so important to
> mass marketing for a minute and relate that to his defense of his current
> behavior and his lack of ability to relate or take responsibility, and
> you do not have something you would want to mass-market _anything_.
>
> | Maybe you get a clue.
>
> Yeah, the clue is simple: Ferret out the criminally insane faster. When
> you showed everybody that you were a sick, prejudiced asshole with many
> serious personal problems, I should have left you alone. I keep thinking
> it is possible to talk to things like you, but that is a grave mistake:
> You are on longer human, by virtue of your willingness to de-humanize.
>
> #:Erik
> --
> Performance is the last refuge of the miserable programmer.
>
Now you are starting to show the real Erik Naggum. *This*
post will be remembered a long time, for sure Erik.
You even start talking of me as a "thing": "This sick thing ...".
This is the language of the "evil".
I ask the c.l.l reader to read his posting very carefully
and then ask yourself, whether you would be willing
to accept such a manner in this newsgroup. Remember
it is not just me, but he has done this to a lot
of excellent members of the Lisp community in the last
year.
See just one example from 8/25/2000:
http://x59.deja.com/getdoc.xp?AN=662341510&CONTEXT=
980394567.1545207830&hitnum=0
People on c.l.l get insulted by Erik Naggum for a long time.
The way he does it is beyond any civilized way
to communicate on this newsgroup. Letting him go with
this is really no solution. It has been tried, but it
seems to get worse all the time - together with
degrading "technical quality" in his postings otherwise.
Erik Naggum's postings are an all-time low to comp.lang.lisp,
no matter how good he hides behind some technical
knowledge.
How sad - for comp.lang.lisp .
Rainer Joswig.
Sent via Deja.com
http://www.deja.com/
Erik Naggum wrote:
> no holds are barred once he feels he is sufficiently justified. (When
> this happens to a _German_, the world needs to be much more on guard
> than when it happens to people from cultures who do not have a long
> history of using such moral justification of prejudice to commit
> atrocities against homosexuals, to take but one of _many_ examples.)
This isi enough!
I do not think that anyone not even *YOU* is justified in spreading such a
complete *SHIT* in the world.
I don't know how you will ever make such a faux pax good. This KILLS any
reason to here on any of your words any more.
(Why should I here to someone who thinks of me all the time as a NAZI)
I think no other land than Germany and no other people than the people of
_my_ AND my Parents age are more aware and guarded of German history.
In Germany _any_ tone of national awareness is coupled with a bad taste of
a possible nationalistic touch.
However - I was born 33 years after this time. Both of my parents was born
_after_ this time TELL me what lets YOU think that I'am a NAZI heh?
Probably you are a NAZI? _Your_ behavior is muchmore related to this.
Probable you are just a completely paranoid, lonely, bitter old man.
Get a life! Old man!
So please be quiet with such linguistic shit before "the evil Germans come"
_not_ Regards,
Jochen Schmidt
Erik Naggum <····@naggum.net> writes:
Why can't people both feel _and_ think at the same time?
because doing so requires balance, which to many imply motionlessness,
which to many imply death. people often swerve around to feel alive.
there is a perceptual analog -- your eyeballs twitch involuntarily at
10Hz to be able to gather new info.
thi
Jochen Schmidt <···@dataheaven.de> writes:
> I think no other land than Germany and no other people than the people of
> _my_ AND my Parents age are more aware and guarded of German history.
> In Germany _any_ tone of national awareness is coupled with a bad taste of
> a possible nationalistic touch.
Let me give you my full support. I am a norwegian, but once worked in
Germany for three years. My general impression is that people in large
parts of Germany are significantly *less* xenophobic than norwegians.
The sad fact is that the kind of anti-german prejudices that Erik
shows when he turns his flamethrower on full power, are still not
uncommon :-( (and only contributes to the picture of the xenophobic
norwegian).
And regarding history: Over the last few years, several cases of severe
abuse by norwegian health authorities have been uncovered. As late
as in the 1970s, mentally retarded were lobotimized, and "tater" (a
minority with unclear origins, but gypsy-like lifestyle) were sterilized.
(And now it's about time to end this ridiculous thread)
--
(espen)
Erik Naggum <····@naggum.net> writes:
> I have limited my comments to _prejudiced Germans_. Pay attention!
If the sentence "Just what _is_ it with you Germans?" (in Message-ID:
<················@naggum.net>) was covering only the prejudiced
germans, I think you are obeying a quite nonstandard ruleset for
anaphora and definite descriptions.
--
(espen)
Erik Naggum <····@naggum.net> writes:
> Oh, Christ! Lighten up! Even Jochen understood that as a joke.
Of course. I forgot that I was watching Fawlty Towers.
Please forgive me!
--
(espen)
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> | However - I was born 33 years after this time.
>
> No, you weren't. The German culture is largely unchanged over the past
> 400-500 years in its philosophical structure. This structure has
> produced a number of very serious problems, and they last to this day.
> The German culture has been amenable to these problems like no other
> Western culture has, and to this day, large fractions of the population
> harbor ideas that betray a lack of understanding of their dangers. One
> of them is the uniquely prejudicial structure of your core philosophy.
> (Like the French and Japanese are xenophobic, but that is _not_ the same
> as prejudice of thought.) Kant's expression of das ding an sich vs das
> dign f�r mich implies the existence of the true nature of something, and
> once you know the true nature, you no longer need to look at it. This is
> the core problem with prejudicial thought, and it cannot survive without
> the strong willingness to stop observing. When this willingness is made
> an ideal, however, as it is when das ding an sich is used to argue for a
> Pflicht-Ethik where somebody _else_ knows the true nature of something,
> like what is virtuous, das ding f�r mich is reduced to irrelevance, even
> if it is the only real truth anyone can observe.
Seeing Kant in this tradition is only something you are
making up.
> that battered gray matter. The likelihood that Rainer Joswig will ever
> be _able_ to listen
I'm able to listen. I'm not willing to listen - unless you follow
basic rules of human communication. Then we can speak. You
don't provide the necessary condition for that right now.
But reading through your postings makes me wonder if it
is not only the lack of manners and civilized
behaviour , but something more severe. Maybe you
should look for an expert to get professional help.
Everything you mention looks more like a projection
of your own personality. Some of your (deeper) ideas
(not the technical, but the cultural etc. ideas) you
express here, might be - superficially looked at -
interesting, but are (not always, but often) fundamentally
flawed (like for example the application of the consumer/provider
distinction and the distinction itself, like you described
it earlier). It is interesting to discuss that, but as I
said, necessary preconditions for a discussion must be met.
Another thing I've noticed is, is that you make a lot
of assumptions about certain people without knowing
any direct context - just from a historic or cultural
context that you have. You seem to be interested to
discuss with people on an "intellectual" level and you
seem to look for "intellectual" people (just my observation
of some of your attempts to get a certain communication
going and you expressing interest in such a communication)
- but it seems difficult to maintain the necessary conditions
over some time during a discussion with you. Another
thing that I observe is that you have a certain technical
excellence which you display here on c.l.l on a regular
base, that you are doing this very self-assured (with
a complete positive meaning) and that you quite
often get positive feedback about that. On the other hand
you seem to assume that some people are not self-assure
and not reflecting (seeing the scope and limits of their
abilities). Sometimes you mention the topic of
"proving something" (which interestingly doesn't seem
to be problematic in your technical side, where
I have the feeling that *you* aren't (!) trying
to "prove anything" (which is positive) - you are
just trying to be helpful and share knowledge and experience)
- but you seem to express that some other person either has
to prove something (to be worth for a discussion) or that
the other person actually tries to prove something
(and thus is not equal terms). Not a "win/win"
situation - the other person can only "lose".
You mention the distinction between emotion and
thought (-> technology vs. nature), as it were that
nobody else did detect the problems that exist in
this area. The limits of "rationalism" and
our biological heritage are well known by other people,
too. Your assumption about what people think, their
cultural background etc. is limiting you to contact
people (like me) - because they don't accept your
particular set of preconditions. Usually participants
won't display much of their personality (background,
culture, family, experience, interests, ...) on
a discussion channel like c.l.l. This has many reasons
(like limits of the channel, it is simply not necessary,
off-topicness, personal choice, being shy, ...).
I know that there are/were readers of c.l.l that are not
even posting, just because they are shy and don't
want to be "judged" as a person by the quality of their
technical contribution. If you really want to understand
or know about the background of a certain person,
it is not sufficient look at the top-level domain
of their email address ("de" in my case). Erik, I know next
to nothing about you and I'm openly saying that. I just
have not enough context to even attempt to have
an idea about your person. Almost all I see is your
stream of postings on c.l.l - which only is a poor
channel, considered the limited amount and quality of information
a Usenet group can transport about a human personality.
But given such a low-bandwidth channel, you should make
more effort of being polite/forgiving/non-prejudicial/etc.
In German we have the word "Narrenfreiheit" (something
like "fool's license"), where the fool/Narr is entertaining
the king/K�nig - he is allowed to say things no other is allowed.
But if the K�nig is not feeling entertained anymore, the Narr
loses his job (or even his life). It is my impression
that you act here on c.l.l like you have "Narrenfreiheit"
(based on some reasons I can't follow) - but you don't
have Narrenfreiheit and you crossed the boundaries of
"Narrenfreiheit" with a few of your last postings.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Erik Naggum wrote:
> * Jochen Schmidt
> | (Why should I here to someone who thinks of me all the time as a NAZI)
>
> You shouldn't, but nobody does that. Please have a close look at what I
> _actually_ say and just quit that stupid defense act. Examine why you
> feel attacked. It isn't from what I said.
Yes sure but saying that the world should be _more_ careful if a german
shows any signs of prejudice and pointing particularily at german history
is at least more than a sidekick to this topic. Yes you have not said
"Nazi" at all but it was the central point most people (and me) have seen
by reading your statement. So it would have been better if you don't meant
that to you ensure that what you say cannot be misunderstood this way.
I felt particularily attacked because I'am a extremely non-nationalistic
person. For _me_ it counts _nothing_ that you come from Norwegen.
I see it neither positive nor negative that someone comes from somewhere.
But I hate it to get prejudiced by someone only because I'am german.
Particularily when someone points to historic facts (also when it's
implicit and not explicit) that I can not change because I've not lived at
all to that time.
> | I think no other land than Germany and no other people than the people
> | of _my_ AND my Parents age are more aware and guarded of German history.
>
> I mostly agree with this, but the problem with the way you respond is
> that you think the specific incident you have in mind was the one that I
> had in mind, and the only one I had n mind. That is not the case and
> you, too, make a number of unwarranted assumptions that do not stand to
> scrutiny. Pay attention to what I write. I work hard to make it
> precise...
Everyone can make failures and IMHO you should have trying harder to
eliminate the above stated topics if you don't want to get misunderstood.
> | In Germany _any_ tone of national awareness is coupled with a bad taste
> | of a possible nationalistic touch.
>
> This isn't about any nationalistic touch at all. READ WHAT I WRITE! If
> even you can't pay enough attention to prevent yourself from blowing up
> over something I have not said, I'm losing _all_ hope for Germany.
Sometimes I have the impression by reading your replies that you answer
them while first reading them. I do this too sometimes. But sometimes is is
not such a good idea. In this particular case and in your answer to Rainer
in this subthread you make the situation much more difficult. In my case I
say here nothing other than I've said above. I had _not_ read your reply to
the time of writing of my part you critizice here and as _I_ have read
Rainers reply there was a lot of points with what he has tried to give you
a hand.
> | However - I was born 33 years after this time.
>
> No, you weren't. The German culture is largely unchanged over the past
> 400-500 years in its philosophical structure. This structure has
> produced a number of very serious problems, and they last to this day.
> The German culture has been amenable to these problems like no other
> Western culture has, and to this day, large fractions of the population
> harbor ideas that betray a lack of understanding of their dangers. One
> of them is the uniquely prejudicial structure of your core philosophy.
> (Like the French and Japanese are xenophobic, but that is _not_ the same
> as prejudice of thought.) Kant's expression of das ding an sich vs das
> dign f�r mich implies the existence of the true nature of something, and
> once you know the true nature, you no longer need to look at it. This
> is the core problem with prejudicial thought, and it cannot survive
> without
> the strong willingness to stop observing. When this willingness is made
> an ideal, however, as it is when das ding an sich is used to argue for a
> Pflicht-Ethik where somebody _else_ knows the true nature of something,
> like what is virtuous, das ding f�r mich is reduced to irrelevance, even
> if it is the only real truth anyone can observe. You see this dichotomy
> at work in people who exclaim that they know what somebody is _really_
> like if they see something they _want_ to be what others are like, and
> then stop listening or observing. There are people who think they know
> what somebody is _really_ like if they have black skin, right? They
> don't need to listen to the individal to know what _that_ person is
> like,
> because they already know "the black person an sich". Similarly, Rainer
> Joswig's dysfunctional brain has suffered a similarly anti-intelligent
> blow as a rabid racist, and reacts from a notion that lives _only_
> inside
> that battered gray matter. The likelihood that Rainer Joswig will ever
> be _able_ to listen to anything I say is smaller than that of a Ku Klux
> Klan leader discussing the future of community schools with a black
> Baptist priest, by virtue of his mentally deranged "decision" to stop
> dealing with the real world when he is so satisfied dealing with what's
> inside his sick mind. He is no longer reacting to what _I_ do, but to
> what that monster in his own mind is doing, and it is _tormenting_ him
> because he has found what he thinks is my "true nature", Naggum an sich.
> The sheer insanity of such a mental process as he displays is never
> going to become visible to him, because of his prejudicial thought
> processes and his obvious philosophical bent that it is always better to
> know the true nature of something over actually observing it.
>
> This isn't about your favorite hot spot, but how it came to _be_ the
> favorite hot spot, which is still largely unexamined in Germany due to
> the severe restrictions on access to early NSDAP literature, the
> prohibition against anything that could be termed "nazi effects", etc.
> Thus, the history is attempted buried, not understood. This is a move
> that has been criticized by historians for 50 years, now, so I'm hardly
> alone in being negative to the way you have _not_ dealt with it, no
> matter how much you have done to deal with it.
When talking on Kant - You certainly know "Der kategorische Imperativ".
Read between the lines what this means as I should have done in your
statement!
> | Probably you are a NAZI? _Your_ behavior is muchmore related to this.
>
> Oh, great. THINK! THINK, don't cave in to this stupid emotional shit.
>
> Why can't people both feel _and_ think at the same time? That stupid
> notion that these are antithetical or enemies is a learned behavioral
> trait with no support in biology or nature. It is not one of Germany's
> philosophical creations, but it has always been _very_ popular in German
> philosophy. Thought and emotion are supposed to work together, damnit!
> The human being, qua animal, has evidently evolved a brain with all its
> faculties because it helped the survival of species and individual
> alike, but now we have some bad cultures that argue that only half of
> the two
> most important functions of our brain should be in use at a time. Do
> you
> expect to work at full speed if you shut down half the engines? Instead
> of working at full speed, we find that people who shut down their
> thinking engine and fire up the emotional engine don't work at all and
> make so many idiotic mistakes that they are literally insane when they
> have shut down their thiking processes. This is what a bad philosophy
> can do to people, and it has evidently destroyed the working brain of a
> number of people here, who simply do not think if they can avoid it.
Here we are much on the way to "Descartes" but I don't think that this of
any value here.
IMHO you should try to overcome that national prejudice thinking - and yes
it is national prejudice thinking when you think of "Germans" other than on
e.g "Norwegians". It may be that people from on nations have often some
behaviors in common but _nobody_ likes to be generalized as only being
e.g. a "German".
So this was now really completely OT and I would enjoy to discuss with you
too - but please a bit more Lispy topic.
Regards,
Jochen
>>>>"JS" == Jochen Schmidt schrieb am Thu, 25 Jan 2001 15:52:31 +0100:
JS> I felt particularily attacked because I'am a extremely
JS> non-nationalistic person.
FWIW: I didn't[1]. And even less so when Erik explicitely restricted his
comments to "prejudical Germans" (whoever he might want to include in
such a set, at least I myself would not classify to belong to such a
group of people --- which may or may not tell a story about me, decide
for yourself. Who cares?). But I must admit that I was immediately
reminded of Goodwin's Law.
JS> IMHO you should try to overcome that national prejudice thinking
JS> - and yes it is national prejudice thinking when you think of
JS> "Germans" other than on e.g "Norwegians". It may be that people
JS> from on nations have often some behaviors in common but _nobody_
JS> likes to be generalized as only being e.g. a "German".
I believe that many people outside of Germany would not mind at all if
they were generalized (whatever that means in particular) as "<their
nationality>" [2]. This self-deniance of any nationalistic feelings is
a feature quite particular to Germans, I believe --- that's at least
my observation from several travels through various countries, both
inside and outside Europe. To make this clear, I am not at all sad
about this particular behaviour.
It is also pretty obvious that Germany and Germans are still seen with
some suspicion when it comes to prejudices [3] and the racist-motivated
instances during the last ten years surely haven't helped. (However,
one explicitly has to ask for an opinion on whether Germany still
shows signs of its racist history, while most people I've met outside
of Germany are much more interested in the unification.)
JS> So this was now really completely OT and I would enjoy to discuss
JS> with you too - but please a bit more Lispy topic.
ACK
In the big8, which group would be appropriate for this topic?
Holger
Footnotes:
[1] I would not want to qualify myself as being a "whatever"
person. Although I know what you want to say and would probably have a
similar opinion on the corresponding topics.
[2] Yes, I saw your "only", but throughout this flamewar, Erik has
said a lot more than just generalize someone as being German.
[3] Currently, an obviously totally stupid north-american girl posts
(in English, of course) to the German-speaking usenet groups related
to Linux. Full of non-sensical prejudices and insults about Germans,
but also about people like Prof. Tannenbaum or L. Torvalds. At
the same time, she has no clue whatsoever about any technical issues
but demands that we all should be thankful (and behave to her
accordingly) that the US saved not only Europe but also Russia, India,
the Gulf region etc. Prejudices of people are an interesting topic ---
but perhaps should be discussed in non-technical discussion groups.
np: Hagfish - She needs therapy
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Und ja, es ist September im Netz." "Du meinst, es fallen wieder die
Luser vom Baum^W^Waus dem Usenet?" "Nee, eher in's Usenet - und dann
gleich `ein'. Aber es ist ja immer September im Netz."
-- A.Barth und J.Luster in de.alt.sysadmin.recovery
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <877l3k5a80.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> (When
> this happens to a _German_, the world needs to be much more on guard than
> when it happens to people from cultures who do not have a long history of
> using such moral justification of prejudice to commit atrocities against
> homosexuals, to take but one of _many_ examples.)
Thanks for pointing our your opinion so clearly. I will save this
message for later citation if another German dares to have another
opinion than Mr Naggum. This has nothing to do any longer with c.l.f
it' just a sign that you run out of control.
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87wvbj3nc8.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
>
> | This has nothing to do any longer with c.l.f it' just a sign that you run
> | out of control.
>
> The only thing out of control here is your need to defend
>yourself.
Why should I defend myself? You do a better job on that as I ever
will. Now I have made up my mind about you Eric. You can't control
yourself, and you are not capable of seeing all the borders you
crossed. Rainer has pointed out how he feels about you behaviour and
what you really are. I do not have ot add anything.
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Erik Naggum <····@naggum.net> writes:
>
> >
> > | This has nothing to do any longer with c.l.f it' just a sign that you run
> > | out of control.
> >
> > The only thing out of control here is your need to defend
> >yourself.
>
> ... Now I have made up my mind about you Eric. ...
Still thinking that things and people don't change (including
yourself) as soon as you "make up your mind"? How can you learn
anything if you shut down your thinking process?
We have had and still have a bunch of people like you here. Thank god
(whoevert that might be) they get driven out.
Janis Dzerins
--
If million people say a stupid thing it's still a stupid thing.
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87ae8etevl.fsf@frown.here>
Janis Dzerins <·····@latnet.lv> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > Erik Naggum <····@naggum.net> writes:
> >
> > >
> > > | This has nothing to do any longer with c.l.f it' just a sign that you run
> > > | out of control.
> > >
> > > The only thing out of control here is your need to defend
> > >yourself.
> >
>
> > ... Now I have made up my mind about you Eric. ...
>
> Still thinking that things and people don't change (including
> yourself) as soon as you "make up your mind"? How can you learn
> anything if you shut down your thinking process?
I can come back if we get back to a more civilized behavior.
>
> We have had and still have a bunch of people like you here. Thank god
> (whoevert that might be) they get driven out.
You might read the thread again, and would not just spending blaiming
me for everthing written in it. And I won't get driven out, a lot of
people have shown clearly where my "shortcomings" regarding the
threads I were involved are. Why should I leave just because some
people make me angry?
I just can suggest looking trough the threads where people made good
remarks on why what seems to be useless. You might find out too that
there were some areas where good advice was given.
Friedrich
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87hf2ls7py.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus
> | I can come back if we get back to a more civilized behavior.
>
> Do you really think making such threats is civilized?
I can't see any threat in that sentence.
> Do your part,
> instead.
I do my part, so the sentence can be returned as "Do your part"
> (Note: I make no calls for a "return" to civilized behavior.)
Maybe you like the things as they are.
>
> The main reason netiquette discussions tend to be inflammatory is that
> the people who start them think they are above netiquette
>themselves.
Please point out where I'm going against the netiquette.
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87r91pqmg0.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> You explicitly
> seek to punish and reward people according to some idiosyncratic set of
> values.
My set of values included not blaming other of beeing assholes and the
like. I don not know how idiosyncratic that set of value is. You are
simply not able to no insult people. That is obviously your
problem. Oh sorry we are in usenet. I have to live with that insults
because this is usenet. So feel free ranting along. It's your way and
anything I will say will hardly change that. But hey it's you
responsibility, and who am I to say that you should change
that. Obviously this is insulting, gosh I can seel clear. If you say
I'm an whatever that is not insulting, attacking me for nothing else
but beeing a whatever is of coure not insulting. So obviously we got a
bit stuck. I hope I'm not so hopelessly stuck. But you wil point me
into the right direction I'm sure.
In article <················@naggum.net>, Erik Naggum <····@naggum.net>
wrote:
> * Friedrich Dominicus
> | My set of values included not blaming other of beeing assholes and the
> | like.
>
> So ask them not to behave in a way that has no other description. People
> _don't_ get called assholes when they aren't behaving badly. Is this
> really so hard for you to understand? Why is it OK to _behave_ like a
> rimshot asshole but not OK to _say_ people are? Don't _be_ nice, only
> _say_ nice? No wonder guys you are full of shit, is it?
[...]
It's time to end this thread, Friedrich. The point, that
there are limits to personal attacks and that such a
violent attitude against participants of comp.lang.lisp
does no good, has been made.
I do wish us all a nice sunny day with many new LOLC
(lines of lisp code), ;-)
Rainer Joswig
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87n1cdqi7z.fsf@frown.here>
Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> It's time to end this thread, Friedrich.
You're right. It's even time soon to apologize to the readers of
c.l.l. I've driven this thread way too far, way too off-topic.
Sorry guys, I try to do not let that happen again.
>
> I do wish us all a nice sunny day with many new LOLC
> (lines of lisp code), ;-)
;)))
With best regards
Friedrich
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <8766j33gc7.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus <·····@q-software-solutions.com>
> | Why should I defend myself?
>
> Beats me, too, but that's actually what you do.
>
> | Now I have made up my mind about you Eric.
>
> You don't seem to understand that such a statement is an indictment of
> yourself and is completely unrelated to me, but prejudice is like
>that.
Prejudice? Have I wrote about assholes, and the German per se? You can
not see what you are making out of yourself. You are so vain that you
can't help yourself with other things than insulting people. Of beeing
idiots, assholes and bunch of other nice things. It's up to you to
like you style and selfishness, it's not my part to confirm you
behavior.
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87n1cf1zpb.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
>
> Yes, that's all good examples of your prejudicial thinking pattern.
> Thank you for playing. Now go back to your sump and evolve a
>brain.
I consider using my brain after you reveled yours.
Sincerly yours
Friedrich
From: Friedrich Dominicus
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <87snm6x0z6.fsf@frown.here>
Erik Naggum <····@naggum.net> writes:
> * Friedrich Dominicus
> | I consider using my brain after you reveled yours.
>
> That seems about right, since it makes _no_ sense.
As none of you messages.
My brain is telling me "don't do this", but still.
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <················@naggum.net>, Erik Naggum <····@naggum.net>
> wrote:
>
> > I have no goodwill left for this newsgroup, now, especially towards
> > anything that has to do with that sick fuck Rainer Joswig.
>
> That's good news.
Really?
You actually consider that someone losing goodwill towards something,
anyone at all, is a good thing?
I'm quite astonished.
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 524 842
(FORMAT T "(·@{~w ········@{~w~^ ~})" 'FORMAT T "(·@{~w ········@{~w~^ ~})")
Erik Naggum <····@naggum.net> writes:
> * Holger Schauer
>
> | From your reaction to Rainers reactions, I guess that you may have
> | been thinking of some other points.
>
> I have no goodwill left for this newsgroup, now, [...]
Does this mean that you will stop driving the morons out?
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
> wrote:
>
> > * joswig wrote:
> > > Yeah, this is exactly the view from the past that is holding
> > > us back. You are in pre-stone-age, where people
> > > were not *building* tools. Progress starts when you
> > > build tools and you use your capabilities (people have
> > > a real strong ***visual*** input channel that is
> > > waiting to be used). You are not even aware of
> > > the limitations.
> >
> > Do you have measurements that show these fancy gui systems are more
> > productive?
>
> It has nothing to do with being "fancy". GUI systems are
> everywhere. The few people who are still on the CLI
> or on the Emacs terminal side are just dinosaurs. ;-)
Thank you. :)
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
<······@corporate-world.lisp.de> wrote in message
·················@nnrp1.deja.com...
> <SNIP>
>
> Emacs/ILISP and CMUCL (which is okay for some people
> and you can get your work done) is not exactly a good
> comfortable multi-threaded IDE for Lisp development.
> MCL is so much better. MCL has the complete IDE
> written in Common Lisp (source only
> a keystroke away) and you can change/adapt/reuse components
> easily, since the GUI toolkit is simple/effective and
> it is nicely using the power of CLOS. There is no
> mismatch/translation between the Lisp in the environment
> and the Lisp you are using for programming.
Who is behind MCL? Why is it that the Mac ended up with such
a nice environment? Is MCL an actively supported environment with
new releases? I don't have a Mac, but I'm just curious. At first
glance I would have probably expected Linux to host the best
environment due to (my perception of) the number of seats out there
in academia and reseach, and (again my perception) a wide disdain
for MS Windows within these communities,
Julian.
In article <············@news7.svr.pol.co.uk>,
"Julian" <······@123lomberg456.net> wrote:
> > Emacs/ILISP and CMUCL (which is okay for some people
> > and you can get your work done) is not exactly a good
> > comfortable multi-threaded IDE for Lisp development.
> > MCL is so much better. MCL has the complete IDE
> > written in Common Lisp (source only
> > a keystroke away) and you can change/adapt/reuse components
> > easily, since the GUI toolkit is simple/effective and
> > it is nicely using the power of CLOS. There is no
> > mismatch/translation between the Lisp in the environment
> > and the Lisp you are using for programming.
>
> Who is behind MCL?
http://www.digitool.com/
> Why is it that the Mac ended up with such
> a nice environment?
Because it had some clever inventors, went through several
stages of evolution (it had a nice prototype-object
system called Object Lisp in early times),
was actively used and supported by Apple (at the same time
when people like Alan Kay were at Apple) for
some years, ...
But MCL is showing it's age also.
> Is MCL an actively supported environment with
> new releases?
I think a MacOS X version will surface at some point.
This is where the future of the Mac will be.
> I don't have a Mac, but I'm just curious. At first
> glance I would have probably expected Linux to host the best
> environment due to (my perception of) the number of seats out there
> in academia and reseach, and (again my perception) a wide disdain
> for MS Windows within these communities,
What do you think is being used in research labs and the like?
Those can afford to use LispWorks or (mainly) ACL. I guess
those companies can figure out themselves where their
weak points are.
Actually "User interfaces" means today more than GUI toolkits
(this is just expected to exist and work now). The influence
of the Internet has changed the UIs many people use and expect.
It is also the only UI many new users see and know.
Sent via Deja.com
http://www.deja.com/
"Julian" <······@123lomberg456.net> writes:
> <······@corporate-world.lisp.de> wrote in message
> ·················@nnrp1.deja.com...
> > <SNIP>
> >
> > Emacs/ILISP and CMUCL (which is okay for some people
> > and you can get your work done) is not exactly a good
> > comfortable multi-threaded IDE for Lisp development.
> > MCL is so much better. MCL has the complete IDE
> > written in Common Lisp (source only
> > a keystroke away) and you can change/adapt/reuse components
> > easily, since the GUI toolkit is simple/effective and
> > it is nicely using the power of CLOS. There is no
> > mismatch/translation between the Lisp in the environment
> > and the Lisp you are using for programming.
>
> Who is behind MCL? Why is it that the Mac ended up with such
> a nice environment? Is MCL an actively supported environment with
> new releases? I don't have a Mac, but I'm just curious. At first
> glance I would have probably expected Linux to host the best
> environment due to (my perception of) the number of seats out there
> in academia and reseach, and (again my perception) a wide disdain
> for MS Windows within these communities,
MCL was at one point property of Apple itself (it was beautiful even
before they took over).
Then they (Apple) made the mistake of spinning off Dylan.
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
>>>>"RJ" == joswig schrieb am Fri, 19 Jan 2001 21:37:37 GMT:
>> Indeed. One can easily get lost in modern IDEs with tons of
>> possibilities offered which some- or most of the time are mainly
>> irrelevant to the problem that needs to be solved.
RJ> Yeah, this is exactly the view from the past that is holding us
RJ> back. You are in pre-stone-age, where people were not *building*
RJ> tools. Progress starts when you build tools and you use your
RJ> capabilities (people have a real strong ***visual*** input
RJ> channel that is waiting to be used). You are not even aware of
RJ> the limitations.
Thanks for your polite response, Rainer :-( Actually, you don't know
*anything* - about me and my needs.
At least, please note that I'm not at all denying that a "modern IDE"
may have benefits. And FWIW, if I were to build some GUI for some
application, I would prefer an Interface-Builder over hacking the
stuff myself anyday.
So, could you perhaps please elaborate on where exactly "the visual
input channel" is used when programming when you are not doing
graphics and GUI design? Using the mouse clicking on menus is
hopefully not the answer. When I'm programming, having menus and staff
*additionally* available is nice, but for most things I don't want to
take off my hands from my keyboard (yes, C-z e is faster than
copy&paste and then hitting the return-key!).
RJ> Emacs/ILISP and CMUCL (which is okay for some people and you can
RJ> get your work done) is not exactly a good comfortable
RJ> multi-threaded IDE for Lisp development.
It depends. My diploma thesis mainly involved AI-level stuff and
TCP/IP-communication to some external program. In my current task, I'm
mainly hacking knowledge bases (btw making use of Ontosaurus, a
browser for knowledge bases on top of CL-HTTP), so could you please be
so kind and tell me *where* and *what* exactly the benefits of <you
name it>-GUI should be for this task?
RJ> MCL has the complete IDE written in Common Lisp (source
RJ> only a keystroke away) [...]
Yeah, this sounds nice. So you can extend your IDE. ACL3 for Wins IDE
was AFAIR not extensable. Its keybindings and general response sucked.
It constantly got in your way, like most Windows application
interfaces do. It's nice to hear though, that at least one particular
Lisp vendor has come up with a fancy environment.
RJ> Emacs forces you to see everything as a
RJ> buffer, forces you to use arcane keybindings (you may need to
RJ> change them to escape RSI), forces you to use a poorer extension
RJ> system, forces you to slower response times, forces you to use a
RJ> non-threaded environment, forces you to a design that is showing
RJ> its age, ...
Emacs (XEmacs in particular) allows much more things than just
programming and *you know that*. I'm mostly spending my time doing
research work and why the heck should I use another *editor* for
writing texts than for programming? And btw: why are the keybindings
arcane and why has it a poorer extension system (I'm not even sure
what extensions you are talking about)?
RJ> support for developer workgroups - like Genera, but for being
RJ> just an IDE, MCL is pretty damn effective.
Fine, more power to them, then.
>> But I'm sure happy that universities (at least German ones) don't
>> let one conclude that an IDE and a mouse is all you need to do
>> programming.
RJ> There is much more than a text editor, a prompt and a Lisp
RJ> system. If you don't tell people how to handle complexity and how
RJ> to work effectively, than you've done them a disservice. Using
RJ> visual tools is one big way to improve productivity and software
RJ> understanding.
I am not sure how this relates to what I have said. If you're studing
*computer science* you should IMHO learn how to handle complexity and
how to work effectively, but these lessons are IMHO rather unrelated
to whether you use an IDE to automatically build your Makefile or
defsystem or whether you do that by hand. Recognizing the problems at
hand and knowing about the solutions is one thing, using tools
another.
>> FWIW, I would also like to know which benefits Erik actually sees
>> of using, say ACL, over CMUCL. I'm currently using ACL (Prof) with
>> XEmacs (under Ilisp, not with fi) and I can't say I feel that much
>> added value over CMUCL.
RJ> ACL has not a particular good IDE under Unix.
Exactly that (and my prior bad experience with ACL under Win) was the
reason why I was asking. I didn't intend to bash on IDEs. I even was
not really thinking about the IDE, I must admit. I thought Erik was
talking about some technical issues.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Eigentlich konnte uns ja auch damals in den 68ern niemand so richtig
den Unterschied zwischen LSD und BSD erkl�ren, kommt schlie�lich
beides aus Berkeley."
-- Christian Anzenberger in de.comp.os.linux.misc
In article <··············@ipanema.coling.uni-freiburg.de>, Holger
Schauer <··············@gmx.de> wrote:
> So, could you perhaps please elaborate on where exactly "the visual
> input channel" is used when programming when you are not doing
> graphics and GUI design? Using the mouse clicking on menus is
> hopefully not the answer. When I'm programming, having menus and staff
> *additionally* available is nice, but for most things I don't want to
> take off my hands from my keyboard (yes, C-z e is faster than
> copy&paste and then hitting the return-key!).
See below.
> RJ> Emacs/ILISP and CMUCL (which is okay for some people and you can
> RJ> get your work done) is not exactly a good comfortable
> RJ> multi-threaded IDE for Lisp development.
>
> It depends. My diploma thesis mainly involved AI-level stuff and
> TCP/IP-communication to some external program. In my current task, I'm
> mainly hacking knowledge bases (btw making use of Ontosaurus, a
> browser for knowledge bases on top of CL-HTTP), so could you please be
> so kind and tell me *where* and *what* exactly the benefits of <you
> name it>-GUI should be for this task?
Isn't Ontosaurus already a step in this direction?
It is hard to imagine that one can develop ontologies without
the help of graphical browsers. In this case Common Lisp uses
an external tool (a web browser), HTTP as a communication
protocol and HTML as the layout and presentation language. Isn't
this already a step to a GUI-based tool I was talking about? Here
it's the browser that displays the data - you could have
used a browser written with Common Windows (or CLIM, ...).
Ontosaurus already presents a hyperlinked description of
knowledge bases plus some other stuff.
> Yeah, this sounds nice. So you can extend your IDE. ACL3 for Wins IDE
> was AFAIR not extensable. Its keybindings and general response sucked.
> It constantly got in your way, like most Windows application
> interfaces do. It's nice to hear though, that at least one particular
> Lisp vendor has come up with a fancy environment.
It is not extremely "fancy" (you can develop fancy stuff on top of that).
But it is very responsive, uncluttered and extensible.
> Emacs (XEmacs in particular) allows much more things than just
> programming and *you know that*. I'm mostly spending my time doing
> research work and why the heck should I use another *editor* for
> writing texts than for programming? And btw: why are the keybindings
> arcane
come on, "numeric-prefix c-something shift-control-something" ???
> and why has it a poorer extension system (I'm not even sure
> what extensions you are talking about)?
Emacs Lisp vs Macintosh Common Lisp, for example.
> I am not sure how this relates to what I have said. If you're studing
> *computer science* you should IMHO learn how to handle complexity and
> how to work effectively, but these lessons are IMHO rather unrelated
> to whether you use an IDE to automatically build your Makefile or
> defsystem or whether you do that by hand. Recognizing the problems at
> hand and knowing about the solutions is one thing, using tools
> another.
Software visualization, visual programming, visual
query languages, ...
To give a few examples and comparisons:
Let's look at the domain of chess problems.
A game is a sequence of moves and an initial situation.
Situation: Ta6, Tc4, Kc5 and Kc8, Te3, Tg7
1. Kc5-b6 (+) Kc8-d8!
2 Ta6-a8 + Kd8-e7!
3. Ta8-a7 +!
Now you can:
a) Imagine what's going on by just creating a mental image
b) draw a chess board with the initial situation
c) draw chess boards for the initial and all the following situations
d) take a chessboard, place the pieces and play around with the problem
Version d) directly brings us to the idea of direct manipulative
graphical user interfaces.
(-> Chessbase "http://www.chessbase.com/products/cb8/cb801.htm")
Emacs+CL as an IDE reminds me of a).
Another example: computer aided music composition (which
often is music programming).
Some possible UI models for computer aided music composition software :
a) create a composition language as an extension to Common Lisp
and use that for music composition. That's obviously cool
and powerful. So that's "Common Music",
http://www-ccrma.stanford.edu/CCRMA/Software/cm/cm.html
b) take Macintosh Common Lisp, create a composition language and
a graphical interface. That's "Common Music" plus "Capella"
c) take Macintosh Common Lisp, create a composition language,
a GUI and visualization tools: that's "Symbolic Composer",
http://www.mrac.org.uk/scom/scom-doc.htm.
d) take Macintosh Common Lisp, and create a tool
for music notation (so that you can write down
your compositions in a nice way (WYSIWYH) and play them).
The software is kind of an expert system, cause it has domain
knowledge.
That's "Igor Engraver", http://www.noteheads.com/igor/igor.html.
e) create a visual version of CLOS and apply it
to the domain of music composition. So you can
draw CLOS programs (extended with music specific graphical editors)
and see and hear the music your programs are creating.
That's Open Music (also a Macintosh Common Lisp application):
http://www.ircam.fr/equipes/repmus/OpenMusic/Documentation/OMUserDocumentation/DocFiles/Tutorial/tut016/index.html
http://www.ircam.fr/equipes/repmus/OpenMusic/
All of the above software is really cool. (Just as a side
note to those interested, Common Music and Open Music are
freely available including full source code.
Igor Engraver can be downloaded as an application
and costs nothing. :-) )
I'm sure, you can get far with the Emacs+CL approach. But using MCL with
Open Music is so much more fun. ;-)
Rainer Joswig
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
[...]
> Software visualization, visual programming, visual
> query languages, ...
>
> To give a few examples and comparisons:
>
> Let's look at the domain of chess problems.
> A game is a sequence of moves and an initial situation.
>
> Situation: Ta6, Tc4, Kc5 and Kc8, Te3, Tg7
>
> 1. Kc5-b6 (+) Kc8-d8!
> 2 Ta6-a8 + Kd8-e7!
> 3. Ta8-a7 +!
>
> Now you can:
> a) Imagine what's going on by just creating a mental image
> b) draw a chess board with the initial situation
> c) draw chess boards for the initial and all the following situations
> d) take a chessboard, place the pieces and play around with the problem
>
> Version d) directly brings us to the idea of direct manipulative
> graphical user interfaces.
> (-> Chessbase "http://www.chessbase.com/products/cb8/cb801.htm")
>
> Emacs+CL as an IDE reminds me of a).
Well, to bring this thread back 'round to the original topic, that is
one of the advantages the commercial lisp environments offer over the
free lisp environments.
Allegro's Composer is, IMO, the "right" way to do an IDE. It is an
emacs environment extended by GUI pop-up windows for things like
graphing class hierarchies, etc. Of course, this does assume that
developers want to use emacs as their editor... :-)
-- Kaelin
Kaelin Colclasure wrote:
>
> Well, to bring this thread back 'round to the original topic, that is
> one of the advantages the commercial lisp environments offer over the
> free lisp environments.
Yes, let's do exactly that. I would like to quote the last two
paragraphs from the first post in this thread:
"I do know that newbies, students should go from easy to hard,
simple to complex. I also know that the majority of students
will keep with the simple to avoid challenges that may in fact
eventually make their life simpler. And I also know that if the
perception of using a language like Lisp is that it's hard and
unwieldy, very few new people will approach it."
"So I guess the question is, what's the best learning environment
for new students interested in lisp? A side question to that
would be, should you use or learn lisp to the exclusion of other
programming models?"
IBMackey has put some very good remarks to this group, and a
question. The question was about "the best learning environment",
and that not merely for learning. It is about making the Lisp
concept attractive as well.
Yet, most of you guys descend into yapping about Emacs, with or
without X, and what kind of system environment *you* prefer in your
everyday activities that relate to Common Lisp somehow. And you
worry about descending to the levels of 'popularity', thus risking
some "scientific" aura.
Why don't you wrench your minds away from the technicalities and
think about planning and leading a course in Common Lisp at
university level. The students would be people like you and me -
that is average. Assume that the main goal is to make the students
to want *more* of this unique combination of programming language
*and* environment/system.
Now, how does one raise interest in Lisp in the first place? You
certainly don't by renouncing "visuals". Online tutorials, manuals,
browsers to access Lisp function code easily, etc, need it, and that
should be obvious to anyone. Reading most of the replies in this
thread makes me either angry or sad, I have not decided yet.
> Allegro's Composer is, IMO, the "right" way to do an IDE. It is an
> emacs environment extended by GUI pop-up windows for things like
> graphing class hierarchies, etc. Of course, this does assume that
> developers want to use emacs as their editor... :-)
We are getting somewhere. This is obviously one of the first
obstacles the newbeginner will encounter, and which the tutor must
deal with. I say this because I have met the situation myself, in
teaching.
The experienced programmer will arrive at Emacs, sooner or later.
But note that the topic was about the Best Learning Environment.
There is much more in this than Emacs. I have used Emacs quite a
lot, and I cannot see why this editor should be the first obstacle.
Something built on top, using the functionality, yes perhaps, but we
are not talking about Emacs itself then.
I think that Rainer is doing a Good Thing in this thread. He may be
recommending MCL a lot, and why not? There are other commercial
systems too, and they can be put to good use in introducing and
teaching Common Lisp. If someone wants to enhance a "free" Lisp with
whatever is required to become a "best learning environment", fine.
If students are already into "computer science" (sigh), and it is
appropriate to limit Common Lisp to *standard-input* -
*standard-output*, then do so by all means.
But recommending such a course (heh) generally is rubbish.
Poppycock. Consult a dictionary for stronger words.
So is this notion that students must be protected from the evils of
graphics. Getting graphics integrated into Lisp was one of my main
concerns, but that was long ago. We looked into cognition "science",
to grasp how interaction should best be designed. We wanted to
enhance man-machine communication as much as was possible at *that*
time. Now I read your (collective) sour remarks about IDE:s being
too comfortable? It has been said before: Argghh.
If the best learning environment today is Emacs and a raw Lisp, then
the Dark Ages are indeed here.
Lars
In article <·················@era.ericsson.se>, "Lars Lundb?ck"
<·············@era.ericsson.se> wrote:
> IBMackey has put some very good remarks to this group, and a
> question. The question was about "the best learning environment",
> and that not merely for learning. It is about making the Lisp
> concept attractive as well.
This was why I was mentioning Macintosh Common Lisp.
Which is IMHO excellent for these tasks. There is a lesson
to be learned for the other Lisps, again IMHO.
> Why don't you wrench your minds away from the technicalities and
> think about planning and leading a course in Common Lisp at
> university level. The students would be people like you and me -
> that is average. Assume that the main goal is to make the students
> to want *more* of this unique combination of programming language
> *and* environment/system.
I've seen that. The reason the professor tried it here
in Hamburg was, that she wanted students to be more
proficient with the stuff they need later
in the projects, their theses, their student work, ...
Instead of learing in "toy" (forgive me) languages
like Oberon or Scheme, they got the full treatment
of computer science in Common Lisp. ;-)
> The experienced programmer will arrive at Emacs, sooner or later.
> But note that the topic was about the Best Learning Environment.
> There is much more in this than Emacs. I have used Emacs quite a
> lot, and I cannot see why this editor should be the first obstacle.
> Something built on top, using the functionality, yes perhaps, but we
> are not talking about Emacs itself then.
Emacs needs to learned, too. If a student for example is
working in a lab, he will get an introduction and
people will share their Emacs knowledge. I've seen
long-time wizards of Emacs and it was very valuable
to talk to them (Side note: they used to play table tennis after
lunch. An emacs mode was there to determine who
played with whom. ;-) ). The University had special
introductory coursed to explain the use of - in
the example of the computer science course starting with
Lisp - ACL/Composer and Emacs, so the Professor had not to do
it in his lecture.
> I think that Rainer is doing a Good Thing in this thread.
Atleast someone is saying that. ;-)
> He may be
> recommending MCL a lot, and why not? There are other commercial
> systems too, and they can be put to good use in introducing and
> teaching Common Lisp. If someone wants to enhance a "free" Lisp with
> whatever is required to become a "best learning environment", fine.
> If students are already into "computer science" (sigh), and it is
> appropriate to limit Common Lisp to *standard-input* -
> *standard-output*, then do so by all means.
Many Universities have site-licenses for Lisp systems.
The university I was at, had site-licenses for ACL/Composer/CLIM
on the main SUN-Cluster - accessible to every student.
Another University for example started years ago
with a couple (which I now learned means exactly two sometimes)
of hundred Macs and MCL on them for computer
science education. Also a good thing.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
"Lars Lundb�ck" <·············@era.ericsson.se> writes:
[...]
> Yet, most of you guys descend into yapping about Emacs, with or
> without X, and what kind of system environment *you* prefer in your
> everyday activities that relate to Common Lisp somehow. And you
> worry about descending to the levels of 'popularity', thus risking
> some "scientific" aura.
>
> Why don't you wrench your minds away from the technicalities and
> think about planning and leading a course in Common Lisp at
> university level. The students would be people like you and me -
> that is average. Assume that the main goal is to make the students
> to want *more* of this unique combination of programming language
> *and* environment/system.
Oh yes, heaven forefend that a *student* should be exposed to an
environment that they, themselves, could actually extend. Or that they
be forced to *read documentation* to figure out how to use the tools
available to them. They might get the impression that Computer Science
is *hard* and that it takes *discipline and study* to succeed!
Good God, they might drop the course!!!
> Now, how does one raise interest in Lisp in the first place? You
> certainly don't by renouncing "visuals". Online tutorials, manuals,
> browsers to access Lisp function code easily, etc, need it, and that
> should be obvious to anyone. Reading most of the replies in this
> thread makes me either angry or sad, I have not decided yet.
Ponder the platitude "learn how to learn".
The market today is absolutely flooded with people I've heard called
"para-professionals". They are proficient with a certain set of tools
-- usually ones with nice GUI's and lots of wizards. Some of them are
extremely productive within their realm. But pluck them from their
comfortable and familiar environment and they are at a *complete loss*
as to how to proceed.
My very first formal training in software development was provided by
the military. The first course in that program basically covered
rudimentary computer architecture and based arithmetic, and the next
assembly language programming -- writing our code on key-punch
machines, turning in our card decks to be executed and the results
returned to us an hour or so later.
After that, FORTRAN on an H6000 with serial terminals. Then COBOL on
Burroughs machines with "full-screen" terminals. This was all a very
deliberate and conscious part of the curriculum. The idea was that if
you could make it through this obstacle course, you could be expected
to function usefully at whatever assignment the military might need
you on.
On average (I was told) the attrition rate was around 20%.
Now, I'll freely admit that I didn't get much of a grounding in
Computer Science from this program. But I by-God learned how to find
my way around in technical documentation! And I got a personal taste
of a good chunk of the evolutionary process that brought us to today's
computing environments.
> > Allegro's Composer is, IMO, the "right" way to do an IDE. It is an
> > emacs environment extended by GUI pop-up windows for things like
> > graphing class hierarchies, etc. Of course, this does assume that
> > developers want to use emacs as their editor... :-)
>
> We are getting somewhere. This is obviously one of the first
> obstacles the newbeginner will encounter, and which the tutor must
> deal with. I say this because I have met the situation myself, in
> teaching.
>
> The experienced programmer will arrive at Emacs, sooner or later.
> But note that the topic was about the Best Learning Environment.
> There is much more in this than Emacs. I have used Emacs quite a
> lot, and I cannot see why this editor should be the first obstacle.
> Something built on top, using the functionality, yes perhaps, but we
> are not talking about Emacs itself then.
Learning emacs is an investment. The earlier you make the investment,
the more time it has to compound, and the larger the ultimate pay-off.
And emacs is Free Software. It runs on every interesting platform
these days. There is an excellent chance that students will be able
to take their emacs expertise with them to any job their career leads
them to. Sadly, this is not true of MCL.
> I think that Rainer is doing a Good Thing in this thread. He may be
> recommending MCL a lot, and why not? There are other commercial
> systems too, and they can be put to good use in introducing and
> teaching Common Lisp. If someone wants to enhance a "free" Lisp with
> whatever is required to become a "best learning environment", fine.
> If students are already into "computer science" (sigh), and it is
> appropriate to limit Common Lisp to *standard-input* -
> *standard-output*, then do so by all means.
>
> But recommending such a course (heh) generally is rubbish.
> Poppycock. Consult a dictionary for stronger words.
>
> So is this notion that students must be protected from the evils of
> graphics. Getting graphics integrated into Lisp was one of my main
> concerns, but that was long ago. We looked into cognition "science",
> to grasp how interaction should best be designed. We wanted to
> enhance man-machine communication as much as was possible at *that*
> time. Now I read your (collective) sour remarks about IDE:s being
> too comfortable? It has been said before: Argghh.
Too, comfortable? Try too limiting! Confining! Un-extensible,
un-portable and ultimately a poor example (for students) of how
software tools should be built.
> If the best learning environment today is Emacs and a raw Lisp, then
> the Dark Ages are indeed here.
Well, obviously we'll just have to agree to disagree.
-- Kaelin
>>>>> "KC" == Kaelin Colclasure <······@everest.com> writes:
> "Lars Lundb�ck" <·············@era.ericsson.se> writes: [...]
[...]
>> Why don't you wrench your minds away from the technicalities
>> and think about planning and leading a course in Common Lisp at
>> university level. The students would be people like you and me
>> - that is average. Assume that the main goal is to make the
>> students to want *more* of this unique combination of
>> programming language *and* environment/system.
KC> Oh yes, heaven forefend that a *student* should be exposed to
KC> an environment that they, themselves, could actually
KC> extend. Or that they be forced to *read documentation* to
KC> figure out how to use the tools available to them.
In the gut level I do agree with you. But I disagree in the sense that
*teaching* might actually involve some marketing and that, I believe,
was what LL was pointing to. I don't know if -- outside of the bootcamp
environments -- you can really force people to do things that are good
for their character when in the guy down the hall can advertise flashy
easy and popular at the same time.
KC> They might
KC> get the impression that Computer Science is *hard* and that it
KC> takes *discipline and study* to succeed!
It takes discipline and study to succeed in most things. At least that
should be the assumpion at the start and anything else, a pleasant surprise.
Would it not be wonderful if people magically learned that? So how do
we teach people that? Or should we pick our battles carefully?
KC> Good God, they might drop the course!!! [...]
Surely they will not learn what you want them to learn if they do drop
it. You have to motivate people to stay on. How far one should go is
hard for me to pin down. I have been in and survived boot camp
environments (not army, army was easy because I was lucky) and the
attrition rate and human costs were high enough for me to question
their value. As long as people see viable alternatives, they will
take the path of least resistance. I don't see anything wrong with
that per se.
I agree with the rest of your posting, and I like your war stories. (me?
I had to walk to school in 0F to get printouts of my microcode that I
edited over 1200bps. All true!). I also think the teaching point of
the original poster is a valid one that I'd very much like to see it
addressed by someone who actually succeeded in running such a course.
cheers,
BM
>>>>"KC" == Kaelin Colclasure schrieb am 23 Jan 2001 10:02:35 -0800:
>> Why don't you wrench your minds away from the technicalities and
>> think about planning and leading a course in Common Lisp at
>> university level. The students would be people like you and me -
>> that is average. Assume that the main goal is to make the students
>> to want *more* of this unique combination of programming language
>> *and* environment/system.
KC> Oh yes, heaven forefend that a *student* should be exposed to an
KC> environment that they, themselves, could actually extend. Or that
KC> they be forced to *read documentation* to figure out how to use
KC> the tools available to them. They might get the impression that
KC> Computer Science is *hard* and that it takes *discipline and
KC> study* to succeed!
KC> Good God, they might drop the course!!!
I agree, but I think you are missing a point that wasn't made very
clear in the first place (i.e. the posting you were responding
to). While it is surely one of the major things to learn in U that you
"learn how to learn", teaching them the environment should not be part
of the course. Or to put it otherwise: one will try to give a course
on Lisp and not on the particular tools you are using to get your Lisp
programming done [1]. I.e. Learning Emacs should not be part of your
course. If you want people/students to learn Lisp, but don't want to
teach them Emacs or whatever too, then at least you have to state that
(i.e. "Familarity with the Unix environment and one of its popular
editors (Emacs or vi) is assumed.") --- or you have to use a tool in
which some basic familarity how to use it can be assumed of at least
most of the students. This latter requirement at least seems to be
fulfilled by most "modern" IDEs, as they resemble the look of any
other application (okay, the content of the menus is a bit different,
of course. But that's true for any two applications, and the File and
Edit menu are where most people expect them to be and basically
contain what most people expect them to contain).
Two stories: a friend of mine is currently giving a course on
Perl. But not to students of computer science. Because there was no
clear statement of what basic skills was required, he spent the first
quarter explaining the Unix environment. Second: I was in a course on
SmallTalk -- with students who sat for the first time in front of an
IDE (VisualWorks, if anybody cares). A terrible mistake not to have
required a basic idea of computer understanding in advance.
>> Now, how does one raise interest in Lisp in the first place? You
>> certainly don't by renouncing "visuals". Online tutorials,
>> manuals, browsers to access Lisp function code easily, etc, need
>> it, and that should be obvious to anyone. Reading most of the
>> replies in this thread makes me either angry or sad, I have not
>> decided yet.
KC> Ponder the platitude "learn how to learn".
Yup. And also, most of that stuff is *there* even in such an "arcane"
environment like Emacs (Function menu, Tags, "Edit Function
Definition" in Ilisp, hyperspec.el, browse-cltl2.el, etc. Hyperbole
even provides a class browser for CLOS objects, IIRC.).
>> Now I read your (collective) sour remarks about IDE:s being too
>> comfortable? It has been said before: Argghh.
KC> Too, comfortable? Try too limiting! Confining! Un-extensible,
KC> un-portable and ultimately a poor example (for students) of how
KC> software tools should be built.
Well, I found Rainers remarks about MCL quite interesting - and only
one of your criticms sounds valid: un-portable. Which is probably
essentially due to the lack of availability of a generally available
portable GUI toolkit, as we all know.
Holger
Footnotes:
[1] Which is one of the issues in which Rainer and I certainly
disagree. My statement is of course only valid in case you are not
trying to make use of some of the special features of your environment
like an Interface builder. However, I don't think that one should
spend precious time on explaining the environment or doing GUI stuff
in a programming course, especially not with Lisp where so much
more interesting stuff can be done. GUI programming is (most of the
time) just boring. (That's not to say that you shouldn't have the
possibility to learn such things or how to connect to some SQL server
and stuff like that. But that's not something that has anything to do
with programming *languages* courses, so stuff like that probably
requires additional courses or "advanced" p.l. courses.)
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Und ja, es ist September im Netz." "Du meinst, es fallen wieder die
Luser vom Baum^W^Waus dem Usenet?" "Nee, eher in's Usenet - und dann
gleich `ein'. Aber es ist ja immer September im Netz."
-- A.Barth und J.Luster in de.alt.sysadmin.recovery
Holger Schauer <··············@gmx.de> writes:
[...]
> I agree, but I think you are missing a point that wasn't made very
> clear in the first place (i.e. the posting you were responding
> to). While it is surely one of the major things to learn in U that you
> "learn how to learn", teaching them the environment should not be part
> of the course. Or to put it otherwise: one will try to give a course
> on Lisp and not on the particular tools you are using to get your Lisp
> programming done [1]. I.e. Learning Emacs should not be part of your
> course. If you want people/students to learn Lisp, but don't want to
> teach them Emacs or whatever too, then at least you have to state that
> (i.e. "Familarity with the Unix environment and one of its popular
> editors (Emacs or vi) is assumed.") --- or you have to use a tool in
> which some basic familarity how to use it can be assumed of at least
> most of the students.
Is there no introductory course to cover the computing environment?
That might be an excellent venue in which to introduce CS students to
emacs, the Unix shell, etc. I didn't mean to imply this should be a
part of a course on Lisp or any other language.
> This latter requirement at least seems to be
> fulfilled by most "modern" IDEs, as they resemble the look of any
> other application (okay, the content of the menus is a bit different,
> of course. But that's true for any two applications, and the File and
> Edit menu are where most people expect them to be and basically
> contain what most people expect them to contain).
True, but this familiarity is only superficial when it comes to any
but the most trivial programming tasks. I could rant at some length
here about Visual C++, Wizards, etc. -- but many of my criticisms
are less relevant (or not at all) to the Lisp IDEs I have seen.
But consider, you must end up spending *some* class time introducing
this particular IDE that your students will never have seen before.
And these students will likely come from or move on to other language
courses -- and have to be taught multiple superficially-similar IDEs.
They will become acquainted with many, but proficient with none.
Could this time not be better spent incrementally refining their
expertise with tools that work across languages and platforms? And
that support extension and customization?
[...]
> KC> Too, comfortable? Try too limiting! Confining! Un-extensible,
> KC> un-portable and ultimately a poor example (for students) of how
> KC> software tools should be built.
>
> Well, I found Rainers remarks about MCL quite interesting - and only
> one of your criticms sounds valid: un-portable. Which is probably
> essentially due to the lack of availability of a generally available
> portable GUI toolkit, as we all know.
Again, I intended no disparagement of MCL. My rant is against IDEs in
general. And I certainly think a superb IDE is achievable. For
instance, I have done Ada development on a Rational Ada development
system. When I hear people reminisce about the Lisp machines, their
descriptions sound even more idyllic. BUT none of those wonderful
tools are available to me professionally today. In contrast, emacs
has been my constant companion throughout most of my career. And
yes, I'm still learning obscure new tricks from time to time... All
the more reason to assert that starting sooner is better!
-- Kaelin
In article <··············@ipanema.coling.uni-freiburg.de>, Holger
Schauer <··············@gmx.de> wrote:
> clear in the first place (i.e. the posting you were responding
> to). While it is surely one of the major things to learn in U that you
> "learn how to learn", teaching them the environment should not be part
> of the course. Or to put it otherwise: one will try to give a course
> on Lisp and not on the particular tools you are using to get your Lisp
> programming done [1]. I.e. Learning Emacs should not be part of your
> course.
Exactly. At the University of Hamburg there a "Programmierpraktische
Einf�hrung" (PPE), which explains the basic use of Unix,
compilers and editors to the students.
> Holger
>
> Footnotes:
> [1] Which is one of the issues in which Rainer and I certainly
> disagree. My statement is of course only valid in case you are not
> trying to make use of some of the special features of your environment
> like an Interface builder. However, I don't think that one should
> spend precious time on explaining the environment or doing GUI stuff
> in a programming course, especially not with Lisp where so much
> more interesting stuff can be done.
Often courses even don't make it to CLOS or to macros. Sigh.
List manipulation will be explained in all depth, though. ;-)
> GUI programming is (most of the
> time) just boring. (That's not to say that you shouldn't have the
> possibility to learn such things or how to connect to some SQL server
> and stuff like that. But that's not something that has anything to do
> with programming *languages* courses, so stuff like that probably
> requires additional courses or "advanced" p.l. courses.)
What I mean is that tool building should be taught. Together
with programm introspection, reflection and visualization.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Holger Schauer wrote:
>
>
> I agree, but I think you are missing a point that wasn't made very
> clear in the first place (i.e. the posting you were responding
> to).
That was intentional, I wanted you to give considered input on more
aspects than the source editor.
> Yup. And also, most of that stuff is *there* even in such an "arcane"
> environment like Emacs (Function menu, Tags, "Edit Function
> Definition" in Ilisp, hyperspec.el, browse-cltl2.el, etc. Hyperbole
> even provides a class browser for CLOS objects, IIRC.).
Yes. Could one even say that Emacs is slowly getting the functionality
and the appearance that a proper IDE should have?
> Footnotes:
> [1] Which is one of the issues in which Rainer and I certainly
> disagree. My statement is of course only valid in case you are not
> trying to make use of some of the special features of your environment
> like an Interface builder. However, I don't think that one should
> spend precious time on explaining the environment or doing GUI stuff
> in a programming course, especially not with Lisp where so much
> more interesting stuff can be done. GUI programming is (most of the
> time) just boring. ....
No argument from me. I have not said anything about the students
building interfaces, graphic or otherwise. As you say, it can be pretty
boring. But about the learning/programming environment, why should it be
crippled in the first place? I just don't see any reason.
Pling, beep
Lars
>>>>"LL" == Lars Lundb�ck schrieb am Thu, 25 Jan 2001 14:18:40 +0100:
>> Yup. And also, most of that stuff is *there* even in such an
>> "arcane" environment like Emacs (Function menu, Tags, "Edit
>> Function Definition" in Ilisp, hyperspec.el, browse-cltl2.el,
>> etc. Hyperbole even provides a class browser for CLOS objects,
LL> Yes. Could one even say that Emacs is slowly getting the
LL> functionality and the appearance that a proper IDE should have?
All of that functionality is at least five years old, AFAIK, some of
it is even older. A more interesting question to ask would thus have
been about what is still missing (and I would agree at the very second
that there are probably things that one wouldn't want to add directly
to (X)Emacs).
LL> No argument from me. I have not said anything about the students
LL> building interfaces, graphic or otherwise. As you say, it can be
LL> pretty boring. But about the learning/programming environment,
LL> why should it be crippled in the first place? I just don't see
LL> any reason.
I was not at all arguing for a crippled environment, neither anybody
else. I was specificially *asking* in which way using the facilities
of "Emacs+a free CL" should be a less efficient learning environment
compared to a commercial lisp. Because /this/ is what the claim was,
and I don't let you or anybody else shift the burden of proof (i.e. I
wasn't claiming the opposite). Instead, in the posting you're
responding too, I was even offering some of the possible things you or
anybody else from the "IDE camp", if I may use that term just for a
short moment, might think of.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Und ja, es ist September im Netz." "Du meinst, es fallen wieder die
Luser vom Baum^W^Waus dem Usenet?" "Nee, eher in's Usenet - und dann
gleich `ein'. Aber es ist ja immer September im Netz."
-- A.Barth und J.Luster in de.alt.sysadmin.recovery
Holger Schauer wrote:
> All of that functionality is at least five years old, AFAIK, some of
> it is even older. A more interesting question to ask would thus have
> been about what is still missing (and I would agree at the very second
> that there are probably things that one wouldn't want to add directly
> to (X)Emacs).
I said functionality _and_ appearance. Appearance does not neccessarily
translate as 'glossiness', and I'm not talking about that. The more
interesting question is how fresh students find this functionality in
the first place.
>
> I was not at all arguing for a crippled environment, neither anybody
> else. I was specificially *asking* in which way using the facilities
> of "Emacs+a free CL" should be a less efficient learning environment
> compared to a commercial lisp. Because /this/ is what the claim was,
> and I don't let you or anybody else shift the burden of proof (i.e. I
> wasn't claiming the opposite). Instead, in the posting you're
> responding too, I was even offering some of the possible things you or
> anybody else from the "IDE camp", if I may use that term just for a
> short moment, might think of.
>
I know you did. I actually interpreted it as a first step in my
direction.
As for efficiency, I believe the original question was about "the best
...", and there were other considerations beyond the language itself.
In situations similar to yours, "Emacs + a free CL" may be good enough.
I say it is not generally, for a wide spectrum of students, who should
also have a fair view/glimpse of what can be accomplished. So you *are*
arguing for a crippled environment. Anyhow, reflection will show you
that you are already in the IDE camp. It's just that my tent is brighter
and roomier than yours. >:->
Many regards, Lars
>>>>"LL" == Lars Lundb�ck schrieb am Thu, 25 Jan 2001 18:13:54 +0100:
[Emacs+CL, tutorials and stuff]
>> All of that functionality is at least five years old, AFAIK, some
>> of it is even older.
LL> I said functionality _and_ appearance. Appearance does not
LL> neccessarily translate as 'glossiness', and I'm not talking about
LL> that. The more interesting question is how fresh students find
LL> this functionality in the first place.
Sigh. Do I really need to post a (link to a) binary showing an XEmacs
with Ilisp-menu in which *all* of the functionality discussed so far
(in this part of the thread, not what Rainer was telling about MCL) is
just as directly available as in --- which GUI anyway? Surely not ACL,
because their "IDE" exactly consists of just an other EMACS(!) add-on
IDE.
>> I was specificially *asking* in which way using the
>> facilities of "Emacs+a free CL" should be a less efficient
>> learning environment compared to a commercial lisp.
LL> In situations similar to yours, "Emacs + a free CL" may be good
LL> enough.
Come on. Can't you read? I wanted to know what there is that is
said to be better and in which respect. If never even wanted to imply
that my situation couldn't be improved.
LL> I say it is not generally, for a wide spectrum of students, who
LL> should also have a fair view/glimpse of what can be
LL> accomplished. So you *are* arguing for a crippled environment.
No, you are able to read, but not able to comprehend. You can't even
tell a question from an argument.
Let me repeat: what is there and what can you accomplish with it? I
know CMUCL and CLisp from the Free-CL camp, and I know ACL Win/Unix
from the commercial camp and the latter experience leaves me puzzling
of what it might be that whoever thinks is superior. Don't you get it?
I want to know about what the other commercial lisp systems offer and
what is maybe there in ACL which I somehow just don't see.
LL> Anyhow, reflection will show you that you are
LL> already in the IDE camp. It's just that my tent is brighter and
LL> roomier than yours. >:->
Man, I start to get really sick on this discussion. I am not in *any*
camp. I just want to get my work done as efficiently as possible and
therefore I am *asking* which tools I might miss. *Asking, asking*
(repeat chorus twice)
Has everybody lost their communicative capabilities? How could I have
been more explicit then in the statement quoted above (the one with
*asking*)?
Holger
PS: Sorry, for the somewhat personal attacks. But I am really starting
to get sick of this discussion. In the mean time of writing these
postings and discussing in this flame-war, I could have easily
downloaded all of those commercial systems with a free version and
have a detailed look at each of them. I guess that's what I'll end up
doing anyway, because obviously nobody really has even as much as a
well-founded opinion on the question whether Emacs+CL or
CL-with-you-name-it-IDE is better. Just plain flamewars without any
info, how boring.
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"I mean, the bazaar I don't mind, but the bizarre I have problems with."
-- Russell Marks in comp.os.linux.announce
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3r91r6x0h.fsf@cley.com>
* Holger Schauer wrote:
> Sigh. Do I really need to post a (link to a) binary showing an XEmacs
> with Ilisp-menu in which *all* of the functionality discussed so far
> (in this part of the thread, not what Rainer was telling about MCL) is
> just as directly available as in --- which GUI anyway? Surely not ACL,
> because their "IDE" exactly consists of just an other EMACS(!) add-on
> IDE.
I think the ACL IDE probable means the thing that runs on Windows, and
is definitely not an emacs-based thing. I haven't used it other than
in the most trivial way (I use Windows basically as a platform for
running emacs and cygwin: my life will be complete when one of the
emacs hyperspec-lookup packages works on Windows...), but it looks
pretty whizzy. I don't know how it compares with the
visual-<whatever> environments.
--tim
>>>>"TB" == Tim Bradshaw schrieb am 25 Jan 2001 23:18:54 +0000:
>> [...] which GUI anyway? Surely not ACL, because their "IDE"
>> exactly consists of just an other EMACS(!) add-on IDE.
TB> I think the ACL IDE probable means the thing that runs on
TB> Windows, and is definitely not an emacs-based thing.
No, in the sentence you quoted, I was thinking of ACL under Unix,
whose IDE consists of an interface to Emacs plus some additional CLIM
windows. I know the ACL/Win-IDE from ACL3 and didn't like it (in fact
I found it to be much more limited than Ilisp, but maybe that has
changed in the mean time. If this is so, I would be eager to hear more
about it).
TB> emacs and cygwin: my life will be complete when one of the emacs
TB> hyperspec-lookup packages works on Windows...), but it looks
TB> pretty whizzy.
What doesn't work? I haven't tried it, but I would be surprised to
learn that they don't work as they AFAIR all only rely on w3 or more
specifically browse-url.el.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Und ja, es ist September im Netz." "Du meinst, es fallen wieder die
Luser vom Baum^W^Waus dem Usenet?" "Nee, eher in's Usenet - und dann
gleich `ein'. Aber es ist ja immer September im Netz."
-- A.Barth und J.Luster in de.alt.sysadmin.recovery
Holger Schauer <··············@gmx.de> writes:
> windows. I know the ACL/Win-IDE from ACL3 and didn't like it (in fact
> I found it to be much more limited than Ilisp, but maybe that has
> changed in the mean time. If this is so, I would be eager to hear more
> about it).
Note that ACL3 on Windows was really another product from the normal
ACL. Since Version 5.0, the core engine on Windows is the same as on
Unix, and if I'm not very mistaken, the IDE is a totally new one, too.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
On 25 Jan 2001 23:18:54 +0000, Tim Bradshaw <···@cley.com> wrote:
>I think the ACL IDE probable means the thing that runs on Windows, and
>is definitely not an emacs-based thing. I haven't used it other than
>in the most trivial way (I use Windows basically as a platform for
>running emacs and cygwin: my life will be complete when one of the
>emacs hyperspec-lookup packages works on Windows...), but it looks
>pretty whizzy. I don't know how it compares with the
>visual-<whatever> environments.
Last time I checked it it was very similar to Delphi/Borland Builder.
The only remarcable differences were the lack of syntax highlighting and the
abscence of the GPFs that make life with BCB so enjoyable. };-)
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
writes
>* Holger Schauer wrote:
>> Sigh. Do I really need to post a (link to a) binary showing an XEmacs
>> with Ilisp-menu in which *all* of the functionality discussed so far
>> (in this part of the thread, not what Rainer was telling about MCL) is
>> just as directly available as in --- which GUI anyway? Surely not ACL,
>> because their "IDE" exactly consists of just an other EMACS(!) add-on
>> IDE.
>
>I think the ACL IDE probable means the thing that runs on Windows, and
>is definitely not an emacs-based thing. I haven't used it other than
>in the most trivial way (I use Windows basically as a platform for
>running emacs and cygwin: my life will be complete when one of the
>emacs hyperspec-lookup packages works on Windows...), but it looks
>pretty whizzy. I don't know how it compares with the
>visual-<whatever> environments.
>
>--tim
>
I don't remember having any problems with the hyperspec-lookup packages
under Windows - what problems are you having? If it is the because of
the change to the filenames in the latest hyperspec release, I have a
revised mapping definition I could send you.
Guy
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3elxn7so0.fsf@cley.com>
* Guy Footring wrote:
> I don't remember having any problems with the hyperspec-lookup packages
> under Windows - what problems are you having? If it is the because of
> the change to the filenames in the latest hyperspec release, I have a
> revised mapping definition I could send you.
I admit to not having tried the, very carefully, but do they talk to
IE the same way they talk to NS on Unix? (I don't want to use w3).
If they do then clearly they just work...
--t
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
writes
>* Guy Footring wrote:
>
>> I don't remember having any problems with the hyperspec-lookup packages
>> under Windows - what problems are you having? If it is the because of
>> the change to the filenames in the latest hyperspec release, I have a
>> revised mapping definition I could send you.
>
>I admit to not having tried the, very carefully, but do they talk to
>IE the same way they talk to NS on Unix? (I don't want to use w3).
>If they do then clearly they just work...
>
>--t
As far as I can remember they do (although my default browser is still
NS under Windows) - I certainly didn't use Emacs' W3 for the hyperspec
lookup. It's been a while since I used Ilisp, but the only problem I
recall was the filename mapping. Once I fixed that I had no problems
using Erik's hyperspec lookup package that is distributed with Ilisp.
Guy
Kaelin Colclasure wrote:
> Oh yes, heaven forefend that a *student* should be exposed to an
> environment that they, themselves, could actually extend. Or that they
> be forced to *read documentation* to figure out how to use the tools
> available to them. They might get the impression that Computer Science
> is *hard* and that it takes *discipline and study* to succeed!
Hm, the documentation manuals could be worn and have Coke-can smears all
over them? Do we allow variable-width fonts when typesetting the
introductory texts? Printout from Teletype rolls would make the students
properly awed, I think.
> Good God, they might drop the course!!!
Seeking shelter in some other eASY sCIENCE perhaps, one that does not
require study or discipline, even self-inflicted?
> > Now, how does one raise interest in Lisp in the first place? You
> > certainly don't by renouncing "visuals". Online tutorials, manuals,
> > browsers to access Lisp function code easily, etc, need it, and that
> > should be obvious to anyone. Reading most of the replies in this
> > thread makes me either angry or sad, I have not decided yet.
>
> Ponder the platitude "learn how to learn".
I'm pondering ...
> The market today is absolutely flooded with people I've heard called
> "para-professionals". They are proficient with a certain set of tools
> -- usually ones with nice GUI's and lots of wizards. Some of them are
> extremely productive within their realm. But pluck them from their
> comfortable and familiar environment and they are at a *complete loss*
> as to how to proceed.
Sure, any profession has them. Some of the worst are those that claim,
say 20 years of experience, when they have in fact one year, repeated
twenty times.
> My very first formal training in software development was provided by
> the military. The first course in that program basically covered
> rudimentary computer architecture and based arithmetic, and the next
> assembly language programming -- writing our code on key-punch
> machines, turning in our card decks to be executed and the results
> returned to us an hour or so later.
Sounds like a resort to me. I had to bootstrap our 16-bit, 8k
ferrite-memory Raytheon 704 manually in the mornings, and then feed in
the boot paper tape. The Fortran compiler and linker were on on separate
(paper) tapes ...
> Now, I'll freely admit that I didn't get much of a grounding in
> Computer Science from this program. But I by-God learned how to find
> my way around in technical documentation! And I got a personal taste
> of a good chunk of the evolutionary process that brought us to today's
> computing environments.
>
> Learning emacs is an investment. The earlier you make the investment,
> the more time it has to compound, and the larger the ultimate pay-off.
> And emacs is Free Software. It runs on every interesting platform
> these days. There is an excellent chance that students will be able
> to take their emacs expertise with them to any job their career leads
> them to. Sadly, this is not true of MCL.
The few students that survived the initial weeks and stayed in the
course? :)
> Too, comfortable? Try too limiting! Confining! Un-extensible,
> un-portable and ultimately a poor example (for students) of how
> software tools should be built.
Dear me, I said explicitly that any serious programmer will arrive at
Emacs sooner or later.
> > If the best learning environment today is Emacs and a raw Lisp, then
> > the Dark Ages are indeed here.
>
> Well, obviously we'll just have to agree to disagree.
I don't give up easily you know, not in this topic, but we can always
avoid the early morning duel. I haven't fired a gun the last 30 years
anyway.
Regards, Lars
"Lars Lundb�ck" <·············@era.ericsson.se> writes:
[...]
> Hm, the documentation manuals could be worn and have Coke-can smears all
> over them? Do we allow variable-width fonts when typesetting the
> introductory texts? Printout from Teletype rolls would make the students
> properly awed, I think.
Oh no, these days they should definately be introduced to the Web as a
technical library beyond compare... But make them surf it with lynx or
emacs w3. ;-)
[...]
> Sounds like a resort to me. I had to bootstrap our 16-bit, 8k
> ferrite-memory Raytheon 704 manually in the mornings, and then feed in
> the boot paper tape. The Fortran compiler and linker were on on separate
> (paper) tapes ...
Okay okay, I apologize for succumbing to the temptation to tell war
stories. The point I was trying to make, admittedly not very effectively,
was that IDEs hide a lot of the little details that you need to know to
function without them. And that it often is necessary to function without
them.
[...]
> > Too, comfortable? Try too limiting! Confining! Un-extensible,
> > un-portable and ultimately a poor example (for students) of how
> > software tools should be built.
>
> Dear me, I said explicitly that any serious programmer will arrive at
> Emacs sooner or later.
And my argument is simply that sooner is better. :-)
> > > If the best learning environment today is Emacs and a raw Lisp, then
> > > the Dark Ages are indeed here.
> >
> > Well, obviously we'll just have to agree to disagree.
>
> I don't give up easily you know, not in this topic, but we can always
> avoid the early morning duel. I haven't fired a gun the last 30 years
> anyway.
Oh, I prefer to duel with ideas. That way, even if you strike me down,
I still win. :-)
-- Kaelin
In article <····························@news.is-europe.net>, Rainer
Joswig <······@corporate-world.lisp.de> wrote:
> In article <··············@ipanema.coling.uni-freiburg.de>, Holger
> Schauer <··············@gmx.de> wrote:
>
> > So, could you perhaps please elaborate on where exactly "the visual
> > input channel" is used when programming when you are not doing
> > graphics and GUI design? Using the mouse clicking on menus is
> > hopefully not the answer. When I'm programming, having menus and staff
> > *additionally* available is nice, but for most things I don't want to
> > take off my hands from my keyboard (yes, C-z e is faster than
> > copy&paste and then hitting the return-key!).
>
> See below.
To put some more perspective to it you might want to look at:
The Debugging Scandal and What to Do About It,
Communications of the ACM, April 1997,
Henry Lieberman, guest editor
http://lieber.www.media.mit.edu/people/lieber/Lieberary/Softviz/CACM-Debugging/CACM-Debugging-Intro.html
especially:
Introduction to the Special Issue on the Debugging Scandal
http://lieber.www.media.mit.edu/people/lieber/Lieberary/Softviz/CACM-Debugging/CACM-Debugging-Intro.html#Intro
Programming on an Already Full Brain
http://lieber.www.media.mit.edu/people/lieber/Lieberary/Softviz/CACM-Debugging/Already-Full/Already-Full.html
(rj: I like the title)
Well, actually all the articles are interesting.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> To put some more perspective to it you might want to look at:
[ ... ]
> Programming on an Already Full Brain
> http://lieber.www.media.mit.edu/people/lieber/Lieberary/Softviz/CACM-Debugging/Already-Full/Already-Full.html
> (rj: I like the title)
Oh, I quite agree that a software development environment should aid
the programmer by absolving him from the need to care about low-level
details. But nothing in there will tell you anything on either the
GUI vs. The Dinosaurs debate, nor the commercial vs. "free" debate
that this thread has covered. Furthermore the article suffers from
the exact same problems that Tim Bradshaw has pointed out in your
original posting, namely that of claims largely unsupported by
anything resembling serious evidence. See also the review of the
article in ACM Computing Reviews by Boris Beizer[1], which though IMHO
overly harsh, points out serious flaws.
One section of the article seems to me to be very telling indeed,
and that might indeed account for the controversy in this debate. To
quote[2] from page 62 right-hand column, bottom of page, in the
section "Language Design and Hardware":
<quote>
Emacs Menus is software that can benefit from input interface hardware
designed with humans in mind. Switching between mouse and keyboard is
bad. Most hackers I know think in terms of keyboard commands that
perform equivalent mouse operations, so they don't have to switch to
and from the mouse. I think in the opposite direction, so the
programmer doesn't have to switch to and from the keyboard. Emacs
Menus provides most operations via mouse input, although each new
identifier must be entered at least once.
</quote>
So much of the design of Emacs Menus seems to be driven by the authors
preference of the mouse over the keyboard. Now that is of course the
authors freedom, but even the author admits that there exist those
that prefer the keyboard over the mouse, so that it seems to me quite
evident that those users (among which I count myself) would prefer
quite a different design, which indeed I do.
Furthermore the author then goes on to suggest improved input devices
that could take the place of the mouse, like e.g. five-button mice,
mice with wheels (we now have those), pen-input, OCR, speech-input,
etc. Underlying this is the assumption that all of them are not only
better suited to the task of programming, but that they are better
suited to the human body, regardless of the task at hand, which he
states directly near the end of that section:
<quote>
Throwing out the keyboard and using input devices designed to fit
the human body would finally permit the smooth integration of hardware
and software. Under such an arrangement, tools like Emacs Menus could
really shine, because the hardware wouldn't get between users and
their bugs.
</quote>
(The end of the last sentence seems a bit of a language bug, and should
probably read "because the hardware wouldn't get between users and
their code" or something similar.)
Of course the assertion that keyboards don't fit the human body, comes
without any cited evidence at all. Implicit in the article and more
explicit in this thread, seems to me the more far-reaching assertion,
that keyboards and keyboard-based interfaces don't fit the human
mind. Again no evidence has been provided.
In the absence of this evidence, I refuse to accept that those of us
who use GNU (X)Emacs-based systems with similar capabilities as Emacs
Menu, that leverage the power of the keyboard instead of the mouse are
to be considered The Dinosaurs, just because keyboards have been in
use for a larger time-frame than mice.
Regs, Pierre.
Footnotes:
[1] Available to the public via the following URL:
http://www.acm.org/pubs/citations/journals/cacm/1997-40-4/p55-fry/
[2] I'm quoting from the published ACM article, which is available
electronically to ACM DL members under the following URL:
http://www.acm.org/pubs/articles/journals/cacm/1997-40-4/p55-fry/p55-fry.pdf
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
In article <··············@orion.bln.pmsf.de>,
"Pierre R. Mai" <····@pmsf.de> wrote:
> Oh, I quite agree that a software development environment should aid
> the programmer by absolving him from the need to care about low-level
> details. But nothing in there will tell you anything on either the
> GUI vs. The Dinosaurs debate, nor the commercial vs. "free" debate
> that this thread has covered. Furthermore the article suffers from
> the exact same problems that Tim Bradshaw has pointed out in your
> original posting, namely that of claims largely unsupported by
> anything resembling serious evidence.
You are drawing here a connection between completely unconnected
things. An argumentation pattern. Thanks.
> See also the review of the
> article in ACM Computing Reviews by Boris Beizer[1], which though IMHO
> overly harsh, points out serious flaws.
Actually from reading Boris Beizer's review, I'm under the impression
that he does not have much experience with software development
and people doing it.
> One section of the article seems to me to be very telling indeed,
> and that might indeed account for the controversy in this debate. To
> quote[2] from page 62 right-hand column, bottom of page, in the
> section "Language Design and Hardware":
>
> <quote>
> Emacs Menus is software that can benefit from input interface hardware
> designed with humans in mind. Switching between mouse and keyboard is
> bad. Most hackers I know think in terms of keyboard commands that
> perform equivalent mouse operations, so they don't have to switch to
> and from the mouse. I think in the opposite direction, so the
> programmer doesn't have to switch to and from the keyboard. Emacs
> Menus provides most operations via mouse input, although each new
> identifier must be entered at least once.
> </quote>
>
> So much of the design of Emacs Menus seems to be driven by the authors
> preference of the mouse over the keyboard. Now that is of course the
> authors freedom, but even the author admits that there exist those
> that prefer the keyboard over the mouse, so that it seems to me quite
> evident that those users (among which I count myself) would prefer
> quite a different design, which indeed I do.
>
> Furthermore the author then goes on to suggest improved input devices
> that could take the place of the mouse, like e.g. five-button mice,
> mice with wheels (we now have those), pen-input, OCR, speech-input,
> etc. Underlying this is the assumption that all of them are not only
> better suited to the task of programming, but that they are better
> suited to the human body, regardless of the task at hand, which he
> states directly near the end of that section:
>
> <quote>
> Throwing out the keyboard and using input devices designed to fit
> the human body would finally permit the smooth integration of hardware
> and software. Under such an arrangement, tools like Emacs Menus could
> really shine, because the hardware wouldn't get between users and
> their bugs.
> </quote>
>
> (The end of the last sentence seems a bit of a language bug, and should
> probably read "because the hardware wouldn't get between users and
> their code" or something similar.)
>
> Of course the assertion that keyboards don't fit the human body, comes
> without any cited evidence at all. Implicit in the article and more
> explicit in this thread, seems to me the more far-reaching assertion,
> that keyboards and keyboard-based interfaces don't fit the human
> mind. Again no evidence has been provided.
You are making up a strawman. The question was about "rich"
(a term that would need some further definition) IDEs for
Common Lisp.
To quote from this discussion, Lars Lundback wrote:
> I cannot say that the primitive environment I started with, made
> Lisp easier to learn. I rather feel that would-be Common Lispers
> will benefit from rich environments, and that Common Lisp itself
> would then be even more attractive than people seem to perceive it
> is today.
Holger said: "One can easily get lost in modern IDEs with tons of
possibilities offered which some- or most of the time are mainly
irrelevant to the problem that needs to be solved."
Which is neither necessary nor a particular feature of modern IDEs
(you can easily get lost get in any modern version of Emacs just by
browsing the Info system ;-) ).
In the following I was argueing that the Emacs/CL-IDE (-> ILisp, ...)
is not such a thing and that IDEs have to provide a richer user interface
than Emacs/CL, especially on the side of visualization. Ways to
type/draw/... programs and tools to simply that is also an
interesting topic.
As a side note, RSI is a problem, especially for programmers (who
do a lot of typing) and some people are blaming their RSI problems
to the frequent use of chords in Emacs commands. These people
are **very** interested to explore alternative input methods
(diffrent keymaps for Emacs, voice-based input for Emacs, ...).
> In the absence of this evidence, I refuse to accept that those of us
> who use GNU (X)Emacs-based systems with similar capabilities as Emacs
> Menu, that leverage the power of the keyboard instead of the mouse are
> to be considered The Dinosaurs, just because keyboards have been in
> use for a larger time-frame than mice.
Again you are making up a strawman. Nobody has argued that.
Rainer Joswig
Sent via Deja.com
http://www.deja.com/
>>>>"j" == joswig schrieb am Sun, 21 Jan 2001 21:30:54 GMT:
j> You are making up a strawman. The question was about "rich" (a
j> term that would need some further definition) IDEs for Common
j> Lisp.
No, it wasn't and *you* made up the strawman in the first
place. Actually, the question was what is the added value of
commercial lisps over free ones.
j> To quote from this discussion, Lars Lundback wrote:
>> I cannot say that the primitive environment I started with, made
>> Lisp easier to learn. I rather feel that would-be Common Lispers
>> will benefit from rich environments, and that Common Lisp itself
>> would then be even more attractive than people seem to perceive it
>> is today.
And *in between*, *you* said:
j> You need to learn about programming environments, too.
j> Holger said: "One can easily get lost in modern IDEs with tons of
j> possibilities offered which some- or most of the time are mainly
j> irrelevant to the problem that needs to be solved."
j> Which is neither necessary nor a particular feature of modern IDEs
What I wanted to say is that you need to learn about the complex
issues of modern IDEs, and to start learning Lisp (note the initial
topic!) most of the features will not help you in solving the tasks
that you will have to solve during your university years (unless you
will do a large project in CL, which is rather seldom nowadays). Or
are you really saying or implying that the tons of menus offered in
"modern" IDEs are directly understandable? [1] They are *not*: similar
to the "Windows is easy to administrate"-myth, just because you see
what options are there, it's still not true that you don't have to
*understand* the options first.
Holger
Footnotes:
[1] BTW: I'm not at all arguing against having such menus. Heck, the
current version of Ilisp seems to be shipped with an extension or
modification of the ilisp-menu that I wrote for XEmacs some four or
five years ago.
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"jaja... die armen Hefezellen wollen auch leben. *BIER IST MORD!* ;-)"
-- Carsten Baumgardt in de.alt.punk
In article <··············@ipanema.coling.uni-freiburg.de>, Holger
Schauer <··············@gmx.de> wrote:
> And *in between*, *you* said:
>
> j> You need to learn about programming environments, too.
>
> j> Holger said: "One can easily get lost in modern IDEs with tons of
> j> possibilities offered which some- or most of the time are mainly
> j> irrelevant to the problem that needs to be solved."
>
> j> Which is neither necessary nor a particular feature of modern IDEs
>
> What I wanted to say is that you need to learn about the complex
> issues of modern IDEs, and to start learning Lisp (note the initial
> topic!)
You might want to decide to what you want respond - to the
initial topic or the topic that is been discussed in
a particular discussion thread.
> most of the features will not help you in solving the tasks
> that you will have to solve during your university years (unless you
> will do a large project in CL, which is rather seldom nowadays).
What are they doing in "university years" in Germany? I mean
students are studying computer science and need five to
8 years. For what? For example the girl that was working for us
wrote a large CLIM-based user interface for an ECAD-like
application as her "Studienarbeit" and as her diploma
thesis she extended Classic to include probability
mechanisms. Without extended knowledge of Common Lisp
and a good Common Lisp development
environment - what would she do - getting lost? We had another
"Diplom Informatiker" working in a project - he had
zero experience of Lisp and advanced development environments.
He went nowhere in two years. A rather bad experience.
Even given a Lisp with an IDE on Windows and getting it
explained to him he was not
able to figure it out. He was trying to develop
a research prototype. :-) **I** want a student or
somebody with a degree who **can** program and knows about
the tools - I don't want to have the upstart of one
year to make people productive. We had another student
(a real bright guy), he had prior Scheme experience,
got LispWorks and he hacked CL-HTTP very successful.
I had another student, who was proficient in some development
stuff - but not Lisp - he was not able to hack productively even
on a small-scale (a few thousand lines of dense Lisp code)
application - he had a hard time figuring out what was going on.
How can I make him productive?
When I was at the University in Hamburg, my first student
job was to work on a **big** natural language system ("HAM-ANS")
to port functionality with a semi-automatic code translator
from one Lisp-dialect to another. I was not really good.
But I learned to understand that if you get a 100000+ line
NL research application under your hands, you better get some
grip on the tools.
Many of the research projects in AI are hard and big. I saw
students hacking in Lisp in large multi-university
projects like "India" (diagnosis), "Plakon"
(Planning and Configuration), ... How do you think anybody
will work on this stuff productively with inferior
development environments or without domain specific
tools?
> Or
> are you really saying or implying that the tons of menus offered in
> "modern" IDEs are directly understandable?
First: they are there. You can see them. This is a big plus.
When I don't need a menu I do (remove-menu ...). When
I need a menu of my own I do (add-menu (make-instance 'menu ...))).
Or I fire up the menu editor.
When I want to know what a particular menu does, I turn
on "Erkl�rungen an" (the second menu in a Help menu) and
when the mouse moves over windows, menus, menu item,
dialog items, ... it displays unobstrusive small bubbles
explaining them.
But there is a lot more to an Lisp IDE than just menus.
The Emacs-like editor can be used as a dialog-item or
as a window. Each fred-dialog-item is a full emacs-like
editor (which is subclassable and programmable in CLOS,
etc.). You get Inspector windows where you can
directly cut, paste, edit objects.
The Inspector has different displays depending on
the class of the object. You can write your own inspectors
for classes or you can add commands to existing inspectors
(for example a friend of mine added CLIM-specific inspectors
to MCL). There are backtrace windows for each thread.
Windows which list source files for functions. Windows
where you can ask complex apropos queries to actually
locate functionality easily. Windows which list callers.
Backtrace windows for each thread. Restart windows on
demand for break loops. Etc. Etc. A window designer
to draw the user interface and to generate the code,
making changes to running instances possible, ...
> [1] They are *not*: similar
> to the "Windows is easy to administrate"-myth, just because you see
> what options are there, it's still not true that you don't have to
> *understand* the options first.
But they are easier to locate and you can provide unobstrusive
in-place help easily.
A) It is much easier to locate commands.
Because they are assembled in menus and the menu-items
are gouped by functionality. Or the commands are
available as buttons. or as context sensitive menus, or...
B) it is much easier to fill in the options for the commands.
Because you have dialogs, which actually display the options
and give you choices.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
>>>>"RJ" == Rainer Joswig schrieb am Mon, 22 Jan 2001 11:41:29 +0100:
>> What I wanted to say is that you need to learn about the complex
>> issues of modern IDEs, and to start learning Lisp (note the
>> initial topic!)
RJ> You might want to decide to what you want respond - to the
RJ> initial topic or the topic that is been discussed in a particular
RJ> discussion thread.
No, I don't as both topics are indeed related, or better said, the
initial topic provides the context for discussing the latter.
>> most of the features will not help you in solving the tasks that
>> you will have to solve during your university years (unless you
>> will do a large project in CL, which is rather seldom nowadays).
RJ> What are they doing in "university years" in Germany?
With CL or at all? If I hadn't worked outisde of the university on a
project involving CL, I would probably still have no clue about
it. So, my impression is that students will either never use CL at
all, or just get to solve small homework tasks and per chance they
will work on some term project (which the "large project" should refer
to). I guess, for most students the second option is the most
likeliest and for these homework assignments I think that most of the
features are in a CL environment as distracting as a similar
environment for C++ or Java or whatever. When you're working on a
larger project, you will always have to learn to use the tools needed
for working on it anyway, but the choice of the tools is unlikely to
be yours.
RJ> I mean students are studying computer science and need five to 8
RJ> years. For what? [...] **I** want a student or somebody with a
RJ> degree who **can** program and knows about the tools - I don't
RJ> want to have the upstart of one year to make people
RJ> productive.
Well, I would prefer a student who has a good understanding at solving
problems over one who knows how to press which buttons anyday. And I
would prefer a student who knows both over either one, sure. But given
that there are a lot of companies using lots of different languages
and tools, and that CL is currently not exactly the language en vogue,
I believe that what your wishes are just that: wishes.
Your point with regards to University education then is ...? My
*impression*, though is that very few students will have the chance to
work on a large project, not even for their diploma thesis. And only
very few will use CL, unfortunately.
RJ> But I learned to understand that if you get a 100000+ line NL
RJ> research application under your hands, you better get some grip
RJ> on the tools.
Sure. Did I or anybody else deny that in this thread?
RJ> How do you think anybody will work on this stuff productively
RJ> with inferior development environments or without domain specific
RJ> tools?
Whether your development environment is inferior not, depends on your
task. Nobody is denying the use of the tools available. All I was
saying is that clicking on the mouse is not equal to programming.
RJ> But there is a lot more to an Lisp IDE than just menus.
[...]
Ah, finally, some useful information! Why didn't you post that
information directly, because this is exactly what the initial poster
wanted to learn more about?
Relating this to the university discussion above, I fear that most
students will never ever throughout their university live use only 1%
of such an environment. But perhaps this is just my impression.
>> [1] They are *not*: similar to the "Windows is easy to
>> administrate"-myth, just because you see what options are there,
>> it's still not true that you don't have to *understand* the
>> options first.
RJ> But they are easier to locate and you can provide unobstrusive
RJ> in-place help easily.
I still wait to see an administration environment that both comes with
an easy interface and at the same time provides in-depth in-place
help. Which doesn't make the idea invalid, of course. But this really
takes the thread off-topic.
Holger
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"Hi ! I'm a .signature virus!
Copy me into your ~/.signature to help me spread!"
In article <··············@ipanema.coling.uni-freiburg.de>, Holger
Schauer <··············@gmx.de> wrote:
> >> most of the features will not help you in solving the tasks that
> >> you will have to solve during your university years (unless you
> >> will do a large project in CL, which is rather seldom nowadays).
>
> RJ> What are they doing in "university years" in Germany?
>
> With CL or at all? If I hadn't worked outisde of the university on a
> project involving CL, I would probably still have no clue about
> it. So, my impression is that students will either never use CL at
> all, or just get to solve small homework tasks and per chance they
> will work on some term project (which the "large project" should refer
> to).
Well, this seems to be different in Hamburg. A lot of the
professors know Lisp and teach Lisp (over the years I have seen a lot
of Lisp dialects being used). A lot of projects (not only
AI) have been using Lisp in the past 20 years. Some of them
were big research projects - some of them spawned commercial
applications. The range was/is: image processing, image
sequence understanding, psychology, natural language systems,
music programming, simulation systems, expert systems,
visual programming, hardware design, lambda calculus, ...
> that there are a lot of companies using lots of different languages
> and tools, and that CL is currently not exactly the language en vogue,
> I believe that what your wishes are just that: wishes.
As I said, I saw quite some very good students using Lisp
in interesting applications. Just look what some
of the students of Ralf M�ller were doing:
http://kogs-www.informatik.uni-hamburg.de/~moeller/diploma-theses.html
> Your point with regards to University education then is ...? My
> *impression*, though is that very few students will have the chance to
> work on a large project, not even for their diploma thesis. And only
> very few will use CL, unfortunately.
Really? This is clearly different in Hamburg.
> Ah, finally, some useful information!
Don't say this is news ?
For those interested, David Lamkins has some excellent
online resources (highly recommended):
His online book:
"Successful Lisp: How to Understand and Use Common Lisp"
http://psg.com/~dlamkins/sl/html/contents.html
"David Lamkins' FTP Site" shows some extensions to MCL:
http://psg.com/~dlamkins/ftp-catalog.html
> Relating this to the university discussion above, I fear that most
> students will never ever throughout their university live use only 1%
> of such an environment. But perhaps this is just my impression.
I really can't imagine that.
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> In article <··············@ipanema.coling.uni-freiburg.de>, Holger
> Schauer <··············@gmx.de> wrote:
> Let's look at the domain of chess problems.
> A game is a sequence of moves and an initial situation.
>
> Situation: Ta6, Tc4, Kc5 and Kc8, Te3, Tg7
>
> 1. Kc5-b6 (+) Kc8-d8!
> 2 Ta6-a8 + Kd8-e7!
> 3. Ta8-a7 +!
>
> Now you can:
> a) Imagine what's going on by just creating a mental image
> b) draw a chess board with the initial situation
> c) draw chess boards for the initial and all the following situations
> d) take a chessboard, place the pieces and play around with the problem
>
> Version d) directly brings us to the idea of direct manipulative
> graphical user interfaces.
> (-> Chessbase "http://www.chessbase.com/products/cb8/cb801.htm")
>
> Emacs+CL as an IDE reminds me of a).
The problem [which may be one of "violent agreement" moreso than
"violent disagreement"] is that while d) may be the preferred _final
system approach_, you need to have a) in mind as well, as this
represents the underlying implementation.
The "Windows Wizard" approach seems to try to jump straight to
generating d) without having thought through anything about the
underlying system model.
To be a bit critical for a moment, you have mentioned visual
representation and description of positions, but haven't thus far
mentioned anything about the evaluation of legal moves. Now, I'm
reasonably sure that this lack of mention was inadvertant; it still
shows that there's a fair bit more to things. The legal set of chess
moves do have a sort of visual representation, but it seems to me that
they're better represented symbolically.
--
(concatenate 'string "cbbrowne" ·@ntlug.org")
http://vip.hyperusa.com/~cbbrowne/unix.html
"It don't mean a thing, if it ain't got that swing..."
>>>>"RJ" == Rainer Joswig schrieb am Sun, 21 Jan 2001 15:21:40 +0100:
>> In my current task, I'm mainly hacking knowledge bases (btw making
>> use of Ontosaurus, a browser for knowledge bases on top of
>> CL-HTTP), so could you please be so kind and tell me *where* and
>> *what* exactly the benefits of <you name it>-GUI should be for
>> this task?
RJ> Isn't Ontosaurus already a step in this direction?
It is an external tool made availabe by the developers of Loom, so we
are not talking about a Lisp issue here anymore. I just wanted to
illustrate that I do use tools if they are available.
RJ> It is hard to imagine that one can develop ontologies without the
RJ> help of graphical browsers.
Right. So the tool is made available by the developers of the
kr-system in which one is developing the ontology.
Which tool is made available of a similar usefulness for programming
Common Lisp by which commercial lisp vendor (and no, I'm not denying
that there are some. I just would like to know which ones)?
>> It's nice to hear though, that at least one particular Lisp vendor
>> has come up with a fancy environment.
RJ> It is not extremely "fancy" (you can develop fancy stuff on top
RJ> of that). But it is very responsive, uncluttered and extensible.
So, do I understand you correctly now that you say that from the IDE
itself you don't get much support, but you can easily extend it so
that you get all the support you might want? Excuse me, but if this
is so, then this is certainly not at all what a "modern" IDE should
give you, because it should bring with it *most* of the tools you
need. CLOS class browser and similar things come to mind. That's the
kind of things I wanted to get answers to. [1]
>> Emacs (XEmacs in particular) allows much more things than just
>> programming and *you know that*. I'm mostly spending my time doing
>> research work and why the heck should I use another *editor* for
>> writing texts than for programming? And btw: why are the
>> keybindings arcane
RJ> come on, "numeric-prefix c-something shift-control-something" ???
In my constant use of Emacs over the last ten years, I almost never
used keybindings of the complexity that you're suggesting. In Ilisp,
almost all you need is C-z plus one key. And changing that is
easy. Yes, changing that in a CL-based IDE is probably similar
easy.
No, I'm not arguing that Emacs has tons of advantages over whatever
IDE. Actually, you are shifting the burden of proof (see alt.atheism's
faq) because it was *claimed* that commercial Lisps have some added
value (of which I wanted to learn more about) and first you're saying
"that's obvious" (it's not, otherwise I wouldn't ask) and now you're
even trying to make me bring arguments in favour of some never stated
Emacs+CL superiority.
>> and why has it a poorer extension system (I'm not even sure what
>> extensions you are talking about)?
RJ> Emacs Lisp vs Macintosh Common Lisp, for example.
Emacs Lisp is not as comfortable to program as CL, true. Are you
extending your MCL IDE to allow for LaTeX editing? There are many
extensions to Emacs available, so more often than not I don't have to
extend Emacs myself.
>> Recognizing the problems at hand and knowing about the
>> solutions is one thing, using tools another.
RJ> Software visualization, visual programming, visual query
RJ> languages, ...
Hah. Which of these is there for Common Lisp? Jam tomorrow? Next week?
I wouldn't hold my breath for most tasks that await solutions
today. (Again: I'm not denying that "visual" programming might be a
good idea. Unfortunately, I haven't seen much of it.)
RJ> To give a few examples and comparisons:
... which are completely irrelevan to what we're discussing, because
as I have stated probably five times at least by now, I'm not against
any kind of *additional* tool, be it menus or whatever.
RJ> Now you can: a) Imagine what's going on by just creating a mental
RJ> image [...] d) take a chessboard, place the pieces and play
RJ> around with the problem. Version d) directly brings us to the
RJ> idea of direct manipulative graphical user interfaces. (->
RJ> Chessbase "http://www.chessbase.com/products/cb8/cb801.htm")
RJ> Emacs+CL as an IDE reminds me of a).
I have no idea, why Emacs+CL has anything to do with a) or stands in
contrast to d) like you're suggesting. d) is a specific tool for a
specific problem. Fine for me, I use a visual tool (Ontosaurus) any
day. But could you please explain how your graphical or visual
environment for a Turing-complete language aka Common Lisp looks like?
Does it ship with MCL or are you just making up another strawman?
RJ> I'm sure, you can get far with the Emacs+CL approach. But using
RJ> MCL with Open Music is so much more fun. ;-)
Nobody argued that the holy grail of programming can be found by
fanatically restricting yourself to Emacs+CL.
Holger
Footnotes:
[1] And yes, in this respect, I'm probably more a consumer type of
user, but I recognize the amount of work being done at the
infra-structure level. Life is too damn short to always build the
infra-structure from scratch yourself. Nobody of us would use a
computer today, if we were all to first provide electricity for it.
--
--- http://www.coling.uni-freiburg.de/~schauer/ ---
"While it may look like it at a casual glance, XEmacs does not link
against every library in Known Space."
-- SL Baur on xemacs-beta
In article <··············@ipanema.coling.uni-freiburg.de>,
Holger Schauer <··············@gmx.de> wrote:
> Which tool is made available of a similar usefulness for programming
> Common Lisp by which commercial lisp vendor (and no, I'm not denying
> that there are some. I just would like to know which ones)?
You might need to look, if the LispWorks IDE, the MCL IDE
or the Genera IDE is something that gives you a productivity
(or a learning) advantage.
> RJ> It is not extremely "fancy" (you can develop fancy stuff on top
> RJ> of that). But it is very responsive, uncluttered and extensible.
>
> So, do I understand you correctly now that you say that from the IDE
> itself you don't get much support,
I didn't say that. You get the nice, easy uncluttered support
of MCL. Plus the ability to extend it easily.
> but you can easily extend it so
> that you get all the support you might want? Excuse me, but if this
> is so, then this is certainly not at all what a "modern" IDE should
> give you, because it should bring with it *most* of the tools you
> need. CLOS class browser and similar things come to mind. That's the
> kind of things I wanted to get answers to.
Even if it does not bring everything out of the box,
users have contributed tons of extensions over the years.
This is not different form Emacs. Only that it
is specifically for a Common Lisp development environment.
> No, I'm not arguing that Emacs has tons of advantages over whatever
> IDE. Actually, you are shifting the burden of proof (see alt.atheism's
> faq) because it was *claimed* that commercial Lisps have some added
> value (of which I wanted to learn more about)
Holger, I'm not sure we are in the same discussion thread. ;-)
> Emacs Lisp is not as comfortable to program as CL, true. Are you
> extending your MCL IDE to allow for LaTeX editing?
Why? I'm not doing Latex editing. Should a Lisp
IDE support Latex editing? Why? I'm reading Acrobat
docs. Should my IDE do support displaying Acrobat docs?
I can easily control external tools to do that.
With a keystroke (or menu) I'm in the other app
and with a keystroke I'm back - same like changing
buffers or windows in Emacs - I could also change
to Emacs on the fly. If the Latex support is
good in Emacs, that's fine. Use it. I would use
it too, if I'd need it. Maybe there is support
for that in some MCL contributions - I haven't
looked.
> There are many
> extensions to Emacs available, so more often than not I don't have to
> extend Emacs myself.
That's fine. That's one of the ideas of Emacs. This
is the reason I'm using XEmacs - it has more stuff
out-of the box than GNU Emacs.
> Hah. Which of these is there for Common Lisp? Jam tomorrow? Next week?
> I wouldn't hold my breath for most tasks that await solutions
> today. (Again: I'm not denying that "visual" programming might be a
> good idea. Unfortunately, I haven't seen much of it.)
I have seen such stuff and I have seen people developing it.
> ... which are completely irrelevan to what we're discussing, because
> as I have stated probably five times at least by now, I'm not against
> any kind of *additional* tool, be it menus or whatever.
Oh!
> I have no idea, why Emacs+CL has anything to do with a) or stands in
> contrast to d) like you're suggesting. d) is a specific tool for a
> specific problem.
Yep, and we have a specific problem: developing and maintaining
software (where the latter is the much more costly task).
> Fine for me, I use a visual tool (Ontosaurus) any
> day. But could you please explain how your graphical or visual
> environment for a Turing-complete language aka Common Lisp looks like?
What does it have to do with Turing-completeness?
> RJ> I'm sure, you can get far with the Emacs+CL approach. But using
> RJ> MCL with Open Music is so much more fun. ;-)
>
> Nobody argued that the holy grail of programming can be found by
> fanatically restricting yourself to Emacs+CL.
And I'm not arguing that Emacs+CL+whatever is not useful.
But I'm saying that there is more to that, that some
IDEs are easier to use, are more powerful
for some tasks, and I'm also saying that for any
complex application it is of great value to develop
graphical tools (maybe domain specific) in parallel with
the application (even for server/infrastructure like software
Erik was talking about) - like you develop
tests suites in parallel to the application. This needs
to be learned, just like it needs to be learned to Emacs
or whatever IDE you are using.
Thanks for your patience. ;-)
Sent via Deja.com
http://www.deja.com/
I'd like to jump in here
"Holger Schauer" <··············@gmx.de> ha scritto nel messaggio
···················@ipanema.coling.uni-freiburg.de...
> Thanks for your polite response, Rainer :-( Actually, you don't know
> *anything* - about me and my needs.
>
> So, could you perhaps please elaborate on where exactly "the visual
> input channel" is used when programming when you are not doing
> graphics and GUI design? Using the mouse clicking on menus is
> hopefully not the answer. When I'm programming, having menus and staff
> *additionally* available is nice, but for most things I don't want to
> take off my hands from my keyboard (yes, C-z e is faster than
> copy&paste and then hitting the return-key!).
I'm an hobbist programmer. I happened to do some mantainance on some java
servlets.
I approache the object orientation for the first time with Squeak
Morphs are a kind of objects that reside in ram but also are sohwn on the
monitor, and you can touch them with the mouse.
That's how I understood what an istance is. That's how I learnt the concept
of a program as a system of istances interacting.
Reading about distributed intelligence helped me.
Even before, I learnt what a directory is on a Mac. Now I can even use a
shell. But if I'd had to learn the concept of filesystem and hierarchy in a
shell I'd gave up.
Now I can even create istances and send them messages. Not so, if I only had
code at my disposal.
Now, my point: visual stuff is an incredible learning tool. May be you're
not so much productive, but you surely can learn concepts and build category
in your mind by seeing stuff on your monitor.
If VISUAL stuff makes no sense at all, what UML diagrams are for?
Alan Kay, the father of object orientation, some time ago, wrote the
following sentence in the Squeak mailing list:
" One of the tricks here is to get away from thinking that programs have to
be composed with only a simple text editor "
Bye
Adri
"Lars Lundb�ck" <·············@era.ericsson.se> writes:
> I had no teacher, and discovered Lisp on my own, long ago. Later,
> when I managed to get an Interlisp-D (Xerox) machine, just to play
> with, my first reaction was *wow* and *wow* again. Moving from a
> primitive, line-based, non-documented environment, with primitive
> tools, to this wonderworld was ... well *wow*.
It never seemed a wonderworld to me. Dedit seemed a terrible editor,
hard to use, the code layout it produced was not very readable, it
encouraged excessively nested code, and so on. S-edit was far better,
but only by being more like the supposedly bad line-based editors.
I've also been very happy with the free Lisps I've used.
Yours, heretically ...
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3zogh969d.fsf@cley.com>
* Jeff Dalton wrote:
> It never seemed a wonderworld to me. Dedit seemed a terrible editor,
> hard to use, the code layout it produced was not very readable, it
> encouraged excessively nested code, and so on. S-edit was far better,
> but only by being more like the supposedly bad line-based editors.
Dedit (DEdit?) was awful I think. SEdit (Sedit s-edit?) was better,
*but* occasionally it would just completely screw you horribly in
such a way that you had to save things and then copy them over to the
Unix machine and fix stuff up. With Emacs. And it had things it just
couldn't really do at all, like #+ / #-. And then you had the whole
nightmare that if you wanted to edit things on the dmachine and work
anywhere else, the code you saved from the dmachine just had this
weirdo eccentric indentation and all the line breaks got lost.
Overall, dmachines were kind of like a precursor of windows: very
pretty, lots of advanced tools, almost no documentation, spoke various
semi-proprietary protocols (we had a vax running 4.3BSD mostly because
it supported XNS), and occasionally (if it was only occasionally you
were lucky) they would just destroy about a week's worth of work for
the pure joy of it. So you can see why people liked them so much.
But it *was* very cool the way the clock ran backwards on april 1....
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com>
wrote:
> * Jeff Dalton wrote:
>
>
> > It never seemed a wonderworld to me. Dedit seemed a terrible editor,
> > hard to use, the code layout it produced was not very readable, it
> > encouraged excessively nested code, and so on. S-edit was far better,
> > but only by being more like the supposedly bad line-based editors.
>
> Dedit (DEdit?) was awful I think. SEdit (Sedit s-edit?) was better,
> *but* occasionally it would just completely screw you horribly in
> such a way that you had to save things and then copy them over to the
> Unix machine and fix stuff up. With Emacs. And it had things it just
> couldn't really do at all, like #+ / #-. And then you had the whole
> nightmare that if you wanted to edit things on the dmachine and work
> anywhere else, the code you saved from the dmachine just had this
> weirdo eccentric indentation and all the line breaks got lost.
;-)
Btw., did they ever adjust the structure editor to
support Common Lisp in some ways? Since it was written
originally for InterLisp?
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Rainer Joswig <······@corporate-world.lisp.de> writes:
> Btw., did they ever adjust the structure editor to
> support Common Lisp in some ways? Since it was written
> originally for InterLisp?
yes, sedit worked with CL. In fact: Didn't it first come with Lyric, the
first Xerox Common Lisp release?
--
(espen)
In article <··············@wallace.ws.nextra.no>,
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
> Rainer Joswig <······@corporate-world.lisp.de> writes:
>
> > Btw., did they ever adjust the structure editor to
> > support Common Lisp in some ways? Since it was written
> > originally for InterLisp?
>
> yes, sedit worked with CL. In fact: Didn't it first come with Lyric, the
> first Xerox Common Lisp release?
But did they add CL specific capabilities to it
(-> documentation, declarations, ...)?
CL was a bit the death to these systems. CL was not
much influenced by InterLisp-D and did not adopt
much from the culture surrounding InterLisp-D.
Sent via Deja.com
http://www.deja.com/
······@corporate-world.lisp.de wrote:
>
> In article <··············@wallace.ws.nextra.no>,
> Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
> >
> > yes, sedit worked with CL. In fact: Didn't it first come with Lyric, the
> > first Xerox Common Lisp release?
>
> But did they add CL specific capabilities to it
> (-> documentation, declarations, ...)?
>
SEdit was indeed extended to work with CL. It did the right thing with
semi-colon comments - comments with 1, 2, 3, or four semicolons were
indented appropriately and they automatically word-wrapped, and you
could put them anywhere in code (unlike Interlisp comments that were
actual forms). Documentation strings were handled correctly, both by
the editor and the rest of the definer system.
After en.vos crashed and burned, I added better support for #b, #o, #x,
and #r, and real support for #+/#-. Before sanity reasserted itself, I
was considering adding support for circular structures.
SEdit was a useable code editor, but the place it really shone was in
debugging - it's so much more natural to display list structure and
modify it as an S-expression than to view it in an inspector all
flattened out.
--
Remove obvious stuff to e-mail me.
Bob Bane
In article <·················@removeme.gst.com>,
Bob Bane <····@removeme.gst.com> wrote:
> ······@corporate-world.lisp.de wrote:
> >
> > In article <··············@wallace.ws.nextra.no>,
> > Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote:
> > >
> > > yes, sedit worked with CL. In fact: Didn't it first come with Lyric, the
> > > first Xerox Common Lisp release?
> >
> > But did they add CL specific capabilities to it
> > (-> documentation, declarations, ...)?
> >
> SEdit was indeed extended to work with CL. It did the right thing with
> semi-colon comments - comments with 1, 2, 3, or four semicolons were
> indented appropriately and they automatically word-wrapped, and you
> could put them anywhere in code (unlike Interlisp comments that were
> actual forms). Documentation strings were handled correctly, both by
> the editor and the rest of the definer system.
Interesting.
> After en.vos crashed and burned, I added better support for #b, #o, #x,
> and #r, and real support for #+/#-. Before sanity reasserted itself, I
> was considering adding support for circular structures.
>
> SEdit was a useable code editor, but the place it really shone was in
> debugging - it's so much more natural to display list structure and
> modify it as an S-expression than to view it in an inspector all
> flattened out.
Yes, this makes sense. The problem with the text editor
is, that it first needs to print the data and then reread
the text from the text buffer. A structure editor can
edit the Lisp data directly.
The Symbolics Lispm also can edit data in place. Example:
- you print a list (1 2 3 4) to any listener
- mouse-right on the 3 for example, menu -> "Modify this structure slot"
- then you can edit it
- a return accepts and changes the actual cons cell content of the list
Sent via Deja.com
http://www.deja.com/
······@corporate-world.lisp.de writes:
> > yes, sedit worked with CL. In fact: Didn't it first come with Lyric, the
> > first Xerox Common Lisp release?
>
> But did they add CL specific capabilities to it
> (-> documentation, declarations, ...)?
I think so. But it's a while ago, about at that time I found out
that MCL on a cheap mac was (all things considered) a better
"lisp machine", so...
--
(espen)
From: Tim Bradshaw
Subject: Re: Commercial Lisp or Free Lisp
Date:
Message-ID: <ey3lms08th6.fsf@cley.com>
* Rainer Joswig wrote:
> Btw., did they ever adjust the structure editor to
> support Common Lisp in some ways? Since it was written
> originally for InterLisp?
sedit kind of mostly worked for CL in medley. In fact really the
dmachines kind of mostly worked for CL...
--tim
Tim Bradshaw <···@cley.com> writes:
> Overall, dmachines were kind of like a precursor of windows: very
> pretty, lots of advanced tools, almost no documentation,
Hey, the D-Machines I've used always came with plenty of binders full
of documentation! In fact, the documentation set that came with a
pre-Lyric release of Interlisp was at least as heavy as a Symbolics
documentation set ca. Release 5. I can't remeber if there was ever a
DocEx of VisiDoc style document viewer for the D-Machines although I
wouldn't be suprised if there was.
Jeff Dalton wrote:
>
> It never seemed a wonderworld to me. Dedit seemed a terrible editor,
> hard to use, the code layout it produced was not very readable, it
> encouraged excessively nested code, and so on. S-edit was far better,
> but only by being more like the supposedly bad line-based editors.
Yes, my memory tells me to agree. But (there is always a but) I merely
wrote that it was wonderful. And it was because it had many of the
properties I lacked at that time, and I could easily overlook the flaws.
> I've also been very happy with the free Lisps I've used.
Me too. But (see, there it is again) I *knew* what I wanted to do with
them. The same goes for FFI, GUI kits, you can do a lot, once you have
learned the essentials.
> Yours, heretically ...
Surely I'm the culprit around here, betraying the True Cause of Common
Lisp, which is line based by definition. :))
Lars
In article <··············@mailandnews.com>, IBMackey
<········@hotmail.com> wrote:
> So I guess the question is, what's the best learning environment for
> new students interested in lisp?
ACL/Windows and LispWorks are okay. Still the best is
Macintosh Common Lisp. It is simple, powerful, and
has an easy to use GUI toolkit.
> A side question to that would be,
> should you use or learn lisp to the exclusion of other programming
> models?
I started with things like UCSD Pascal, Modula 2, several Assembly
languages, VAX Pascal, MacScheme, CSP, SAIL and some other weird stuff.
MacScheme was fun. At the University of Hamburg they did
once have the introductory computer science course
start with Common Lisp. Still you need to add some
Java, Prolog, Ada, Miranda, ... to get a broader picture
of programming. Then you need to practice programming...
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
IBMackey <········@hotmail.com> writes:
>
> So I guess the question is, what's the best learning environment for
> new students interested in lisp? A side question to that would be,
> should you use or learn lisp to the exclusion of other programming
> models?
>
> i.b.
Hi,
I read a quote by Jamie Zawinski, to the effect that "free software is
only free if your time is worth nothing." I agree with that. If you
are in a hurry, then maybe you should go for the commercial stuff.
On the other hand, using free stuff requires you to do a lot of
exploration, poking round in all sorts of places for the answers to
whatever questions arise. That process of poking around often teaches
you things you didn't know you wanted to learn ;-)
Peter
Peter Wood <··········@worldonline.dk> writes:
>
> I read a quote by Jamie Zawinski, to the effect that "free software is
> only free if your time is worth nothing." I agree with that. If you
> are in a hurry, then maybe you should go for the commercial stuff.
> On the other hand, using free stuff requires you to do a lot of
> exploration, poking round in all sorts of places for the answers to
> whatever questions arise. That process of poking around often teaches
> you things you didn't know you wanted to learn ;-)
My experience indicates otherwise. while I have had both commercial
and GNU versions of software available on my system for free to me,
(so for me, they are both free monetarily..), I have always found the
free software well documented.. and documentation very easily
available.. Also, the free versions have also seemed superior..
perhaps because there are many more 'developers' and bug/patch-submitters?
--Deepak, http://www.glue.umd.edu/~deego