To: comp.lang.lisp --
I received the following communication from Harlequin in Boston this
afternoon. It appears that they will continue in business after being
acquired by Global Graphics. The events of the past week should ultimately
serve to strengthen the Lisp community and remind us that survival requires
more than just being the best (language) around. I hope Global Graphics
will appreciate the capabilities of Lisp, the quality of Harlequin's
Lispworks and will work towards expanding its commercial and scientific
utilization.
Phil Marks
·····@tampabay.rr.com
===================================
12th July, 1999.
GLOBAL GRAPHICS ACQUIRES HARLEQUIN
GLOBAL GRAPHICS (EASDAQ: GLGR), the leading worldwide supplier of
plate-processing equipment for the graphic arts industry, announced today
that it has successfully completed the acquisition of Harlequin Group for a
purchase price of 18 million Euro.
Following completion of the acquisition, Global Graphics gave immediate
assurances that Harlequin's greatest asset, its highly talented UK and US
personnel base, would continue to be fully supported.
Johan Volckaerts, Chairman and CEO of Global Graphics said, "the Harlequin
name is an printing and publishing icon and the excellence of its
technology is recognised throughout the whole industry. Such success has
been due to the recognised brilliance of its software development teams and
the unflagging efforts of all the staff. This has been a difficult time for
them and we acknowledge their loyalty and belief in the company.
"Our goal is to strengthen Harlequin, not to change the very origins of its
success. The acquisition will therefore ensure Harlequin's financial
stability and will provide the means and support to continue to nurture the
innovative approach for which Harlequin has become famous."
Global Graphics will operate Harlequin independently from other group
manufacturing operations. A priority consideration is to invest in a new
management infrastructure and those management skills that Harlequin lacked
in the past to accelerate the development of the group's digital solutions
and applications.
Under the new organisation, Harlequin's management team will report
directly to Andrew Brian, Global Graphics UK managing director. Mr. Brian
recognises the strong role the OEM sector will continue to play in the
on-going success of Harlequin. "We look forward to working with our new OEM
partners, some of whom are long-standing customers of other group
companies. We will be meeting all OEM partners in the coming weeks to give
them our firm assurance that there will be no change in our service and
support structure and that there will be no preferential treatment for
group companies."
To the surprise of many in the industry, Harlequin was forced into
receivership on July 6th. Despite this, the Digital Print and Publishing
(DP&P) business was profitable with estimated EBIT (Earnings Before
Interest and Tax) of 5.2 million Euro on sales of 21 million Euro. Global
Graphics is currently assessing Harlequin's recent investments in the
Information Management and Software Tools business to determine
opportunities and strategic direction.
Following extensive restructuring by Harlequin at the end of last year,
staffing was reduced to approximately 140 with offices retained in the US,
the UK (HQ in Cambridge) - rationalisation which marked a return to
profitability for the company. As a result, Harlequin is expected to
generate revenue of approximately 30 million Euro and EBIT before goodwill
amortisation of around 7.5 million Euro for the 12 months ending March 31,
2000.
Established in 1986, Harlequin offers a diverse array of products and
services including digital printing and publishing technology, information
management systems, software development and delivery tools and TV, film
and post production technology.
Global Graphics is an independent company that develops, manufactures and
distributes a broad range of high-performance process equipment dedicated
to meeting the needs of the graphics arts industry. Other companies in
Global Graphics UK include Heights Technologies Ltd. and ICG. The company's
common stock is listed on the EASDAQ Stock Exchange.
- Ends -
Press information: Graeme Holmes
Winwood PR
Tel: Int +44 (0)1484 689755
Fax: Int +44 (0)1484 689744
e-mail: ······@winwood.co.uk
Harlequin Inc. phone: 617-374-2550
One Cambridge Center fax: 617-252-6505
Cambridge, MA 02142 email: ·····@harlequin.com
==========================================================
Robert Monfera wrote:
> Check out the announcement:
>
> http://www.glographics.com/pressrelease15.htm
Hmmmm. It doesn't seem to suggest that Common Lisp is a major feature
in their vision of Harlequin's future... (Nor, for that matter,
ML or Dylan.) It'll be interesting to see what happens.
There's some more information at
http://www.harlequin.com/news/press/hqn_0799.html
All that says about the products likely to be of most interest to c.l.l
readers is
| Global Graphics is currently assessing Harlequin's recent
| investments in the Information Management and Software Tools
| business to determine opportunities and strategic direction.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
················@pobox.com Cambridge University, England.
I wrote:
> There's some more information at
> http://www.harlequin.com/news/press/hqn_0799.html
[etc]
... not realising that the article I was following up to was itself
a followup to an article containing all the text from that page. So,
er, don't bother following that link.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
················@pobox.com Cambridge University, England.
In article <··············@g.pet.cam.ac.uk>, Gareth McCaughan <················@pobox.com> wrote:
> Robert Monfera wrote:
>
> > Check out the announcement:
> >
> > http://www.glographics.com/pressrelease15.htm
>
> Hmmmm. It doesn't seem to suggest that Common Lisp is a major feature
> in their vision of Harlequin's future...
Isn't some of the "Harlequin Intelligence Systems" stuff they
mention written in Lisp?
> (Nor, for that matter,
> ML or Dylan.) It'll be interesting to see what happens.
A sentence from the press release:
"Harlequin was forced into receivership because of massive R&D
investments for several years in software for Information Management
and Software Tools applications. In the fiscal year ended March 31, 1999,
Harlequin spent an estimated 19.5 million Euro on these projects, which
generated only 4.2 million Euro in revenue. The DP&P products were
profitable with estimated EBIT of 5.2 million Euro on sales of 21
million Euro. The continuous cash drain from the development of
Information Management and Software Tools applications ultimately
resulted in the receivership end of June."
Let's guess, Dylan got the biggest part of the "massive R&D investments"?
What would you do? Actually I don't care about Dylan at all
and I only see it drawing money and resources from others -
kind of a vampire. Instead of improving Lisp gradually,
too much money/time/... is being spent on some tool nobody really
needs (IMHO).
In article <·······················@194.163.195.67>,
······@lavielle.com says...
> Let's guess, Dylan got the biggest part of the "massive R&D investments"?
> What would you do? Actually I don't care about Dylan at all
> and I only see it drawing money and resources from others -
> kind of a vampire. Instead of improving Lisp gradually,
> too much money/time/... is being spent on some tool nobody really
> needs (IMHO).
Hmm. I didn't see any references to specific development tools. I'm
just glad that Harlequin is looking healthy again. That's what counts.
--
Remove insect from address | You can never browse enough
will write code that writes code that writes code for food
······@lavielle.com (Rainer Joswig) writes:
> Let's guess, Dylan got the biggest part of the "massive R&D investments"?
> What would you do? Actually I don't care about Dylan at all
> and I only see it drawing money and resources from others -
> kind of a vampire. Instead of improving Lisp gradually,
> too much money/time/... is being spent on some tool nobody really
> needs (IMHO).
They had a whole bunch of AI-type stuff in law enforcement which I
suspect ate huge money, so I'm not sure it was Dylan (though Dylan
took about 5 years to long to ship, so ...). I've heard reports that
the lisp busness was reasonably profitable as well. In any case it's
very important not to fall into the Concorde fallacy with this kind of
thing -- it's only whether the thing will make or lose money in the
future that counts.
--tim
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> They had a whole bunch of AI-type stuff in law enforcement which I
> suspect ate huge money, so I'm not sure it was Dylan (though Dylan
> took about 5 years to long to ship, so ...).
With how many people? What does a man year of an very good
developer/designer/writer/ cost? Sum that over x years...
> very important not to fall into the Concorde fallacy with this kind of
> thing -- it's only whether the thing will make or lose money in the
> future that counts.
It's similar important that you can finance things today.
--
Please remove dot nospamski dot from the return address.
----------
In article <·······················@pbg3.lavielle.com>, ······@lavielle.com
(Rainer Joswig) wrote:
> In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>
>> They had a whole bunch of AI-type stuff in law enforcement which I
>> suspect ate huge money, so I'm not sure it was Dylan (though Dylan
>> took about 5 years to long to ship, so ...).
>
> With how many people? What does a man year of an very good
> developer/designer/writer/ cost? Sum that over x years...
100-130K US per man year just on salary, how about 300K per year
with business overhead per man year.
>
>> very important not to fall into the Concorde fallacy with this kind of
>> thing -- it's only whether the thing will make or lose money in the
>> future that counts.
>
> It's similar important that you can finance things today.
On Mon, 19 Jul 1999 20:17:06 -0600, Todd Nathan
<···············@PalomaBlanca.net> posted:
>In article <·······················@pbg3.lavielle.com>, ······@lavielle.com
>(Rainer Joswig) wrote:
>> In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>>
>>> They had a whole bunch of AI-type stuff in law enforcement which I
>>> suspect ate huge money, so I'm not sure it was Dylan (though Dylan
>>> took about 5 years to long to ship, so ...).
>>
>> With how many people? What does a man year of an very good
>> developer/designer/writer/ cost? Sum that over x years...
>
>100-130K US per man year just on salary, how about 300K per year
>with business overhead per man year.
... And if the product markup isn't drastically high, it may take $500K
in sales to support this.
--
"Another of Fortran's breakthroughs was the GOTO statement, which was a
uniquely simple and understandable means of structuring and modularizing
programs." -- Article on Backus' "Draper Prize"
········@hex.net- <http://www.ntlug.org/~cbbrowne/lsf.html>
>> Hmmmm. It doesn't seem to suggest that Common Lisp is a major feature
>> in their vision of Harlequin's future...
>
>Isn't some of the "Harlequin Intelligence Systems" stuff they
>mention written in Lisp?
Yes indeed - Watson was written in Lisp.
>Let's guess, Dylan got the biggest part of the "massive R&D investments"?
>What would you do?
What indeed? ;-)
One thing you won't see in the press releases, and which still galls me on
and off, is that Harlequin's lisp was in profit, and growing as a business.
Imho the only reason it didn't do stunningly better (if Franz can make a
going concern out of a lisp development product, why shouldn't Harlequin be
able to?) was that in the end Harlequin's top management didn't care enough
about it to want it to succeed.
- nick (whose opinions are not currently those of any employer)
In article <············@barcode.tesco.net>, "Nick Levine" <···········@tesco.net> wrote:
> >Let's guess, Dylan got the biggest part of the "massive R&D investments"?
> >What would you do?
>
> What indeed? ;-)
>
> One thing you won't see in the press releases, and which still galls me on
> and off, is that Harlequin's lisp was in profit, and growing as a business.
> Imho the only reason it didn't do stunningly better (if Franz can make a
> going concern out of a lisp development product, why shouldn't Harlequin be
> able to?) was that in the end Harlequin's top management didn't care enough
> about it to want it to succeed.
What makes me feel sorry is that millions of $ have been
"wasted" on Dylan - much of that would have better
been spend on Lisp - that has been my position for years.
I know that I might not have been the target for
these tools. But somebody needs to buy this Dylan stuff.
These ugly guys are usually called "customers"
and are a pain - they have their own ideas what they need. ;-)
I'm a proponent of the "no apologies" position and additionally
I think the Lisp community in general should better stop
wasting time supporting hopeless projects (inventing the next
great language, bringing Lisp features to C/C++/Java/Eiffel/..., ...)
which have no benefit to Lisp itself.
1) it has to be clear where the benefit for the Lisp community is
2) don't let them blame Lisp for their problems
3) concentrate on the real thing
4) don't be satisfied with 50% "solutions"
5) develop applications
6) be visible - have something to show
7) let people wake up and talk (vendors, ...)
8) achieve customer satisfaction
Okay, I'm willing to give some additional oil to the fire:
http://www3.franz.com/lugm99/conference/index.html
For the next LUGM in SF, somebody from the Java camp ;-) (<- ***big*** smily here)
is keynote speaker - where is the benefit?
······@lavielle.com (Rainer Joswig) writes:
> What makes me feel sorry is that millions of $ have been
> "wasted" on Dylan
Dylan was a good idea marketingwise for two reasons: (1) Apple had
committed to putting marketing dollars into it and (2) People were
disenchanted with C++ and needed an alternative. The decision to
continue with Dylan was, as nearly as I could tell, never reconsidered
in light of Apple backing away from the development and marketing of
Dylan nor in light of the arrival of C++. Before Java, it was a dead
certainty that people abandoning C++ would need a place to go and it
seemed likely that Dylan would offer them cover. That was a strong
reason why the syntax was revised to infix--to not alienate those
seeking something "familiar". But once Java came along with true
syntax compatibility and nearly-overlapping semantics, all those
reasons for Dylan to be as it was were not revisited to see if it
wasn't perhaps better to be more different...
Whether that makes Dylan a bad language is another matter. It has
done some thoughtful redesign of things that have been gnawing at Lisp
for quite some time.
The technical decisions in Dylan are interesting and worth taking
seriously. They were arrived at by observing major problems in a
number of key languages, including but not limited to Lisp, and taking
on those issues directly. BUT, for example, the syntax issue was never
so much a technical as a political one. Dylan made its gamble on the
idea that alienating Lisp was ok because it was going to buy the
affection of the C++ crowd. There as a time during which it was hard
to engage the Dylan managers at Harlequin in a conversation on how
Lisp would relate to Dylan because it seemed that if you mentioned
"Lisp" anywhere near a potential Dylan customer, that would be the
kiss of death.
Now that Java has wooed most of the potential customers that Dylan
sought, that decision deserves some reconsidering. Lisp's syntax is
one of the key reasons I prefer it. It's not Lisp's only feature, but
it's tremendously powerful. An infix Lisp would be nearly unusable to
me, and not because it would be hard to learn another syntax--rather,
because the ergonomics of the language would be impractical. As such,
it's not a practical compromise to me. By contrast, a Dylan
with Lisp syntax (read: ergonomics) would be a big win, and I think
a lot of people would welcome a return to the old "optionally infix"
situation where the underlying language was s-exprssion and infix was
an optional add-on for those who couldn't bear it. Maclisp [on the PDP10
in the 1970's, not the Mac later] had a similar device [CGOL] which
did a similar papering over for the sake of the numerical theory crowd
who preferred infix.
No firm theories here. Just thinking aloud...
In article <···············@world.std.com>, Kent M Pitman <······@world.std.com> wrote:
> (2) People were disenchanted with C++ and needed an alternative.
I don't buy it.
Dylan has been designed (as I understand it) as a programming
language for systems (operating systems) and applications
(and not as a scripting language - somebody mentioned
this on his web page). On the Mac applications are
"usually" either written in Pascal, C or C++. For Pascal
Apple didn't provide much life support. C++ has been
chosen for applications (Finder, ...) and C for a lot of system
level programming (Quicktime, ...).
Now a few years later ... the same combination.
The new "Indesign" from Adobe is written in C++.
Cyberstudio (by some develepers here in Hamburg ;-) )
is a C++ application. These people are satisfied
with C++ and they have written some highly cool toys
to ease development. Cyberstudio for example has
an internal C++ library which origins are coming from the NeXT.
Now this library has a very nice graphical user
interface designer - whose influence are coming from the
NeXT "Interface Builder". The "Interface Builder"
was orinally a Lisp application running on a Mac
written in LeLisp. Porting CyberStudio, a highly graphical
piece of software (it's a cool HTML editor) to the
Windows world took one year - until it reached the
customer. Why should they use Dylan? With Lisp
or Smalltalk they might get a faster development
cycle and more readable code and better development
systems - you can tailor a Lisp-based development
system much better. (But for example IBM has
development systems written in Smalltalk (VisualAge
for Java, for example) - and they won't let users
customize the IDE - this model is foreign to those
managers - they are fearing that customers then
depend too much on special features of the IDE
and this makes upgrading/selling hard). But
C++ is good enough for *them*.
So, the bad news is (IMHO), developers are often sufficiently
satisfied with C++. There isn't even a slight chance
to get into this market, unless you make
some fundamental things right (like showing off
real applications and development processes how to get
to these applications, education, mindshare, libraries,
source code, ...).
> The decision to
> continue with Dylan was, as nearly as I could tell, never reconsidered
> in light of Apple backing away from the development and marketing of
> Dylan nor in light of the arrival of C++.
I have thought that this might be the case. Wasn't
this is a basic management problem?
> Whether that makes Dylan a bad language is another matter. It has
> done some thoughtful redesign of things that have been gnawing at Lisp
> for quite some time.
I was thinking that at that time EuLisp was a chance for
the Lisp community. Well, it's a European design and those US
people are not really knowing that there are other
continents - I know - but it was an attempt to fix
things and stay within the Lisp mindset. And yes,
people were thinking how to fix the CLOS "problems" ->
TELOS.
But a few Lisp users here in Hamburg were thinking about
this years ago. The conclusion was that Common Lisp
is good enough and we are **using** it until something
really better comes along - in those years a number
of very nice Common Lisp applications were the result
(research and commercial).
Anecdote: Lately a large research project ended and the results
had to be presented. The University was earlier asked
to switch to C++ but refused - one special semi-commercial partner
was doing C++. You can guess after all the women and men years
of development, whose code has been presented at the
of the project to the public? ... It was the Lisp code that
did something useful.
> so much a technical as a political one. Dylan made its gamble on the
> idea that alienating Lisp was ok because it was going to buy the
> affection of the C++ crowd.
It goes so far that in one of these Dylan books they
don't even mention Lisp or CLOS. Not even once.
And Dylan was a repackaged Common Lisp.
> There as a time during which it was hard
> to engage the Dylan managers at Harlequin in a conversation on how
> Lisp would relate to Dylan because it seemed that if you mentioned
> "Lisp" anywhere near a potential Dylan customer, that would be the
> kiss of death.
Think of Franz's "Dynamic Objects" - the same problem.
> Now that Java has wooed most of the potential customers that Dylan
> sought, that decision deserves some reconsidering.
*I* don't think so. Dylan's opportunity is gone. Period.
As a Lisp user, I never cared much about Dylan - other
than seeing whether the hype was justified - in the
end it wasn't even a "Dynamic" Language - it was static.
Now it's even less attractive - not only the
syntax changed.
My position:
I as a Lisp user ask myself, what should be done to make
Lisp users happy and make it attractive for other
to develop applications (or even a new operating system)
in Lisp? Yes, widening the market is one goal. Yes,
serving the needs of the current users is another.
At the end the ability to deliver software is my measurement
of success. "Delivery" means getting something out of the
door ***and*** make it surving the next years.
"Ability" means having the necessary infrastructure
(modelling languages, UI designers, multilanguage
support, dongles, source debuggers, robustness of tools, ...).
Isn't it great that Common Lisp hasn't changed in the last years?
All my code still runs - while outside a storm is going on.
Rainer Joswig
······@lavielle.com (Rainer Joswig) writes:
> In article <···············@world.std.com>, Kent M Pitman <······@world.std.com> wrote:
>
> > (2) People were disenchanted with C++ and needed an alternative.
>
> I don't buy it.
>
I do. People *hate* C++. They use it because they perceive there is
no alternative, but they loathe it. There are lots of horrors --
spectacular compile times mean you spend most of your time in the
coffee room; large OO programs with lots of pointers mean you
basically need something like purify (at however many thousand dollars
per seat per year) to get your code to run; the language is unstable
and different compilers seldom implement the same subset, not even
different versions of the same compiler. People doing large C++
projects are living in hell, *and many of them know they are living in
hell*.
I don't understand even slightly why even people who know they are in
it can't get out of this spiral of death, but it does seem to be
genuinely hard. Partly at least I think it's to do with the fact that
window-system based programs really became common about the time C++
became common, so these really enormous, C/C++-specific APIs appeared
to things like Windows which serve to bind people into the language.
Java certainly has not been a realistic option for much of its
lifetime because performance was often really bad (I mean 100s of
times worse than C/C++ for typical apps, not some silly factor of 2
like Lisp), and the APIs are even less stable than C++'s, and equally
enormous. Even so people are leaping all over Java.
So really, I don't understand what is causing things to happen, but I
can see that it must have been easy to think that there was an
opportunity when Dylan was being thought about: the large C++
disasters now in full view were just emerging, Lisp was unfortunately
still too tainted by 80s AI hype to consider, so it must have seemed
like a golden opportunity for a cleaned-up Lisp in slight disguise.
Of course a lot of the large software-project catastrophes are just
plain failures of management. But no one wants to admit that they
might have fouled up, so they will always be searching for the next
cool thing to avoid having to think bad thoughts about themselves.
Exactly the same people who were saying `my project is no good because
it is in Lisp, we must reimplement in C++' about 10 years ago are no
saying `my project is no good because it is in C++, we must
reimplement in Java' now. I know some of these people, and they
really do say this! It takes real strength of character to admit that
actually your project is going wrong because it has not been managed
right, and that what you actually need to do is pick a stable,
non-crippling language (Lisp is a really good candidate now!) which is
adequate if not perfect, and *stick to it* and concentrate on getting
things right.
Or something
--tim
this is so funny...:)
> -----Original Message-----
> From: Tim Bradshaw [··········@tfeb.org]
> Posted At: Tuesday, July 13, 1999 2:53 PM
> Posted To: lisp
> Conversation: Harlequin Is Back!
> Subject: Re: Harlequin Is Back!
>
>
> ······@lavielle.com (Rainer Joswig) writes:
>
> > In article <···············@world.std.com>, Kent M Pitman
> <······@world.std.com> wrote:
> >
> > > (2) People were disenchanted with C++ and needed an alternative.
> >
> > I don't buy it.
> >
>
> I do. People *hate* C++. They use it because they perceive there is
They also loathe Java, I might add. Within the Perl camp
they joke about the OO features of perl...Many who hate C++
still love C...and this is because of its closeness to the
machine and therefore its reflexiveness, which is akin to
Lisp(code==data)...(Java is simply abominable to the core).
I might add, C has an obfuscated code contest, Perl also
has an obfuscated one-liner contest...Lisp has even more gusto
in the area of obfuscation...I've never heard of anything
like this for Java or C++ they're wimps
> no alternative, but they loathe it. There are lots of horrors --
Not to mention projects that fail because they are 1)
mis-conceptualized
from the beginning in UML or some other C++ gigbag and 2)
implemented in C++
> spectacular compile times mean you spend most of your time in the
> coffee room; large OO programs with lots of pointers mean you
> basically need something like purify (at however many thousand dollars
> per seat per year) to get your code to run; the language is unstable
> and different compilers seldom implement the same subset, not even
> different versions of the same compiler. People doing large C++
> projects are living in hell, *and many of them know they are living in
> hell*.
I didn't for years...AND THAT WAS EVEN AFTER having spent a
solid
year on Symbolics in '91
>
> I don't understand even slightly why even people who know they are in
> it can't get out of this spiral of death, but it does seem to be
> genuinely hard. Partly at least I think it's to do with the fact that
It's just ignorance
> window-system based programs really became common about the time C++
> became common, so these really enormous, C/C++-specific APIs appeared
We should all separate C from C++ on our resumes,
never put down "C/C++", always "C, Lisp, Perl blah blah
Java/C++"
> to things like Windows which serve to bind people into the language.
> Java certainly has not been a realistic option for much of its
> lifetime because performance was often really bad (I mean 100s of
> times worse than C/C++ for typical apps, not some silly factor of 2
> like Lisp), and the APIs are even less stable than C++'s, and equally
> enormous. Even so people are leaping all over Java.
Java is subsidized...
It's because you can download all these damn free servers
and database drivers(I mean, FREE Oracle SQL*net drivers, that
means the whole driver is written in Java sockets and talks
Oracle's
proprietary network protocol, for free) and write sloppy code
that
gets garbage collected
>
> So really, I don't understand what is causing things to happen, but I
> can see that it must have been easy to think that there was an
> opportunity when Dylan was being thought about: the large C++
> disasters now in full view were just emerging, Lisp was unfortunately
> still too tainted by 80s AI hype to consider, so it must have seemed
> like a golden opportunity for a cleaned-up Lisp in slight disguise.
>
> Of course a lot of the large software-project catastrophes are just
> plain failures of management. But no one wants to admit that they
> might have fouled up, so they will always be searching for the next
> cool thing to avoid having to think bad thoughts about themselves.
> Exactly the same people who were saying `my project is no good because
> it is in Lisp, we must reimplement in C++' about 10 years ago are no
> saying `my project is no good because it is in C++, we must
> reimplement in Java' now. I know some of these people, and they
> really do say this! It takes real strength of character to admit that
Of old, when Yao governed the empire, he made the people live
happily;
consequently the people struggled to be happy
and became restless. When Chieh governed the empire he made the
people
live miserably; consequently the people
regarded life as a burden and were discontented. Restlessness
and
discontent are subversive of character; and without
character there has never been such a thing as stability.
> actually your project is going wrong because it has not been managed
> right, and that what you actually need to do is pick a stable,
> non-crippling language (Lisp is a really good candidate now!) which is
> adequate if not perfect, and *stick to it* and concentrate on getting
> things right.
>
> Or something
>
> --tim
>
>
>
>
>
>
>
"Kucera, Rich" <·······@hhmi.org> writes:
> Of old, when Yao governed the empire, he made the people live
> happily; consequently the people struggled to be happy and became
> restless. When Chieh governed the empire he made the people live
> miserably; consequently the people regarded life as a burden and
> were discontented. Restlessness and discontent are subversive of
> character; and without character there has never been such a thing
> as stability.
I always knew that Chuang Tse would get quoted at least once in
this newsgroup.
for those interested in the rest of the text this quote came from,
slightly different translation tho:
http://www.ii.uib.no/~arnemo/tao/ChuangTse.html#tolerance
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
I say woe unto those who are wise in their own eyes, and yet
imprudent in 'dem outside -Sizzla
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> I do. People *hate* C++.
But why are many big desktop applications written in C++?
> Java certainly has not been a realistic option for much of its
> lifetime because performance was often really bad (I mean 100s of
> times worse than C/C++ for typical apps, not some silly factor of 2
> like Lisp), and the APIs are even less stable than C++'s, and equally
> enormous. Even so people are leaping all over Java.
But there are others who have large Lisp applications.
They survived the rush to C++ and stayed in Lisp.
But now they might be moving to Java - because of the UI
possibilities. How many are already?
> can see that it must have been easy to think that there was an
> opportunity when Dylan was being thought about: the large C++
> disasters now in full view were just emerging, Lisp was unfortunately
> still too tainted by 80s AI hype to consider, so it must have seemed
> like a golden opportunity for a cleaned-up Lisp in slight disguise.
From what I'm inferring it seemed that Apple wanted
to create new breeds of machines. These were possible
targets for Dylan. The Newton was such a target.
But AFAIK there were concepts for a new range
of computers between PDAs and desktop machines (maybe
more in the line of the original Newton ideas).
So you would have got the chance to have a perfect
combination of innovative Hardware and Software
in a nice package. The mismatch between something
like Dylan and the OS would not be existing. People
even might be forced to use Dylan on those machines
(like Apple forced (or tried to force) developers to use NewtonScript on
the Newton).
> Or something
Exactly.
Rainer
Rainer Joswig wrote:
...
> But now they might be moving to Java - because of the UI
> possibilities. How many are already?
While agreeing with most of what you write, this one makes me think. Do
people write a lot of standalone Java applications, especially because
of its GUI? AWT? Swing? Or are you referring to applets? I am
interested to learn more about it. (For our purposes, we find DOM+HTML
preferable over Swing.)
Off-topic question: if Swing or DHTML is so great, why couldn't we use
it? E.g., lisp plug-in to Netscape or (de facto standard) Swing
bindings? JavaScript feels a bit like a simplified prototype based CL,
so it should not be too hard.
Thanks,
Robert Monfera
In article <·················@fisec.com>, ·······@fisec.com wrote:
> Rainer Joswig wrote:
> ...
> > But now they might be moving to Java - because of the UI
> > possibilities. How many are already?
>
> While agreeing with most of what you write, this one makes me think. Do
> people write a lot of standalone Java applications, especially because
> of its GUI? AWT? Swing? Or are you referring to applets?
Example: BBN is moving CLIM GUIs to Java.
One thing is that some Lisp GUI libraries are looking
****old****. Really old. Just look at modern
applications and their UIs. Applications **need** to keep
pace with what's in current use. It's what
customers are expecting. In MCL for example
some newer stuff is not supported by Digitool
(-> appearance manager). But developers have done it
themselves and it is available for the community.
MCL has a very open approach making that possible.
Additionally Lisp might have to learn something
from component-like approaches to interfaces
(-> Javabeans) - given the introspective
capabilities of Lisp this would an
excellent area to show competence. An interface
builder based on a incremental development system
and a component architecture would be cool.
This is where you could win - not by
discussing infix vs. prefix. Provide cool
solutions - people would either accept
prefix syntax or they would even see it, because
it is hidden behind visual metaphors.
*I* don't want to write Java UIs (some are doing it,
for example with CL-HTTP as a server component).
But for applications based on CL-HTTP I'd surely
use JavaScript for some basic interaction components
(like PopUp menus), driving this stuff via W3P or
CLIM.
I'm also thinking about distributed applications -
those would exchange Lisp format data and the
applications would be written in Lisp. Think
for example about an approach using "Agents"
talking to each other exchanging primitive
data (you could use XML, or better something like Lisp
expressions if you don't need to talk to foreign
code) or something like KQML. I can easily
imagine that this might be an interesting
approach in a networked environment (like in
our company) once you have developed
the basic design of the infrastructure.
In article <·······················@194.163.195.67>,
······@lavielle.com says...
> Example: BBN is moving CLIM GUIs to Java.
ISTR suggesting using Java with Lisp a few years ago, and getting
severely flamed for it. ;)
--
will write code that writes code that writes code for food
> Rainer Joswig wrote:
> ...
> > But now they might be moving to Java - because of the UI
> > possibilities. How many are already?
>
> people write a lot of standalone Java applications, especially because
> of its GUI? AWT? Swing? Or are you referring to applets? I am
> interested to learn more about it. (For our purposes, we find DOM+HTML
> preferable over Swing.)
We're talking "standalone", which means some classic
pre-distribution
acceptable?
"DOM"...you're talking Javascript, right? gag!
I'd choose Swing over Browser+Javascript for standalone app any
day...
just pick some acceptable IDE such as VisualAge, for some
ActiveX
hooks pick Visual J++
For relatively few expert users, I'd choose ACL Lite for GUI
and logic
plus $100 bucks for PerlCOM to do some network and database
dirty work.
Just distribute the two...might work fine.
Depends on the audience for the app and whether you expect to
sell units,
in that case become one of those Sun partners...but for in-house
type
app developers, if there are any left, there are lots of
alternatives
>
> Off-topic question: if Swing or DHTML is so great, why couldn't we use
> it? E.g., lisp plug-in to Netscape or (de facto standard) Swing
> bindings? JavaScript feels a bit like a simplified prototype
> based CL,
> so it should not be too hard.
You've got to be kidding :) Don't waste your focus on
bleeding-edge proprietary stuff that's just going to be
unsupported in a couple years due to some merger and staff
cuts or whatever stock market phenomenon happens next...
We shouldn't talk about Java or these other proprietary
offerings in the same context as standard languages, makes
them seem like viable platforms...they're not free, just
subsidized and create dependence and outsourcing
"Kucera, Rich" wrote:
>
> > Rainer Joswig wrote:
> > ...
> > > But now they might be moving to Java - because of the UI
> > > possibilities. How many are already?
> >
> > people write a lot of standalone Java applications, especially because
> > of its GUI? AWT? Swing? Or are you referring to applets? I am
> > interested to learn more about it. (For our purposes, we find DOM+HTML
> > preferable over Swing.)
>
> We're talking "standalone", which means some classic
> pre-distribution
> acceptable?
"For our purposes" is a networked application.
> "DOM"...you're talking Javascript, right? gag!
I thought JS is closer to Lisp than Java? Think of lazy typing and
loading.
> I'd choose Swing over Browser+Javascript for standalone app any
> day...
I guess depending on what you want. It takes a bit of more work to
develop and distribute that and you may not realize a lot of benefits
(strong typing, more elaborate GUI handling, compiling, distributing
front-end application and a JVM...).
> just pick some acceptable IDE such as VisualAge, for some
> ActiveX
> hooks pick Visual J++
We don't use Activex.
>
> For relatively few expert users, I'd choose ACL Lite for GUI
> and logic
This is a really interesting option. How do you solve client-side
caching (wrt. heap limit, maybe no FFI, no ODBC)? How do you use
PerlCOM? For client-side storage, you also install a database? We may
need a few megs of storage. I would like to know about your solution.
By the way, we tried to use LW CAPI this way (with ODBC support and no
limitations), but it exposes relatively little of the widget properties
and events (e.g., we could not trigger an event on clicking on an input
field, so we had to write an input field from scratch including cursor
postition handling). Do you find that ACL exposes all or most of what
you possibly need?
Thanks for the information.
Regards
Robert
Been told my Outlook screws everything up.
I'll try to get to the point.
> From: Robert Monfera [··············@fisec.com]
> >
> > For relatively few expert users, I'd choose ACL
> Lite for GUI
> > and logic
>
> This is a really interesting option. How do you solve client-side
> caching (wrt. heap limit, maybe no FFI, no ODBC)? How do you use
> PerlCOM? For client-side storage, you also install a database? We may
> need a few megs of storage. I would like to know about your solution.
First of all, this is a loosey approach not suitable for
delivering anything to a platform with a version on it.
Second of all, it's packaging, therefore boring to the
extreme.
We're not talking about programming anything other than
packaging.
And it's no shrink-wrapped deliverable. We're talking widely
scoped activity that will take up all your time and drive you
out of your mind and yield nothing.
That said, the PerlCOM platform is available for $100 US
from ActiveState, Inc. Once set up, you can do your basic
Perl munging, probably load LWP and DBI, but CORBA is just
much too hard for perl at the moment...real bleeding edge.
For CORBA access, I'd suggest instead going to a Java
if you can stand the boredom. You have two choices: Visual J++
MSJAVA platform with full typelib access, or Sun's ActiveX
bridge (now up to 1.1) for your scripting misery. This
gets you to the Java platform from which you can do
whatever you can do there.
These options are untested in terms of performance.
Each platform would be In or OutProc COM servers
accessible using ACL OLE stuff.
And as I implied, using them will make whatever you write
undeliverable in terms of shrink-wrapping something for
given platform with a version on it.
If you want to have a professional focus, you ought to
be writing meaningful units that do something on existing
platforms, rather than this loosey integration.
Like I said, this CORBA/COM stuff is extremely boring
packaging stuff without a beefy app to make it interesting.
>
> By the way, we tried to use LW CAPI this way (with ODBC support and no
> limitations), but it exposes relatively little of the widget
> properties
> and events (e.g., we could not trigger an event on clicking
> on an input
> field, so we had to write an input field from scratch including cursor
> postition handling). Do you find that ACL exposes all or most of what
> you possibly need?
I really don't know.
>
> Thanks for the information.
> Regards
> Robert
>
* Rainer Joswig wrote:
> In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>> I do. People *hate* C++.
> But why are many big desktop applications written in C++?
Because if you want to interface to Windows or X and keep up with the
GUI-of-the-week you are basically completely stuffed unless you use C
or C++, and doing really large-scale OO stuff in C is not fun (witness
Xt).
> But there are others who have large Lisp applications.
> They survived the rush to C++ and stayed in Lisp.
> But now they might be moving to Java - because of the UI
> possibilities. How many are already?
How many are about to discover, belatedly, that the java people are
basically in the same situation as the Lisp people -- chasing a GUI
specified in C &/or C++ in an alien language, and never really keeping
up. Except, unlike various Lisp GUIs, the java GUI stuff doesn't even
have any particularly interesting and innovative ideas in it (because
it's a lowest-common-denominator interface to existing GUIs which
themselves have precious little innovation), and, unlike Lisp, neither
does the language (because it's kind of a sanitised lowest-common
denominator of C++ and smalltalk).
--tim
In article <···············@lostwithiel.tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> > But there are others who have large Lisp applications.
> > They survived the rush to C++ and stayed in Lisp.
> > But now they might be moving to Java - because of the UI
> > possibilities. How many are already?
>
> How many are about to discover, belatedly, that the java people are
> basically in the same situation as the Lisp people -- chasing a GUI
> specified in C &/or C++ in an alien language, and never really keeping
> up.
That might change given enough interest.
> Except, unlike various Lisp GUIs, the java GUI stuff doesn't even
> have any particularly interesting and innovative ideas in it
I'm not so sure about that. Most Lisp GUIs are old
and only few new ideas have not been approached in the last years
by the Lisp community. MCL's interface is unchanged for years.
LWW's UI is very conventional and Franz's new IDE
is downright ugly (IMHO).
Instead strong graphical tools are available now for Java.
I think for example the component approach of "JavaBeans" is an
interesting concept. See for some visual tools:
http://java.sun.com/beans/tools.html
Doesn't look that bad...
······@lavielle.com (Rainer Joswig) writes:
> In article <···············@lostwithiel.tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>
> > How many are about to discover, belatedly, that the java people are
> > basically in the same situation as the Lisp people -- chasing a GUI
> > specified in C &/or C++ in an alien language, and never really keeping
> > up.
>
> That might change given enough interest.
The same exact remark could of course be made for a Lisp GUI.
>
> > Except, unlike various Lisp GUIs, the java GUI stuff doesn't even
> > have any particularly interesting and innovative ideas in it
>
> I'm not so sure about that. Most Lisp GUIs are old
> and only few new ideas have not been approached in the last years
> by the Lisp community. MCL's interface is unchanged for years.
> LWW's UI is very conventional and Franz's new IDE
> is downright ugly (IMHO).
>
But who is doing a presentation system outside Lisp? I don't care if
it *looks* clunky now, that stuff was innovative in a way which
nothing I have seen in Windows is (sorry, don't have regular access to
Macs), and it lead to interfaces which were a *significant*
improvement over anything else I have ever seen. You should know this
Rainer, you have a Symbolics (:-).
--tim
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > In article <···············@lostwithiel.tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> >
> > > How many are about to discover, belatedly, that the java people are
> > > basically in the same situation as the Lisp people -- chasing a GUI
> > > specified in C &/or C++ in an alien language, and never really keeping
> > > up.
> >
> > That might change given enough interest.
>
> The same exact remark could of course be made for a Lisp GUI.
Java has enough interest.
> But who is doing a presentation system outside Lisp?
Who is using a presentation system inside Lisp?
Aren't we the last bastion?
But otherwise I'm interested in an answer to your question, too.
Who is doing a presentation system outside Lisp?
> I don't care if
> it *looks* clunky now, that stuff was innovative in a way which
> nothing I have seen in Windows is
Sorry, I have to say that I have seen a lot of really
cool user interfaces on both Windows and Mac.
> (sorry, don't have regular access to
> Macs), and it lead to interfaces which were a *significant*
> improvement over anything else I have ever seen. You should know this
> Rainer, you have a Symbolics (:-).
In article <·······················@pbg3.lavielle.com>,
······@lavielle.com (Rainer Joswig) writes:
> In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>> But who is doing a presentation system outside Lisp?
>
> Who is using a presentation system inside Lisp?
Nobody. The vendors don't want to support CLIM but they also don't want
anyone else to.
Mike McDonald
·······@mikemac.com
>> The vendors don't want to support CLIM
Almost. The vendors would probably rather they didn't have to support CLIM,
as it's not a very profitable activity. But they are prepared to support it
because of vociferous (if not very large) customer demand.
>> but they also don't want anyone else to.
Why on earth should that be?
- nick (opinions no longer those of any vendor)
noticed that?
pre 7/11
>- n
7/13
>- nick (whose opinions are not currently those of any employer)
7/15
>- nick (opinions no longer those of any vendor)
Reini Urban wrote in message <·················@judy.x-ray.local>...
>noticed that?
>
>pre 7/11
>>- n
>
>7/13
>>- nick (whose opinions are not currently those of any employer)
>
>7/15
>>- nick (opinions no longer those of any vendor)
>
Nope.
- n
In article <············@spitting-spider.aracnet.com>, ·······@mikemac.com wrote:
> In article <·······················@pbg3.lavielle.com>,
> ······@lavielle.com (Rainer Joswig) writes:
> > In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>
> >> But who is doing a presentation system outside Lisp?
> >
> > Who is using a presentation system inside Lisp?
>
> Nobody. The vendors don't want to support CLIM but they also don't want
> anyone else to.
Atleast CL-HTTP has W3P.
······@lavielle.com (Rainer Joswig) writes:
> > I don't care if
> > it *looks* clunky now, that stuff was innovative in a way which
> > nothing I have seen in Windows is
>
> Sorry, I have to say that I have seen a lot of really
> cool user interfaces on both Windows and Mac.
What do you think is stopping people from implementing similar
interfaces using LISP? Is it the attempt at supporting multiple
platforms?
It seems to be difficult to emulate some 'cool' Windows or Mac
interface feature if you also have to support it on some other
completely different platform. Allegro CL for Windows has some nice
GUI features but I don't believe their class library that the Windows
versions has is portable.
Chris.
In article <··············@ihug.co.nz>, Chris Double <···@ihug.co.nz> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > > I don't care if
> > > it *looks* clunky now, that stuff was innovative in a way which
> > > nothing I have seen in Windows is
> >
> > Sorry, I have to say that I have seen a lot of really
> > cool user interfaces on both Windows and Mac.
>
> What do you think is stopping people from implementing similar
> interfaces using LISP? Is it the attempt at supporting multiple
> platforms?
Depends on the market. MCL applications are not portable,
unless you use a library like that from IISY
(http://www.iisy.de/e/contents/mcl-acl-con.html)
or even CLIM.
But MCL has been used for a couple of cool UIs.
I haven't used or seen (other than the screen shots)
Nichimen's Mirai, but I'd expect that they have a very
cool UI, too. I think it is implemented with Allegro CL.
> interface feature if you also have to support it on some other
> completely different platform. Allegro CL for Windows has some nice
> GUI features but I don't believe their class library that the Windows
> versions has is portable.
Actually, *I* find Franz's new UI ultra ugly. ;-)
But they think, that Windows is the dominant UI and
with libraries you can get the same UI on
X, too. So Franz's effort for porting would
be greatly reduced.
Chris Double <···@ihug.co.nz> writes:
> > Sorry, I have to say that I have seen a lot of really
> > cool user interfaces on both Windows and Mac.
>
> What do you think is stopping people from implementing similar
> interfaces using LISP? Is it the attempt at supporting multiple
> platforms?
Sheer numbers. The knowledge that outside of Lisp, the rate of
creation of new technology (the "million monkeys with a million
typewriters" syndrome) is so high that some good stuff is coming
in spite of the less powerful technology making it.
What CL needs to fix this, more than anything, is a technology
bridge so that anything created in the other world is automatically
annexed by Lisp. Vendors really MUST sell all of their bridge
technology as part of their base system and keep the cost low.
If you charge for CORBA, people have a reason not to use it.
If you charge for SQL, people have a reason not to use it.
If you make a Java RMI interface, and charge for it, people
will have reason not to use it. These things must be added to Lisp
as part of the cost of being in the game and they must not be charged
for beyond the cost of a base language. If Lisp is to make money, it
should make it on volume and on added value (like the runtime compiler,
macros, meta object protocol, etc). But every time you make a reason
not to talk to the outside world you are creating a daunting obstacle
to individual success for each customer and, by induction, to the success
of the industry.
The Lisp industry has it in its hands right now to make that better
by simple changes in pricing. That is commercially risky, but if it
were my company, I would take the risk. I think the risk of not taking
the risk is higher: soon CORBA and SQL pricing will drop and Lisp will
no longer be able to command a premium for these things anyway, and
what will it be left with? Right now vendors have worked hard to make
these packages and this is the time to deploy them strategically in order
to gain market share.
To fail to aggressively go after new market with competitive pricing and
accessibility at this one time when we have the things that are needed
is to miss a window that I'm not sure will come again.
And every time you don't make a bridge, you make Lisp compete with those
other languages, instead of leverage them. Lisp practically invented
the concept of strategic leverage of one program over another. It's
foolhardy for it to turn its back on that now.
The new Harlequin should bundle the SQL and CORBA support into the base
package and charge the same old base price ($800) for the whole thing.
What have they got to lose? They're on shakey ground already. No one is
going to blame a pricing change on the death of the company if they're
wrong. They may lose anyway. On the other hand, if they don't do these
things, I predict they'll be in trouble anyway because I don't see a
plan other than that to grow the market.
CORBA is a nice idea but a pain to work with. Lisp can make that better
because macro technology is really what's needed to make CORBA livable.
Missing this opportunity will be sad. I've been saying this for a while
now. The window may be closing, and it may be starting to be too late.
Not sure ...
> It seems to be difficult to emulate some 'cool' Windows or Mac
> interface feature if you also have to support it on some other
> completely different platform. Allegro CL for Windows has some nice
> GUI features but I don't believe their class library that the Windows
> versions has is portable.
Vendors need as many ways as possible to call into these things so that
they don't have to program the things, they can just access them. Then,
when that is in place, they can add abstraction that keeps you from
having to program them and allows you to just slap a few classes together
in multiple-inheritance fashion, and that will be cool added value you can
charge more money for. But first they have to get ahead of the curve
on raw access to technology. The problem may be tough but will only get
worse. The time to strike is now.
I think I've said this all before. Sorry to repeat it all but I feel as
if it's periodically necessary. All just my opinion, of course. I might
be wrong. But I'd rather be wrong for having taken a stand on something
I believe than wrong for not speaking out.
Kent M Pitman wrote:
...
> What CL needs to fix this, more than anything, is a technology
> bridge so that anything created in the other world is automatically
> annexed by Lisp.
Key point.
> The new Harlequin should bundle the SQL and CORBA support into the base
> package and charge the same old base price ($800) for the whole thing.
And do something on the GUI front. Although the GUI is reasonable in
many respects, it's clear that it's tough to keep up with competition
from other languages. There could be two ways:
1. Open to libraries like Swing such a way that they are straightforward
to use.
2. Open source code for GUI and perhaps other commodity stuff so that
users aren't locked in.
What I never understood: why did not some of the Lisp vendors come up
with a JIT compiler and Lisp compiled to bytecode. It should have been
straightforward (GC, the already existing native compilation, dynamic
optimized compiling, availability of libraries like Swing, RMI, Corba
etc.), and for some type of applications the runtime speed would have
been acceptable. Maybe Lisp related products could have been delivered
in quantities without Java people knowing, and then you can charge for
MOP, macros, ...
Maybe this is still not late, unless "limelight" compiler technology
like HotSpot superseded those applied in CL environments. Can anybody
tell?
The possible benefits look enormous compared to the effort. I may
underestimate the difficulties of implementation and the risk of not
being successful with such a product, so I am interested in more
experienced people's opinion who have considered it.
To avoid flames, the point is not to jump on the Java bandwagon but to
leverage resources, markets and mindshare.
Regards,
Robert
Robert Monfera <·······@fisec.com> writes:
> What I never understood: why did not some of the Lisp vendors come up
> with a JIT compiler and Lisp compiled to bytecode.
What problem would a Lisp portable bytecode system solve?
In article <···············@world.std.com>,
Christopher C Stacy <······@world.std.com> wrote:
> Robert Monfera <·······@fisec.com> writes:
> > What I never understood: why did not some of the Lisp vendors come
up
> > with a JIT compiler and Lisp compiled to bytecode.
>
> What problem would a Lisp portable bytecode system solve?
A friend of mine competed head to head with Lucid with a
compiler that produced bytecodes, interpreted&compiled
said bytecodes on first execution and often saved the
compilation result for later execution.
On almost every "micro" benchmark, his system was significantly
slower than Lucid. On large systems, he'd often win big. (The
worst case, which wasn't rare, was when his system would run to
completion and Lucid's simply wouldn't because it ran out of
space. More often Lucid would be so far behind page-faulting and
GC'ing that the customer would pull the plug.)
Size can affect speed, both run-time, or porting.
-andy
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Kent M Pitman <······@world.std.com> writes:
> What CL needs to fix this, more than anything, is a technology
> bridge so that anything created in the other world is automatically
> annexed by Lisp. Vendors really MUST sell all of their bridge
> technology as part of their base system and keep the cost low.
> If you charge for CORBA, people have a reason not to use it.
> If you charge for SQL, people have a reason not to use it.
> If you make a Java RMI interface, and charge for it, people
> will have reason not to use it.
And if you make the base system, and charge for it,
people will have a reason not to use it.
No, nothing.
After this january's flamewar on comp.lang.lisp, I am convinced that
c.l.l is definitely not the place to discuss issues of free software.
And I wish to apologize again for the noise it brought to the newsgroup,
and for the less than optimal behavior that was mine during it.
But in case people lisp people are interested in discussing the issue,
I wish to make sure they are aware of a forum where they can.
I've setup a mailing list where such discussions are perfectly on-topic.
You can browse/search its archive and subscribe to it/unsubscribe from it
at following URL:
http://lists.tunes.org/cgi-bin/wilma/cybernethics
I think followups to this article should go there.
PS: does CL-HTTP run stably on CMUCL? It would be nice to replace
the klugy existing framework of Apache+CGI(Perl) with a free LISP platform!
Hum, as an exception, answers to this question would I think
be welcome as a c.l.l. followup.
PPS: once again, I'd like to point out the possible relevance of my article
Metaprogramming and Free Availability of Sources
http://www.tunes.org/~fare/articles/ll99/index.en.html
Best regards,
[ "Far�" | VN: Уng-V� B�n | Join the TUNES project! http://www.tunes.org/ ]
[ FR: Fran�ois-Ren� Rideau | TUNES is a Useful, Nevertheless Expedient System ]
[ Reflection&Cybernethics | Project for a Free Reflective Computing System ]
Majority, n.:
That quality that distinguishes a crime from a law.
> PS: does CL-HTTP run stably on CMUCL? It would be nice to replace
> the klugy existing framework of Apache+CGI(Perl) with a free
> LISP platform!
CL-HTTP looks like the most relevant thing going right now with CL,
community-ware that's been around for a long time, with some promise
of XML support(though I have no idea how XML is supposed to replace
all my server-side hacks)--external entities and notation declarations
are yet to be implemented.
If CL-HTTP were multithreaded on CMUCL it might be easier to justify
moving to that platform. As it stands, it's one-request-at-a-time,
though it seems stable on my little Sparc Ultra 5.
Tried running it on LWW Lite and of course ran out of heap. I heard
someone got it up on ACL Lite after fixing a couple errors. It'd be
nice to have a repost of what those errors were and the fixes.
But Apache's pre-forking model is so ugly (each child with it's own
address space)...Apache may be multi-threaded in the future, but
there are too many issues related to using the OS-specific
multithreading
that emulating threads (green threads) may actually be technically
cleaner (Netscape's servers optionally emulate threads and they suggest
that their model is better than an OS specific model).
Apache would be burdened with getting the multi-threading working for
every OS, NT appearing to be the easiest to accomplish (it's working
now).
This means faster response and common address space for session
management.
You could move to mod_perl, but then there's some gotchas, like
having
to reboot the server with every change(it needs to re-compile the parse
tree)
...bleeding edge stuff also, one platform, app divided and embedded in
little snippets here and there
"Kucera, Rich" <·······@hhmi.org> writes:
> > PS: does CL-HTTP run stably on CMUCL? It would be nice to replace
> > the klugy existing framework of Apache+CGI(Perl) with a free
> > LISP platform!
>
> CL-HTTP looks like the most relevant thing going right now with CL,
> community-ware that's been around for a long time [...]
CL-HTTP is definitely cool. Mallery seems to be a very skilled Lisp
programmer (could of fooled me anyways) and the sources are very
instructional of how to use CLOS and of a lot of Lisp's features in a
real-world application. In fact, it's the only large, modern
application out there written in Lisp that you can easily get the
source code for. If not for it and the Lisp Machine sources, I'd be
completely without guidance and on my own as to how to write non-toys
in Lisp.
That said, it unfortunately is not without its problems.
1. Its primary development is done on Lisp Machines (virtual Lisp
Machines, actually) which have very different performance tuning
requirements compared to Lisps on regular hardware. In particular,
an application spends a good-bit smaller percentage of its total
runtime doing GC, because as far as I know LispMs have special
hardware for GC. The feeling is very real. Also, CLOS is "free" on a
Lisp Machine. A while back I posted something about how the
excessively CLOS-using HTTP:COPY-FILE is 4 times slower than a
simple, portable COPY-FILE routine that Steve Haflich posted and how
this is true of a lot of the CL-HTTP code in general. The CLOS code
is every bit as fast as the non-CLOS code on a Lisp Machine,
however. So whatever performance tuning Mallery has been doing on
the LispMs, a lot of it is likely not helping at all - possibly even
hurting - performance on non-Lisp hardware.
2. The license has a few really ugly clauses, particularely one
about how all rights are reserved on any works using CL-HTTP code,
making it far more restrictive than the GPL. I often wonder if
Mallery is waiting for some brilliant Lisper to pull a Paul Graham
stunt and make a cool 50 Million on some dynamic web technology and
then decide to hire a lawyer and exercise some of the rights he's
reserved himself in that license.... ;-)
The license issue hasn't stopped a lot of people from doing neat
commercial stuff with CL-HTTP, but there is the potential there to get
burned.
Christopher
In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> real-world application. In fact, it's the only large, modern
> application out there written in Lisp that you can easily get the
> source code for.
Wrong. There are others.
> That said, it unfortunately is not without its problems.
>
> 1. Its primary development is done on Lisp Machines (virtual Lisp
> Machines, actually) which have very different performance tuning
> requirements compared to Lisps on regular hardware. In particular,
> an application spends a good-bit smaller percentage of its total
> runtime doing GC, because as far as I know LispMs have special
> hardware for GC. The feeling is very real. Also, CLOS is "free" on a
> Lisp Machine. A while back I posted something about how the
> excessively CLOS-using HTTP:COPY-FILE is 4 times slower than a
> simple, portable COPY-FILE routine that Steve Haflich posted and how
> this is true of a lot of the CL-HTTP code in general. The CLOS code
> is every bit as fast as the non-CLOS code on a Lisp Machine,
This has something to do with the fact that the OS
is written in Lisp - which makes it faster for certain
operations than a Lisp that is running on a conventional
OS - where the Lisp routines are *layered* on, say, C
routines.
> however. So whatever performance tuning Mallery has been doing on
> the LispMs, a lot of it is likely not helping at all - possibly even
> hurting - performance on non-Lisp hardware.
The primary development environments for CL-HTTP are the MacIvory,
the VLM and a lot of stuff is done with Macintosh Common Lisp.
Real hackers have a Macintosh Powerbook G3 with MCL. ;-)
Users you can find on ACL and LispWorks, too.
Performance is best where real applications have been deployed.
Recently (you should see it now in the lastest devo
version: CL-HTTP 67.138) a lot
of performance tuning has been done for MCL (which
by they way has an Ephemeral Garbage Collector).
There was somebody paying for it, AFAIK.
Franz now is been reimplementing the basic CL-HTTP stuff for ACL.
Guess why - customers were begging for it. ;-)
Other than that ports need to have special versions
of several facilities to get maximum speed. Copying
a file to an HTTP stream is such a case. For best
performance you need to go as OS near as possible.
> The license issue hasn't stopped a lot of people from doing neat
> commercial stuff with CL-HTTP, but there is the potential there to get
> burned.
Not by John. The reason for its license is that we want control
of the base CL-HTTP, and making it available for Lisp users as widely
as possible. This stuff is very cool and users should pay back
by sending their patches and improvements of the base CL-HTTP.
Comparable systems may cost several thousands of dollars.
CL-HTTP does cost nothing.
Above Cl-HTTP users can implement what they want. We just
don't want it to have the fate of CLIM - where development
has stalled, fixes are not shared and nobody moves forward.
Just to the contrary CL-HTTP has been widely ported (the
same thing runs on Unix/Windows/Mac/Lispm and under
several Lisp systems (ACL, LW, LWW, Genera, CMU CL, MCL). People
have been writing very
cool applications and we got cool stuff like an XML parser.
There is more code running on the Symbolics
CL-HTTP which has not been ported to the basic CL-HTTP, yet.
People already have problems learning what's there.
Even if a company would be started to provide commercial
support for CLIM, it is the declared will to always
give the Lisp community access to CL-HTTP.
In article <·······················@194.163.195.67>, ······@lavielle.com (Rainer Joswig) wrote:
> The primary development environments for CL-HTTP are the MacIvory,
> the VLM and a lot of stuff is done with Macintosh Common Lisp.
> Real hackers have a Macintosh Powerbook G3 with MCL. ;-)
I should add that compiling and loading CL-HTTP on a fast Mac is
done in maybe 90 seconds.
On the Lisp machine you don't compile it that often. The
last full recompile of CL-HTTP on the Lispm has been done
around 8/27/97. The rest are 138 patches in two years.
In article <·······················@194.163.195.67>,
······@lavielle.com (Rainer Joswig) writes:
> In article <·······················@194.163.195.67>, ······@lavielle.com (Rainer Joswig) wrote:
>
>> The primary development environments for CL-HTTP are the MacIvory,
>> the VLM and a lot of stuff is done with Macintosh Common Lisp.
>> Real hackers have a Macintosh Powerbook G3 with MCL. ;-)
>
> I should add that compiling and loading CL-HTTP on a fast Mac is
> done in maybe 90 seconds.
After about three months of trying to figure it out. :-) Getting a handle of
the thing is a big problem.
> On the Lisp machine you don't compile it that often. The
> last full recompile of CL-HTTP on the Lispm has been done
> around 8/27/97. The rest are 138 patches in two years.
It'd be REALLY nice if a new version for Lispms was made sometime. I'm kind
of put off by having to go look for a two year old base and 138 patches.
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> It'd be REALLY nice if a new version for Lispms was made
> sometime. I'm kind of put off by having to go look for a two year
> old base and 138 patches.
I got the 67.138pre version in the form of a fake .reel file from the
CL-HTTP site. When you load it it just loads the base and then the 138
patches. The load bombs at one point saying that :OS/2 is not a
defined system type. Since I don't know how to define new system types
yet, I just hit <Resume> and supplied :MSDOS a few times.
Note that the LispM .reel doesn't include the contrib directory and
other stuff you want, so I also grabbed the sources-67-138pre.tar.Z
and copied those directories over.
The LispM .reel has BIN (36xx), IBIN (Ivory) and VBIN (Open Genera)
binaries. Deleating the BINs and VBINs frees a lot of space.
Christopher
······@lavielle.com (Rainer Joswig) writes:
> In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
>
> > real-world application. In fact, it's the only large, modern
> > application out there written in Lisp that you can easily get the
> > source code for.
>
> Wrong. There are others.
Like what? How large? Boring stuff or cool stuff written by real Lisp
people?
> > however. So whatever performance tuning Mallery has been doing on
> > the LispMs, a lot of it is likely not helping at all - possibly even
> > hurting - performance on non-Lisp hardware.
>
> The primary development environments for CL-HTTP are the MacIvory,
> the VLM and a lot of stuff is done with Macintosh Common Lisp.
> Real hackers have a Macintosh Powerbook G3 with MCL. ;-)
Well, it seems the Lisp Machine port is always the first to get new
stuff. Perhaps because of pub.whitehouse.gov. I'm running 67.138pre on
mine right now.
> Franz now is been reimplementing the basic CL-HTTP stuff for ACL.
> Guess why - customers were begging for it. ;-)
I read the www-cl mailing list.
> > The license issue hasn't stopped a lot of people from doing neat
> > commercial stuff with CL-HTTP, but there is the potential there to get
> > burned.
>
> Not by John. The reason for its license is that we want control
> of the base CL-HTTP, and making it available for Lisp users as widely
> as possible. This stuff is very cool and users should pay back
> by sending their patches and improvements of the base CL-HTTP.
There are many Free Software licenses out there written by real
lawyers that achieve this effect and are distributed in terms of
themselves or such that you can use the license for free. The Mozilla
Public License is a decent example. Something similar to the LGPL
except forcing improvements to be given back and preventing forking of
source (if this is what Mallery wants) would be good for you
guys. That current license is rediculous. If you compile a fasl that
uses a CL-HTTP routine, Mallery "owns" your fasl.
In the past when the issue has been brought up Mallery's attitude
seems to have been something like "CL-HTTP has enough users."
I don't think it does.
Christopher
* Rainer Joswig wrote:
> Not by John. The reason for its license is that we want control
> of the base CL-HTTP, and making it available for Lisp users as widely
> as possible. This stuff is very cool and users should pay back
> by sending their patches and improvements of the base CL-HTTP.
> Comparable systems may cost several thousands of dollars.
> CL-HTTP does cost nothing.
> Above Cl-HTTP users can implement what they want. We just
> don't want it to have the fate of CLIM - where development
> has stalled, fixes are not shared and nobody moves forward.
Bogus argument, sorry. If that's what you want, GPL it. the GPL has
exactly this nature and has been designed so to have. But it's
reasonably well tested and it doesn't have these awful vague clauses
in it which could mean, basically, anything and look like they were
written by someone with basically no understanding of how to write a
license.
--tim
Rainer Joswig wrote:
> In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
>
> > real-world application. In fact, it's the only large, modern
> > application out there written in Lisp that you can easily get the
> > source code for.
>
> Wrong. There are others.
It might be more helpful to name some. ;)
dave
On Thu, 15 Jul 1999 23:42:33 +0200, ······@lavielle.com (Rainer Joswig)
wrote:
> In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
>
> > real-world application. In fact, it's the only large, modern
> > application out there written in Lisp that you can easily get the
> > source code for.
>
> Wrong. There are others.
Can you please provide some examples? As a beginner, I'm very interested.
Paolo
--
Paolo Amoroso <·······@mclink.it>
In article <················@news.mclink.it>, ·······@mclink.it (Paolo Amoroso) wrote:
> On Thu, 15 Jul 1999 23:42:33 +0200, ······@lavielle.com (Rainer Joswig)
> wrote:
>
> > In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
> >
> > > real-world application. In fact, it's the only large, modern
> > > application out there written in Lisp that you can easily get the
> > > source code for.
> >
> > Wrong. There are others.
>
> Can you please provide some examples? As a beginner, I'm very interested.
Some stuff that is worth looking at and learning from
(disclaimer: not necessarily a complete list nor necessarily "applications"
nor necessarily modern, biased):
- SK8 <ftp://ftp.apple.com/research/sk8/>, you get
a cool Multimedia environment for MCL. Has it's own
compiled prototype-oriented scripting language, a cool IDE, interfaces
to Mac stuff, ...
- LOOM, a knowledge representation system
- CMUCL, the compiler
- PCL, CLOS in CLOS
- PAIL, AI stuff
- Babylon, knowledge representation system
- PAIP sources, Peter Norvig has some nice larger examples
- Common Music, compose music in Lisp
- Common Lisp Music, sound synthesis, compiles to various architectures, UI
- oodles-of-utils, MCL code for stuff like controlling video discs and
video digitizers
- Cartiers Contribs, Cartier had a style of his own
- "Building Problem Solvers" sources, you even can get a book of the source
- QSIM, simulation stuff
- Weyl, math in CLOS
- GBB, blackboards - it might be interesting to know about this paradigm
- ABCL, distributed/reflective/... objects
- MCS, Meta Class System
- Screamer, nondeterministic programming
- tons of other code, MCL and Genera come with so much source
code that you should be busy for the rest of the year. The MCL CDROM
has a large collection of useful stuff. I guess I must have on
my Powerbook a million lines of Lisp code.
Exercise: locate the code.
······@lavielle.com (Rainer Joswig) wrote:
>In article <················@news.mclink.it>, ·······@mclink.it (Paolo Amoroso) wrote:
>
>> On Thu, 15 Jul 1999 23:42:33 +0200, ······@lavielle.com (Rainer Joswig)
>> wrote:
>>
>> > In article <··············@2xtreme.net>, ······@2xtreme.net (Christopher R. Barry) wrote:
>> >
>> > > real-world application. In fact, it's the only large, modern
>> > > application out there written in Lisp that you can easily get the
>> > > source code for.
>> >
>> > Wrong. There are others.
>>
>> Can you please provide some examples? As a beginner, I'm very interested.
>
>Some stuff that is worth looking at and learning from
>(disclaimer: not necessarily a complete list nor necessarily "applications"
>nor necessarily modern, biased):
>
>- SK8 <ftp://ftp.apple.com/research/sk8/>, you get
> a cool Multimedia environment for MCL. Has it's own
> compiled prototype-oriented scripting language, a cool IDE, interfaces
> to Mac stuff, ...
>- LOOM, a knowledge representation system
>- CMUCL, the compiler
>- PCL, CLOS in CLOS
>- PAIL, AI stuff
>- Babylon, knowledge representation system
>- PAIP sources, Peter Norvig has some nice larger examples
>- Common Music, compose music in Lisp
>- Common Lisp Music, sound synthesis, compiles to various architectures, UI
>- oodles-of-utils, MCL code for stuff like controlling video discs and
> video digitizers
>- Cartiers Contribs, Cartier had a style of his own
>- "Building Problem Solvers" sources, you even can get a book of the source
>- QSIM, simulation stuff
>- Weyl, math in CLOS
>- GBB, blackboards - it might be interesting to know about this paradigm
>- ABCL, distributed/reflective/... objects
>- MCS, Meta Class System
>- Screamer, nondeterministic programming
>- tons of other code, MCL and Genera come with so much source
> code that you should be busy for the rest of the year. The MCL CDROM
> has a large collection of useful stuff. I guess I must have on
> my Powerbook a million lines of Lisp code.
>
>Exercise: locate the code.
What a pity there aren't more useful bits of code out there for "enterprise
application" code. Things like:
- SSL implementations
- MD5, SHA, and other things (which aren't encumbered by the CL-HTTP license,
but which are, perhaps, usable despite it, I don't know).
- POP, SMTP, MAPI, and other nicely packaged bits of code (sure, Lispm's have
it, but there's nothing I can run on my stock hardward lisp).
- HTTP implementations
- COM/DCOM/CORBA solutions (all proprietary where they exist now)
- OODB, ODBC solutions (also proprietary.. particularly OODB mappings)
- EDI and CIM support
- SNMP
- XML, HTML, and SGML support (CL-HTTP aside, see below).
- Win32 APIs galore
- Java support (wouldn't you like to run javabeans from lisp?)
Rainer, your pointers are welcome, and you're always helpful.
But even if people locate the code you mention, chances are that it won't work
quite right on their system unless they have the same lisp as that on which it
was built.
CL-HTTP is an example of that. And let's not blame Franz just because they
didn't want to join the effort for free, I can't fault them for wanting to pay
the rent, that's my goal too.
I really would have liked to use CL-HTTP in my app. But I didn't for two
reasons:
- Mallery's license is not acceptable to me for a commercial endeavor.
(for reasons I've cited before in this group and won't rehash now)
- CL-HTTP doesn't run sufficiently well on my lisp, namely Franz ACL.
When I asked John about commercial licenses and/or support for CL-HTTP, he
alluded to an effort to "productize" CL-HTTP, but I haven't seen any sign of
that happening.
CL-HTTP would help the lisp community more with a more pragmatic and
commercially viable license. If CL-HTTP *did* have a better license, then
chances are I'd be using it, and CL-HTTP would benefit from the efforts of a
paid staff of experienced lispers. As it is, we all have to do without, and I'm
reinventing a wheel.
Lisp would be more viable as a commercial product platform if there were more
lisp library pickings than a bunch of crufty old (and usually unsupported) AI
programs. Even simple things like REGEXP and DEFSYSTEM programs don't often
work, or haven't been kept up to date for the current rev of ANSI common lisp.
People who do perform the updates and try to submit the patches back to the
author or source repository will often find there is no place to submit the
changes.
I've bet my company's future on Lisp, but part of taking that pill was knowing
I'd have to reinvent lots of wheels. (Wheels the Java community has for free,
and which are actively supported). For a community which supposedly frowns on
wheel reinvention, we're not doing so hot in 1999.
Don't get me wrong. There is an ROI to be had from LISP. I'm counting on it.
The leather seats in this lisp automobile are very comfortable, and the car
drives well. But finding replacement parts is a bitch, it doesn't fit in most
parking spaces, and the mechanics charge me double the usual rate if I ask for
any custom work.
D. Tenny
············@mediaone.net - no spam please
············@mediaone.net writes:
> What a pity there aren't more useful bits of code out there for "enterprise
> application" code. Things like:
>
> - SSL implementations
I haven't looked into it, but I'd imagine that doing an FFI binding
for one of the freely available SSL libraries and wrapping some gray
stream stuff around that (ACL, LWW and I think MCL support gray
streams, CMU CL has some support that has to be loaded) shouldn't be
that difficult. Good error handling might be more problematic...
> - MD5, SHA, and other things (which aren't encumbered by the CL-HTTP license,
> but which are, perhaps, usable despite it, I don't know).
Erik Naggum might have implementations of MD5 (and maybe others), so
if you wanted access to them, I'd get in touch with him and negotiate
a deal. Most certainly cheaper than reinventing the wheel.
Insisting on these things being freely available probably won't get
you very far, I'm afraid...
> - POP, SMTP, MAPI, and other nicely packaged bits of code (sure, Lispm's have
> it, but there's nothing I can run on my stock hardward lisp).
> - HTTP implementations
There might be some development in that area. Nothing as complex and
industrial-strenght as CL-HTTP. But with a clear licence...
> - COM/DCOM/CORBA solutions (all proprietary where they exist now)
ILU is free (they clarified their licence some time ago), and should
cooperate with other ORBs via IIOP. Stuff you write using ILU won't
be portable to Franz's or Harlequin's CORBA stuff, since apparently
they use another IDL to CL mapping, but otherwise... The only thing
I'm missing would be CMU CL support for ILU, but this seems
non-trivial, and I don't have the time right now.
> - OODB, ODBC solutions (also proprietary.. particularly OODB mappings)
Hmm? SQL-ODBC from Paul Meurer is not proprietary, and it implements
(nearly?) the same SQL interface as Harlequin's Common SQL. Runs on
Franz ACL, Harlequin LWW and MCL. Someone did start CMU CL support,
but hasn't finished it, IIRC. But with a little work, that should be
doable (note though that ODBC on Unix plattforms is not very stable or
easy to configure, IMHO).
If you've got CMU CL and want SQL access on Unix without ODBC, there's
also (little plug) MaiSQL, which has support for MySQL and PostgreSQL
(but adding support for Adabas or Oracle shouldn't be that difficult.
Maybe I'll get around to it). Not nearly as nice as SQL-ODBC, and not
really industrial-strength, but non-proprietary nonetheless...
As for OODBs: I don't think that there exist any non-proprietary
bindings to the standard, proprietary OODBs. If you really need
something non-proprietary, PLOB might fit the bill (though I have some
doubts about the licensing, especially for the POSTORE stuff), if it
meets your needs.
But why must this stuff be non-proprietary? For most of these things
I'd be happy with a proprietary solution, especially if I had "bet my
company on Lisp"...
> - EDI and CIM support
> - SNMP
> - XML, HTML, and SGML support (CL-HTTP aside, see below).
> - Win32 APIs galore
> - Java support (wouldn't you like to run javabeans from lisp?)
[...]
> paid staff of experienced lispers. As it is, we all have to do
> without, and I'm reinventing a wheel.
Well, since you complain of the lack of freely available stuff, I'm
sure you'll make the wheels you reinvent freely available, won't you?
That's what I'm trying to do (MaiSQL is the start of this). There are
also other's doing this, so given a little time, there will be a lot
less wheels to reinvent... For licensing I suggest an X-style
license...
> programs. Even simple things like REGEXP and DEFSYSTEM programs don't often
MK's DEFSYSTEM is being kept reasonably up-to-date as part of the CMU
CL effort (that is, the version in the CMU CL archives is the most
current version to my knowledge). I've also had little problems
getting it to work in ACL 5 and LWW (CLISP was a bit more problematic,
IIRC). It's sadly got a slight licensing problem, as well, though.
If you're not in need of staying portable for this stuff, all vendors
have their own defsystems, though, which should be current. Then
there are also the other free implementations out there.
I think we have enough DEFSYSTEMs out there.
RegExp stuff might be a little more problematic. OTOH IIRC Franz has
a very nice RegExp package in their ACL5 offerings, don't they?
> People who do perform the updates and try to submit the patches back to the
> author or source repository will often find there is no place to submit the
> changes.
That's more of a problem. Since the CMU AI repository has effectively
gone (no updates anymore), the community might be lacking a central
repository for this kind of stuff. Maybe we should try to get
something set up for this. Maybe some companies that have bet their
future on Lisp might want to contribute net resources or money towards
this goal?
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
* Pierre R. Mai
|
| ILU is free (they clarified their licence some time ago), and should
| cooperate with other ORBs via IIOP. Stuff you write using ILU won't
| be portable to Franz's or Harlequin's CORBA stuff, since apparently
| they use another IDL to CL mapping, but otherwise...
The OMG is currently standardizing an IDL to CL mapping, under Franz's
lead. I assume Harlequin, ILU and others will follow this mapping once
it is finalized.
--Lars M.
Lars Marius Garshol <······@ifi.uio.no> wrote in message
···················@ifi.uio.no...
>
> * Pierre R. Mai
> |
> | ILU is free (they clarified their licence some time ago), and should
> | cooperate with other ORBs via IIOP. Stuff you write using ILU won't
> | be portable to Franz's or Harlequin's CORBA stuff, since apparently
> | they use another IDL to CL mapping, but otherwise...
>
> The OMG is currently standardizing an IDL to CL mapping, under Franz's
> lead. I assume Harlequin, ILU and others will follow this mapping once
> it is finalized.
Harlequin already use the same IDL->Lisp mapping as Franz (modulo changes
during the standarisation process).
.
"Clive Tong" <·····@harlequin.com> writes:
> Lars Marius Garshol <······@ifi.uio.no> wrote in message
> ···················@ifi.uio.no...
> >
> > * Pierre R. Mai
> > |
> > | ILU is free (they clarified their licence some time ago), and should
> > | cooperate with other ORBs via IIOP. Stuff you write using ILU won't
> > | be portable to Franz's or Harlequin's CORBA stuff, since apparently
> > | they use another IDL to CL mapping, but otherwise...
> >
> > The OMG is currently standardizing an IDL to CL mapping, under Franz's
> > lead. I assume Harlequin, ILU and others will follow this mapping once
> > it is finalized.
>
> Harlequin already use the same IDL->Lisp mapping as Franz (modulo changes
> during the standarisation process).
But ILU has been using another mapping for quite some time (a mapping
I think I like better, but that's a very superficial statement only).
I assume that ILU might (grudgingly) follow Franz's "lead", once the
OMG standardizes it, though...
(Beware that events might have overtaken me here, I didn't look
closely at ILU and Franz's developments in recent times)...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
············@mediaone.net writes:
< - Win32 APIs galore
This is easy to do using the available tools. Why have a win32 api
when you have a foreign function interface? These are some examples I
have come up with using Harqulens LispWorks for windows. These are
examples that where not in the manual, so they may prove useful.
(defpackage win
(:use COMMON-LISP FOREIGN-LANGUAGE-INTERFACE)
(:export #:get-logical-drives
#:get-drive-information
#:get-windows-directory
#:get-default-drive))
(in-package :win)
(defvar *external-string-format*
(if (string= (software-type) "Windows NT")
:unicode
:ascii))
(defconstant +max-path+ 260)
(defconstant +drive-letters+ "ABCDEFGHIJKLMNOPQRSTUVWXYZ")
(defconstant +drive-types+
#(:unknown :none :removable :fixed :remote :cdrom :ramdisk))
(deftype drive-type () `(member ,@ (coerce +drive-types+ 'list)))
(fli:register-module "kernel32")
(fli:define-c-typedef LPCTSTR :pointer)
(fli:define-foreign-function (%get-logical-drives "GetLogicalDrives")
()
:result-type :long)
(fli:define-foreign-function (%get-drive-type "GetDriveTypeA")
((lpRootPathName LPCTSTR))
:result-type (:unsigned :int))
(fli:define-foreign-function (%get-windows-directory "GetWindowsDirectoryA")
((lpBuffer LPCTSTR) (USize (:unsigned :int)))
:result-type (:unsigned :int))
;;; Lisp functions
(defun make-drive-name (char)
(concatenate 'string (list char #\: #\\)))
(defun get-logical-drives ()
;; values: drive-names, drive-count
(let ((drive-mask (%get-logical-drives))
(drive-count 0))
;; Count the number of drives
(do ((idx 0 (1+ idx))
(bit 1 (ash bit 1)))
((> idx 24))
(when (plusp (logand drive-mask bit))
(incf drive-count)))
;; Build the drive string
(let ((drive-names (make-vector drive-count))
(letter-idx 0))
(do ((cnt 0 (1+ cnt))
(bit 1 (ash bit 1)))
((> cnt 24)
(values drive-names drive-count))
(when (plusp (logand drive-mask bit))
(setf (svref drive-names letter-idx)
(make-drive-name (schar +drive-letters+ cnt)))
(incf letter-idx))))))
(defun get-drive-information (drive)
(fli:with-foreign-string
(ptr count bytes :external-format *external-string-format*)
drive
(declare (ignore count bytes))
(the drive-type (svref +drive-types+ (%get-drive-type ptr)))))
(defun get-windows-directory ()
(let* ((buffer (fli:allocate-foreign-object
:type (list :c-array :char +max-path+)))
(size (%get-windows-directory buffer +max-path+)))
(prog1
(fli:convert-from-foreign-string buffer :length size)
(fli:free-foreign-object buffer))))
(defun get-default-drive ()
(make-drive-name (schar (get-windows-directory) 0)))
#|
(get-logical-drives)
(get-drive-information "C:\\")
(get-windows-directory)
(get-default-drive)
|#
Had much fun playing with this, the `fli' interface very straight
forward and easy to use. Also lispworks has a parser generator and ACL
has a regexp system.
The one problem I have is with these `symbolic constants'. I really
would like to be able to query the operating system about these
values.
LispWorks for Windows has suitable types already defined, but
undocumented. Sorry about that omission. In particular the WIN32:TSTR
type (and friends) choose between ANSI and UNICODE encodings at
runtime. For Win32 functions that deal with strings, the 'A' APIs want
ANSI data, and the 'W' APIs expect Unicode data. There's an argument
to FLI:DEFINE-FOREIGN-FUNCTION which allows you to call the former on
Windows 9x and the latter on NT.
I took the liberty of rewriting (below) your example using the
WIN32:TSTR and WIN32:LPCTSTR types and corresponding foreign function
definitions. Not that there's anything wrong with your original
example: my version just changes it so that the 'W' APIs are called on
NT, and the encoding is handled by the system-defined types.
There's an article "Win32 API and strings" in the Knowledgebase on our
support web pages.
;; start modified example...
(defpackage win
(:use COMMON-LISP FOREIGN-LANGUAGE-INTERFACE)
(:export #:get-logical-drives
#:get-drive-information
#:get-windows-directory
#:get-default-drive))
(in-package :win)
#|
;; Use the code page encoding, rather than ASCII, but this is implicit
;; when using WIN32:TSTR, WIN32:LPTSTR, or WIN32:LPCTSTR to choose
;; between the encodings
(defvar *external-string-format*
(if (string= (software-type) "Windows NT")
:unicode
win32:*multibyte-code-page-ef*))
|#
(defconstant +max-path+ 260)
(defconstant +drive-letters+ "ABCDEFGHIJKLMNOPQRSTUVWXYZ")
(defconstant +drive-types+
#(:unknown :none :removable :fixed :remote :cdrom :ramdisk))
(deftype drive-type () `(member ,@ (coerce +drive-types+ 'list)))
(fli:register-module "kernel32")
;; No need. Use WIN32:LPCTSTR instead
;; (fli:define-c-typedef LPCTSTR :pointer)
(fli:define-foreign-function (%get-logical-drives "GetLogicalDrives")
()
:result-type :long)
;; Add :DBCS argument, to use 'A' APIs on Windows9x and 'W' APIs on
;; WindowsNT And use system-defined WIN32:LPCTSTR type which passes
;; string data in the correct encoding
(fli:define-foreign-function (%get-drive-type "GetDriveType" :dbcs)
((lpRootPathName WIN32:LPCTSTR))
:result-type (:unsigned :int))
(fli:define-foreign-function (%get-windows-directory "GetWindowsDirectory" :dbcs)
((lpBuffer :pointer) (USize (:unsigned :int)))
:result-type (:unsigned :int))
;;; Lisp functions
(defun make-drive-name (char)
(concatenate 'string (list char #\: #\\)))
(defun get-logical-drives ()
;; values: drive-names, drive-count
(let ((drive-mask (%get-logical-drives))
(drive-count 0))
;; Count the number of drives
(do ((idx 0 (1+ idx))
(bit 1 (ash bit 1)))
((> idx 24))
(when (plusp (logand drive-mask bit))
(incf drive-count)))
;; Build the drive string
(let ((drive-names (make-array drive-count))
(letter-idx 0))
(do ((cnt 0 (1+ cnt))
(bit 1 (ash bit 1)))
((> cnt 24)
(values drive-names drive-count))
(when (plusp (logand drive-mask bit))
(setf (svref drive-names letter-idx)
(make-drive-name (schar +drive-letters+ cnt)))
(incf letter-idx))))))
(defun get-drive-information (drive)
(the drive-type (svref +drive-types+ (%get-drive-type drive))))
(defun get-windows-directory ()
(fli:with-dynamic-foreign-objects ()
(let* ((buffer (fli:allocate-dynamic-foreign-object
:type `(WIN32:TSTR :length ,+max-path+)))
(size (%get-windows-directory buffer +max-path+)))
(declare (ignore size))
(fli:dereference buffer))))
(defun get-default-drive ()
(make-drive-name (schar (get-windows-directory) 0)))
#|
(get-logical-drives)
(get-drive-information "C:\\")
(get-windows-directory)
(get-default-drive)
|#
;; Had much fun playing with this, the `fli' interface very straight
;; forward and easy to use. Also lispworks has a parser generator and ACL
;; has a regexp system.
;;
;; The one problem I have is with these `symbolic constants'. I really
;; would like to be able to query the operating system about these
;; values.
;; ... end modified example
Steve Gonedes <········@worldnet.att.net> writes:
>
> ············@mediaone.net writes:
>
> < - Win32 APIs galore
>
> This is easy to do using the available tools. Why have a win32 api
> when you have a foreign function interface? These are some examples I
> have come up with using Harqulens LispWorks for windows. These are
> examples that where not in the manual, so they may prove useful.
>
> (defpackage win
> (:use COMMON-LISP FOREIGN-LANGUAGE-INTERFACE)
> (:export #:get-logical-drives
> #:get-drive-information
> #:get-windows-directory
> #:get-default-drive))
>
> (in-package :win)
>
> (defvar *external-string-format*
> (if (string= (software-type) "Windows NT")
> :unicode
> :ascii))
>
> (defconstant +max-path+ 260)
> (defconstant +drive-letters+ "ABCDEFGHIJKLMNOPQRSTUVWXYZ")
> (defconstant +drive-types+
> #(:unknown :none :removable :fixed :remote :cdrom :ramdisk))
>
> (deftype drive-type () `(member ,@ (coerce +drive-types+ 'list)))
>
> (fli:register-module "kernel32")
> (fli:define-c-typedef LPCTSTR :pointer)
>
> (fli:define-foreign-function (%get-logical-drives "GetLogicalDrives")
> ()
> :result-type :long)
>
> (fli:define-foreign-function (%get-drive-type "GetDriveTypeA")
> ((lpRootPathName LPCTSTR))
> :result-type (:unsigned :int))
>
> (fli:define-foreign-function (%get-windows-directory "GetWindowsDirectoryA")
> ((lpBuffer LPCTSTR) (USize (:unsigned :int)))
> :result-type (:unsigned :int))
>
> Next page...
>
> ;;; Lisp functions
>
> (defun make-drive-name (char)
> (concatenate 'string (list char #\: #\\)))
>
> (defun get-logical-drives ()
> ;; values: drive-names, drive-count
> (let ((drive-mask (%get-logical-drives))
> (drive-count 0))
> ;; Count the number of drives
> (do ((idx 0 (1+ idx))
> (bit 1 (ash bit 1)))
> ((> idx 24))
> (when (plusp (logand drive-mask bit))
> (incf drive-count)))
> ;; Build the drive string
> (let ((drive-names (make-vector drive-count))
> (letter-idx 0))
> (do ((cnt 0 (1+ cnt))
> (bit 1 (ash bit 1)))
> ((> cnt 24)
> (values drive-names drive-count))
> (when (plusp (logand drive-mask bit))
> (setf (svref drive-names letter-idx)
> (make-drive-name (schar +drive-letters+ cnt)))
> (incf letter-idx))))))
>
> (defun get-drive-information (drive)
> (fli:with-foreign-string
> (ptr count bytes :external-format *external-string-format*)
> drive
> (declare (ignore count bytes))
> (the drive-type (svref +drive-types+ (%get-drive-type ptr)))))
>
> (defun get-windows-directory ()
> (let* ((buffer (fli:allocate-foreign-object
> :type (list :c-array :char +max-path+)))
> (size (%get-windows-directory buffer +max-path+)))
> (prog1
> (fli:convert-from-foreign-string buffer :length size)
> (fli:free-foreign-object buffer))))
>
> (defun get-default-drive ()
> (make-drive-name (schar (get-windows-directory) 0)))
>
> #|
> (get-logical-drives)
> (get-drive-information "C:\\")
> (get-windows-directory)
> (get-default-drive)
> |#
>
> Had much fun playing with this, the `fli' interface very straight
> forward and easy to use. Also lispworks has a parser generator and ACL
> has a regexp system.
>
> The one problem I have is with these `symbolic constants'. I really
> would like to be able to query the operating system about these
> values.
--
Dave Fox Email: ·····@harlequin.com
Harlequin Ltd, Barrington Hall, Tel: +44 1223 873879
Barrington, Cambridge CB2 5RG, England. Fax: +44 1223 873873
These opinions are not necessarily those of Harlequin.
David Fox <·····@harlequin.co.uk> writes:
< LispWorks for Windows has suitable types already defined, but
< undocumented. Sorry about that omission. In particular the WIN32:TSTR
< type (and friends) choose between ANSI and UNICODE encodings at
< runtime. For Win32 functions that deal with strings, the 'A' APIs want
< ANSI data, and the 'W' APIs expect Unicode data. There's an argument
< to FLI:DEFINE-FOREIGN-FUNCTION which allows you to call the former on
< Windows 9x and the latter on NT.
<
< I took the liberty of rewriting (below) your example using the
< WIN32:TSTR and WIN32:LPCTSTR types and corresponding foreign function
< definitions. Not that there's anything wrong with your original
< example: my version just changes it so that the 'W' APIs are called on
< NT, and the encoding is handled by the system-defined types.
I'm not too knowledgeable about the win32 api; thanks for the info.
In article <········································@exchange1.hhmi.org>, "Kucera, Rich" <·······@hhmi.org> wrote:
> If CL-HTTP were multithreaded on CMUCL it might be easier to justify
> moving to that platform. As it stands, it's one-request-at-a-time,
> though it seems stable on my little Sparc Ultra 5.
>
> Tried running it on LWW Lite and of course ran out of heap. I heard
> someone got it up on ACL Lite after fixing a couple errors. It'd be
> nice to have a repost of what those errors were and the fixes.
ACL 5.0.1 is going to provide better CL-HTTP (eventually! Thanks to Franz
and requests from customers!) support.
A preliminary version of the CL-HTTP code for running
under ACL is available for adventurous hackers.
CL-HTTP is *the* single application of the last years that
forced Lisp vendors to improve their offerings in multiple
dimensions (networking, processes, performance,
ANSI compliance, ...). This is also to the contributions
and the hard work from users all over the world.
"Kucera, Rich" <·······@hhmi.org> writes:
> If CL-HTTP were multithreaded on CMUCL it might be easier to justify
> moving to that platform. As it stands, it's one-request-at-a-time,
> though it seems stable on my little Sparc Ultra 5.
The Good News: CL-HTTP is multi-threaded on CMUCL, wherever CMUCL is
multi-threaded (in the non-OS sense for the moment).
The Bad News (for you): CMUCL currently is only multi-threaded on the
iA32 platform, i.e. under *BSD and Linux on Intel, and it looks like
this might stay so for some time...
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
"Kucera, Rich" <·······@hhmi.org> writes:
> But Apache's pre-forking model is so ugly (each child with it's own
> address space)...Apache may be multi-threaded in the future, but
> there are too many issues related to using the OS-specific
> multithreading
> that emulating threads (green threads) may actually be technically
> cleaner (Netscape's servers optionally emulate threads and they suggest
> that their model is better than an OS specific model).
Unfortunately you typically need native threading to take advantage of
multiprocessors, and you probably need that if you want to be a big
web-server type thing. It doesn't mean it isn't a pain of course: I
get the impression that the various Unix threads interfaces are pretty
buggy.
--tim
On 14 Jul 1999 21:40:02 +0200, Francois-Rene Rideau
<···········@tunes.NO.org.SPAM> wrote:
>PS: does CL-HTTP run stably on CMUCL? It would be nice to replace
>the klugy existing framework of Apache+CGI(Perl) with a free LISP
>platform!
>Hum, as an exception, answers to this question would I think
>be welcome as a c.l.l. followup.
I suspect not...
The last time such a discussion came up, it turned into a bit of a
"flame war" since CL-HTTP apparently has one of those licenses that is
a bit ambiguous, with one (apparently valid) interpretation that would
indicate that it is forbidden to use it in commercial contexts.
Reports suggest that the authors were asked if they could
"disambiguate" this, which they declined to do.
--
HELP! I'm being attacked by a tenured professor!
········@ntlug.org- <http://www.hex.net/~cbbrowne/langlisp.html>
> From: ······@world.std.com (Kent M Pitman)
>
> Chris Double <···@ihug.co.nz> writes:
>
> > > Sorry, I have to say that I have seen a lot of really
> > > cool user interfaces on both Windows and Mac.
> >
> > What do you think is stopping people from implementing similar
> > interfaces using LISP? Is it the attempt at supporting multiple
> > platforms?
>
> Sheer numbers. The knowledge that outside of Lisp, the rate of
> creation of new technology (the "million monkeys with a million
> typewriters" syndrome) is so high that some good stuff is coming
> in spite of the less powerful technology making it.
>
> What CL needs to fix this, more than anything, is a technology
> bridge so that anything created in the other world is automatically
> annexed by Lisp. Vendors really MUST sell all of their bridge
> technology as part of their base system and keep the cost low.
> If you charge for CORBA, people have a reason not to use it.
> If you charge for SQL, people have a reason not to use it.
> If you make a Java RMI interface, and charge for it, people
> will have reason not to use it. These things must be added to Lisp
[...]
> The new Harlequin should bundle the SQL and CORBA support
> into the base
> package and charge the same old base price ($800) for the whole thing.
> What have they got to lose? They're on shakey ground already.
He's right. Lisp is sufficiently different in character
(well, it *has* character) than anything out there that it could
make a lot of money with all the add-on bridges built-in and a big
price reduction.
Incidently, I'd de-emphasize SQL within Lisp, stick with making the
COM/CORBA
bridges very usable because we'll be talking to SQL agents running
SQL logic on the app server or on the database, rather than spreading
SQL around in the old monolithic way of doing things. Once all your
servers(Notes, Oracle, Exchange) are running a bus and have some
programmable agent capability, Lisp is out of the box...no need to
get burdened with developing and maintaining all these different
protocols for different servers(SQL*net, IMAP, MAPI, Notes.DLL,
whatever).
"Kucera, Rich" wrote:
...
>
> Incidently, I'd de-emphasize SQL within Lisp, stick with making the
> COM/CORBA
> bridges very usable because we'll be talking to SQL agents running
> SQL logic on the app server or on the database, rather than spreading
> SQL around in the old monolithic way of doing things.
Do you have positive or negative experiences in CORBA overhead, maybe in
performance-critical environments by any chance? I am interested in it.
Thanks,
Robert
> From: Robert Monfera [··············@fisec.com]
>
> "Kucera, Rich" wrote:
> ...
> >
> > Incidently, I'd de-emphasize SQL within Lisp, stick with making the
> > COM/CORBA
> > bridges very usable because we'll be talking to SQL agents running
> > SQL logic on the app server or on the database, rather
> than spreading
> > SQL around in the old monolithic way of doing things.
>
> Do you have positive or negative experiences in CORBA
> overhead, maybe in
> performance-critical environments by any chance? I am
> interested in it.
>
> Thanks,
> Robert
>
Nothing first hand. Just the positive testimonial from the heavyweights
in comp.object.corba (Michi Henning) about moving huge amounts of data
over the bus. It's harder than heck to get out of 2-tier and still
have
meaningful things to do in the organization if the platforms aren't
there.
You have to justify the time spent
Meaningful units in the near future may run on EJB...
On Wed, 14 Jul 1999 14:09:30 GMT, Kent M Pitman <······@world.std.com> wrote:
>The new Harlequin should bundle the SQL and CORBA support into the base
>package and charge the same old base price ($800) for the whole thing.
>What have they got to lose? They're on shakey ground already. No one is
>going to blame a pricing change on the death of the company if they're
>wrong. They may lose anyway. On the other hand, if they don't do these
>things, I predict they'll be in trouble anyway because I don't see a
>plan other than that to grow the market.
Hear, hear!
>CORBA is a nice idea but a pain to work with. Lisp can make that better
>because macro technology is really what's needed to make CORBA livable.
>Missing this opportunity will be sad. I've been saying this for a while
>now. The window may be closing, and it may be starting to be too late.
>Not sure ...
The other thing that this offers is a Fully Functional alternative to
C++/Java.
C++ and Java vendors have been pursuing CORBA integration pretty
aggressively; there are lots of fairly decent CORBA implementations
for these languages, along with language mappings that are reasonably
natural to the languages.
[Contrast with C, where CORBA mappings are mucho-painful, as you have
to manually carry around lots of environment and structure
information...]
In a Lisp, where macros can be used to simplify the representation of
the CORBA-specific "stuff," it could be far easier to write *and make
robust* CORBA code.
--
"Heuristics (from the French heure, "hour") limit the amount of time
spent executing something. [When using heuristics] it shouldn't take
longer than an hour to do something."
········@hex.net- <http://www.ntlug.org/~cbbrowne/computing.html>
> From: ········@news.hex.net (Christopher Browne)
> In a Lisp, where macros can be used to simplify the representation of
> the CORBA-specific "stuff," it could be far easier to write *and make
> robust* CORBA code.
Let's not get too excited, CORBA is still plumbing not much more
abstract than sockets. Even callback frameworks like EJB or
CORBAComponents
are still plumbing when compared to state-of-the-art SQL environments
with
all their business application models and database development guidance
(designer 2000) and through-to-physical-design code generation. They're
perfectly content to tune everything to b-trees of primitive types.
They're
way out in front with respect to physical tunability to-the-masses as
well.
Still, though a free-for-all, Lisp itself is way more abstract than
SQL or
E-R notation could ever be, so what are we waiting for? D2000 in the
hands
of the most intelligent designer can still produce some of the most
god-awful
2-tier monolithic growths...yum yum
-Maggot
······@lavielle.com (Rainer Joswig) writes:
> > I don't care if
> > it *looks* clunky now, that stuff was innovative in a way which
> > nothing I have seen in Windows is
>
> Sorry, I have to say that I have seen a lot of really
> cool user interfaces on both Windows and Mac.
>
So have I, but are they *useful*? I see lots of very pretty & clever
looking things, but I have seen little or nothing that is actually
more productive than a Unix shell (which isn't saying much). This is
what I'd expect of course, becuase computers & their interfaces are
typically sold on the basis of 10 minutes trial, so pretty & clever
count, but useability is basically irrelevent. I'm very left field,
because I don't care for cool, I care for getting more done so I can
spend less hours in front of the machine & more doing something more
fun...
I'd be genuinely interested to hear of any interfaces (to anything)
that are really interesting in the being-productive sense. Ones with
free demos (Unix or Windows) would be particularly interesting so I
can try them.
--tim
In article <··················@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> So have I, but are they *useful*?
Sorry, but where are you living? ;-) We have 1999.
My experience is with areas like publishing and media
production. Why do you think the Mac is the favorite
tool of artists, designers, publishers, ???
They are used to use highly graphical tools in daily
work. I mean we are talking about production of
serious things like newspapers and magazines.
Given that people are very good at visible perception,
I think it is only logical to support this
input channel. I know that there are hardcore
Unix weenies who love "sh", but I know also
that there are hundreds of thousands of people
who don't care about that a bit and prefer
graphical interfaces.
Have you ever looked closely at applications like:
- Freehand (which I think is really elegant)
- Illustrator
- Quark Xpress
- Indesign
- Cyberstudio
- Director
Compare Freehand to Symbolics' Graphic editor, and
then we are talking again. Freehand is light years
ahead. Really light years.
Sorry, but sometimes I have the impression that Lisp
people are so fascinated by their possibly
superior technology that they forget that
other people aren't **that** stupid, too.
It can't be that two decades of HCI research and
improvements are not recognized and that we
still think presentation based interfaces
of the past are state of the art. **I**'d be
interested to see those techniques combined
with a killer UI. (Hello peter!)
Read for example the old papers from Xerox PARC
about their 3d user interface stuff -
this is highly cool. Much of it has been done
in Lisp - you can still see it in the screen
shots - for example the perspective wall
is show a directory - a Lisp directory.
Nowadays this stuff is market by InXight,
and is no longer in Lisp - but in Java
and C++. See: http://www.inxight.com/.
Look for their Chief Technology Officer
and then search your Lisp library for
publications about "Silica". Sigh.
Sigh.
······@lavielle.com (Rainer Joswig) writes:
> In article <··················@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>
> > So have I, but are they *useful*?
>
> Sorry, but where are you living? ;-) We have 1999.
>
> My experience is with areas like publishing and media
> production. Why do you think the Mac is the favorite
> tool of artists, designers, publishers, ???
>
> They are used to use highly graphical tools in daily
> work. I mean we are talking about production of
> serious things like newspapers and magazines.
> Given that people are very good at visible perception,
> I think it is only logical to support this
> input channel. I know that there are hardcore
> Unix weenies who love "sh", but I know also
> that there are hundreds of thousands of people
> who don't care about that a bit and prefer
> graphical interfaces.
>
> Have you ever looked closely at applications like:
>
> - Freehand (which I think is really elegant)
> - Illustrator
> - Quark Xpress
> - Indesign
> - Cyberstudio
> - Director
I see that you carefully left out some of the most used programs on
MSW platforms :)
Cheers :)
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
In article <··············@copernico.parades.rm.cnr.it>, Marco Antoniotti <·······@copernico.parades.rm.cnr.it> wrote:
> > Have you ever looked closely at applications like:
> >
> > - Freehand (which I think is really elegant)
> > - Illustrator
> > - Quark Xpress
> > - Indesign
> > - Cyberstudio
> > - Director
>
> I see that you carefully left out some of the most used programs on
> MSW platforms :)
Yeah, but most of the above are Mac and Windows.
Btw., you can say what you want, but I see some good
ideas in software like Outlook, Powerpoint and
VisualBasic.
(with-asbestos ()
I even see some CLIM/DW ideas in Outlook. It
made my wonder how a Outlook version in CLIM
would be. This would be a nice showcase
for Lisp technology. But now I'm really dreaming.)
From: Tim Bradshaw
Subject: Re: GUIs (was Re: Harlequin Is Back!)
Date:
Message-ID: <nkj7lo3bgv3.fsf@tfeb.org>
······@lavielle.com (Rainer Joswig) writes:
> Have you ever looked closely at applications like:
>
> - Freehand (which I think is really elegant)
> - Illustrator
> - Quark Xpress
> - Indesign
> - Cyberstudio
> - Director
I think I would agree that modern GUIs for producing (possibly
electronic) paper things are very good at what they do. It's hard to
compare against older ones because these things are very dominated by
machine performance: without a colour screen & decent graphics
performance it's pretty hard to do a fair comparison. I'm also biased
because my main experience of these things has been trying to deal
with people who think that quark is a good way to produce large
structured technical documents, so my immediate bias is to hit anyone
who mentions it (:-). Really I think they do a task which I'm not
interested in (in computing terms: I'm interested in this kind of
thing, but I prefer to do it with silver, type and ink) very well.
> It can't be that two decades of HCI research and
> improvements are not recognized and that we
> still think presentation based interfaces
> of the past are state of the art. **I**'d be
> interested to see those techniques combined
> with a killer UI. (Hello peter!)
But 2 decades of HCI research has produced what it set out to do:
systems usable by morons. Modal dialogues so you can't find out what
the question the program is asking you means; click to type, the
interface for people who have to prod you before they can talk to you.
It's design for the masses: design for the lowest common denominator
which actively prevents people ever rising above that lowest common
denominator.
There's a pointer to an article on slashdot today by someone talking
about linux for the masses. While I'm no big fan of current (or old)
Unix user interfaces, it makes distressing reading. The subtext is
pretty clear: users should not be given choices. Give them one way of
doing everything, guide them ruthlessly through it, like sheep. The
result of this kind of thought is the kind of stuff you get in
Windows, where the only way out of some dialogues is
control-alt-delete and kill the process (I am serious, and this is
windows 98 not some old version).
I'm not trying to argue that some antique Lisp-based interface is the
be all and end all, far from it (I hate the symbolics window system
for instance). I *am* trying to argue that the vast majority of
modern interface design is designed to be used by sheep, and is just
frustrating if you are either not a sheep, or a sheep who desires
somehow to be something other than a sheep. What is worse is that
much of this design is making it hard for people even to imagine what
it might be like not to be a sheep.
I will check out the xerox stuff -- I knew about it but thought it had
died.
Other than that I think I've said all (more than all) I have to say
here, this is likely to deteriorate into some gui flame war (:-).
--tim
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> I think I would agree that modern GUIs for producing (possibly
> electronic) paper things are very good at what they do. It's hard to
> compare against older ones because these things are very dominated by
> machine performance: without a colour screen & decent graphics
> performance it's pretty hard to do a fair comparison. I'm also biased
> because my main experience of these things has been trying to deal
> with people who think that quark is a good way to produce large
> structured technical documents, so my immediate bias is to hit anyone
> who mentions it (:-). Really I think they do a task which I'm not
> interested in (in computing terms: I'm interested in this kind of
> thing, but I prefer to do it with silver, type and ink) very well.
Don't forget there are products that are based on Quark
as a platform, for example to manage the workflow, to query
databases, etc.
> But 2 decades of HCI research has produced what it set out to do:
> systems usable by morons.
What a nice wording for "users". ;-)
> Modal dialogues so you can't find out what
> the question the program is asking you means; click to type, the
> interface for people who have to prod you before they can talk to you.
> It's design for the masses: design for the lowest common denominator
> which actively prevents people ever rising above that lowest common
> denominator.
Not really, there are different markets with different needs.
These get different UIs. But for a lot of software you
are right - I personally think the windows UI in general is
a catastrophe and, I can't describe it better, anti
democratic.
> There's a pointer to an article on slashdot today by someone talking
> about linux for the masses. While I'm no big fan of current (or old)
> Unix user interfaces, it makes distressing reading. The subtext is
> pretty clear: users should not be given choices.
But there are good reasons for that. It helps people
to navigate in a complex world.
Personally I think this is a fundamental design principle:
Reduce complexity. Make things easy.
And it fits in my view of Lisp as a tool for
handling complexity. People are overwhelmed by
useless "information", sounds and visuals.
Creativity is suppressed - what would you do with an
empty screen? What would you do when you start again.
You have a computer, a disk, a screen, ...
How would Lisp greet you on a PC? How would the UI
be presented to you? Could you paint 3d dataflow languages
on the screen? Could you understand 2d animated
programs?
http://kogs-www.informatik.uni-hamburg.de/~haarslev/pjmovies.html
You shouldn't forget that computers are tools for people and
only one tool of many. Not everyone is able to deal efficiently with
a complex piece of software (the Windows NT UIs, for example are much too
complex). Apple was experimenting with customizable UIs
and they are not supporting it in newer systems anymore.
Look for example at the UIs by Kai Krause (PhotoSoap, Bryce, ...).
They were seen as something new, but the software is
not really easier to use.
> Other than that I think I've said all (more than all) I have to say
> here, this is likely to deteriorate into some gui flame war (:-).
But what can we learn?
······@lavielle.com (Rainer Joswig) wrote:
>You shouldn't forget that computers are tools for people and
>only one tool of many. Not everyone is able to deal efficiently with
>a complex piece of software (the Windows NT UIs, for example are much too
>complex). Apple was experimenting with customizable UIs
>and they are not supporting it in newer systems anymore.
>
>Look for example at the UIs by Kai Krause (PhotoSoap, Bryce, ...).
>They were seen as something new, but the software is
>not really easier to use.
finally the first who mentions those really modern UI's.
i would extend it to WinAmp, the new XING Encoder or most of the stuff
all what this fresh young anti-ms techno (the music) breed does.
This is a modern UI.
they re-invented the wheel (avoiding MFC or all other libraries), it IS
easier to use, needs less space, is faster and has better controls than
the usual stuff. nice attitude.
not as customizable as in X Windows of course, but almost.
i'd like to see this in lisp also, re-inventing the wheel is nothing new
to us :)
--
Reini
> >Look for example at the UIs by Kai Krause (PhotoSoap, Bryce, ...).
> >They were seen as something new, but the software is
> >not really easier to use.
>
> finally the first who mentions those really modern UI's.
>
> i would extend it to WinAmp, the new XING Encoder or most of the stuff
> all what this fresh young anti-ms techno (the music) breed does.
> This is a modern UI.
> they re-invented the wheel (avoiding MFC or all other libraries), it IS
> easier to use, needs less space, is faster and has better controls than
> the usual stuff. nice attitude.
I haven't had the time to check Xing out, but WinAMP or all those
shaped music players really don't improve. Quite the contrary, you
don't recognize your basic GUI elements without looking twice which
basically destroys the principle of consistency. If a GUI isn't
predictable, it's worth nothing...
All those themable applications add is a huge bunch of eye-candy.
...Michael...
PS : But on the other hand, I even dislike those pseudo-3D shadings
that you get with Windows, NeXt, Motif or the newer Mac stuff.
In article <·················@mindless.com>,
Michael Dingler <········@mindless.com> writes:
>
> PS : But on the other hand, I even dislike those pseudo-3D shadings
> that you get with Windows, NeXt, Motif or the newer Mac stuff.
Long live Xaw!
Mike McDonald
·······@mikemac.com
> > PS : But on the other hand, I even dislike those pseudo-3D shadings
> > that you get with Windows, NeXt, Motif or the newer Mac stuff.
>
> Long live Xaw!
Well, as long as you don't mean those heretic Xaw3D or neXtaw versions ;)
But it still hasn't all the sufficient widgets/controls, although the
resource mechanism is pretty nice, especially when you take in account
that there's no non-Xt widget library with something similar.
To get OT again: Through lack of professional experience and money
I haven't had the pleasure(?) of working with CLIM, but from what
I've heard it's pretty big. Is this true and if the answer's yes,
why? Widgets? A big foundation mechanism? Cross-platform abstractions?
...Michael...
In article <·················@mindless.com>,
Michael Dingler <········@mindless.com> writes:
>> > PS : But on the other hand, I even dislike those pseudo-3D shadings
>> > that you get with Windows, NeXt, Motif or the newer Mac stuff.
>>
>> Long live Xaw!
>
> Well, as long as you don't mean those heretic Xaw3D or neXtaw versions ;)
The beauty of Xaw/Xaw3d is that if some misguided individual wants those
pseudo 3D effects, they can have them without bugging me.
> But it still hasn't all the sufficient widgets/controls,
True, but that's because all work stopped on them 5-10 years ago. The idea
of a simple widget set still appeals to me, especially after I get done
wrestling with Motif's RowColumn widget!
>
> To get OT again: Through lack of professional experience and money
> I haven't had the pleasure(?) of working with CLIM, but from what
> I've heard it's pretty big.
It's pretty big. But it's more than just a "widget set".
> Is this true and if the answer's yes,
> why? Widgets? A big foundation mechanism? Cross-platform abstractions?
Actually, one of the problems with CLIM is it has almost no "widgets". It
has the hooks for some but the sample implementation doesn't provide much.
They're also pretty ugly. You can definitely tell a CLIM app. (Most of the
time anyway. Franz had a screendump on one of their newsletters a couple of
years ago that looked pretty modern. Unfortunately, at the time, they hadn't
updated any of the examples or docs to tell a user how to get the new look
instead of the old, plan CLX look.)
CLIM has a large foundation. If you just scan the table of contents for the
spec (http://www.mikemac.com/mikemac/clim/cover.html), you'll see a long list
(there are 30 chapters and 5 appendices) of pretty complicated pieces. Some of
the chapters make you stop and ask what this has to do with a GUI. CLIM is
much richer than what most people expect from a GUI system.
Yes, CLIM is meant to be display independant. You don't normally think in
terms of pixels or such in CLIM since all graphics goes thru an arbitrary
transformation matrix. You tend not to worry about things like visuals or
pixel depths either. You just call make-rgb-color and let the system worry
about it.
Mike McDonald
·······@mikemac.com
Rainer Joswig wrote:
> My experience is with areas like publishing and media production. Why do you
> think the Mac is the favorite tool of artists, designers, publishers?
The reason why publishing and media production people like Mac is because they
are technophobes and Macs are easy to use and hard to break. Macs are easy to
integrate and the hardware is stable. That is why artists and designers use
Macs. Publisher however, IMHE, use Macs to design stuff on an big UNIX boxes to
output and RIP stuff on. Back to the marmoset: a semi-sober marmoset in a fair
wind can draw pictures and print pictures after 30s of Mac training! This may
not be a bad thing though.
> ... I know that there are hardcore Unix weenies who love "sh",
This is going it some: most people have move onto csh by now :-)
> Have you ever looked closely at applications like:
>
> - Freehand (which I think is really elegant)
> - Illustrator
> - Quark Xpress
> - Indesign
> - Cyberstudio
> - Director
Yes, I have and they are problematic and buggy. The 'stuff' they output is often
dubious and cause serious problems. Many hours are required in trying to sort
out some of the more difficult problem before the graphic output can be used or
printed. A lot of this maybe user error but not all of it.
Have you ever tried to get freehand, illustrator and quark (for example) to talk
to each other?
In particular, there are some serious flaws in Freehand, which when these have
been brought to the attention of the company that develops this software they
have shown little interest in. Have you ever tried to decode or debug the native
freehand format to try and get information out of it? verify colour separation?
If you thing C++ or Java is bad try looking at the proprietary languages that
are embedded in the native files of these programmes. Nice GUI awful output.
Sorry about that rant. But I have to deal with this stuff day in and day out.
As Wittgenstein once wrote 'whereof one does not know thereof one should not
speak'
:-) will
In article <·················@pindar.com>, ········@pindar.com wrote:
> > Have you ever looked closely at applications like:
> >
> > - Freehand (which I think is really elegant)
> > - Illustrator
> > - Quark Xpress
> > - Indesign
> > - Cyberstudio
> > - Director
>
> Yes, I have and they are problematic and buggy.
I was talking about UI issues.
> If you thing C++ or Java is bad try looking at the proprietary languages that
> are embedded in the native files of these programmes. Nice GUI awful output.
>
> Sorry about that rant. But I have to deal with this stuff day in and day out.
Yes, I know about these problems, too. I have similar
problems in Lisp systems, too.
So, there is this company who is developing a typesetting
software for music. They are using Macintosh Common
Lisp. Might be interesting to hear what their experience
is in this area, where high-quality output on
screen and print is extremely important. The basic
library is for graphical output is not written in Lisp
(does fonts, graphics, scaling, ...).
It's my feeling that it is of outmost importance to
hear these stories and let people learn how to do
similar things.
-> Folks, go to the next LUGM in San Francisco.
http://www3.franz.com/lugm99/conference/index.html
Send your papers and your reports about your
cool stuff to Richard Gabriel.
Rainer Joswig wrote:
> I was talking about UI issues.
Fairy snuff. That is a very fair point.
I am always extremely suspicious of anything that looks nice but when you look
'under the hood' the output is so cack-handed. Particularly in the case of
Freehand. As some in Yorkshire say 'However much you polish a turd, it is still a
turd.'
> .... it is of outmost importance to hear these stories and let people learn how
> to do
> similar things.
I could not agree more.
:-) will
> From: ······@lavielle.com (Rainer Joswig) [·············@lavielle.com]
> Nowadays this stuff is market by InXight,
> and is no longer in Lisp - but in Java
> and C++. See: http://www.inxight.com/.
> Look for their Chief Technology Officer
> and then search your Lisp library for
> publications about "Silica". Sigh.
>
> Sigh.
>
Ok, I looked at a few demos of Hyperbolic Tree, and it's
really no big deal. You lose information in the Org chart
because you don't know where you are from linear indentation,
you can't see complete headings so you don't know where to go
in the United Nations example, and the Grocery store demo
is a joke--it's just a star that dances around a little.
So a tree mapped onto a sphere is no tree...and how is it supposed
to scale 1000s of nodes when you don't know how it's organized
and hundreds of lines just trail off the end of the cluster?
This is just hyped radical hypertext and career-building
from the look of it. Lotus Notes TOC Twisties are better.
Fundamentals folks...
http://www.cybtrans.com/infostrc/
Here's some diatribe that is now edited out (I mirrored the site
a while back)...
The Overemphasis of Radical Hypertext
Hypertext should be seen as augmenting the existing techniques of
structure and navigation, not as superceding and replacing them.
Hypertext theory has ignored half the domain: the practical power of
linear hypertext. Practical, linear hypertext applications are of great
practical importance, yet the theorists of extreme hypertext haved
ignored and practically denied that this half of hypertext exists. We
need
research on the ability of hypertext to support and augment conventional
document structures.
The fundamental models and assumptions of hypertext theory are distorted
at their core, due to overgeneralizing and focusing strictly on the
novel potentials of hypertext, while ignoring the important ability of
hypertext to support conventional document models. The theorists
deserve criticism because they have not justified their decision to
focus strictly on the novel aspects of hypertext, and they have not been
forthright about the real nature of their *interests*. They do not
acknowledge the power of linear hypertext and then declare that they are
choosing to concentrate on extreme hypertext instead. Rather, they
distort the essential nature of what they are studying, in order to fit
their
personal interests that they freely choose to pursue. They say that
hypertext is *essentially* nonlinear, and that nodes are *essentially*
"card"-shaped. They say that scrolling is interesting, but not really
relevant to hypertext. These statements and positions are distortions of
the
very foundation of all the extreme-hypertext theorizing. These supposed
statements of fundamental theory are actually statements about the
fraction of hypertext that is most novel and most intriguing to these
theorists, who thrive on novelty and not on mundane practicality. I
wonder how many theoretical analyses there are that study hypertext as
implemented in Windows Help 4.0; I wonder how often IBM
BookManager is analyzed by the hypertext theorists. These classically
structured, linear hypertext environments are designed to be as
boringly effective as possible -- in a way, like the Web page. No
theoretical fuss and sweating brow and cries of emancipation from the
evils
of linearity, just electronically automated cross-references between
subsections of online, conventional, linear books.
They say "a node is like a card and lacks linearity, that's what
hypertext is about", I must counter: "No, that's false. That's how *you
choose* to study hypertext, that's the model you choose to adopt --
please don't say how everyone else is supposed to approach hypertext.
You claim that hypertext fundamentally only has *this* nature --
fragmentation and nonlinearity. That's simply not true. Hypertext *also*
has
other important capabilities, to support linearity and coherence. Talk
about its *capabilities* for nonlinearity if you wish, but don't
generalize
those capabilities into a statement of the fundamental and complete
nature of hypertext. That's what you've been doing, making statements
about *fundamentals* that are generalizations of a special limited case,
and thus, your statements about fundamentals are fundamentally
false, or at least fundamentally distorted and partial. And the part
that you are leaving out is none other than practical hypertext
applications
for business and library science, and the very features that support
efficient, general nonfiction reading! You claim that you are studying
the
important aspects of hypertext. Are not the practical linear
capabilities and the coherence-strengthening capabilities of hypertext
*also*
important aspects, as well as the extreme, radical, and novel aspects?
It's a very serious and important realm of hypertext applications, and
you deny it exists, and you deny it's real hypertext, and you don't
study it. Then all your research is not so valuable. You aren't
interested in
studying the nature of hypertext in its fullness, as it helps people in
its many ways. You are only interested in the extreme aspects of
hypertext, and that's all the credit you can fairly be given; you can't
claim to be a *general* theorist of hypertext."
Against the Theory that Hypertext Represents a Fundamental Break from
Hardcopy Information Structures
Often while reading the research papers, I have a gut feeling that
hypertext theory is 95% BS; false promises and vague dreams that are
define in such a way as to prevent their coming true. I'm picking up a
strange overtone, a fear of attainment of the goals, a joyous
celebration
of The Problem. They are in love with the problem, as a problem. I don't
think they actually *want* to solve the problem; they want the
problem to evade solution. The theorists love the intoxicating freedom
from structure, a freedom that only wild hypertext can possibly offer.
Taming hypertext would imprison us once more in the hell of linearity.
The hypertext theorists take a self-defeating approach to the problem
of hypertext, so the "problem" of orientation seems to be a problem that
they choose to fabricate out of the sheer desire for challenge, a
challenge which they have no interest in winning, but every interest in
losing, to preserve the expansive wildlands of this untrammeled, new
frontier. They don't want The Navigation Problem to ever be solved.
Hypertext is the new Heisenburg Uncertainty Theorem, the new
psychological equivalent of Quantum Mechanics - the Copenhagen view. The
extreme-hypertext theorists have taken their positions against
the Apollonian, and so far, have been denying that their Dionysian
guiding light, Hypertext, could have any role in promoting the
Apollonian.
Hypertext lends its power to both parts of the psyche; order and
structure just as well as unchained exuberance. Just as Modernity brings
two opposing forces -- the Enlightenment Rationality and its reverse,
Romanticism -- so does hypertext bring forth a new manifestation of
the old tension: the polarization of linear structure and nonlinear
chaos or "chaoplexity".
Radical hypertext cannot deliver large-scale knowledge structures more
effectively than traditional information structures that were born in
the hardcopy book. Rather than radical hypertext, all you actually need
to do is add hypertext links to a properly structured hardcopy book,
placed online, and you've got a better system than any glitzy hypertext
theorist can come up with. Specially-designed hypertext books are
almost without exception difficult to navigate in; books that merely use
hypertext to assist a traditional structure are almost always bound to
be usable and have a strong sense of orientation and control. There is
so much strenuous research, impressive posturing and publishing of
PhDs, and hardcore theorizing, yet ultra-traditional, ultra-structured
BookManager runs circles around the fancy gizmos and strenuous
thinking of the pointy-headed theorists. They are trying to make
hypertext navigation and structuring difficult, a challenge, a career
for
experts. But it's actually simple, if they would quit trying to treat
hypertext as such a new device.
Hypertext is the ancient device of a cross-reference, sped up by an
online link. It's only somewhat new; hypertext is not an entirely new
information structuring device.
Those who begin thinking with the axiom of the uniqueness of hypertext,
the assumption that information structuring using hypertext is
essentially different than with hardcopy, start off with ignorance and
loathing of hardcopy, and alienation from hardcopy, seeking a
fundamental alternative to, essentially, information structure itself.
There is no fundamental alternative to the ancient structure of the
book,
which is true to the needs of information structuring at its core. There
is no alternate route, just an escalation of complexity if you drop the
ancient devices in the effort to outdo them. When these theorists
finally get hypertext to deliver on the promises they've made for it,
they will
find that all their inventions aren't new. They will find that they have
reinvented the wheel and have merely reproduced the ancient information
structuring and navigation devices that are used in books: the
cross-reference, the hierarchical outline, the topical index, the
partial table of
contents at the front of the chapter, the hierarchical set of headings,
the list, the caption.
Ah, finally I have found the *religious* philosophy of the two attitudes
toward hypertext (radical vs. linear; novelty vs. tradition). Hypertext
in its true essence is not opposed to hardcopy, is not an alternative to
hardcopy. Hypertext links merely augment and amplify hardcopy
information structure.
Once this union of hardcopy and hypertext is achieved, only then can you
speak of further refining hypertext. The real point is not hypertext,
but rather, putting traditional writing structures online. It's a huge
mistake to put hypertext on a pedestal and elect it president.
Information
Structure is the key and the god to worship, not Hypertext.
All books that focus specifically on "hypertext" and "technical writing
for online documents" are seriously, fundamentally misguided. It's
better to read books that focus on "structured documents" such as SGML
books.
The only people who go to the trouble of writing a book about
"hypertext" or "writing for online documents" are those who see
hypertext as
an entirely new frontier that makes a clean break with the past (and
joyously burning all the wisdom about information structuring that is
embedded in The Book). I co-authored a book about hypertext called _No
Hype_ - a review of online document viewers. I didn't write the
theory part; I'll look at it anew.
There is a newly evident split, a new battle: the "traditional
structuralists" versus the "radical hypertext theorists". I'm a
traditional structuralist.
The radical hypertext theorists write all the books with "hypertext" in
the title; the traditional structuralists write books with more general
or
traditional terms in the title, because hypertext should not be treated
in isolation from more general structures of information formatting.
When you isolate hypertext in a way that alienates it from other
structures, hypertext becomes false: it then fails to deliver the
promise that
the proponents extend. If a theorist promises hypertext as a panacea and
total self-contained alternative to the hardcopy book, then that
theorist doesn't understand the power of the book, and doesn't
understand information structuring and efficient communication of
knowledge
structures.
From Talmud Folios To Web Sites: Hot Pages, Cool Pages, and the
Information Plenum - Edmond H. Weiss, Ph. D.
The particular style of handling information and extracting
knowledge inherent in the Talmud folio is different from the traditional
way of reading and studying in the West. The differences are
philosophical and cultural, based on quite different models of
mind and intelligence. A Talmud page is not a page of King James
Bible; Talmudic logic is not Aristotelian logic.
There are two perspectives on knowledge: Hellenistic and Talmudic.
The worldview of the Greek philosophers (mainly
Aristotle) versus the worldview of the Rabbis and Sages who
compiled the Talmud. And if, as it appears, the new ways of
communicating are making our lives less Hellenistic and more
Talmudic, does this not also signal a major cultural shift in the
communications profession.
This new way of communicating, which Ted Nelson probably saw first,
is almost entirely dependent on hypertext/media, the
perfect alternative to the inexorable forward moment of Hellenistic
communication. (In a Platonic "dialogue," the secondary
speakers are merely instruments to advance Socrates' arguments; he
never concedes or loses a point! There is no real
discussion or deliberation.)
Interestingly, Gershom Gorenberg, writing about the use of new
media in Bible and Talmud study observes that "Jewish
religious study became hypertext centuries ago, even if it's taken
technology until now to catch up."
But why? Why - until recent electronic innovations - was it
necessary for the Talmud student to have someone to argue with,
as well as several open books, merely to understand what was on a
page before him?
I suspect that the methods and approach of technical communicators
are shaped by whichever of these two world views most
closely describe their own orientation.
Edmond H. Weiss, <blink>Ph.D.</blink> wrote a book about structured
hardcopy documents. Now he seems to have stopped promoting
structure; he doesn't propose the right way forward, which is to add
nonlinearity to a solid base of structure.
Setting aside the Talmud's format and the truth of the information woven
into the hypermedia blitz of the Talmud, my position is that
unstructured information is chaos, while Order is Good.
Order is almost always what readers of technical documents urgently want
and need. Once you have secured a stable foundation of order,
only then should technical writers and business site designers
experiment with adding additional alternative devices, nonlinearity, and
multiple
alternative structures.
Hypertext should be seen as augmenting the existing techniques of
structure, *not* replacing them. The choice is a choice between
development and insanity; greater order or a breakdown into
fragmentation and disintegration. Only you can make the choice upon
which
the fate of the infosphere depends!
How to Tell Whether You Are a Radical Hypertext Theorist or a
Traditional Structuralist
Which of the following do you more readily agree with:
Hypertext is an improvement beyond the information structures that
came from hardcopy books.
Hypertext is an improvement of the information structures that came
from hardcopy books.
The first position, which sounds innocent enough, is the position of the
radical hypertext theorists. Hypertext is seen as replacing all the
familiar navigational and organizational devices that were born in the
hardcopy book.
The second position puts the emphasis on information structures
themselves, abstracting them out of the hardcopy medium itself. The
hypertext link is an online implementation of the cross-reference.
The radical hypertext theorists base their stance on two main
differences of online document presentation compared to book properties:
The cross-references are traversed electronically.
The reading area is smaller.
The theorists exagerrated the significance of these two axioms and said
they make all the difference in the world. The theorists took the
stance of "Here's our opportunity to throw out all the rules and invent
an entirely new set of principles for information layout and
navigation!"
Upon an exagerrated interpretation of these two axioms, and an antipathy
to the familiarity of hardcopy, the radical hypertext theorists built
their new idea space. But this idea space turned out to have a lot of
starry-eyed dreams with only a little innovation, and little ability to
organize the information. They didn't understand the devices they were
attempting to reject, in the book, and they didn't really understand or
accept information structure itself.
A hypertext link is an automated cross-reference lookup, a fast
book-retriever and page-flipper. A small reading area does not mean
having
to switch from the linear page to a cellular 'card' metaphor, because
devices such as scrolling and a default sequence of nodes can
effectively
emulate the linearity of a set of printed pages. Hypertext is faster
than manual cross-reference lookups, and speed makes a qualitative
difference, but not such a radical difference that we need to throw away
the book techniques and create an essentially new set of techniques.
Ask radical hypertext theorists if they like structure: "Of course!
Well, sort of. But structure can be restricting. Structure is a thing of
the past
-- we're in the postmodern, nonlinear, hypermedia era! Everything moves,
flashes! Like Sesame Street and MTV! We're in more of an
multimedia entertainment paradigm now, a free-form exploration space,
without being locked into structure. Structure is basically a cage,
and we're ready to evolve beyond it, for the emancipation of
consciousness."
The Dark Side of Sesame Street
In _Amusing Ourselves to Death_ (search http://www.amazon.com), Neil
Postman critiques of the hypermedia blitz of Sesame Street. He
describes how children are dazed, frustrated, and bewildered as bits of
potentially interesting information are extended to them, and then
yanked away just as the child is starting to engage. Has Sesame Street
been destroying our expectation that paying attention will be
rewarding? The result of this random parade of flashes, this free-form
multimedia collage, is not an emancipating nonlinearity that
supplements structure and coherence; but rather, sheer disintegration
and fragmentation of attention.
To denigrate and firmly abandon structure is insanity. Only when you
commit to preserving, enhancing, and respecting structure should you
talk of supplementing structure with nonlinearity. Only when you have
(and keep within reach) the techniques of structure, should you
venture into the unstructured, if your goal is serious information
access rather than stimulating entertainment. Even for entertainment,
structure
is essential. Chaos is boring, frustrating, and mind-numbing, not
entertaining.
In article <········································@exchange1.hhmi.org>, "Kucera, Rich" <·······@hhmi.org> wrote:
> Ok, I looked at a few demos of Hyperbolic Tree, and it's
> really no big deal.
I don't like the "Hyperbolic Tree", too.
The question is, did you see the other stuff Xerox did?
Cone trees, perspective walls, organisational maps,
lenses, ...
> From: ······@lavielle.com (Rainer Joswig) [·············@lavielle.com]
> In article
> <········································@exchange1.hhmi.org>,
> "Kucera, Rich" <·······@hhmi.org> wrote:
>
> > Ok, I looked at a few demos of Hyperbolic Tree, and it's
> > really no big deal.
>
> I don't like the "Hyperbolic Tree", too.
> The question is, did you see the other stuff Xerox did?
> Cone trees, perspective walls, organisational maps,
> lenses, ...
>
No I didn't see any of that, I just picked the first thing
on the list. They ought to put their best foot forward,
rather than that Hyperbolic Tree...they ought to know that
being information design people...now I have to find an
occasion to back to the site, perhaps I'll check it out.
Tim Bradshaw <···@tfeb.org> writes:
Not really replying to Tim here---but I couldn't find Rainer's original
message to reply to.
> ······@lavielle.com (Rainer Joswig) writes:
>
> > I'm not so sure about that. Most Lisp GUIs are old
> > and only few new ideas have not been approached in the last years
> > by the Lisp community. MCL's interface is unchanged for years.
> > LWW's UI is very conventional and Franz's new IDE
> > is downright ugly (IMHO).
I really like the look of the Franz IDE. It's got some details I'd change,
and Franz has them filed as bug reports (many of which they've been very
responsive about--they have excellent support), but it's extraordinarily
easy to use. I think summing it up as downright ugly is a subjective
judgment and this message is intended to add balance by saying that my
subjective judgment is just the opposite. I personally think the look is
pretty darned similar to Symantec Visual Cafe, and the key difference is that
I can actually figure out how to get work done in the Franz IDE where
Visual Cafe is always doing "helpful" things for me that I don't want.
(It writes all of code I didn't want ... I'm continually amazed by how I'll
hit a button and it will write me a big glob of code that it thinks implements
my request and then I'm stuck to deal with the consequences. The Franz IDE
has a lot more human engineering in it, I think, to insert just the right
amount of time at just the right time.) Just my opinion.
Kent M Pitman <······@world.std.com> writes:
> my request and then I'm stuck to deal with the consequences. The Franz IDE
> has a lot more human engineering in it, I think, to insert just the right
> amount of time at just the right time.) Just my opinion.
^^^^
That would be an incredibly useful thing to have in an IDE, especially
before dead-lines! ;)
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
In article <···············@world.std.com>, Kent M Pitman <······@world.std.com> wrote:
> I really like the look of the Franz IDE.
It's good to hear that users are satisfied with it
(I'm not a user of ACL). As a Mac user, I couldn't
even look at the icons... ;-)
······@lavielle.com (Rainer Joswig) writes:
> In article <···············@world.std.com>,
> Kent M Pitman <······@world.std.com> wrote:
>
> > I really like the look of the Franz IDE.
>
> It's good to hear that users are satisfied with it
> (I'm not a user of ACL). As a Mac user, I couldn't
> even look at the icons... ;-)
This is probably a window-system-preference issue. As an owner
of Macs-only at home, I also prefer the Mac look-and-feel. And I am
not a Graphics Design expert, so I may miss some of the deeper
sublteties that make the Mac so popular in GD circles, but even as
a casual window-system user I can appreciate the gestalt of the Mac
windows system which from my point-of-view makes it easier to use.
Since I am writing this from a Franz account, I should say for those
readers who might be horrified by such a statement that I have no
direct role in the development or maintenence of our Windows GUI/IDE;
My work on Windows systems has little to do with the GUI, and others
have made our IDE match the look-and-feel of Windows.
Also, I have noticed over the last few years that there has been a
distinctive merging of concepts in both windows systems, and although
there will always be differences between the two systems, they do seem
to be converging.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
>
>Also, I have noticed over the last few years that there has been a
>distinctive merging of concepts in both windows systems, and although
>there will always be differences between the two systems, they do seem
>to be converging.
>
Sort of a fundamental theorem of user interfaces to match the
fundamental theorem of programming languages: to make a user
interface better, add something from the Macintosh user interface.
Apple really did a whole lot of work on their interface, and it
shows in ease of use.
(Sometimes it seems odd to me at work, casually mentioning, "Yes, that
feature originally came from Lisp" all the time.)
--
David H. Thornley | If you want my opinion, ask.
·····@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
> From: ······@lavielle.com (Rainer Joswig) [·············@lavielle.com]
> I think for example the component approach of "JavaBeans" is an
> interesting concept. See for some visual tools:
> http://java.sun.com/beans/tools.html
> Doesn't look that bad...
"...and we can hold the world hostage for...one million
dollars!" :)
stuff's been out for two years, you're being sarcastic
JavaBeans is just a coding format for builder tools, quite
hokey
actually, may be more merit in the introspection concept
Enterprise Java Beans is a completely different thing, despite
the confusing marketing name, it's a callback framework for
writing
distributed transactional objects. MTS raise some useful
criticism
of EJB, but wouldn't buy into MTS either. CORBA Components is
OMGs answer to EJB, but it's a 500 page specification!
All of this stuff is hot air because hardly anyone has had a
chance
to sit down and actually try the stuff out
My suggestion is to get the free Oracle8i for NT and the free
JDeveloper
to try out the n-tier application platform thing
Also try out a free ORB, Orbacus seems clean, in VisualAge for
Java
to get experience with the Standard Bus
······@lavielle.com (Rainer Joswig) writes:
> In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>
> > I do. People *hate* C++.
>
> But why are many big desktop applications written in C++?
People write in things they don't like.
Also, my remark was a statement of purported fact, not an assertion on
my part. That is, I wasn't asserting people hate C++ or wanted to
shift. I was asserting that it was percieved by the Dylan designers
that this was true. I could be wrong in my recollection, but I doubt
I am. And whether it's a fact or not that C++ was hated, the feeling
that it was should have been reconsidered at the time Java came along
since Java appears to have been designed on the same theory. Perhaps
you are just quibbling about hate.
Specifically, things like "memory leaks", "the fragile base class problem",
and others are specific things about C++ that at the time Dylan was
being created (late 1992 and early 1993) were felt would make a lot of
people want to leave C++. Arguing that they now don't hate it or whatever
seems like and inappropriate use of hindsight insofar as you're trying to
understand the process issues which gave rise to Dylan. As to the question
of whether it should have been kept alive, my claim is that the high order
bit in that analysis is "I didn't see a specific retargeting of Dylan to
accomodate the presence of Java". Given that this didn't (appear to)
happen, the rest seems like it was in the noise. Then again, I didn't
follow Dylan design in detail because early on it became clear to me
that the internal Harlequin politics were such that my voice was going to
be lost, so I just opted to wholly withdraw myself rather than face the
day-to-day frustration of trying to be heard. Now and then I sent them
specific comments on specific details, and once I made an abortive attempt
to use Dylan for a project, but largely I was separated from it.
> From what I'm inferring it seemed that Apple wanted to create new
> breeds of machines.
As I understand it, some in Apple wanted it and some didn't. To try to
attribute the result to the language in any way is probably inappropriate.
It's more likely, I'd guess, though I wasn't inside Apple to see it, that
where someone physically sat (Massachusetts vs California) was what
determined the answer. The fact of Apple's disinterest seems a mere
fact of history to me, about which I would infer little other than that
managing politics is a separate and essential part of success.
Kent M Pitman <······@world.std.com> writes:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> >
> > > I do. People *hate* C++.
> >
> > But why are many big desktop applications written in C++?
>
> People write in things they don't like.
>
> Also, my remark was a statement of purported fact, not an assertion on
> my part. That is, I wasn't asserting people hate C++ or wanted to
> shift.
However, I was asserting that, and I continue to assert that. I know
people doing medium to large C++ systems, and they hate it. How much
they hate it depends a lot on how much other experience thy have and
how good they are at analysing what is causing so much pain, but they
hate it.
However they see that there is no way out right now, and I basically
agree with them.
--tim
Kent M Pitman <······@world.std.com> writes:
> Now and then I sent them specific comments on specific details, and
> once I made an abortive attempt to use Dylan for a project, but
> largely I was separated from it.
What was abortive about it if you don't mind me asking?
Chris.
Chris Double <···@ihug.co.nz> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > Now and then I sent them specific comments on specific details, and
> > once I made an abortive attempt to use Dylan for a project, but
> > largely I was separated from it.
>
> What was abortive about it if you don't mind me asking?
Heh. Nothing material. Harlequin internal politics. Didn't really get
far enough to have the language itself be an issue. Toyed with it for
a few days and then we set up some internal weekly meetings between the
internal clients and the group maintaining it.
They put all the documentation in Lotus Notes and a large faction of
Harlequin internal people, myself included, refused to use Notes.
Notes was a disaster within Harlequin--all kinds of problems reported,
but apparently not on the platforms the people who had chosen it were
running; I gues maybe worked better on PC's--I had a SPARC at the
time. There was no other way to account for why some people hated it
and others couldn't understand what was the matter with it. On the
SPARC, it was a memory hog, a color map drain, and it wedged things
all the time. There were gripes about it on the PC, too, but not from
everyone--not sure the details. I don't know if anyone ever left the
company over the use of Notes, but certainly some cited that as a
contributing factor and made this a criterial issue in where they
would work next--that it be Notes-free. It was hugely controversial;
perhaps it still is. I remember that when I got laid off, that as one
of the big consolations of the event--that I wouldn't have to endure
Notes any more.
Anyway, the Dylan Group insisted that Lotus Notes was the official
answer to the company's internal communication needs and that by
definition having doc in Notes was The Right Thing (TM). But the
company, although it tried to require us to use Notes, ironically did
not require us to use any particular programming language. So I went
back to using Lisp because I felt the group was unresponsive to my
needs. Others in my group felt likewise. But it was a simple matter
of a single meeting in which the group got the users in the room and
said "We're here to solve your needs" and then when I cited a need
they said "We define ourselves to not have to care about that need."
(External doc was done a totally different way, of course, so this
story has no real relevance outside the company and is just trivia
value at this point. The people involved are, I believe, all gone
from the company now. But it is perhaps an instructive story about
the importance of listening to what your customers want. We were
internal customers, but we had the option of walking. And we did.
Never tell a customer that you want to keep that you don't have to
care about their concerns.)
I was working on WebMaker at the time. WebMaker is written in CL.
It translates FrameMaker MIF format documents to HTML. Most Harlequin
documentation is HTML-ified using it. (The CLHS uses a custom tool of
unrelated nature.)
In article <···············@world.std.com>, Kent M Pitman
<······@world.std.com> wrote:
>······@lavielle.com (Rainer Joswig) writes:
>
>> In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
>>
>> > I do. People *hate* C++.
>>
>> But why are many big desktop applications written in C++?
>
>People write in things they don't like.
To expand on this a little, I've observed that there is a small
contingent of us in the software industry for whom learning a new
language--even if you adhere to Alan Perlis' dictum that "A language
that doesn't change how you think about programming isn't worth
learning"--is all but trivial: we get whatever the
changing-your-thinking-about-programming insight is, the syntax is just
another syntax, and boom: we're competent, and fluency is really just a
matter of time.
This is a *tiny* minority of people. It's the crew that tends to go on
and on about how brain-damaging BASIC is, following Edsgar Dijkstra's
lead, conveniently ignoring the huge amount of useful, productive work
done in Visual Basic. More significantly, it's a group that
acknowledges no momentum, no friction, no drag coefficient. Often, it's
a group that doesn't have to maintain a large body of production code
in *any* language.
Lest this seem offensive, let me acknowledge that I'm a member of this
group. :-)
Most people, though, learn new languages--computer or human--only at
great cost in time, blood, sweat, tears, and sometimes money in books
and classes. It's a *huge* investment, fiscally, psychologically,
professionally... and, as with many investments made for good or ill,
people tend to feel compelled to defend them, sometimes out of
proportion to their actual value at any given point in time or any
particular situational context.
C++, for example, succeeded largely because of a Big Lie: you can take
a C programmer, given them a C++ compiler and a book or a couple of
classes, and have an Instant Object-Oriented Programmer. Any of us in
industry have seen the results.
>Also, my remark was a statement of purported fact, not an assertion on
>my part. That is, I wasn't asserting people hate C++ or wanted to
>shift. I was asserting that it was percieved by the Dylan designers
>that this was true. I could be wrong in my recollection, but I doubt
>I am.
While I am not a Dylan designer, I know several of them and was at
Apple in the early Dylan days. I think it's fair to say not so much
that people hated C++ specifically because, circa 1990-1991, C++ was
still awfully new to be hated so :-) but rather that there was a
strong, strong sense among the Dylan team that dynamic languages such
as Common Lisp, Scheme, and Smalltalk had *huge* software engineering
benefits over static languages such as Pascal, C, and C++, but had a
couple of *huge* barriers to acceptance for commercial software
development, specifically runtime performance and turnkey application
production (the classic dead-code stripping/packaging a standalone
binary problem). Dylan, at least as originally conceived as best I
recall, was explicitly intended to address these two issues while
retaining the advantages of CL, Scheme, and Smalltalk.
>And whether it's a fact or not that C++ was hated, the feeling
>that it was should have been reconsidered at the time Java came along
>since Java appears to have been designed on the same theory. Perhaps
>you are just quibbling about hate.
I think the sense among Dylanites is that Java is a step in the right
direction (e.g. being GC'ed) but doesn't go far enough (e.g. being
manifestly typed).
>Specifically, things like "memory leaks", "the fragile base class problem",
>and others are specific things about C++ that at the time Dylan was
>being created (late 1992 and early 1993) were felt would make a lot of
>people want to leave C++. Arguing that they now don't hate it or whatever
>seems like and inappropriate use of hindsight insofar as you're trying to
>understand the process issues which gave rise to Dylan. As to the question
>of whether it should have been kept alive, my claim is that the high order
>bit in that analysis is "I didn't see a specific retargeting of Dylan to
>accomodate the presence of Java". Given that this didn't (appear to)
>happen, the rest seems like it was in the noise.
This seems apt. I wonder what might have been done with a Dylan
retargeted to generate Java bytecode?
>Then again, I didn't
>follow Dylan design in detail because early on it became clear to me
>that the internal Harlequin politics were such that my voice was going to
>be lost, so I just opted to wholly withdraw myself rather than face the
>day-to-day frustration of trying to be heard. Now and then I sent them
>specific comments on specific details, and once I made an abortive attempt
>to use Dylan for a project, but largely I was separated from it.
This I obviously cannot speak to.
>> From what I'm inferring it seemed that Apple wanted to create new
>> breeds of machines.
>
>As I understand it, some in Apple wanted it and some didn't. To try to
>attribute the result to the language in any way is probably inappropriate.
>It's more likely, I'd guess, though I wasn't inside Apple to see it, that
>where someone physically sat (Massachusetts vs California) was what
>determined the answer.
This, however, I can speak to, albeit totally unofficially.
There definitely were those within Apple at high levels--for example,
Larry Tesler--who were quite vocal about their desire to see, e.g.
Newton as a Dylan-machine. In fact, I can generalize the observation to
point to the phenomenon that Apple quite often began with humongous,
overarching project ideas such as the "Family Farm" project circa 1989,
which, in principal, encompassed the entirety of AppleEvents,
AppleScript, OpenDoc... and when it became apparent that various
real-world constraints would prevent the Grand Unified Vision from
coming about, various compartmentalized and reduced pieces (such as
AppleEvents, AppleScript, OpenDoc...) would be initiated as separate
projects, under separate management, on separate timelines... typically
too poorly integrated and too late and too expensive to do any good.
From one point of view, Newton and Dylan were similarly decoupled, and
NewtonScript was the last-minute last-ditch drive to have a "new-world"
language for Newton. Having been *very* close to the Dylan world at the
time, and only slightly farther away from the Newton world, I tend to
believe this version of history.
As for California vs. Massachusetts, I don't think geography was as
important to this as it might seem: the Cambridge group was also, of
course, responsible for Macintosh Common Lisp in those days, having
acquired the assets of Coral Software. MCL was in heavy use in Apple's
Advanced Technology Group, which was the motivator for acquiring Coral
Software to begin with. The fact that most of ATG was in Cupertino and
ATG East was in Cambridge didn't seem to hurt MCL in ATG at the
time--ATG Cupertino was much busier engaging in internal MCL vs.
Smalltalk wars. ;-)
>The fact of Apple's disinterest seems a mere
>fact of history to me, about which I would infer little other than that
>managing politics is a separate and essential part of success.
Amen: a necessary, but insufficient, condition for success.
Paul Snively
--
Paul Snively <···············@earthlink.net>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 5.0 for non-commercial use <http://www.pgp.com>
mQGiBDcaPxsRBADpVRDb/ttx31kMsThK8cZjKhaTBlsG/C9W692x3YzHB7M1T82z
0OL3HL/ddk2Qz9o9ekgIM9GzVq7mg/NfzXB7qC/L7M+rztvVVBmj8Yi8R11o+0rm
vG5bEBTlTd4fSm3BDPUuw3BDt1SQ7BjGaJvRJTb5QE1BMzP3QHLSUznFYwCg/9fv
BEtCgEzpxiqGzQuOm6BSZw0EAOHZpqoDlU6QzDeGPHgFlNIXRcjm/yWZeOuEEpie
XwBwYl8q2FlnlkWROYF9Oxce3WOJzvHovwAjEWpHTlLmUpaGrew0ld1rj+yd4U0h
T397XtQ9ax2pmm5t81iijnrTEDrkBn2+EkvESQ7SnHjY0DRGRhy7UYpKNRt5uWdr
bDcVBADDYylRcVfyZMTjsb6gkVL99qjxtWR2CCaoIxV17BiDVkDGQgB3CDL4zBzT
4p1Q+Ql/Xq0YFQ5XxY2nEj4mwmycwiYf2j21yUgb7nOG5DSzQg751MAuBpiV+xmF
/BoDOJOIa2tFH7husWyAUFwtbhdZLzKEWWk8FooUOcwSdTibHrQlUGF1bCBTbml2
ZWx5IDxwc25pdmVseUBlYXJ0aGxpbmsubmV0PokASwQQEQIACwUCNxo/GwQLAwEC
AAoJEPV1SOJariLoTOwAmwbFBuCfnKwv4XSVnB4jOZYzAs1OAKCy8bHKQn/yxfjw
d1266EjA6meYbbkBDQQ3Gj/nEAQA3mrjXICi9+oj67jetHlpdC/rlTh7jpkjKRzB
1AvZjz4N2cRpWcHvVfL7RhOAMKJaWhfjB73CnWcCl5h3EnH++D2yJ6X75bnzfLo2
EpUsvSfmWZ7BCjyzpWIdvYqz4sj6xY4s1Jtzdi1hgM18+qi+CtSdkz3wEaAFzid7
69Rdi58AAgID/3mz52xXgit9wyo1wjFq55WXwfi5YVsZ7jjQl/eZsEJ5Epxm+MFb
qKCUg+1x1PlV92QzbhaMF7UaPcAdMOpUTtjMFRY5HOXaDDQrRadY9+/5f7/abfLK
OqYsHt3VjAczzZMXRnX0b2aT25jZfofUUANHaZNEASPjIjSaR6bUrJWniQA/AwUY
Nxo/5/V1SOJariLoEQLQuACg6IX+Cnrh4L+s9abxC12JyljciFYAoNQSrLpTwPsC
sqx8aMJZnHB0KK6c
=4ZXy
-----END PGP PUBLIC KEY BLOCK-----
From: Gareth McCaughan
Subject: Learning programming languages -- was Re: Harlequin Is Back!
Date:
Message-ID: <86d7xsfweh.fsf_-_@g.pet.cam.ac.uk>
Paul F. Snively wrote:
> To expand on this a little, I've observed that there is a small
> contingent of us in the software industry for whom learning a new
> language--even if you adhere to Alan Perlis' dictum that "A language
> that doesn't change how you think about programming isn't worth
> learning"--is all but trivial: we get whatever the
> changing-your-thinking-about-programming insight is, the syntax is just
> another syntax, and boom: we're competent, and fluency is really just a
> matter of time.
>
> This is a *tiny* minority of people. It's the crew that tends to go on
> and on about how brain-damaging BASIC is, following Edsgar Dijkstra's
> lead, conveniently ignoring the huge amount of useful, productive work
> done in Visual Basic. More significantly, it's a group that
> acknowledges no momentum, no friction, no drag coefficient. Often, it's
> a group that doesn't have to maintain a large body of production code
> in *any* language.
Gosh. I had always assumed -- perhaps very wrongly -- that this
wasn't a tiny minority of software people: that most good programmers
are people who find learning programming languages easy. (I take it
that you aren't just saying that most programmers are not good;
that your point is that there are plenty of good programmers who
require a lot of effort to become good programmers in a new language.)
Have I been deluded on this point for years?
If so, it's an interesting question what distinguishes programmers
who are good at learning new languages from ones who aren't. Does it
correlate with having learned at an early age? With early exposure
to several different languages? Ability in other related areas
(mathematics? natural languages?)?
One small bunch of data points: so far as I can tell, most of the
good programmers I know are good language learners too. They are
also mostly (1) good all-round minds and (2) from mathematical
or scientific backgrounds.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
················@pobox.com Cambridge University, England.
Gareth McCaughan wrote in message <·················@g.pet.cam.ac.uk>...
>
>Gosh. I had always assumed -- perhaps very wrongly -- that this
>wasn't a tiny minority of software people: that most good programmers
>are people who find learning programming languages easy. (I take it
>that you aren't just saying that most programmers are not good;
>that your point is that there are plenty of good programmers who
>require a lot of effort to become good programmers in a new language.)
>
I've always thought that myself. It really didn't matter what type of
programmer you are...given enough time, you could learn any language (how
tough is an IF statement or a Switch [or cond, or whatever] anyway?). But
over the last couple of years I've learned that this just isn't the case.
You can find a wizard Unix based C programmer -- put them in front of VB --
and they just die. This isn't the case for everyone mind you but it
certainly isn't rare. The combination of language and paradign shift just
throws them into a loop.
One other thing I've noticed in the last couple of years is the formal
protests of those who you try to encourage to learn a new language. I've
had people tell me that there is no reason to learn another language other
than VB, so why bother with C or C++ or Java or SQL. I don't see it that
way...my day job has me switching between several languages....some people
at the office can't (or won't) handle that type of thing. This fact hasn't
escaped my boss...so I tend to get the "weird" assignments...but with these
weird assignments come more money. :)
>Have I been deluded on this point for years?
>
No, you just thought that all programmers were like yourself. No, wait
a second... :)
>If so, it's an interesting question what distinguishes programmers
>who are good at learning new languages from ones who aren't. Does it
>correlate with having learned at an early age? With early exposure
>to several different languages? Ability in other related areas
>(mathematics? natural languages?)?
>
How can linguists learn so many languages. I think it's something along
the same lines. Personally? I stink at math, speak only English (with a
smattering of German)...
>One small bunch of data points: so far as I can tell, most of the
>good programmers I know are good language learners too. They are
>also mostly (1) good all-round minds and (2) from mathematical
>or scientific backgrounds.
>
Might it just be the willingness to study a language? Find out what
makes it tick? Some people are just into that type of thing. Who can say
really -- good programmers come in all shapes, sizes, and backgrounds
(socially, educationally, etc). This sounds like some kind of survey
exercise to me. :)
Damond
"Damond Walker" <·······@iximd.com> writes:
> You can find a wizard Unix based C programmer -- put them in front of VB --
> and they just die. This isn't the case for everyone mind you but it
Well, I can relate to someone who is thrown into a loop by VB. In
fact, the day I grok VB is probably the day that I die (or stop
programming, and start farming, or something). VB is the first and
only language I ever had the misfortune to use (and I've used quite a
bag full of evil languages) where functions are "defined" to return "a
number" (mind you, this isn't CL where NUMBER is a precisely defined
type!). Now you try to write a version-control system for Access
database schemas in VB, where you need to store that "number" in a
field in a database. So what you have to do in the end is some trial
and error, to find out, what type of number that damn function returns
(and hope to god, or more precisely Billy Boy, that you a) got it
right, and b) this doesn't change in the next (minor) version).
So for me VB is the first "language" that I refuse to recognize as a
programming language.
Other than that (end of VB rant), I agree... ;)
> Might it just be the willingness to study a language? Find out what
> makes it tick? Some people are just into that type of thing. Who can say
> really -- good programmers come in all shapes, sizes, and backgrounds
> (socially, educationally, etc). This sounds like some kind of survey
> exercise to me. :)
Or indeed the willingness to study anything, for that matter. I just
find that more and more programmers don't care about anything they
don't absolutely need to know, and even then they are quite willing to
let someone else do the "knowing". In effect, they probably feel
best, when they can get their job "done" (and get the pay check),
without having to know (or worse: learn!) something.
This seems to me incredibly sad (and this is also quite annoying at
times).
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre R. Mai wrote in message
<··············@orion.dent.isdn.cs.tu-berlin.de>...
>
[VB flogging snipped with much haste]
>So for me VB is the first "language" that I refuse to recognize as a
>programming language.
>
Yes, VB is a horrid language... Microsoft doesn't use version numbers
to note which release they use -- they actually use "levels of hell."
Currently we're only on the sixth level of hell (v6.0 they say...sure...) --
we got several more to go. :)
BUT, I've been using the platform since v1.0 hit the streets so I'm
comfortable with it. It's sorta like "that flashy guy with no soul" we all
tend to know. We don't like dealing with him, but you know how to handle
the guy.
>Or indeed the willingness to study anything, for that matter. I just
>find that more and more programmers don't care about anything they
>don't absolutely need to know, and even then they are quite willing to
>let someone else do the "knowing". In effect, they probably feel
>best, when they can get their job "done" (and get the pay check),
>without having to know (or worse: learn!) something.
>
On the flipside, the way the market is going, can you really blame some
people? Acronyms are created and forgotten faster than you can say "I have
to rewrite what?!?" Certain markets or more stable than others...but the PC
(read: Microsoft) world changes so wildly. I think it could be easy to get
burned out with the whole thing myself.
With my VB work I tend to code things with the knowledge that Microsoft
will change things on me. On one project I worked on we changed data access
methods two times. I had data access encapsulated in VB's notion of a class
so it wasn't a big hit...but it was time wasted if you ask me (we'll use
Jet..uh okay [time passes] we'll use RDO.... Uh, OK [more time passes] We
should use ADO.. Uh, OK [sigh]).
Damond
>This seems to me incredibly sad (and this is also quite annoying at
>times).
>
>Regs, Pierre.
>
>--
>Pierre Mai <····@acm.org> PGP and GPG keys at your nearest
Keyserver
> "One smaller motivation which, in part, stems from altruism is Microsoft-
> bashing." [Microsoft memo, see
http://www.opensource.org/halloween1.html]
From: Rob Warnock
Subject: Re: Learning programming languages -- was Re: Harlequin Is Back!
Date:
Message-ID: <7mpfn5$1ioug@fido.engr.sgi.com>
Gareth McCaughan <················@pobox.com> wrote:
+---------------
| Paul F. Snively wrote:
| > ...about how brain-damaging BASIC is, following Edsgar Dijkstra's lead...
...
| One small bunch of data points: so far as I can tell, most of the
| good programmers I know are good language learners too. They are
| also mostly (1) good all-round minds and (2) from mathematical
| or scientific backgrounds.
+---------------
As long as we're referencing Dijkstra, I believe he also said something
to the effect that the most reliable predictor of becoming a good programmer
is a solid competency/fluency in one's native tongue.
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
On 17 Jul 1999, Rob Warnock wrote:
|As long as we're referencing Dijkstra, I believe he also said something
|to the effect that the most reliable predictor of becoming a good programmer
|is a solid competency/fluency in one's native tongue.
|
|
does any one have a refernce for this quote? It really echoes some of my
feelings.
Ehud Lamm ······@pluto.mscc.huji.ac.il
http://purl.oclc.org/NET/ehudlamm <== My home on the web
From: Christopher B. Browne
Subject: Dijkstra - Re: Learning programming languages -- was Re: Harlequin Is Back!
Date:
Message-ID: <slrn7p40mk.3lu.cbbrowne@knuth.brownes.org>
On Sun, 18 Jul 1999 19:16:05 +0300, Ehud Lamm <······@mscc.huji.ac.il> posted:
>On 17 Jul 1999, Rob Warnock wrote:
>
>|As long as we're referencing Dijkstra, I believe he also said something
>|to the effect that the most reliable predictor of becoming a good programmer
>|is a solid competency/fluency in one's native tongue.
>
>does any one have a refernce for this quote? It really echoes some of my
>feelings.
"Besides a mathematical inclination, an exceptionally good mastery of
one's native tongue is the most vital asset of a competent programmer."
-- Edsger W. Dijkstra
I'm afraid I can't associate a specific reference to this.
--
STATED REASON DOES NOT COMPUTE WITH PROGRAMMED FACTS...
········@ntlug.org- <http://www.hex.net/~cbbrowne/lsf.html>
In article <·······················@knuth.brownes.org>,
········@news.brownes.org says...
> "Besides a mathematical inclination, an exceptionally good mastery of
> one's native tongue is the most vital asset of a competent programmer."
> -- Edsger W. Dijkstra
>
> I'm afraid I can't associate a specific reference to this.
Dijkstra, E. W. EWD498: How do we tell truths that might hurt?
in /Selected writings on computing: a personal perspective./
Springer Verlag, 1982.
Qqv. http://serv1.imm.dtu.dk/documents/users/aaa/hurtingtruths.html
Gareth McCaughan <················@pobox.com> writes:
> Paul F. Snively wrote:
>
> > To expand on this a little, I've observed that there is a small
> > contingent of us in the software industry for whom learning a new
> > language--even if you adhere to Alan Perlis' dictum that "A language
> > that doesn't change how you think about programming isn't worth
> > learning"--is all but trivial: we get whatever the
> > changing-your-thinking-about-programming insight is, the syntax is just
> > another syntax, and boom: we're competent, and fluency is really just a
> > matter of time.
> >
> > This is a *tiny* minority of people. It's the crew that tends to go on
> > and on about how brain-damaging BASIC is, following Edsgar Dijkstra's
> > lead, conveniently ignoring the huge amount of useful, productive work
> > done in Visual Basic. More significantly, it's a group that
> > acknowledges no momentum, no friction, no drag coefficient. Often, it's
> > a group that doesn't have to maintain a large body of production code
> > in *any* language.
>
> Gosh. I had always assumed -- perhaps very wrongly -- that this
> wasn't a tiny minority of software people: that most good programmers
> are people who find learning programming languages easy. (I take it
> that you aren't just saying that most programmers are not good;
> that your point is that there are plenty of good programmers who
> require a lot of effort to become good programmers in a new language.)
>
> Have I been deluded on this point for years?
As a card-carrying member of the I-can-learn-any-computer-language-in-a-
few-hours school, I have to agree that very few people find learning computer
languages easy and (*gasp*) fun. I really enjoy it when a new computer
language teaches me a new way to think about programming, but most people
absolutely *despise* it. I think that is one of the key points that
distinguishes programmers who like lisp from the average programmer:
lisp-types like having their minds stretched, and the average programmer is
more comfortable doing the same old thing over and over again.
To give a more concrete (though trivial) example: one of the (many) things I
hate about C is that I get so sick of writing stuff like this:
for (i = 0; i < N; i++)
a[i] = a[i] * a[i] + 2 * a[i] + 3
whereas in lisp, scheme (and many other high level languages) you can do
something like
(map
(lambda (x)
(+ (* x x) (* x 2) 3))
a)
This to me is the right level of abstraction for the problem ("do this for all
elements of a"), so I like it better. But most computer languages only allow
you to work at one level of abstraction, and most programmers can only *think*
at one level of abstraction. Never mind that you're wasting your brain cells
doing repetitive stuff over and over again; as long as it's comfortable and
familiar, the average guy is happy.
<rant>
However, after having learned about 20 different programming languages (PHP
and SQL being the last two), I must say that I *am* getting really really sick
of seeing umpteen different syntaxes dressing up languages that are
fundamentally almost identical. This is another reason I've gotten interested
in lisp/scheme again; I'm so sick of having to learn new syntaxes that are
totally worthless. I find that more and more I prefer the much more
minimalist syntax of lisp because it's always the same no matter what
programming paradigm you're using. Why should every new programming paradigm
force us to learn a brand new syntax (not to mention having to learn new
syntaxes for languages which only support the same old paradigms?). We have
better things to do with our minds.
</rant>
> If so, it's an interesting question what distinguishes programmers
> who are good at learning new languages from ones who aren't. Does it
> correlate with having learned at an early age? With early exposure
> to several different languages? Ability in other related areas
> (mathematics? natural languages?)?
I think flexibility of thought is the crucial point here, and it's something
that isn't easily captured on IQ tests. I've heard very smart people who have
used Fortran for years tell me that they were "struggling to learn C" as if it
was incredibly hard. It's an interesting question.
Mike
--------------------------------------------------------------
Mike Vanier ·······@bbb.caltech.edu
Department of Computation and Neural Systems, Caltech 216-76
GNU/Linux: We can't lose; we're on a mission from God.
> From: ·······@arathorn.bbb.caltech.edu
> I get so sick of writing stuff like this:
>
> for (i = 0; i < N; i++)
> a[i] = a[i] * a[i] + 2 * a[i] + 3
>
> whereas in lisp, scheme (and many other high level languages)
> you can do
> something like
>
> (map
> (lambda (x)
> (+ (* x x) (* x 2) 3))
> a)
>
> This to me is the right level of abstraction for the problem
> ("do this for all
> elements of a"), so I like it better.
Click! This is very valuable.
"Kucera, Rich" <·······@hhmi.org> writes:
> > From: ·······@arathorn.bbb.caltech.edu
> > I get so sick of writing stuff like this:
> >
> > for (i = 0; i < N; i++)
> > a[i] = a[i] * a[i] + 2 * a[i] + 3
> >
> > whereas in lisp, scheme (and many other high level languages)
> > you can do
> > something like
> >
> > (map
> > (lambda (x)
> > (+ (* x x) (* x 2) 3))
> > a)
> >
> > This to me is the right level of abstraction for the problem
> > ("do this for all
> > elements of a"), so I like it better.
>
> Click! This is very valuable.
Er. Actually
(map-into a
#'(lambda (x)
(+ (* x x) (* x 2) 3))
a)
has the same semantics of the C code.
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
> From: Marco Antoniotti [··············@copernico.parades.rm.cnr.it]
> "Kucera, Rich" <·······@hhmi.org> writes:
> > > From: ·······@arathorn.bbb.caltech.edu
> > > I get so sick of writing stuff like this:
> > >
> > > for (i = 0; i < N; i++)
> > > a[i] = a[i] * a[i] + 2 * a[i] + 3
> > >
> > > whereas in lisp, scheme (and many other high level languages)
> > > you can do
> > > something like
> > >
> > > (map
> > > (lambda (x)
> > > (+ (* x x) (* x 2) 3))
> > > a)
> > >
> > > This to me is the right level of abstraction for the problem
> > > ("do this for all
> > > elements of a"), so I like it better.
> >
> > Click! This is very valuable.
>
> Er. Actually
>
> (map-into a
> #'(lambda (x)
> (+ (* x x) (* x 2) 3))
> a)
>
> has the same semantics of the C code.
>
yes, this is the exact same destructive semantics.
mapcar would be the non-destructive way just returning the new result:
(mapcar
#'(lambda (x)
(+ (* x x) (* x 2) 3))
a)
for demonstration purposes, using "map-into" would probably
get the point across better than "mapcar", which is alien syntax
and semantics(you get a new result and the old result is GC'd etc).
In article <········································@exchange1.hhmi.org>,
Kucera, Rich <·······@hhmi.org> wrote:
>> From: Marco Antoniotti [··············@copernico.parades.rm.cnr.it]
>> "Kucera, Rich" <·······@hhmi.org> writes:
>> > > From: ·······@arathorn.bbb.caltech.edu
>> > > I get so sick of writing stuff like this:
>> > >
>> > > for (i = 0; i < N; i++)
>> > > a[i] = a[i] * a[i] + 2 * a[i] + 3
>> > >
>> > > whereas in lisp, scheme (and many other high level languages)
>> > > you can do
>> > > something like
>> > >
>> > > (map
>> > > (lambda (x)
>> > > (+ (* x x) (* x 2) 3))
>> > > a)
>> > >
>> > > This to me is the right level of abstraction for the problem
>> > > ("do this for all
>> > > elements of a"), so I like it better.
>> >
>> > Click! This is very valuable.
>>
>> Er. Actually
>>
>> (map-into a
>> #'(lambda (x)
>> (+ (* x x) (* x 2) 3))
>> a)
>>
>> has the same semantics of the C code.
>>
>yes, this is the exact same destructive semantics.
>mapcar would be the non-destructive way just returning the new result:
>
>(mapcar
> #'(lambda (x)
> (+ (* x x) (* x 2) 3))
> a)
>
>for demonstration purposes, using "map-into" would probably
>get the point across better than "mapcar", which is alien syntax
>and semantics(you get a new result and the old result is GC'd etc).
>
MAPCAR only works for lists, not arbitrary sequences. The above C code
seems to imply a vector, therefore you could use
(map 'simple-vector
(lambda (x)
(+ (* x x) (* x 2) 3))
a)
SIMPLE-VECTOR is the type of the result. The result-types and the type(s)
of the mapped over sequence(s) need not match in general.
MAP-INTO is ok for arbitrary sequences.
Bernhard
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence ········@ai.univie.ac.at
> From: ········@hummel.ai.univie.ac.at (Bernhard Pfahringer)
> [·············@hummel.ai.univie.ac.at]
> In article
> <········································@exchange1.hhmi.org>,
> Kucera, Rich <·······@hhmi.org> wrote:
> >> From: Marco Antoniotti [··············@copernico.parades.rm.cnr.it]
> >> "Kucera, Rich" <·······@hhmi.org> writes:
> >> > > From: ·······@arathorn.bbb.caltech.edu
> >> > > I get so sick of writing stuff like this:
> >> > >
> >> > > for (i = 0; i < N; i++)
> >> > > a[i] = a[i] * a[i] + 2 * a[i] + 3
> >> > >
> >> > > whereas in lisp, scheme (and many other high level languages)
> >> > > you can do
> >> > > something like
> >> > >
> >> > > (map
> >> > > (lambda (x)
> >> > > (+ (* x x) (* x 2) 3))
> >> > > a)
> >> > >
> >> > > This to me is the right level of abstraction for the problem
> >> > > ("do this for all
> >> > > elements of a"), so I like it better.
> >> >
> >> > Click! This is very valuable.
> >>
> >> Er. Actually
> >>
> >> (map-into a
> >> #'(lambda (x)
> >> (+ (* x x) (* x 2) 3))
> >> a)
> >>
> >> has the same semantics of the C code.
> >>
> >yes, this is the exact same destructive semantics.
> >mapcar would be the non-destructive way just returning the new
> result:
> >
> >(mapcar
> > #'(lambda (x)
> > (+ (* x x) (* x 2) 3))
> > a)
> >
> >for demonstration purposes, using "map-into" would probably
> >get the point across better than "mapcar", which is alien syntax
> >and semantics(you get a new result and the old result is GC'd etc).
> >
>
> MAPCAR only works for lists, not arbitrary sequences. The above C code
> seems to imply a vector, therefore you could use
>
> (map 'simple-vector
> (lambda (x)
> (+ (* x x) (* x 2) 3))
> a)
>
> SIMPLE-VECTOR is the type of the result. The result-types and the
> type(s)
> of the mapped over sequence(s) need not match in general.
>
> MAP-INTO is ok for arbitrary sequences.
>
> Bernhard
>
Ah...now I'm interested in data types, thanks. Is the tree of types
which is labeled "CLOS types" considered to be the "primitive types"
of the language itself? This labeling was in Slade's OOCL. Perhaps
I should be reading Graham.
"Kucera, Rich" <·······@hhmi.org> writes:
> Ah...now I'm interested in data types, thanks. Is the tree of types
> which is labeled "CLOS types" considered to be the "primitive types"
> of the language itself? This labeling was in Slade's OOCL. Perhaps
> I should be reading Graham.
What difference does it matter what the primitive types are?
(Just curious.)
Lisp is about being able to flexibly change the level of what is
called primitive. The idea of knowing what's primitive seems to me
like asking whether "microcode" or "hardware" is what the primitive
instructions of a machine are executing? What, other than cocktail
party talk or a hiring decision about who to get to design a
replacement machine from scratch, would the answer actually cause
anyone to do differently?
> From: ······@world.std.com (Kent M Pitman) [···········@world.std.com]
> Posted At: Wednesday, July 21, 1999 5:21 PM
> Posted To: lisp
> Conversation: Learning programming languages
> Subject: Re: Learning programming languages
>
> "Kucera, Rich" <·······@hhmi.org> writes:
>
> > Ah...now I'm interested in data types, thanks. Is the tree of
> types
> > which is labeled "CLOS types" considered to be the "primitive types"
> > of the language itself? This labeling was in Slade's OOCL.
> Perhaps
> > I should be reading Graham.
>
> What difference does it matter what the primitive types are?
> (Just curious.)
>
> Lisp is about being able to flexibly change the level of what is
> called primitive. The idea of knowing what's primitive seems to me
> like asking whether "microcode" or "hardware" is what the primitive
> instructions of a machine are executing? What, other than cocktail
> party talk or a hiring decision about who to get to design a
> replacement machine from scratch, would the answer actually cause
> anyone to do differently?
>
Well, what did the primitives look like before CLOS? There must have
been
something. I know it's irrelevant and burdensome to ask questions
from
a Java point of view, where it does make a difference on an application
level
whether something is an "int" or an Integer. Perhaps my learning
would go
faster if I were to dispense with irrelevant knowledge, forget what I
know and
try not to ask any questions...
* "Kucera, Rich" <·······@hhmi.org>
| Well, what did the primitives look like before CLOS?
you speak as if "primitive" is an intrinsic quality of something.
| There must have been something.
where did you get that idea?
once upon a time, both CAR and LDB were machine instructions. these
days, CAR may be a single instruction on some machine and several or even
a function call on others. LDB is usually a shift and a mask on RISC
processors, and byte pointers are probably not first-class objects like
they used to be, so it's fast and inlined only for constant byte
specifiers on fixnums. for instance. Common Lisp has no concept of
forcing an implementation to make certain decision about which is
primitive and which is built from primitive. for all you know, all the
functions and types in Common Lisp may be "primitives", or none, which
may be the case in a hosted (interpreted) environment.
| I know it's irrelevant and burdensome to ask questions from a Java point
| of view, where it does make a difference on an application level whether
| something is an "int" or an Integer. Perhaps my learning would go faster
| if I were to dispense with irrelevant knowledge, forget what I know and
| try not to ask any questions...
you should update your knowledge and understanding of Java when you get
answers to your questions about Common Lisp. the problem with most of
the questions from another world is that the requestors tend to forget
that their old world is more in need of an update than the new world. it
is unfortunately true that it often makes better sense to suspend all
that you know from one world when entering another, just to see that you
arrive at some "universal truths" while the details are different and
some ways of getting at them may be from radically different directions.
#:Erik
--
@1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
"Kucera, Rich" <·······@hhmi.org> writes:
> Well, what did the primitives look like before CLOS? There must
> have been something. I know it's irrelevant and burdensome to ask
> questions from a Java point of view,
No, it's not burdensome, just confusing. One has to understand a
question to answer it. If you elaborate better, someone may be able
to answer better.
> where it does make a difference
> on an application level whether something is an "int" or an Integer.
> Perhaps my learning would go faster if I were to dispense with
> irrelevant knowledge, forget what I know and try not to ask any
> questions...
All things that are not STANDARD-CLASS looked pretty much identical
before and after CLOS was introduced.
Lisp has no int/Integer distinction. The corresponding item of both is
just "fixnum" and the distinction is an irrelevant one. Lisp has always
had "general purpose pointer to integer" and any decision by Lisp to have
"machine integer" has always been an "implementation decision" taken
privately by the compiler in places where it can care. This had nothing
to do with CLOS.
The major thing CLOS introduced was the notion of user-defined opaque
classes in a way that was not "compiled away" so that later if you
redefined a class to have an extra slot, the old instances could be
updated because you hadn't discarded so much information that you
were unable to rearrange things appropriately. In essence, CLOS fills
in this table which had previously had a missing entry:
| inline (open-coded) | opaque (closed-coded)
-----+------------------------+---------------------------
| |
operator | DEFMACRO | DEFUN
definition | |
-----+------------------------+---------------------------
| |
structure | DEFSTRUCT | DEFCLASS
definition | | [added by CLOS]
-----+------------------------+---------------------------
This probably doesn't answer your question. I really just don't
understand what you're asking. There are about 20 different things
you could mean, and to answer each with no direction is more than I'm
up for.
> From: ······@world.std.com (Kent M Pitman) [···········@world.std.com]
>
> The major thing CLOS introduced was the notion of user-defined opaque
> classes in a way that was not "compiled away" so that later if you
> redefined a class to have an extra slot, the old instances could be
> updated because you hadn't discarded so much information that you
> were unable to rearrange things appropriately. In essence, CLOS fills
> in this table which had previously had a missing entry:
>
>
> | inline (open-coded) | opaque (closed-coded)
> -----+------------------------+---------------------------
> | |
> operator | DEFMACRO | DEFUN
> definition | |
> -----+------------------------+---------------------------
> | |
> structure | DEFSTRUCT | DEFCLASS
> definition | | [added by CLOS]
> -----+------------------------+---------------------------
>
>
Nice chart, is everything "defclass-ed" to implement type checking?
If CLOS is were implemented as just a layer of macros,
not "built-in" as in a compiler, the "type checking" would be
done in the macros? Up to the implementor?
In AMOP, page 14, it indicates "full CLOS closely integrates Common
Lisp types
and CLOS classes. It is possible to define methods specialized to
primitive classes
(e.g. SYMBOL) and structure classes(defined with DEFSTRUCT)".
So "common lisp types" were just an older layer of macros?
Sorry, I haven't seen why this doesn't matter yet.
The major business point would be that Lisp reduces risk in a number of
key areas,
and this is why I'm trying to understand how it transcends the
limitations of
the business language-du-jour.
"Kucera, Rich" <·······@hhmi.org> writes:
> Nice chart, is everything "defclass-ed" to implement type checking?
Only the things that are defclassed are defclassed. I don't understand
the question. No system-defined types are defclassed (unless the system
chooses).
> If CLOS is were implemented as just a layer of macros,
> not "built-in" as in a compiler,
The compiler is an irrelevance. You mean the Lisp runtime system.
The compiler merely makes things faster. It does not define but is merely
one of several ways (the interpreter being another) to implement the
semantics.
> the "type checking" would be
> done in the macros? Up to the implementor?
The "type checking" (I have no idea what this means, frankly) is
whatever the language definition says it is. It's not up to the macro or
implementor. It's what the language says happens. You could implement
the semantics of the language by hand yourself, with no interpreter or
compiler.
What it means for the semantics to be achieved is for you never to do
something that violates what the manual says will happen. All the rest
you know of semantics is really about proofs that semantics are archieved,
not about achieving them. They are achieved merely by achieving them.
> In AMOP, page 14, it indicates "full CLOS closely integrates Common
> Lisp types
> and CLOS classes.
This is really a confusing way to express it. It's more marketing than
reality. Lisp had two notions already and this just made them more
concrete. A "type" is conceptually really nothing more than a predicate
that partitions the world into things "in" the type and things "not in"
the type. Lisp had this notion before. A "class" did not have a name
before, but was present. It was about representation and behavior and
customizability. Before CLOS,
there was no need to have a term to say "this is done differently than
standard class" because there was no way to make anything other than
standard-class. A "structure" existed before, but details of its
implementation and use were never user-visible, and so there was no material
difference between the user-defined type FOO and the user-defined type
INTEGER. Each has a set of operations defined on it that you would only
know if you were there when the type was defined. CLOS added a bunch of
extra functionality, and with it it added the need to be able to tell
certain things. A type can't be dispatched off of, because it's not
required that types don't overlap in certain ways that would be problematic
for dispatch. But then, user-defined type dispatch didn't exist before
CLOS, so that was never an issue. CLOS added some functionality but it did
so in a way that (and that sentence quoted above is supposed to soothe you
into believing) your prior world model is not "changed" but "extended".
That's just a piece of marketing that says "don't worry; we didn't get rid
of what you know, we just made it better".
> It is possible to define methods specialized to
> primitive classes
> (e.g. SYMBOL) and structure classes(defined with DEFSTRUCT)".
You could always do this.
(DEFUN FOO (X)
(COND ((SYMBOLP X) ...)
....))
Only the syntax for doing this has changed.
When the type is manifest (i.e, when there's no int but only Integer,
in Javaspeak), you can dispatch on everything even in the most primitive
Lisps, and so the rest is just window dressing.
> So "common lisp types" were just an older layer of macros?
No, but parts of that system may be retroactively explained as that.
DEFSTRUCT in particular was a kind of type whose accessors "compiled away"
inthe same ways that macros did. Not all types did this. That's why
it's defstruct in the table.
> Sorry, I haven't seen why this doesn't matter yet.
I call this game "deltas and epsilons" (in honor of Calculus).
It's your burden to convince me it doesn't. I'm in possession of
the next step.
> The major business point would be that Lisp reduces risk in a number of
> key areas,
> and this is why I'm trying to understand how it transcends the
> limitations of
> the business language-du-jour.
I don't have time to answer this right now.
But you might see
http://world.std.com/~pitman/PS/Hindsight.html
for more reading.
From: Tim Bradshaw
Subject: Re: Learning programming languages
Date:
Message-ID: <nkjk8rsvia3.fsf@tfeb.org>
"Kucera, Rich" <·······@hhmi.org> writes:
> So "common lisp types" were just an older layer of macros?
No, not at all. Type is a fundamental attribute of objects in Lisp.
Every object has a type, and every object knows what its type is. The
class system brings (most of) the notion of type into the open. For
most purposes (people will disagree...) you can think of classes as
simply the representation of types in the language: every class
corresponds to a type, every object has a class.
Before CLOS it was already possible to add new types to the language,
and to define them as `subtypes' (subclasses, really...) of other
types -- not for all types, only for `structure' types. If you wanted
to you could also write a system which dispatched on the type of
objects, and you'd really have an object system. Smart compilers
could perhaps optimise some of this type dispatching to compile time.
CLOS gives you some extra stuff:
the whole dispatching on classes/types is defined in the
language, and can therefore be optimised by implementors. You
can dispatch on *any* Lisp type (as you could before if you
wanted to).
for `CLOS classes' (things defined with DEFCLASSS) there are
two useful new properties:
1. you can inherit from more than one direct superclass (you
could not do that with structures). Things get merged in good
ways.
2. redefinition is supported. If you change the definition of
a class then everything works right. For other user-defined
classes (defined with DEFSTRUCT), redefinition is not
guaranteed to work (and often won't work).
I think this is what Kent was saying. You now have two places you can
sit. If you use DEFSTRUCT you are restricted in just the ways that
allow very efficient implementation: single inheritance means the
layout of objects is simple, disallowing redefinition means that
everything can be inlined. If you use DEFCLASS, you are allowed
multiple inheritance with hairy merging of the definitions of the
superclasses, and you are allowed redefinition, which means that it is
much harder to redefine things. But redefinition means you can do
incremental change of running systems, so you can do things like patch
running servers and have it work right.
Being able to do that kind of thing is a pretty big win for people
doing mission-critical type applications. I'm currently waiting
around for a chance to take some big servers down for patching, which
may not be for several months. If I could patch them at runtime I'd
be winning, and it would save a lot of money. There has recently been
some stuff by C++ people to allow runtime redefinition (search in
dejanews for an article by me (probably @ed.ac.uk) with C++ in the
title from last year sometime), though that work got various things
significantly wrong compared to CLOS, in particular what happened to
existing instances of the redefined class.
--tim
* Tim Bradshaw <···@tfeb.org>
| For most purposes (people will disagree...) you can think of classes as
| simply the representation of types in the language: every class
| corresponds to a type, every object has a class.
|
| Before CLOS it was already possible to add new types to the language, and
| to define them as `subtypes' (subclasses, really...) of other types --
| not for all types, only for `structure' types.
Tim, don't set the guy up for even more confusion than he "deserves".
_types_ in Common Lisp are orthogonal to classes, and have nothing at all
to do with subclasses. e.g., the types BOOLEAN or KEYWORD, both of which
are only partitions of the value space of the class SYMBOL, or FIXNUM and
BIGNUM, which are but partitioning the value space of the class INTEGER.
of course, a type can exhaustively cover the value space of a class, but
that is trivial. e.g., (SIMPLE-VECTOR (SIGNED-BYTE 32) (128)), objects of
which type would still be instances of the system class VECTOR. (no,
there is no _class_ named SIMPLE-VECTOR, nor classes for all specialized
vectors, but STRING and BIT-VECTOR are exceptions to this rule. sorry
for the pedantry. ;)
| You can dispatch on *any* Lisp type (as you could before if you wanted
| to).
this is false. you can only dispatch on classes in CLOS.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
* "Kucera, Rich" <·······@hhmi.org>
| is everything "defclass-ed" to implement type checking?
what is "type checking"?
if you could please step back to where your ignorance begins and start
asking questions from there, rather than walk miles into the land of
confusion before you stop to ask for directions, you would stand a chance
of learning this stuff, rather than have your questions answered in ways
you do not actually understand.
let me put it this simply: in Common Lisp, objects are typed, variables
are not. in the C tradition, variables are typed, objects are not. if
this doesn't hurt when you think about it, you have not understood what
it means for the purported object-orientedness of C++ and Java.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
On 23 Jul 1999 11:26:01 +0000, Erik Naggum <····@naggum.no> wrote:
> in Common Lisp, objects are typed, variables
> are not. in the C tradition, variables are typed, objects are not. if
> this doesn't hurt when you think about it, you have not understood what
> it means for the purported object-orientedness of C++ and Java.
For me this does not hurt (ergo I have yet to be enlightened). I think
it is more a matter of terminology then a real difference between the
languages.
What is know as the type of a variable in Java is mostly a simple way
give the compiler hints of how to optimize things, like the (the ...)
forms in CL. If you don't want to be concerned with types, you can
simply declare all variables as Object. (There are some additional
problems with things like int and float, but nobody ever claimed Java
was beautiful.)
What is known as the type of an object in Lisp most closely
corresponds to the class of an object in Java. If you wish to find the
class of an Java object, you can use the getClass() method.
-Ville
·······@home.se (Vilhelm Sj�berg) writes:
> On 23 Jul 1999 11:26:01 +0000, Erik Naggum <····@naggum.no> wrote:
> > in Common Lisp, objects are typed, variables
> > are not. in the C tradition, variables are typed, objects are not. if
> > this doesn't hurt when you think about it, you have not understood what
> > it means for the purported object-orientedness of C++ and Java.
>
> For me this does not hurt (ergo I have yet to be enlightened). I think
> it is more a matter of terminology then a real difference between the
> languages.
>
It is. See below.
> What is know as the type of a variable in Java is mostly a simple way
> give the compiler hints of how to optimize things, like the (the ...)
> forms in CL. If you don't want to be concerned with types, you can
> simply declare all variables as Object. (There are some additional
> problems with things like int and float, but nobody ever claimed Java
> was beautiful.)
>
No, you cannot. Consider calling methods of the object.
Object foo=giveMeAShape();
foo->draw();
will not compile since the compiler cannot know whether the method exists.
You will have to do something like
((Shape)foo)->draw();
[I'm not sure of the syntax since I don't do Java.] and then the
runtime system will do the appropriate checks to see whether foo is an
instance of Shape and either call the method or raise an exception.
In CL you can do
((let ((it (giveMeAShape)))
(draw it)))
where draw is a generic function that will be dispatched on the type
of the object it and not on the type of the variable.
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
Lieven Marchand <···@bewoner.dma.be> writes:
> ·······@home.se (Vilhelm Sj�berg) writes:
>
> > On 23 Jul 1999 11:26:01 +0000, Erik Naggum <····@naggum.no> wrote:
> > > in Common Lisp, objects are typed, variables
> > > are not. in the C tradition, variables are typed, objects are not. if
> > > this doesn't hurt when you think about it, you have not understood what
> > > it means for the purported object-orientedness of C++ and Java.
> >
> > For me this does not hurt (ergo I have yet to be enlightened). I think
> > it is more a matter of terminology then a real difference between the
> > languages.
> >
>
> It is. See below.
>
> > What is know as the type of a variable in Java is mostly a simple way
> > give the compiler hints of how to optimize things, like the (the ...)
> > forms in CL. If you don't want to be concerned with types, you can
> > simply declare all variables as Object. (There are some additional
> > problems with things like int and float, but nobody ever claimed Java
> > was beautiful.)
> >
>
> No, you cannot. Consider calling methods of the object.
>
> Object foo=giveMeAShape();
>
> foo->draw();
Shape giveMeAShape() { ... }
.
.
.
Object foo = giveMeAShape(); // Sorry. I *had* to put in spaces! :)
foo.draw();
// Compile error here.
>
> will not compile since the compiler cannot know whether the method exists.
> You will have to do something like
>
> ((Shape)foo)->draw();
((Shape) foo).draw();
> In CL you can do
>
> ((let ((it (giveMeAShape)))
> (draw it)))
>
Yep. It does come with a price though.
And just to be overly annoying :)
(let ((it (give-me-a-shape)))
(draw it))
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
* ·······@home.se (Vilhelm Sj�berg)
| For me this does not hurt (ergo I have yet to be enlightened). I think
| it is more a matter of terminology then a real difference between the
| languages.
sorry, the difference is very real. whether a language types variables
at compile-time or types object at run-time is actually a difference that
goes far beyond terminology. now, object-oriented programming _means_
that one dispatches on type information at run-time. in other words, a
language that types variables needs both techniques, which are at odds
with each other at a fundamental level, but a language that types objects
already has all it needs to be object-oriented from the start.
there will always be hybrid languages, however. it isn't very useful to
use hybrids as arguments unless you understand what they are hybrids of.
#:Erik
--
suppose we blasted all politicians into space.
would the SETI project find even one of them?
> I know it's irrelevant and burdensome to ask questions
> from
> a Java point of view, where it does make a difference on an application
> level
> whether something is an "int" or an Integer.
I think it is helpful to know the agenda behind your question, in this
case the int-Integer thing. Otherwise we might be wondering where you
were coming from.
One of the beautiful things to me about CL is that CLOS classes seem to
have been seamlessy blended into the CL type system, unlike Java and
C++.
Mind you, I am not a language implementer, I am a language user, so the
'seamlessness' is from that perspective...and I benefit from that
seamlessness every day.
kt
From: Steve Gonedes
Subject: Re: Learning programming languages -- was Re: Harlequin Is Back!
Date:
Message-ID: <m2u2qw3psg.fsf@KludgeUnix.com>
Michael Vanier <·······@bbb.caltech.edu> writes:
< To give a more concrete (though trivial) example: one of the (many)
< things I hate about C is that I get so sick of writing stuff like
< this:
<
< for (i = 0; i < N; i++)
< a[i] = a[i] * a[i] + 2 * a[i] + 3
<
< whereas in lisp, scheme (and many other high level languages) you can do
< something like
<
< (map
< (lambda (x)
< (+ (* x x) (* x 2) 3))
< a)
<
< This to me is the right level of abstraction for the problem ("do
< this for all elements of a"), so I like it better. But most computer
< languages only allow you to work at one level of abstraction, and
< most programmers can only *think*
Actually it would be closer if you did something like the following.
(let ((vec (vector 1 2 3)))
(map-into vec #'(lambda (x)
(+ (* x x) (* x 2) 3))
vec))
Personally, I get sick of typing the `int i' and get slightly annoyed
when I have to read something like the following.
int
file_tree_walk (const char *dir,
int (*execute_function)
(const char *,
const struct finddata *,
char * (*) (const char *, int),
void (*) (const char *, const char *),
int),
char * (*file_name_function) (const char *, int),
void (*output_function) (const char *, const char *),
int field)
{
...
}
Ah well, you know what they say: using types catches some errors at
compile time.
[The reason for such outlandish function pointers is because the
compiler I was using had no closures - another nice high-level
feature.]
From: Stig Hemmer
Subject: Re: Learning programming languages -- was Re: Harlequin Is Back!
Date:
Message-ID: <ekvu2qx61xv.fsf@epoksy.pvv.ntnu.no>
Gareth McCaughan <················@pobox.com> writes:
> Gosh. I had always assumed -- perhaps very wrongly -- that this
> wasn't a tiny minority of software people: that most good programmers
> are people who find learning programming languages easy. (I take it
> that you aren't just saying that most programmers are not good;
> that your point is that there are plenty of good programmers who
> require a lot of effort to become good programmers in a new language.)
Well, I don't know about mr. Snively, but I would say that most
programmers aren't good programmers.
This is connected to the fact that most programmers aren't programmers
at all. They are people whose heart is in some other domain and who
has been forced to learn programming to get their job done.
Of course, this depends on what you call "software people", but if you
look at the people Microsoft target with Visual Basic, you will find
people from all walks of life, with the possible exception of computer
professionals. These people aren't programmers because they want to,
but because it is part of their job description.
This does not make for good programmers.
Stig Hemmer,
Jack of a Few Trades.
> Have I been deluded on this point for years?
>
> If so, it's an interesting question what distinguishes programmers
> who are good at learning new languages from ones who aren't. Does it
> correlate with having learned at an early age? With early exposure
> to several different languages? Ability in other related areas
> (mathematics? natural languages?)?
>
> One small bunch of data points: so far as I can tell, most of the
> good programmers I know are good language learners too. They are
> also mostly (1) good all-round minds and (2) from mathematical
> or scientific backgrounds.
>
> --
> Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
> ················@pobox.com Cambridge University, England.
Rainer Joswig wrote:
> Tim Bradshaw wrote:
>
> > I do. People *hate* C++.
>
> But why are many big desktop applications written in C++?
>
This is a similar question to 'why do most people use MS windows on their pc
at home?' To get the look and feel of MicroTosh you buy Visual C++ with MFC.
C++ with MFC (with I truly hate with a long loathing passion) contains a
series of tools that would allow moderately a house-trained marmoset to
generate GUI applications to do things on a PC under MicroTosh propriatery
OS's.
As far as I know, (which isn't a whole lot), ANSI C++ has not been fully
implemented by anyone yet. Visual C++ with MFC contains some ANSI stuff but
there is also a large set of MicroTosh libraries that do things like the
things that are in the ANSI standard, just not as well. Unfortunately, the
marmoset GUI tools seem to use the MicroTosh and not the ANSI stuff.
I don't hate C++ as much as I could, but then again I live in MicroHell and
have never seen C++ yet.
:-) will
ps: Beware any library class that starts with C. Particulary CRecord.
Tim Bradshaw <···@tfeb.org> writes:
> I do. People *hate* C++. They use it because they perceive there is
> no alternative, but they loathe it. There are lots of horrors --
> spectacular compile times mean you spend most of your time in the
> coffee room; large OO programs with lots of pointers mean you
> basically need something like purify (at however many thousand dollars
> per seat per year) to get your code to run; the language is unstable
> and different compilers seldom implement the same subset, not even
> different versions of the same compiler. People doing large C++
> projects are living in hell, *and many of them know they are living in
> hell*.
[ Beware: Heavy (over-)generalizations ahead, so truth may be lost ;-) ]
Yes, C++ doesn't deliver, though in comparison to Java it is a
professional solution. The problem is, people would rather continue
to use unsuitable tools than face the plain facts. Ours is a *VERY*
conservative profession, where it often takes more than 20 years to
get rid of brain-damaged "solutions". This is not something new that
happened with C++ or Unix or DOS or Windows. The history of computing
is ripe with brain-damaged platforms and languages, that outlived
many non-brain-damaged platforms and languages. We might bemoan that
fact, and try to change things. But basing your business on the
premise that this will suddenly change seems to me a dead-certain
recipe for disaster.
That said, I think that the prospects of Dylan have to be judged
differently for Apple and Harlequin:
Apple quite possibly could have made Dylan a "success" on their
platform, since for them the economics are different: They own the
platform and especially the OS, and don't depend on the revenues from
development tools. So they could have pushed Dylan, via good
integration with the OS APIs, a number of applications written in
Dylan (with good Dylan interfaces), and probably some form of
user-visible use, like maybe scripting (though I'm not sure whether
Dylan would be suitable for that task), or the equivalent of CGI
"scripts".
Especially if this could have been targeted on one or more of Apple's
core markets, it might have gone down well with developers, and bound
them firmer to Apple's platform, which is good for Apple.
But this didn't happen, for a number of reasons, one of them probably
being Apple's business problems, which had to lead to quite radical
cuts.
The situation looks quite different, IMHO for a language seller
(which Harlequins language department arguably is), especially after
Apple ceased Dylan development:
- Dylan had to make money for Harlequin within a certain time-span.
To establish a new language on the market, you need _a long time_.
Take C++ for example, which had the benefit of being very compatible
with C code, the C mind-set, and all the C infrastructure (which
Dylan arguably wasn't): It took from 6 to 10 years to get C++ into
wide-spread use, and about the same time (+ 1 or 2 years) to start
making money of it. And C++ is considered to have had very fast
user acceptance. In this period of time, nearly anything can
happen, including new competitors, you going bust, and major shifts
in computing-trends.
So establishing a new language is a very risky venture, _if you
want to make money out of it_. So how come that new languages
do indeed get established? IMHO they either get established via
"free" implementations and user communities, or by being coupled
tightly to a platform (like PL/1 was on Multics).
Free implementations can come either from academia, research
organisations, or platform providers (i.e. hardware or OS firms).
Look at Java, which will probably never provide any noticeable direct
revenue to Sun, but which has reestablished Sun's platform, let
them enter the enterprise in non-engineering fields, and is being
used to break out of Microsoft's strangle-hold on the market.
User communities also only get really started after implementations
are available, which also played against Harlequin, who could only
deliver a Dylan implementation recently.
- As long as Apple was pushing Dylan, Harlequin might have had a
chance to profit from the Apple user community (should Apple have
succeeded in creating such), offering them the possibility of
porting their code to non-Mac platforms, and/or having a familiar
development language available when working on non-Mac projects.
Had CMU also continued it's work on Dylan, there would have been
three implementations (albeit on non-overlapping platforms), so
that wouldn't have looked so threatening to potential customers,
either.
Also Apple's engagement would have meant that a bit of money might
have been spent on promotion, books, application development,
standardization efforts, etc., which would have been beneficial to
Harlequin, too.
All of that collapsed of course with the demise of Apple's Dylan
efforts. That would have been the time to get out and cut your
losses. Sure, the Dylan community would have been furious, and
rightly so. No nice thing to do, but IMHO a necessary move.
- Harlequin should have waited for Apple to establish a viable user
community. From that it would have been possible to judge user
acceptance and user profiles, which would have made it possible for
Harlequin to judge the momentum and direction of the market and act
accordingly.
You don't have to be among the very first to make money in the
language business. Indeed, from the evidence I see, you are at a
huge disadvantage being among the first to implement a language.
Look at Borland, which in it's heyday (most of the eighties, and the
beginning of the 90s) knew how to earn money by selling development
environments. Never were they the first to implement a language
(though they quite often made heavy changes to the languages they
implemented). They took Pascal to the micros[1], when it was clear
that Pascal already had a viable user community, which was aching to
get a usable Pascal implementation for their micro-computers. They
sold C late, and weren't among the first to implement C++ (even
commercially) by a safe margin. The one thing they did sell at an
early stage (at least judged by mainstream standards), was
Turbo Prolog (which they claimed to be, but wasn't really Prolog),
which flopped heavily, at least for Borland.
Note that all of this doesn't say a thing about the technical merit of
Dylan, or indeed about the presence or absence of a potential customer
base for a Dylan product. These things are IMHO often quite
irrelevant to the commercial success or viability of a product.
Regs, Pierre.
Footnotes:
[1] And weren't the first to do this, either. At the time, UCSD
Pascal had been available for some time, though this had the slight
problem of being it's own OS (and VM) as well, which posed slight
delivery problems.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
In article <··············@orion.dent.isdn.cs.tu-berlin.de>, ····@acm.org (Pierre R. Mai) wrote:
> Footnotes:
> [1] And weren't the first to do this, either. At the time, UCSD
> Pascal had been available for some time, though this had the slight
> problem of being it's own OS (and VM) as well, which posed slight
> delivery problems.
Yep, at that time applications were booted.
The Apple II often booted into these applications.
For example one spreadsheet based on Apple Pascal
(-> UCSD) was such a case. If your applications
were sufficiently important (spreadsheets were new and
exciting), it was no problem selling them using
this approach - at that time, which was early 198x.
--
Please remove dot nospamski dot from the return address.
----------
In article <···············@tfeb.org>, Tim Bradshaw <···@tfeb.org> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
>> In article <···············@world.std.com>, Kent M Pitman
> <······@world.std.com> wrote:
>>
>> > (2) People were disenchanted with C++ and needed an alternative.
>>
>> I don't buy it.
>>
>
> I do. People *hate* C++. They use it because they perceive there is
> no alternative, but they loathe it. There are lots of horrors --
> spectacular compile times mean you spend most of your time in the
> coffee room; large OO programs with lots of pointers mean you
> basically need something like purify (at however many thousand dollars
> per seat per year) to get your code to run; the language is unstable
> and different compilers seldom implement the same subset, not even
> different versions of the same compiler. People doing large C++
> projects are living in hell, *and many of them know they are living in
> hell*.
>
> I don't understand even slightly why even people who know they are in
> it can't get out of this spiral of death, but it does seem to be
> genuinely hard. Partly at least I think it's to do with the fact that
> window-system based programs really became common about the time C++
> became common, so these really enormous, C/C++-specific APIs appeared
> to things like Windows which serve to bind people into the language.
> Java certainly has not been a realistic option for much of its
> lifetime because performance was often really bad (I mean 100s of
> times worse than C/C++ for typical apps, not some silly factor of 2
> like Lisp), and the APIs are even less stable than C++'s, and equally
> enormous. Even so people are leaping all over Java.
>
> So really, I don't understand what is causing things to happen, but I
> can see that it must have been easy to think that there was an
> opportunity when Dylan was being thought about: the large C++
> disasters now in full view were just emerging, Lisp was unfortunately
> still too tainted by 80s AI hype to consider, so it must have seemed
> like a golden opportunity for a cleaned-up Lisp in slight disguise.
>
> Of course a lot of the large software-project catastrophes are just
> plain failures of management. But no one wants to admit that they
> might have fouled up, so they will always be searching for the next
> cool thing to avoid having to think bad thoughts about themselves.
> Exactly the same people who were saying `my project is no good because
> it is in Lisp, we must reimplement in C++' about 10 years ago are no
> saying `my project is no good because it is in C++, we must
> reimplement in Java' now. I know some of these people, and they
> really do say this! It takes real strength of character to admit that
> actually your project is going wrong because it has not been managed
> right, and that what you actually need to do is pick a stable,
> non-crippling language (Lisp is a really good candidate now!) which is
> adequate if not perfect, and *stick to it* and concentrate on getting
> things right.
>
> Or something
>
> --tim
>
As much as I want to believe that management is wrong for project
failures, it is the programmers job to either stand up and take
responsibility for the project as well or just get out of the way
(resign, go find someplace where it is a perfect land where failures
don't exist) and let someone come in that will take responsibility
for the failure/success of a project/analysis/design/implementation.
Too often programmers see the fault being the project manager. I have
been on both sides, and it is all too often all peoples fault. Management
not listening to the programmers and such, and the rest not letting
management know in a concrete way how things are not going to work.
It is a team, not a one side and the other. People need to step
up and take responsability for success and failures. Language as I
would agree with you has NOTHING to do with this, yet is does have
something to do with a successful deliverable which is maintainable.
I have not seen C++ projects that are highly maintainable, yet I have
seen ST, ObjC, CL projects that are... Just my personal experiences
over the past 16 years.
\t
In article <···············@world.std.com>, ······@world.std.com
says...
> No firm theories here. Just thinking aloud...
Nice thoughts. Thanks.
--
Please note: my email address is munged; You can never browse enough
"There are no limits." -- ad copy for Hellraiser
In article <·······················@pbg3.lavielle.com>,
······@lavielle.com says...
> I'm a proponent of the "no apologies" position and additionally
> I think the Lisp community in general should better stop
> wasting time supporting hopeless projects (inventing the next
> great language, bringing Lisp features to C/C++/Java/Eiffel/..., ...)
> which have no benefit to Lisp itself.
Don't forgewt MLWorks. Perhaps they should drop that, too? I don't
know how long it took to develop, or how much that cost Harlequin.
I'm waiting for them to announce details of their road plan. We know
what they did in the past, but I'm not going to judge what they'll do
in the future until I have some details.
When were Harlequin interested in C/C++/Java/Eiffel? I think I missed
that press release.
--
Remove insect from address | You can never browse enough
will write code that writes code that writes code for food
In article <··························@news.demon.co.uk>, ···@wildcard.butterfly.demon.co.uk (Martin Rodgers) wrote:
> I'm waiting for them to announce details of their road plan. We know
> what they did in the past, but I'm not going to judge what they'll do
> in the future until I have some details.
Actually, *I* don't care about especially your opinions *that* much.
I haven't seen much (besides misinformation) from you that was
of any apparent value for *me* - in the last *years*.
> When were Harlequin interested in C/C++/Java/Eiffel? I think I missed
> that press release.
I don't think you got my posting.
In article <·······················@pbg3.lavielle.com>,
······@lavielle.com says...
> Actually, *I* don't care about especially your opinions *that* much.
> I haven't seen much (besides misinformation) from you that was
> of any apparent value for *me* - in the last *years*.
Misinformation? Where? I'm not suprised that you find no value in
anything I say, because I'm not so anti-Dylan as you. Perhaps because
I'm questioning the need to promote Lisp at the expense of another
language. It's unnecessary, as I explain below.
> > When were Harlequin interested in C/C++/Java/Eiffel? I think I missed
> > that press release.
>
> I don't think you got my posting.
Was your posting just an anti-Dylan argument, then? Fair enough, but
why stop with Dylan - Harlequin have also "wasted" time and effor on
ML. If you're advocating a pure Lisp policy at Harlequin, I don't have
a problem with that. It might be a wise business plan at this point!
Thanks for your abuse, BTW. I'll find it with the abuse I get from
Lisp skeptics. The "no apologises" attitude is fine with me, as I've
been using it for years. It makes life more interesting.
Now, getting back to Harlequin...What have they been doing wrong that
Franz have been doing right? A right action might be focusing solely
on Lisp. One of Harlquin's wrong actions is hardly adding support for
a few Windows features, like DLLs, because both ISTR vendors have done
that. (In fact, I recall asking them about it a few years ago, and
they both expressed interest.) What else is left? Dylan? ML?
While there may well be technical objections to Dylan, we're talking
about the success of a single company. That means commercial rather
than _technical_ success. This is why I'd like some details of their
road plan. Which products were the "white elephants"? I doubt that it
was LispWorks and Liquid CL.
It's a money issue. After all, it was 18M Euros that saved Harlequin.
That's why I question the relevance of C/C++/Java/Eiffel features.
Dylan could be a white elephant even if it was another CL system, as
Harlequin already had one, and now have two.
If your argument is merely that they've spread they're resources too
thinly, then it might also be an argument for ditching Liquid CLm but
only if it fails to make enough money to pay for itself. Dylan has a
major disadvantage because it's a new language, and therefore costs
more even before being released. Liquid CL has a head start.
MLWorks is a pure loser. Education is increasingly moving over to C++.
Harlequin could hardly have predicted that a few years ago, but they
might be reconsider it today.
However, I've not seen the sales figures for these products. I may be
completely wrong, and MLWorks could be their biggest seller. So could
DylanWorks, but I doubt it. You seem very certain, but you may have
seen their sales figures. OTOH, you may just be making an informed
guess. I hesitate to go that far, but I'll admit that it's plausible.
Of course, that's also what I'd _like_ to believe. Yes, there's a
simple answer: ditch every development tool but LispWorks and Liquid
CL, and all will be golden, or at least as golden as Franz's pile.
What Harlequin's business new plan will actually be remains to be
seen. I look for to it, whatever it'll be, with great anticipation.
--
Remove insect from address | You can never browse enough
will write code that writes code that writes code for food
In article <··························@news.demon.co.uk>, ···@wildcard.butterfly.demon.co.uk (Martin Rodgers) wrote:
> Misinformation? Where?
In your postings, on your website, ...
> simple answer: ditch every development tool but LispWorks and Liquid
**My** business plan would be to concentrate on LispWorks.
But I'm biased.
MLWorks is sufficiently different and interesting to justify a close
look, whether it is possible to make money with it.
In article <·······················@pbg3.lavielle.com>,
······@lavielle.com says...
> > Misinformation? Where?
>
> In your postings, on your website, ...
That's several hundred pages, many of which have not been maintained
or even accessible from the root page for about half a year.
As for my postings, which ones? I know I've said things that you may
disagree with. I have a bad habit of making a distinction between the
choices that programmers would make and the demands of employment.
ISTR a Kent Pitman posting that made a similar distinction. Of course,
he expressed it much better than I can.
In this thread we're discussing the fortune of Harlequin. Recent
events have demonstrated what forces are at work. While technical and
political issues may influence the nature of a language, market
forces determine the fortunes of a _company_. Is that misinformation?
If it is, then it's a popular misconception. Even here.
Money talks. 18M Euros have spoken. For that we can be thankful.
> > simple answer: ditch every development tool but LispWorks and Liquid
>
> **My** business plan would be to concentrate on LispWorks.
> But I'm biased.
So am I. I'd do the same thing, but I write code, not run a business.
If we can run a business like Harelquin's, then our experience and
opinions may be of interest. Otherwise, it's just opinion.
Still, armchair management can be fun. ;)
> MLWorks is sufficiently different and interesting to justify a close
> look, whether it is possible to make money with it.
Whether it is possible to make money with it...This is what I wonder.
Even if education was not shifting toward C++, the student version of
MLWorks would likely be used, and that's free. The docs cost $40,
which should help.
DylanWorks may be sufficiently different and interesting to justify
a close look at the sales figures. They might tell us whether it is
possible to make money with it.
--
Remove insect from address | You can never browse enough
will write code that writes code that writes code for food
In article <··························@news.demon.co.uk>, ···@wildcard.butterfly.demon.co.uk (Martin Rodgers) wrote:
> > > simple answer: ditch every development tool but LispWorks and Liquid
> >
> > **My** business plan would be to concentrate on LispWorks.
> > But I'm biased.
>
> So am I. I'd do the same thing, but I write code, not run a business.
But you are not writing Lisp code. What are you talking about?
> If we can run a business like Harelquin's, then our experience and
> opinions may be of interest. Otherwise, it's just opinion.
The difference is, I'm responsible for a small team
of people. And in the company I'm working we are writing
Lisp code (not exclusively). We are selling Lisp apps. We use Lisp
as an internal tool. We are currently finishing a relaunch
>10000 line SIOD web app which now earned almost
DM 100000. We are also currently moving a web log
tool to a server for a German internet carrier, which is on our
side written in CL and Scheme.
What have you done with Lisp?
All you are presenting is hot air.
> DylanWorks may be sufficiently different and interesting to justify
> a close look at the sales figures. They might tell us whether it is
> possible to make money with it.
But they didn't. Several years with a staff of let's say, twenty
or more developers. How many years would you need
selling, say, $300 boxes to get that back?
Rainer Joswig wrote:
[MArtin Rodgers:]
>> DylanWorks may be sufficiently different and interesting to justify
>> a close look at the sales figures. They might tell us whether it is
>> possible to make money with it.
>
> But they didn't. Several years with a staff of let's say, twenty
> or more developers. How many years would you need
> selling, say, $300 boxes to get that back?
That's not the question. The money spent on Dylan has already
been spent. The question is whether Harlequin / Global Graphics
*now* stand to make more money by selling Dylan or by dropping it.
I'd guess that dropping it is more likely to be profitable, but
that's not obvious; not, at any rate, anything like as obvious
as it is that the decision to develop a Dylan implementation
won't ever turn out profitable on balance.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
················@pobox.com Cambridge University, England.
In article <··············@g.pet.cam.ac.uk>, Gareth McCaughan <················@pobox.com> wrote:
> > But they didn't. Several years with a staff of let's say, twenty
> > or more developers. How many years would you need
> > selling, say, $300 boxes to get that back?
>
> That's not the question.
That *was* the question.
And it's still a question, unless you don't need staff
anymore.
> I'd guess that dropping it is more likely to be profitable, but
> that's not obvious;
I wouldn't invest money on "likely" or "obvious".
I would want to see a business plan, customers,
potential customers, investment plan, project plans,
marketing actions, ... I would take a close look at
the technology and its chances on the market. What are the goals?
Who are the customers? What are the applications...
Well, unless you can "burn" some millions of dollars.
On Tue, 13 Jul 1999 23:35:03 +0200, Rainer Joswig
<······@lavielle.com> wrote:
>In article <··············@g.pet.cam.ac.uk>, Gareth McCaughan
><················@pobox.com> wrote:
>
>> > But they didn't. Several years with a staff of let's say, twenty
>> > or more developers. How many years would you need
>> > selling, say, $300 boxes to get that back?
>>
>> That's not the question.
>
>That *was* the question.
>
>And it's still a question, unless you don't need staff
>anymore.
Elaborating a bit...
It might have taken a team of 40 developers to turn it into what it is
today. The money paid out to those developers is a "sunk cost," and
may safely be ignored today for decisionmaking purposes.
But in order for Harlequin Dylan to *continue* to represent a
commercially viable product, there need to be some developers paid to
do things like:
- Fixing bugs
- Porting it to relevant platforms/architectures
- Improving the development environment and such.
This may take a "team of 5," rather than 40. It is nonetheless
necessary to justify paying for that "team of 5."
>> I'd guess that dropping it is more likely to be profitable, but
>> that's not obvious;
>
>I wouldn't invest money on "likely" or "obvious".
>I would want to see a business plan, customers,
>potential customers, investment plan, project plans,
>marketing actions, ... I would take a close look at
>the technology and its chances on the market. What are the goals?
>Who are the customers? What are the applications...
>
>Well, unless you can "burn" some millions of dollars.
--
Where do you want to go, toady?
········@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
In article <······················@news2.giganews.com>, ········@hex.net wrote:
> >And it's still a question, unless you don't need staff
> >anymore.
>
> Elaborating a bit...
>
> It might have taken a team of 40 developers to turn it into what it is
> today. The money paid out to those developers is a "sunk cost," and
> may safely be ignored today for decisionmaking purposes.
>
> But in order for Harlequin Dylan to *continue* to represent a
> commercially viable product, there need to be some developers paid to
> do things like:
> - Fixing bugs
> - Porting it to relevant platforms/architectures
> - Improving the development environment and such.
>
> This may take a "team of 5," rather than 40.
Given that the language hasn't that much libraries
and it is still hard to interface to C++, I guess
more people would be needed. I won't expect
that the product is in such a state that you
could put it in "maintenance mode" - like
some Lisp vendors do. Instead when trying to
compete on the Windows market you have to track
the latest developments, tools and libraries of
companies like Microsoft, Inprise, IBM, SUN, ...
There is really tough competition.
······@lavielle.com (Rainer Joswig) writes:
> Given that the language hasn't that much libraries
> and it is still hard to interface to C++,
Why do you think it should be necessary to interface to C++? How easy
is Lisp to interface to C++?
I have no problem calling C++ code from my Dylan code and vice versa
by using 'C' functions, COM or CORBA.
> Instead when trying to compete on the Windows market you have to
> track the latest developments, tools and libraries of companies like
> Microsoft, Inprise, IBM, SUN, ... There is really tough
> competition.
I don't disagree with you here - the competition is tough. The
Harlequin Dylan 2.0 beta is an excellent product and I don't think the
release version will have any problem if compared to the 'competition'.
Chris.
In article <··············@ihug.co.nz>, Chris Double <···@ihug.co.nz> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > Given that the language hasn't that much libraries
> > and it is still hard to interface to C++,
>
> Why do you think it should be necessary to interface to C++?
Because C++ is the dominant application development language
in certain areas and some important libraries are
written in C++.
> How easy is Lisp to interface to C++?
Difficult. But this was not my point - I'm not comparing
Dylan with Lisp, since Lisp is serving different
markets, has a different view of the worls and is not really
a mainstream language (and not even trying that hard) that competes with
Visual Basic, Delphi (whatever it is called now), C++ or Java.
> I have no problem calling C++ code from my Dylan code and vice versa
> by using 'C' functions, COM or CORBA.
There are varying degrees of "interfacing".
Can you write a class in X (enter you favorite language here),
let it be the subclass of a C++ class and be subclassed
by C++? Who has an answer to that?
How do you get into the template infrastructure of C++?
How about interfacing to ugly things like MFC?
> I don't disagree with you here - the competition is tough. The
> Harlequin Dylan 2.0 beta is an excellent product and I don't think the
> release version will have any problem if compared to the 'competition'.
Good to hear.
······@lavielle.com (Rainer Joswig) writes:
> Because C++ is the dominant application development language
> in certain areas and some important libraries are
> written in C++.
I have to confess that I've come across very few libraries written in
C++. Most of the ones I've had to interface with have been in
'C'.
I've seen a couple pop up lately though. I've wanted to use Smile
(http://www2.sis.pitt.edu/~genie) and CrstalSpace
(http://crystal.linuxgames.com/) from other languages but they are C++
frameworks.
> Difficult. But this was not my point - I'm not comparing
> Dylan with Lisp, since Lisp is serving different
> markets, has a different view of the worls and is not really
> a mainstream language (and not even trying that hard) that competes with
> Visual Basic, Delphi (whatever it is called now), C++ or Java.
I don't think any of those languages interface to C++ well either (if
at all).
> Can you write a class in X (enter you favorite language here),
> let it be the subclass of a C++ class and be subclassed
> by C++? Who has an answer to that?
No I can't. I don't think anyone has an answer to it due to the number
of different ways C++ compilers can organise the binary layout of the
classes. Without CORBA, COM or the like there is not much chance of
being able to do this sort of thing.
> How do you get into the template infrastructure of C++?
Ditto.
> How about interfacing to ugly things like MFC?
The windows version of Python manages this if I remember correctly. My
hat is off too them for managing it!
Chris.
In article <··············@ihug.co.nz>, Chris Double <···@ihug.co.nz> wrote:
> I don't think any of those languages interface to C++ well either (if
> at all).
I'd expect that you are right.
* Rainer Joswig
|
| How about interfacing to ugly things like MFC?
* Chris Double
|
| The windows version of Python manages this if I remember correctly.
You do remember correctly. This is one of the things I like the most
about Python, compared to languages like Java and Common Lisp: it
interfaces to everything, including, but not limited to, CORBA, COM,
Gtk, ActiveX, MFC, XML-RPC, XML, most IETF network protocols, SGML,
Java, C/C++, Qt, ASP, Apache, tcl and Perl (through Minotaur) and even
things like IRIX-specific audio interfaces.
Most languages can do this, but the ease with which you can do it in
Python impresses me and makes it a very attractive glue language.
| My hat is off too them for managing it!
Mine as well. :)
--Lars M.
In article <··············@ifi.uio.no>,
Lars Marius Garshol <······@ifi.uio.no> wrote:
>
>* Rainer Joswig
>|
>| How about interfacing to ugly things like MFC?
>
>* Chris Double
>|
>| The windows version of Python manages this if I remember correctly.
>
>You do remember correctly. This is one of the things I like the most
>about Python, compared to languages like Java and Common Lisp: it
>interfaces to everything, including, but not limited to, CORBA, COM,
>Gtk, ActiveX, MFC, XML-RPC, XML, most IETF network protocols, SGML,
>Java, C/C++, Qt, ASP, Apache, tcl and Perl (through Minotaur) and even
>things like IRIX-specific audio interfaces.
>
>Most languages can do this, but the ease with which you can do it in
>Python impresses me and makes it a very attractive glue language.
>
>| My hat is off too them for managing it!
>
>Mine as well. :)
>
>--Lars M.
Lars is right (as usual). Actually, compared to *any-
thing*, Python seems to arrive first on the interfacing
scene. This is interesting; Tcl and Lua emphasize ease
of embedding and extensibility in their design, and Perl
has hordes of interfacing worker bees, but a consistent
pattern emerges that Python does at least as well as any
other language in achieving connection to the latest
toolkits-protocols-... It's an interesting story, even
though I don't yet understand it.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
······@NeoSoft.com +1 281 996 8546 FAX
In article <·················@nmia.o_r_g>,
David Hanley <····@nmia.o_r_g> wrote:
.
.
.
>> scene. This is interesting; Tcl and Lua emphasize ease
>> of embedding and extensibility in their design, and Perl
>> has hordes of interfacing worker bees, but a consistent
>> pattern emerges that Python does at least as well as any
>> other language in achieving connection to the latest
>> toolkits-protocols-... It's an interesting story, even
>> though I don't yet understand it.
>
>Hmmm, maybe the right approach is to get lisp to talk
>to python, then, eh?
>
>dave
>
I suspect you are cheerfully mocking the extremes such an
approach might reach. In any case, the reality is that
serious programmers find such extremes useful! With Tcl,
for example, the pressure to do solid COM interfaces has
largely dissipated because of the availability of Robin
Becker's Python server, which supplies these and other
connections. Coincidentally, I report today on several
related projects of cross-language co-operation in <URL:
http://www.sunworld.com/swol-07-1999/swol-07-regex.html#2>.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
······@NeoSoft.com +1 281 996 8546 FAX
······@Starbase.NeoSoft.COM (Cameron Laird) wrote:
>Coincidentally, I report today on several
>related projects of cross-language co-operation in <URL:
>http://www.sunworld.com/swol-07-1999/swol-07-regex.html#2>.
this article unfortunately has several broken links:
http://starbase.neosoft.com/~claird/comp.object.corba/COM.html
-> http://starbase.neosoft.com/~claird/comp.object.corba/CORBA.html
http://starbase.neosoft.com/~claird/comp.protocols.misc/COM.html
-> ??
--
Reini
In article <··················@judy.x-ray.local>,
Reini Urban <······@sbox.tu-graz.ac.at> wrote:
>······@Starbase.NeoSoft.COM (Cameron Laird) wrote:
>>Coincidentally, I report today on several
>>related projects of cross-language co-operation in <URL:
>>http://www.sunworld.com/swol-07-1999/swol-07-regex.html#2>.
>
>this article unfortunately has several broken links:
>
>http://starbase.neosoft.com/~claird/comp.object.corba/COM.html
>-> http://starbase.neosoft.com/~claird/comp.object.corba/CORBA.html
>
>http://starbase.neosoft.com/~claird/comp.protocols.misc/COM.html
>-> ??
>--
>Reini
My apologies for these errors, and thanks to you for spotting them.
The COM.html URL was indeed empty; I've begun to populate it. The
CORBA.html page has been available all along, but at <URL:http://
starbase.neosoft.com/~claird/comp.object.corba/CORBA.html>, as you
clevely discovered. I expect to correct the reference in the
*SunWorld* article tomorrow.
Incidentally, I have ancestors surnamed Urban who apparently were
in Alsace in the early 19th century. That seems quite far from
Graz.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
······@NeoSoft.com +1 281 996 8546 FAX
Rainer Joswig wrote:
> In article <··············@ihug.co.nz>, Chris Double <···@ihug.co.nz> wrote:
>
> > I have no problem calling C++ code from my Dylan code and vice versa
> > by using 'C' functions, COM or CORBA.
That doesn't work then you use a dozen C++ libraries in a "real-time" app (3D,
MIDI, audio, video, sensors..).
This was the latest Harlequin attitude. Their C++ interface was deprecated
(that's the ONLY
reason I chose Harlequin over ACL). Their CAPI is proprietary (and
unimaginative). I'd never use that. With Franz as the leader, and given the
composition of the Lisp market, focusing on an IDE always seemed wrong to me. To
be seriously considered, you have to provide machinery that is better in some
sense, be it
C++ interfacing, CLOS compilation, etc. [At the time, I run some benchmarks, and
Harlequin was faster
in just a couple of CLOS cases, but it seemed that nontrivial dispatching would
dominate my app. Most of the time ACL won, but C++ overrode].
> Can you write a class in X (enter you favorite language here),let it be the
> subclass of a C++ class and be subclassed by C++? Who has an answer to that?
With Lispworks, you could write C++ subclasses in CLOS. The reverse was not
possible, but now that's something I don't care about.
> How do you get into the template infrastructure of C++?
You couldn't do that (neither in ILOG Talk). That's certainly a must.
> How about interfacing to ugly things like MFC?
Isn't the above enough? [I have a personal ban on MFC, so I don't know].
--------------------------------------------------------------------------------------------
Everybody is talking about `sunken Dylan cost'. Isn't it obvious that just
providing
a lisp syntax (cheap to do) would make some Lispers buy Dylan when CLOS doesn't
cut it?
(I imagine Dylan runs faster than CL).
Rainer Joswig wrote:
>>> But they didn't. Several years with a staff of let's say, twenty
>>> or more developers. How many years would you need
>>> selling, say, $300 boxes to get that back?
>>
>> That's not the question.
>
> That *was* the question.
It was the question N years ago, when Harlequin started working
on Dylan. I thought we were discussing what is likely to, or
should, happen now.
> And it's still a question, unless you don't need staff
> anymore.
<guess type="wild">It would probably be possible to sell DylanWorks
without a lot of staff working on it.</guess> In any case, it's
not the *same* question. What matters to Global Graphics isn't
how many years it will take to recoup Harlequin's expenditure on
Dylan; it's whether selling Dylan will come out net positive or
net negative for them. The answer to that doesn't depend on whether
getting the product to where it is now cost $100 or $100 million.
>> I'd guess that dropping it is more likely to be profitable, but
>> that's not obvious;
>
> I wouldn't invest money on "likely" or "obvious".
> I would want to see a business plan, customers,
> potential customers, investment plan, project plans,
> marketing actions, ... I would take a close look at
> the technology and its chances on the market. What are the goals?
> Who are the customers? What are the applications...
Obviously. If this translates as "your post was useless because
it didn't contain a business plan and an analysis of the market",
then I'm sorry. I'm not competent to produce such things, and my
comment wasn't intended to be a prescription for Harlequin's
future.
> Well, unless you can "burn" some millions of dollars.
Me? I can spend weeks deciding whether to spend $20, never mind
millions.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
················@pobox.com Cambridge University, England.
In article <··············@g.pet.cam.ac.uk>, Gareth McCaughan <················@pobox.com> wrote:
> <guess type="wild">It would probably be possible to sell DylanWorks
> without a lot of staff working on it.</guess>
On the highly competetive Windows market? Where Microsoft
changes APIs like other people their underwear (or was it something
different?).
> not the *same* question. What matters to Global Graphics isn't
> how many years it will take to recoup Harlequin's expenditure on
> Dylan; it's whether selling Dylan will come out net positive or
> net negative for them. The answer to that doesn't depend on whether
> getting the product to where it is now cost $100 or $100 million.
- well, my guess is: Dylan doesn't sell already
- so the question is: how much more money
do "I" have to invest to make it sellable
- for that, looking at the past expenses
for moving Dylan from state A to state B
is highly interesting
> > I wouldn't invest money on "likely" or "obvious".
> > I would want to see a business plan, customers,
> > potential customers, investment plan, project plans,
> > marketing actions, ... I would take a close look at
> > the technology and its chances on the market. What are the goals?
> > Who are the customers? What are the applications...
>
> Obviously. If this translates as "your post was useless because
> it didn't contain a business plan and an analysis of the market",
> then I'm sorry.
It translates to: if I were in management I would take
my ego or some vague idea as a business plan.
And in this special case I can't see the business plan
- maybe someone can give me an idea.
> Me? I can spend weeks deciding whether to spend $20, never mind
> millions.
;-) maybe it's cheaper to just spend the $20 - instead of spending
the weeks thinking about it?
In article <·······················@194.163.195.67>, ······@lavielle.com (Rainer Joswig) wrote:
> > Obviously. If this translates as "your post was useless because
> > it didn't contain a business plan and an analysis of the market",
> > then I'm sorry.
>
> It translates to: if I were in management I would take
> my ego or some vague idea as a business plan.
Sigh, to late and not my language. Better version: ;-)
It translates to: if I were in management I wouldn't take
my ego or some vague idea as a business plan.
Yep, this sentence makes more sense. ;-)
······@lavielle.com (Rainer Joswig) writes:
> - well, my guess is: Dylan doesn't sell already
But that's just your guess. I can guess equally as well that Harlequin
have shipped a number of Harlequin Dylan units. The only people who
know are Harlequin and/or the people who bought the company. It's
useless speculating whether Dylan was to blame for the company's
hardship.
I don't think you can blame a language for their problems anyway. To
say that 'Dylan caused Harlequin to go bankrupt' is nonsensical when
we don't know the facts.
Chris.
In article <··············@ihug.co.nz>, Chris Double <···@ihug.co.nz> wrote:
> > - well, my guess is: Dylan doesn't sell already
>
> But that's just your guess. I can guess equally as well that Harlequin
> have shipped a number of Harlequin Dylan units. The only people who
> know are Harlequin and/or the people who bought the company.
Nobody has sofar corrected me on this issue. Even not from
Harlequin.
> It's
> useless speculating whether Dylan was to blame for the company's
> hardship.
For you maybe, not for me. I want learn something from that.
> I don't think you can blame a language for their problems anyway. To
> say that 'Dylan caused Harlequin to go bankrupt' is nonsensical when
> we don't know the facts.
But you saw the numbers in the press release, didn't you?
Take that with the information that the Lisp business
was profitable (that's what I've heard).
I guess it's obvious where the money went - the millions
that went into the R&D.
Again from the press release:
http://www.glographics.com/pressrelease15.htm
---
...
Harlequin was forced into receivership because of massive R&D
investments for several years in software for Information
Management and Software Tools applications. In the fiscal
year ended March 31, 1999, Harlequin spent an estimated 19.5
million Euro on these projects, which generated only 4.2
million Euro in revenue. The DP&P products were profitable
with estimated EBIT of 5.2 million Euro on sales of 21
million Euro. The continuous cash drain from the development
of Information Management and Software Tools applications
ultimately resulted in the receivership end of June.
...
Harlequin also provides a wide range of other software
development tools. They are mostly used for internal
development support and represent only 1-2% of sales.
...
---
Even if I wouldn't believe this naively, it is quite clear, isn't it?
······@lavielle.com (Rainer Joswig) writes:
> > I don't think you can blame a language for their problems anyway. To
> > say that 'Dylan caused Harlequin to go bankrupt' is nonsensical when
> > we don't know the facts.
>
> But you saw the numbers in the press release, didn't you?
I hadn't seen the page you mentioned - just snippets posted by various
people on the newsgroups. Thanks for the link.
> I guess it's obvious where the money went - the millions
> that went into the R&D.
Quite possibly. I can see that there must be a huge cost involved in
developing products like Dylan and ML - languages that are not
mainstream but still involve a reasonably large number of programmers
over a number of months/years. At the selling cost of Dylan (I think
HD 1.2 Enterprise cost me about $300 or so to upgrade from 1.1) it
would take a while to recoup that sort of investment unless it was
being used heavily internally.
But I have to say that I like the Harlequin Dylan product and the
Dylan language. I've used it in a number of projects now and I've
found my productivity to be significantly better than other language
products I've used. Dylan provides me with a nice mix of infix
familiarity (C++ background mainly), object oriented libraries, ease
of re-use (the 'every library is in a DLL' for distribution is great)
and the COM and Corba support is excellent. The ability to interface
with C has meant that there has not been much I've been unable to do
in Dylan that I couldn't do in C or C++. With Gwydion Dylan coming
along nicely the prospects of cross platform programming (including
GUI via DUIM) at a reasonable cost is looking good.
It would disappoint me greatly to see such as wonderful product fall
by the wayside - although I can understand the business drivers if
that were to happen.
As a side point, it was the Dylan language that also introduced me to
LISP. I've written a number of programs using Roger Corman's Lisp on
the Windows platform quite successfully (where my measure of success
is people have downloaded the programs and run them without too many
problems - not exactly startling but hey, it's a start) - although my
Lisp code probably could be identified as coming from a C++ programmer
:-).
I occasionally find myself weighing up what product to use to develop
an application in - Lisp or Dylan. I usually choose Dylan if I want
the static delivery of executables and shared DLL libraries. Or if I
need COM, CORBA or the object model I come up with fits the Dylan
model naturally. The times I've used Lisp have been when I needed some
sort of end-user scripting support or a shell style add-on to the
application. Or the ability to patch the program during runtime.
I use C++ less and less as a result. So for me, Dylan has all but
replaced C++ and Lisp has become my other tool of choice as a result
of my introduction to Dylan. I wouldn't want to lose either tool.
Chris.
In article <··············@ihug.co.nz>, Chris Double <···@ihug.co.nz> wrote:
> Quite possibly. I can see that there must be a huge cost involved in
> developing products like Dylan and ML - languages that are not
> mainstream but still involve a reasonably large number of programmers
> over a number of months/years. At the selling cost of Dylan (I think
> HD 1.2 Enterprise cost me about $300 or so to upgrade from 1.1) it
> would take a while to recoup that sort of investment unless it was
> being used heavily internally.
That's what I'm thinking, too.
> (lot's of stuff on why Dylan is useful)
Sounds like a reasonable position to me.
If people are interested in preserving Harlequin's Dylan
they might have to do something.
It would be very sad for all those people working
very hard for years on this and finally having a shipping
product, to see it going under.
Chris Double <···@ihug.co.nz> writes:
> I don't think you can blame a language for their problems anyway. To
> say that 'Dylan caused Harlequin to go bankrupt' is nonsensical when
> we don't know the facts.
When AI winter happened (where AI and Lisp fell into disrepute in the late
1980's), there were various precipitating events. One was that some
company--MCC I think?--blamed the failure of some major AI project on Lisp.
I remember thinking at the time: <sarcasm>oh, right--and if this had been
done in C++ the project would have been a fabulous success...</sarcasm>
Somehow I think it's that AI was oversold, and I don't think changing
the language to a more brittle--uh, sorry, I meant a more "conventional"
one--would have helped a lot.
I think similar reasoning applies to Harlequin. It made decisions a certain
way that led inevitably to this outcome, I think. Sort of like the focus
character in a Shakespearean tragedy. Saying "maybe <so-and-so> should have
picked a different day to do <whatever>" kind of misses the point of what
those plays are about. So too with Dylan, I think. It wasn't the investment
in Dylan. It was the process that led up to the decision to do that as well
as myriad other overlapping things without coordinating them in a way that
made structural sense to either the community or the business.
If Coke went bankrupt, people wouldn't be sitting around saying "maybe they
never should have done Diet Coke". There is a clear theory of WHY they did
two brands and everyone understands it. What precipitates this discussion at
all is that Harlequin never articulated (nor perhaps had) a clear theory of
why it was all over the map on these products. And it's not the being "all
over the map" that's the problem in such a case, it's the question of how
you can come to be there.
Kent M Pitman wrote:
> If Coke went bankrupt, people wouldn't be sitting around saying "maybe they
> never should have done Diet Coke". There is a clear theory of WHY they did
> two brands and everyone understands it. What precipitates this discussion at
> all is that Harlequin never articulated (nor perhaps had) a clear theory of
> why it was all over the map on these products. And it's not the being "all
> over the map" that's the problem in such a case, it's the question of how
> you can come to be there.
This is a very good point: a lot of work has shown that sucessful companies focus
on core strengths and do not stray too far from them, strive to anticipate and
exceed customers needs and are able to communicate a clear and coherent vision of
what they are about to their staff and customers [1].
Having followed this thread, and having seen dealings with Harlequin wrt their
RIP technology, I am not convinced that this is what Harlequin were about.
Admittedly this is business theory hog wash but it seems to ring true in this
case.
Best Regards,
:-) will
[1] see Tom Peters and Robert Waters in 'In Search of Excellence' or
'Competitiveness - How the Best UK Companies are Winning' by the Warwick Business
School.
* Kent M Pitman wrote:
> When AI winter happened (where AI and Lisp fell into disrepute in the late
> 1980's), there were various precipitating events. One was that some
> company--MCC I think?--blamed the failure of some major AI project on Lisp.
> I remember thinking at the time: <sarcasm>oh, right--and if this had been
> done in C++ the project would have been a fabulous success...</sarcasm>
> Somehow I think it's that AI was oversold, and I don't think changing
> the language to a more brittle--uh, sorry, I meant a more "conventional"
> one--would have helped a lot.
It was MCC, and there is a book around which *still* blames Lisp for
this disaster (although I think it a collection of earlier essays):
@Book{Glass:1998:SWR,
author = "Robert L. Glass",
title = "Software Runaways: lessons learned from massive
software project failures",
publisher = "Prentice-Hall",
year = "1998",
ISBN = "013673443-X",
}
There was a posting here a while ago describing it -- dejanews
probably has it -- and it looked like a classic software foulup with
no one talking to each other and impossible (datasets larger than
address space kind of thing) goals being set.
--tim
Tim Bradshaw wrote:
> It was MCC, and there is a book around which *still* blames Lisp for this
> disaster..
I'm sorry for my ignorance but what is the MCC?
:-) will
[what springs to mind is the Manchester Computing Centre or the Marlebone Cricket
Club ... ;-)]
William Deakin <·····@pindar.com> writes:
> Tim Bradshaw wrote:
>
> > It was MCC, and there is a book around which *still* blames Lisp for this
> > disaster..
>
> I'm sorry for my ignorance but what is the MCC?
>
I think MCC is the same thing which is now at mcc.com and is some kind
of research consortium of hi-tech companies. But I'm not sure if
that's the same MCC, and if it was I doubt that they'd admit to being
the same one.
--tim
(And they have yet *another* website which specifies fonts (Ariel)
which can *only* work on Windows machines, meaning I see the whole
thing in Courier. Do the people who design these things check them at
*all*? I guess not because they're `graphics professionals' who have
no bloody clue that the web is not just a fancy bit of electric paper.
At least it doesn't have the `?'-instead-of-quote bug, which I think
is what a different set of graphics professionals who live entirely on
Macs produce. Grrr.)
In article <···············@tfeb.org>,
Tim Bradshaw <···@tfeb.org> writes:
> William Deakin <·····@pindar.com> writes:
>
>> Tim Bradshaw wrote:
>>
>> > It was MCC, and there is a book around which *still* blames Lisp for this
>> > disaster..
>>
>> I'm sorry for my ignorance but what is the MCC?
>>
>
> I think MCC is the same thing which is now at mcc.com and is some kind
> of research consortium of hi-tech companies. But I'm not sure if
> that's the same MCC, and if it was I doubt that they'd admit to being
> the same one.
That's them!
Mike McDonald
·······@mikemac.com
Tim Bradshaw <···@tfeb.org> writes:
> At least it doesn't have the `?'-instead-of-quote bug, which I think
> is what a different set of graphics professionals who live entirely on
> Macs produce. Grrr.)
That?s a very annoying problem. :-)
I believe this a Microsoft thing. There was a thing on Slashdot about
this ages ago that Microsoft's web development tools don't respect
standards for character encoding so Unix Netscapes don't understand
the Microsoft encoding for #\' and thus put a #\? in its place to show
that it is clueless as to what the heck that character is. The
Slashdot article was mainly about a guy who wrote a Perl script called
"demoronizer" that cleaned up the Microsoft junk so that stuff
displays properly on Unix.
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
< Tim Bradshaw <···@tfeb.org> writes:
<
< > At least it doesn't have the `?'-instead-of-quote bug, which I think
< > is what a different set of graphics professionals who live entirely on
< > Macs produce. Grrr.)
<
< That?s a very annoying problem. :-)
<
< I believe this a Microsoft thing. There was a thing on Slashdot about
< this ages ago that Microsoft's web development tools don't respect
< standards for character encoding so Unix Netscapes don't understand
< the Microsoft encoding for #\' and thus put a #\? in its place to show
< that it is clueless as to what the heck that character is. The
< Slashdot article was mainly about a guy who wrote a Perl script called
< "demoronizer" that cleaned up the Microsoft junk so that stuff
< displays properly on Unix.
I think I fixed this problem (or one similiar to it) in emacs by
setting an entry in the disp-table.
(set-input-mode t nil t 7)
(standard-display-european t)
(aset standard-display-table ?\227 (vector 32))
(aset standard-display-table ?\223 (vector ?\"))
(aset standard-display-table ?\224 (vector ?\"))
Such a simple solution ensures the problem will continue to persist in
new software for hundreds of years to come.
Tim Bradshaw wrote:
> (And they have yet *another* website which specifies fonts (Ariel) which can
> *only* work on Windows machines, meaning I see the whole thing in Courier. Do
> the people who design these things check them at *all*? I guess not because
> they're `graphics professionals' who have no bloody clue that the web is not
> just a fancy bit of electric paper. At least it doesn't have the
> `?'-instead-of-quote bug, which I think is what a different set of graphics
> professionals who live entirely on Macs produce. Grrr.)
Talking about printing, do you know HOW much PAIN fonts causes us? There are at
least three incompatible font encodings and working with Mac, PC and UNIX, we
spend alot of time and money trying to sort this out. There is nothing like
having a print-run halted because the font that somebody created a piece of art
work on used an illegal font which wasn't installed on the film output device and
that sexy banner line at the top of the art work then appeared in nice friendly
courier at the printers.
Some people have nightmares about such things. As to cutting new fonts, I have a
friend who recently suggested that I nailed his hand to an oak table rather than
having to get him to create and test the three different versions we need.
Please, please, please don't ask me what I think about graphics professionals:
ones that use Macintosh or anything else such as using pototo letters dipped in
highly coloured emulsion paint.
Best Regards,
:-) Will
Rainer Joswig wrote:
[I said:]
>> Me? I can spend weeks deciding whether to spend $20, never mind
>> millions.
>
> ;-) maybe it's cheaper to just spend the $20 - instead of spending
> the weeks thinking about it?
Yes. It's a bug in my brain, that's all.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
················@pobox.com Cambridge University, England.
In article <·······················@194.163.195.67>,
······@lavielle.com says...
> I would want to see a business plan, customers,
> potential customers, investment plan, project plans,
> marketing actions, ...
Didn't I mention that I too would like to see a business plan?
;-)
--
Remove insect from address | You can never browse enough
will write code that writes code that writes code for food
On 13 Jul 1999 21:57:39 +0100, Gareth McCaughan
<················@pobox.com> wrote:
>Rainer Joswig wrote:
>[MArtin Rodgers:]
>>> DylanWorks may be sufficiently different and interesting to justify
>>> a close look at the sales figures. They might tell us whether it is
>>> possible to make money with it.
>>
>> But they didn't. Several years with a staff of let's say, twenty
>> or more developers. How many years would you need
>> selling, say, $300 boxes to get that back?
>
>That's not the question. The money spent on Dylan has already
>been spent. The question is whether Harlequin / Global Graphics
>*now* stand to make more money by selling Dylan or by dropping it.
The issue can be looked at from two perspectives:
a) What should Harlequin (a division of GG) do?
...Where the answers should *ignore* sunk costs.
b) What were they thinking when they sunk all that money into Dylan?
...Where the issue *is* relevant.
A postmortem should consider what was spent and why, and make sure
that future decisions don't drop money into a money pit foolishly.
It seems to me that Harlequin put the effort/money into Dylan as a
result of:
a) Thinking Apple was going to pursue it as an important technology,
and
b) Thinking Dylan might be a potential alternative to C++.
Those are both venues that involve enough quantities of systems as to
provide the potential for significant investments to "pay off."
>I'd guess that dropping it is more likely to be profitable, but
>that's not obvious; not, at any rate, anything like as obvious
>as it is that the decision to develop a Dylan implementation
>won't ever turn out profitable on balance.
Had Apple pursued Dylan, as seemed likely at one point, Harlequin's
position of being the primary provider of Dylan for other platforms
would have been a half decent place to be.
--
Strong language gets results. "The reloader is completely broken in
242" will open a lot more eyes than "The reloader doesn't load files
with intermixed spaces, asterisks, and <'s in their names that are
bigger than 64K". You can always say the latter in a later paragraph.
-- from the Symbolics Guidelines for Sending Mail
········@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
········@news.hex.net (Christopher Browne) writes:
> A postmortem should consider what was spent and why, and make sure
> that future decisions don't drop money into a money pit foolishly.
I doubt it requires anything this elaborate. It's extraodinarily
unlikely that the particular problems that happened thre will be
replicated any time soon anywhere else. It was a very unique company.
In a sense, part of its problem is that [I think] it was never out to
make money. It was privately held and getting rich was not Jo Marks'
goal. He just wanted to do the experiment of building a company on
his own terms, rather than on terms dictated to him by the world about
how things had to be. If you were there to see the internal workings
of it, you'd likely be surprised that it got as far as it did on the
theories of organization it used. Now that it's owned differently, I
suppose all of that theory of organization will change. Whether the
result of such change will be to make things better or worse, of
course, is still an open question. We live in interesting times.
In any case, I doubt anyone will rush to duplicate Jo's particular
style too closely, so I think a post mortem will not be as practical
as it sounds. Others in the future will probably just return to more
conventional ways of drop money into pits foolishly, and that will be that.
I also think none of this has much to do with Lisp, even though doubtless
many will paint this as a Lisp issue. Lisp, Dylan, and other matters just
got caught in the crossfire of some "business issues", I think.
All of the above is just my personal opinion and is not, as should be
obvious, meant to officially represent either Harlequin or Jo Marks; I
certainly have no official relationship with either of them at this
point.
In article <···············@world.std.com>, Kent M Pitman <······@world.std.com> wrote:
> In any case, I doubt anyone will rush to duplicate Jo's particular
> style too closely, so I think a post mortem will not be as practical
> as it sounds. Others in the future will probably just return to more
> conventional ways of drop money into pits foolishly, and that will be that.
From my view (as an outsider) Harlequin did a lot of things
wrong in their Lisp business.
Luckily they did a lot of things right, too. Take my
opinion not as something definitive, but here comes
*my* list of things which I always liked and which I'd like
to see preserved:
- They got a pricing structure which made sense.
- Their Lisp products are quite good and relatively complete.
- They have a usable graphical user interface, which made
good use of CLOS.
- Harlequin had a lot of very good Lisp wizards.
- Support.
- A Windows version.
- Support for CL-HTTP.
- A application delivery story.
- a web site with documentation (not to forget Kent's heroic
Hyperspec, thanks!).
- the Lisp business was profitable
- they helped the Lucid customers by providing support and
maintenance of LCL
> I also think none of this has much to do with Lisp, even though doubtless
> many will paint this as a Lisp issue. Lisp, Dylan, and other matters just
> got caught in the crossfire of some "business issues", I think.
I agree with that. Good that you mentioned it, thanks.
······@lavielle.com (Rainer Joswig) writes:
> - a web site with documentation (not to forget Kent's heroic
> Hyperspec, thanks!).
Funny to see this in the list of positives. The CLHS was ready for
roll-out nearly 1.5 years before it was finally rolled out. I was
ready to die over the fact that it was not seeing the light of day for
so long. Everyone at Harlequin was sworn to secrecy to keep someone
else from coming up with the idea while we/I waited interminably for
someone to decide it was worth putting out. When after a year of
having CLHS in-house at Hqn and everyone loving it, Steele's CLTL2
appeared online, I was ready to cry. I felt like I was going to look
like a mere copy-cat when I'd done my thing so long before.
I'd originally wanted to make a tool to attach to Harlequin-specific
doc because I'd never seen the web, but when I saw the web around the
time of the Jupiter comet stuff, I immediately thought "I should
retarget this to HTML". But that was so early that Harlequin had not
yet committed to the idea that the web was interesting and it took
forever to get people to see that it was important for us to be
visible there.
At the time CLHS was originally done, it was probably the biggest and
most tightly interlinked web document ever made, or competitive with,
because there were no automatic tools for making web documents then.
It would have been a fascination even for non-Lispers just as a
glimpse of what the web might become. By the time it was rolled out,
latex2html was already invented [not that I could have used it, of course,
since the ANSI CL document was in raw TeX, but it gives you a feeling
for the intervening maturation that had hapepened].
By that time, CLHS was very pedestrian in size and had lost all of
that original excitement it could have had outside of Lisp. It was
still practically useful to the community, and had undergone sme
tweaks in engineering (slightly more attractive icons, for example).
But in my mind, at least, and perhaps my mind only, it was far from a
success--because of how severely it had missed its proper time to market.
I was at the time sure someone else was going to do the same thing and
that when I left the company in disgust over having been scooped by
someone else, I would not even have anything to put on my resume for
the effort. Funny how different people's perspective can be on the
same event.
IMO Harlequin's big problem was not its failure to do good things, it
was its failure to try to sell the good things that it did. In that
light, too, it had good people, but if *I* had a company with that
many good people for that long, I think I could have done a lot better
with it. We kept hiring technologists. I was there from the time there
were only 8 employees in the US and about the time we had 25 I started
chanting the mantra "no more people that start projects [technologists],
only people that finish them [marketeers]". They did hire some marketeers,
but mostly they didn't apply them to Lisp.
None of this should be taken to say that Harlequin's got a bad product.
Just the opposite. It's like seeing someone who's very sharp and has lots
of useful skills not be able to find a job. You've got to market yourself
or people won't know. I hope whoever takes it over now will do a better
job of focusing on emphasizing the goodness of what they have, or sell it
again to someone who is willing to make that commitment.
- - - - -
Incidentally, a brief footnote on the matter of documentation: I've
found Harlequin doc is somewhat uneven in nature--some parts better
than others, but I've recently been using the CAPI a lot and I have to
say the doc on that is just great and a real pleasure to use. Filled
with good examples for the most part well-organized. (Helps partly
compensate for the fact that LispWorks desperately lacks the extremely
nice GUI that Franz has for developing windowed applications... :-)
Dunno who wrote it, but I've been looking for some place to
acknowledge the nice quality of this CAPI doc so wanted to squeeze
mention of it in here.
[Anyone who has not taken a look at the CAPI and who has "ordinary UI
needs" should have a look. CAPI's in all LW offerings, including the
free one. Franz has a similar kind of capability. Doc's not quite as
good, but it's more than compensated for by their super-whizzy cool-o
GUI-builder tool. I wish we could get these two companies to come up
with some sort of agreement on a common standard for the capabilities
that both really have. People desperately need some standard on
things like that and it's a pity when the functionality is really all
there, since that's not where they're competing marketwise. The right
place for competition on that is on "quality" (e.g., the availability
of the Franz GUI or the quality of the Hqn CAPI documentation). The
riht place for competition is not on the question of what kinds of
arguments are given to a make-button or draw-line kind of operation...
Alas. Maybe J13 can do something about this...]
Kent M Pitman <······@world.std.com> writes:
> At the time CLHS was originally done, it was probably the biggest and
> most tightly interlinked web document ever made, or competitive with,
> because there were no automatic tools for making web documents then.
> It would have been a fascination even for non-Lispers just as a
> glimpse of what the web might become. By the time it was rolled out,
> latex2html was already invented [not that I could have used it, of course,
> since the ANSI CL document was in raw TeX, but it gives you a feeling
> for the intervening maturation that had hapepened].
What I find particularly interesting about the CLHS, is it's impact on
my development style, productivity, and error-count. Of all the gizmos,
techniques, processes and integrated development environments I have
ever used, the CLHS[1] (in combination with Erik's hyperspec.el, which
links to the corresponding entries in the CLHS from the symbol at point
in Emacs, and W3, Emacs' integrated Web browser) has quite probably had
the most positive impact on my productivity and defect rate.[2]
Whereas in other environments you have to either struggle with less
than helpful, strangely organized, and incomplete on-line helpsystems,
or get out the reference books/standards, the CLHS gives me in-depth,
definitive, portable and complete information on every symbol and area
of CL at the touch of a button. No more guessing or tedious breaks
from programming to look up information in a paper-back reference
guide or standard. In effect, this has lowered the threshhold cost of
looking something up to a level, that I'm no longer tempted to rely on
my (often failing) memory.
The high density of links also gives you ample opportunity to browse
related definitions and areas, thereby increasing your understanding
of a part of the language in relation to other parts, sometimes
guiding you to better suited constructs, or completely new ways of
dealing with a problem. This counteracts the human tendency for
tunnel-vision (also known as the hammer effect ;), whereby you
restrict yourself to a small subset of the given language, mis-using
well-known constructs where other lesser-known constructs would have
been better.
In most other on-line helpsystems, I often have to hunt around for
definitions and information on things I know are in there (somewhere),
that is I have to expend serious effort to get what I want. After a
forray into the CLHS, not only have I found what I wanted with nearly
no effort, but quite often I come back with _more_ than I wanted,
i.e. with a clarified understanding of certain issues, or a better
grasp of the relation between different constructs, etc.
The only negative side-effects I've encountered are:
a) I can't really work productively with Common Lisp without access to
the CLHS anymore, and
b) when I'm forced to work with other environments with lesser
documentation, I get depressed very quickly, and yearn for the
CLHS or an equivalent. I'm also not very confident about the
code produced in such an environment, always fearing that I've
missed something important...
So for me the CLHS is a non-trivial part of the usability and
effectiveness of CL, and I'd like to take this opportunity to
thank you for your contributions to the CLHS and the standard
itself. Thank you!
Regs, Pierre.
Footnotes:
[1] The on-line documentation of GNU Emacs (the "self-documenting
editor") is of similar technical usability, but varies wildly in
quality, accurracy and completeness, thereby giving away many of the
benefits that it's usability promises.
[2] What lessons can be learnt from this with regards to usability?
It seems to me that much HIC work has centered on the graphical part
of human-computer interaction (with some justification), but that the
power of the written word has often been neglected when it comes to
interface design. It seems to me, that if more programs had really
good on-line help systems (instead of jumping paper-clips, wizzards,
assistants or the gimick-of-the-day), usability of computers might be
greatly increased. As long as a system is consistent, stable,
uncluttered and well-documented, I find it usable, and I still think
that I'm not alone in this.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
Pierre Mai wrote:
> What I find particularly interesting about the CLHS, is it's impact on
> my development style, productivity, and error-count. Of all the gizmos,
> techniques, processes and integrated development environments I have
> ever used, the CLHS[1] (in combination with Erik's hyperspec.el, which
> links to the corresponding entries in the CLHS from the symbol at point
> in Emacs, and W3, Emacs' integrated Web browser) has quite probably had
> the most positive impact on my productivity and defect rate.[2]
I concur. (With one modification: most of my Lisping is on a
funny platform that doesn't run Emacs. I do my CLHS lookups
using a little thing I wrote in Python, operating on a hacked
CLHS turned into text with most of the HTMLisms expunged.)
I understand Kent's frustration at the CLHS remaining stalled
inside Harlequin for ages, but now it's out and it's tremendously
useful.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
················@pobox.com Cambridge University, England.
In article <···············@world.std.com>, Kent M Pitman <······@world.std.com> wrote:
> ······@lavielle.com (Rainer Joswig) writes:
>
> > - a web site with documentation (not to forget Kent's heroic
> > Hyperspec, thanks!).
>
> Funny to see this in the list of positives. The CLHS was ready for
> roll-out nearly 1.5 years before it was finally rolled out. I was
> ready to die over the fact that it was not seeing the light of day for
> so long. Everyone at Harlequin was sworn to secrecy to keep someone
> else from coming up with the idea while we/I waited interminably for
> someone to decide it was worth putting out. When after a year of
> having CLHS in-house at Hqn and everyone loving it, Steele's CLTL2
> appeared online, I was ready to cry. I felt like I was going to look
> like a mere copy-cat when I'd done my thing so long before.
Kent, it's out now and that counts for me.
We are very thankful for your work and it will
be useful for many Lisp users in the coming years.
It is an excellent reference. I understand your
frustration, but please accept that we a glad that
you did it and that it's very useful.
In article <·······················@pbg3.lavielle.com>,
······@lavielle.com (Rainer Joswig) wrote:
>In article <···············@world.std.com>, Kent M Pitman
><······@world.std.com> wrote:
>
>> ······@lavielle.com (Rainer Joswig) writes:
>>
>> > - a web site with documentation (not to forget Kent's heroic
>> > Hyperspec, thanks!).
>>
>> Funny to see this in the list of positives. The CLHS was ready for
>> roll-out nearly 1.5 years before it was finally rolled out. I was
>> ready to die over the fact that it was not seeing the light of day for
>> so long. Everyone at Harlequin was sworn to secrecy to keep someone
>> else from coming up with the idea while we/I waited interminably for
>> someone to decide it was worth putting out. When after a year of
>> having CLHS in-house at Hqn and everyone loving it, Steele's CLTL2
>> appeared online, I was ready to cry. I felt like I was going to look
>> like a mere copy-cat when I'd done my thing so long before.
>
>Kent, it's out now and that counts for me.
>We are very thankful for your work and it will
>be useful for many Lisp users in the coming years.
>It is an excellent reference. I understand your
>frustration, but please accept that we a glad that
>you did it and that it's very useful.
I realize it's against netiquette to leave the original post in its
entirety only to add "ditto," but this is so overwhelmingly worth doing
that I will take the flames. CLHS is the single most useful
hyperdocument I've ever encountered and *still* sets the standard for
other reference hyperdocuments to emulate.
Many thanks to Kent for all the fine, hard work!
Paul Snively
--
Paul Snively <···············@earthlink.net>
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 5.0 for non-commercial use <http://www.pgp.com>
mQGiBDcaPxsRBADpVRDb/ttx31kMsThK8cZjKhaTBlsG/C9W692x3YzHB7M1T82z
0OL3HL/ddk2Qz9o9ekgIM9GzVq7mg/NfzXB7qC/L7M+rztvVVBmj8Yi8R11o+0rm
vG5bEBTlTd4fSm3BDPUuw3BDt1SQ7BjGaJvRJTb5QE1BMzP3QHLSUznFYwCg/9fv
BEtCgEzpxiqGzQuOm6BSZw0EAOHZpqoDlU6QzDeGPHgFlNIXRcjm/yWZeOuEEpie
XwBwYl8q2FlnlkWROYF9Oxce3WOJzvHovwAjEWpHTlLmUpaGrew0ld1rj+yd4U0h
T397XtQ9ax2pmm5t81iijnrTEDrkBn2+EkvESQ7SnHjY0DRGRhy7UYpKNRt5uWdr
bDcVBADDYylRcVfyZMTjsb6gkVL99qjxtWR2CCaoIxV17BiDVkDGQgB3CDL4zBzT
4p1Q+Ql/Xq0YFQ5XxY2nEj4mwmycwiYf2j21yUgb7nOG5DSzQg751MAuBpiV+xmF
/BoDOJOIa2tFH7husWyAUFwtbhdZLzKEWWk8FooUOcwSdTibHrQlUGF1bCBTbml2
ZWx5IDxwc25pdmVseUBlYXJ0aGxpbmsubmV0PokASwQQEQIACwUCNxo/GwQLAwEC
AAoJEPV1SOJariLoTOwAmwbFBuCfnKwv4XSVnB4jOZYzAs1OAKCy8bHKQn/yxfjw
d1266EjA6meYbbkBDQQ3Gj/nEAQA3mrjXICi9+oj67jetHlpdC/rlTh7jpkjKRzB
1AvZjz4N2cRpWcHvVfL7RhOAMKJaWhfjB73CnWcCl5h3EnH++D2yJ6X75bnzfLo2
EpUsvSfmWZ7BCjyzpWIdvYqz4sj6xY4s1Jtzdi1hgM18+qi+CtSdkz3wEaAFzid7
69Rdi58AAgID/3mz52xXgit9wyo1wjFq55WXwfi5YVsZ7jjQl/eZsEJ5Epxm+MFb
qKCUg+1x1PlV92QzbhaMF7UaPcAdMOpUTtjMFRY5HOXaDDQrRadY9+/5f7/abfLK
OqYsHt3VjAczzZMXRnX0b2aT25jZfofUUANHaZNEASPjIjSaR6bUrJWniQA/AwUY
Nxo/5/V1SOJariLoEQLQuACg6IX+Cnrh4L+s9abxC12JyljciFYAoNQSrLpTwPsC
sqx8aMJZnHB0KK6c
=4ZXy
-----END PGP PUBLIC KEY BLOCK-----
Kent M Pitman wrote:
> In any case, I doubt anyone will rush to duplicate Jo's particular
> style too closely,
I nominate this as comp.lang.lisp Understatement of the Year.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
················@pobox.com Cambridge University, England.
* Rainer Joswig wrote:
> But they didn't. Several years with a staff of let's say, twenty
> or more developers. How many years would you need
> selling, say, $300 boxes to get that back?
This is the Concorde (aka sunk cost) fallacy. Even if Harlequin
got driven out of business by spending too much on Dylan, that money
is now sunk cost, and the interesting question is: could Dylan be
profitable for a company *now*?
--tim
(It is called the concorde fallacy because Concorde was a classic
example of the more common flip side of this: `because we have sunk a
lot of cost into something, we should continue pouring money into it
*even if* it will never make money'. More-or-less this wrong decision
was made about Concorde at some point (and it seems possible that
Harlequin may have made this decision about Dylan at some point in the
past...)
--tim
--
Please remove dot nospamski dot from the return address.
----------
In article <··························@news.demon.co.uk>,
···@wildcard.butterfly.demon.co.uk (Martin Rodgers) wrote:
> In article <·······················@pbg3.lavielle.com>,
> ······@lavielle.com says...
>
>> > Misinformation? Where?
>>
>> In your postings, on your website, ...
>
> That's several hundred pages, many of which have not been maintained
> or even accessible from the root page for about half a year.
>
> As for my postings, which ones? I know I've said things that you may
> disagree with. I have a bad habit of making a distinction between the
> choices that programmers would make and the demands of employment.
Last time I checked where a programmer is employed is a choice they make.
> ISTR a Kent Pitman posting that made a similar distinction. Of course,
> he expressed it much better than I can.
>
> In this thread we're discussing th
\t
In article <············@sloth.swcp.com>,
···············@PalomaBlanca.net says...
> Last time I checked where a programmer is employed is a choice they make.
The employer makes the first choice.
--
Remove insect from address | You can never browse enough
will write code that writes code that writes code for food
In article <·······················@pbg3.lavielle.com>,
Rainer Joswig <······@lavielle.com> wrote:
>What makes me feel sorry is that millions of $ have been
>"wasted" on Dylan - much of that would have better
>been spend on Lisp - that has been my position for years.
>
> (stuff deleted)
and
>
>1) it has to be clear where the benefit for the Lisp community is
> (more stuff deleted)
Well, competition stipulates research, e.g. Dylan caused the following
gem (IMHO):
http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
That's what both DYLAN *and* CLOS should be based on (IMHO again).
Just like having two or more vendors of CL is better than one, having
both CL and DYLAN seems preferable to me.
Bernhard
PS: I'm an "extended-LOOP junkie", maybe that explains my DYLAN
sympathy. I also quite like DYLAN's let-syntax:
let VAR = VALUE; which naturally extends to multiple values as well, e.g.:
let (p, v) = find-position-and-velocity(rock, time);
PPS: Still I have not yet written a single DYLAN program, but use CL
(ACL, CLISP, CMUCL) every day :-)
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence ········@ai.univie.ac.at
I use Outlook reader, therefore my comments are all
manually indented with a TAB since I'm a rebel without a
training ;)
> From: ········@hummel.ai.univie.ac.at (Bernhard Pfahringer)
> In article <·······················@pbg3.lavielle.com>,
> Rainer Joswig <······@lavielle.com> wrote:
> >What makes me feel sorry is that millions of $ have been
> >"wasted" on Dylan - much of that would have better
> >been spend on Lisp - that has been my position for years.
> >
> > (stuff deleted)
> and
> >
> >1) it has to be clear where the benefit for the Lisp community is
> > (more stuff deleted)
>
> Well, competition stipulates research, e.g. Dylan caused the following
> gem (IMHO):
>
http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
That's what both DYLAN *and* CLOS should be based on (IMHO again).
Yep, a gem, but regarding marketing issues, this is just the
kind
of mixin lattice thing C++ was into two years earlier, and
you're not
going to convince any of those legions to switch over to another
language
with infix notations(Dylan) that are similar but mean something
else--and
with no money pipe.
Those legions of C++ programmers then jumped to the Java camp
when
Sun righteously announced it was trashing all the linearization
issues
and we were all going to do it manually with single inheritance
to solve 80% of all problems and it was Good--it was Netscape.
A language with another syntax is not going to attract anyone.
CL may
have some geek appeal with its "more abstract nature and ability
to
more naturally express anything better". The "romance" of Unix
is what
drove C and it's variants--the "religious experience" of Lisp
environments
will drive CL. To win big Lisp must be the best means for
access to some
cool resource...such as workplans that actually mean something
or code
generation (or relative order or whatever turns you on). You
have to
put yourself in the shoes of someone looking at it the first
time to
see how to make it appeal to them.
I would think the appeal would be to make it an act of
rebellion--with
C it was "getting into the internals of the OS", and with Lisp
it may
be "the act of abstraction as a more fundamental rebellion",
therefore
the religious nature of the experience :) On the business
level it's:
write more effective workplans in Lisp first, then translate as
necessary
to old english or UML and other less abstract
notations...writing
programs to write programs ought to be the focus, as I think
Graham put it.
The money model I see here is a purely investment bandwagon of
large
pipe flowing in the direction of "what programmers download".
Java
rode on the coattails of Netscape, which was a huge downloading
phenomenon which is what drove the investment market...nothing
more.
Who can point to a product here? (I have no background in
finance).
Granted Netscape had something interesting to say about
multithreaded
servers, but they give away their servers to techies who have
an
appreciation for performance etc. It's a bandwagon. Investors
just
count downloads and that's what fuels the income pipe. Somehow
it
figures in to the company's perceived worth. But I can't
really
see the world downloading some Lisp app on that scale.
Just like having two or more vendors of CL is better than one, having
both CL and DYLAN seems preferable to me.
Bernhard
PS: I'm an "extended-LOOP junkie", maybe that explains my DYLAN
sympathy. I also quite like DYLAN's let-syntax:
let VAR = VALUE; which naturally extends to multiple values as well,
e.g.:
let (p, v) = find-position-and-velocity(rock, time);
What's with the '=' sign? :) Dylan (IMHO) on the surface
(IMHO) appears to be a waste (IMHO)
PPS: Still I have not yet written a single DYLAN program, but use CL
(ACL, CLISP, CMUCL) every day :-)
There you go.
We need to organize and all download something on the same
day...
the new open source Lispworks?
In article <·············@www.univie.ac.at>,
········@hummel.ai.univie.ac.at says...
> Just like having two or more vendors of CL is better than one, having
> both CL and DYLAN seems preferable to me.
A degree of diversivication can be good business sense, providing you
can afford it. I've no idea how far 18M Euros will take Harlequin, but
if they needed to be conservative then concentrating of their core
development tools and ditching the others would make sense. After all,
they already have _two_ Common Lisp systems to maintain.
However, I can't comment on the commercial value of MLWorks, never
mind DylanWorks. We know that LispWorks has commercial value. I'd
guess that it has more value to Harlequin than their other development
tools. The question is, how much value? How much value is a little
diversivication worth? How much does it cost them?
I'd like to see some numbers before giving them any advice.
--
Remove insect from address | You can never browse enough
will write code that writes code that writes code for food
In article <·············@www.univie.ac.at>, ········@hummel.ai.univie.ac.at (Bernhard Pfahringer) wrote:
> > (stuff deleted)
:-( ;-)
> Well, competition stipulates research, e.g. Dylan caused the following
> gem (IMHO):
>
> http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
I really don't think that Dylan in this case was making
finding this solution possible. It just happened
that several Lisp wizards (Moon!) were working on Dylan
instead on improving Lisp. At the same time many
people
> Just like having two or more vendors of CL is better than one, having
> both CL and DYLAN seems preferable to me.
Why?
> PS: I'm an "extended-LOOP junkie",
Personally, I think the ITERATE macro stylistically much better.
LOOP is broken.
> sympathy. I also quite like DYLAN's let-syntax:
> let VAR = VALUE; which naturally extends to multiple values as well, e.g.:
> let (p, v) = find-position-and-velocity(rock, time);
How was it done in the prefix syntax?
> PPS: Still I have not yet written a single DYLAN program, but use CL
> (ACL, CLISP, CMUCL) every day :-)
You are a lucky guy. ;-)
······@lavielle.com (Rainer Joswig) writes:
> In article <·············@www.univie.ac.at>, ········@hummel.ai.univie.ac.at (Bernhard Pfahringer) wrote:
>
> > Well, competition stipulates research, e.g. Dylan caused the following
> > gem (IMHO):
> >
> > http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
>
> I really don't think that Dylan in this case was making
> finding this solution possible. It just happened
> that several Lisp wizards (Moon!) were working on Dylan
> instead on improving Lisp. At the same time many
> people
This phenomenon is called "opportunity cost"--when the doing of one thing
precludes [and hence has as its effective price] the non-doing of another.
There is a lot of this kind of cost in this corner of the languages
marketplace. We must choose our time usage carefully.
In article <·······················@pbg3.lavielle.com>,
Rainer Joswig <······@lavielle.com> wrote:
>In article <·············@www.univie.ac.at>, ········@hummel.ai.univie.ac.at (Bernhard Pfahringer) wrote:
>
>> Well, competition stipulates research, e.g. Dylan caused the following
>> gem (IMHO):
>>
>> http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
>
>I really don't think that Dylan in this case was making
>finding this solution possible. It just happened
>that several Lisp wizards (Moon!) were working on Dylan
>instead on improving Lisp. At the same time many
>people
>
Well I don't know for this particular case, but sometimes it is easier
to be funded for something that seems radically newer than for something
being perceived as merely an incremental improvement. So this research may
have been funded because it was Dylan, and might not have been funded
had it been merely CL (wild speculations, of course).
>> Just like having two or more vendors of CL is better than one, having
>> both CL and DYLAN seems preferable to me.
>
>Why?
Because Dylan seems to address some points differently, like having
an infix syntax (I prefer sexprs anytime, but I know there are people
you would never consider sexprs). Dylan trades off some dynamicity for
better optimization possibilities. Whether this is essential, I don't know,
but it is interesting to have people try it out.
Dylan also seems to try to make integration of C/C++ libraries easier.
Harlequin developed a GUI kit called DUIM, the Gwydion Dylan folks plan
to support/port this as well, so Dylan may soon have "standard" GUI tools.
I bet, should we ever see CL3, it sure will include (swallow up) a lot
of the good ideas developed due to Dylan. And quite some of this work
would have been funded because of Dylan and would have never happened
for merely CL.
>Personally, I think the ITERATE macro stylistically much better.
>LOOP is broken.
>
I should look into ITERATE, it is on my todo-list, maybe I'll convert :-)
>> let (p, v) = find-position-and-velocity(rock, time);
>
>How was it done in the prefix syntax?
>
Good question, I'll see if I find anything in my old Apple Dylan copy
about it. It's shelved at home, so maybe tomorrow.
>You are a lucky guy. ;-)
I sure am!
Bernhard
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence ········@ai.univie.ac.at
In article <·············@www.univie.ac.at>, ········@hummel.ai.univie.ac.at (Bernhard Pfahringer) wrote:
> Well I don't know for this particular case, but sometimes it is easier
> to be funded for something that seems radically newer than for something
> being perceived as merely an incremental improvement. So this research may
> have been funded because it was Dylan, and might not have been funded
> had it been merely CL (wild speculations, of course).
But we had projects in Europe to improve Lisp. In Germany
it was the Apply project - remember CLICC?
People were looking into improving Lisp. You just
need to look at the literature.
http://nathan.gmd.de/projects/apply.html
From that web page:
Results
The most important scientific result of GMD is the second version
of the EuLisp object system (TELOS). With respect to the APPLY
goals mentioned above, it is significantly improved compared to
the first version and to the Common Lisp Object System (CLOS).That
was discussed on the IMSA'92 International Workshop on Reflection
and Meta-level Architecture in Tokyo [1]. TELOS is an integrated
part of the EuLisp definition which is described in a special
issue of the "Lisp and Symbolic Computation" Journal [2].
The Meta Class System (MCS), a predecessor of TELOS, has achieved
the status of an efficient, well tested software system used as a
CLOS compatible implementation language for the commercial AI
workbench babylon.
An ECOOP'93 workshop on Object-Oriented Programming in Lisp:
Languages and Applications was organized in collaboration with the
University of Stuttgart. Talks have been presented on GI workshops
"Alternative Konzepte f�r Sprachen und Rechner" in Bad Honnef.
The work is done in cooperation with many european partners
supported by the EC, the Anglo-German research collaboration
(ARC). Recently, a net proposal "VIM: A Virtual Multicomputer" in
the Human Capital and Mobility Programme (HCM) has been accepted.
> Because Dylan seems to address some points differently, like having
> an infix syntax (I prefer sexprs anytime, but I know there are people
> you would never consider sexprs).
But this is nothing new (besides trying to provide
some version of macros with infix syntax).
> Dylan trades off some dynamicity for
> better optimization possibilities. Whether this is essential, I don't know,
> but it is interesting to have people try it out.
Others did try that in the Lisp context.
> Dylan also seems to try to make integration of C/C++ libraries easier.
Yes? C or C++? Or Both?
> Harlequin developed a GUI kit called DUIM, the Gwydion Dylan folks plan
> to support/port this as well, so Dylan may soon have "standard" GUI tools.
Sorry, but DUIM is a straight successor of CLIM. Nothing new here.
Instead CLIM remains largely unmaintained. Arghhhh. It
seems policy of almost all Lisp companies to not develop
any common GUI toolkit. In the case of CLIM I have
the feeling of sabotage.
> I bet, should we ever see CL3, it sure will include (swallow up) a lot
> of the good ideas developed due to Dylan. And quite some of this work
> would have been funded because of Dylan and would have never happened
> for merely CL.
Wrong. Look around there are many many ideas that have developed
for Lisp and in context of Lisp research. Many of them are much
more significant than what Dylan provided - especially
when many Dylan things are hidden inside commercial
companies and not done in open research.
Dylan has got almost no new ideas. And that was a goal
(and a reasonable one). Apple didn't want to puzzle
developers of "conventional" languages.
It is a repackaging of old stuff in a different combination.
Rainer Joswig
From: Bernhard Pfahringer
Subject: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <7mhmoi$3a2c$1@www.univie.ac.at>
In article <·······················@194.163.195.67>,
Rainer Joswig <······@lavielle.com> wrote:
>In article <·············@www.univie.ac.at>, ········@hummel.ai.univie.ac.at (Bernhard Pfahringer) wrote:
>
>But we had projects in Europe to improve Lisp. In Germany
>it was the Apply project - remember CLICC?
Sure do, nice try, but failed, right?
>People were looking into improving Lisp. You just
>need to look at the literature.
>
I never claimed the opposite. But it is a matter of fact that
CMUCL funding was stopped, and the same group (at least the
same leader) was able to secure funding for a few more years
to develop Dylan, until this was stopped as well. So Dylan
gave them the opportunity to develop a lisp-like language
for a few years, that otherwise would not have existed (the
opportunity and the language as well in that case :-).
Also, do you believe Harlequin would have funded a development
team the size of both the Lisp and Dylan group for solely
CL development? I bet not. So this way we got more people
working on developing dynamic languages, for some time at
least. And I doubt that this effort will be lost, until
now the open-source Gwydion Dylan folks and Harlequin's
Dylan group seemed to have cooperated sensibly.
As Kent has pointed out in a former message, Dylan tried to
improve on quite a few things which are not so nice in CL.
My impression was that the initial goal of Dylan was to be
a lisp-like language enabling small, efficient, stand-alone
applications. This was something not possible with 1990's
Lisps. Today that's different, standard PCs now have tons
of memory and are rather speedy (we have to thank M$ for
this, as their bloated OSes and apps drove that speedy
evolution of PCs, now we can reap the benefits thanks to
Linux :-)
>
>> Dylan also seems to try to make integration of C/C++ libraries easier.
>
>Yes? C or C++? Or Both?
>
There is interesting stuff for C only, you are right. E.g. the
automatic interface generator Melange, which processes standard .h files.
(somewhat outdated info to be found at:
http://www.gwydiondylan.org/old-docs/maker-out/melange.htm)
>
>Sorry, but DUIM is a straight successor of CLIM. Nothing new here.
>Instead CLIM remains largely unmaintained. Arghhhh. It
>seems policy of almost all Lisp companies to not develop
>any common GUI toolkit. In the case of CLIM I have
>the feeling of sabotage.
>
Exactly, whereas with DUIM who'd have a common GUI toolkit
(provided it is ported to Gwydion Dylan), definitely an
advantage for Dylan.
>
>Wrong. Look around there are many many ideas that have developed
>for Lisp and in context of Lisp research. Many of them are much
>more significant than what Dylan provided - especially
>when many Dylan things are hidden inside commercial
>companies and not done in open research.
>
I see a lot of Scheme research, but not that much CL research,
CL too is mostly commercial development, so Dylan and CL seem
on equal footing.
>
>It is a repackaging of old stuff in a different combination.
>
If you choose the right bits and pieces from different sources,
your simple combination can still we a winner :-)
To conclude, I accept you being more skeptical about Dylan
than me, and only time will tell who's right, as they say.
Bernhard
PS: Self and Cecil are interesting language developments which
should have impact on CL implementation technology as well.
--
--------------------------------------------------------------------------
Bernhard Pfahringer
Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/
Artificial Intelligence ········@ai.univie.ac.at
From: David Bakhash
Subject: Re: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <cxj908ivjyh.fsf@acs5.bu.edu>
········@hummel.ai.univie.ac.at (Bernhard Pfahringer) writes:
> As Kent has pointed out in a former message, Dylan tried to
> improve on quite a few things which are not so nice in CL.
what exactly are these things that Dylan tried to improve upon? What was
"broken" in CL? I still don't know.
I personally don't like the way `let' works in CL. but there are macros that
can fix that, if you care. (I remember reading a post where someone talks
about how let is better in Dylan). What I would like to know is where CL went
wrong, and where Dylan tried to clean up.
It seems to be that for an avg-minded person to become really good at CL
requires loving CL. I don't know how else to describe it. It's a large
language, and very complex. I know I'm still learning new stuff all the time.
I some people probably perceive this as a bad thing for a computer language.
I don't know. To me, you can quickly learn to do the ordinary with CL, and
not have to know all the details. Did KMP once mention that he would take
this approach with his book?
Can someone list some of the major problems with CL? Are they:
o lacking in low-level OS interface as part of the spec?
o no standards for multiprocessing
o no standards for sockets and networking
o CLOS stuff, like: CLOS is too dynamic. Can't seal classes, etc.
o no standard way to compile into an stand-alone executable.
o CL doesn't use infix (please no one mention this is a weakness).
I'd love to hear these qualms.
dave
From: Lyman S. Taylor
Subject: Re: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <378D90DE.B9240CF0@mindspring.com>
David Bakhash wrote:
...
> what exactly are these things that Dylan tried to improve upon? What was
> "broken" in CL? I still don't know.
I'll take a stab at this.
On the continuum of:
|------------------------------------------------------------------------------|
totally dynamic totally static
Dylan tries to be a little left of the center. ;-)
More specifically.
1. You can't turn CLOS's dynamism OFF.
Sometimes you really don't need a class (or hiearchy) that can be
dynamically changed at any moment. When you have solved the
problem and there are no more changes required. Another example
is to look at most of the CLOS to OODBMS bindings out there. There
may be exceptions but often I think objects are either CLOS object or OODBMS objects
but not both at the same time.
Ditto with the methods. Sometimes you only want to write generic functions
for users to "use" not wrap more stuff around/onto them.
[ By limiting some dynamism to the boundaries of the library you don't have to
do a static analysis of the whole program in order to do some optimizations.
In CL, There isn't really a standard mechanisms that can group definitions
together like this. ]
2. A saner module/library/package system.
Most folks eventually find a methodology of using CL's packages that makes them happy,
but that usually takes time and is sometimes awkward. I would hope nobody
held up CL's package system as "inspired".
3. Built-in macro-hygiene. The identifiers of a macro are from the context in which
the macro was defined not the context where it is expanded.
[ there a times when not having gensym/gentemp are frustrating, but for common
situations you don't need them. Some other Lisps have this.
In Dylan you also loose the ability for macros to perform "arbitary" computations.
You are limited to macros that implement Dylan-like syntax. Sometimes macro
writers should have some limitations placed upon them. A dual edges sword
that isn't quite so easy to cut yourself with. ]
4. Dylan explicitly decouples the development "tools" (evaling, compiling) from
the language itself.
[ Again this is about turning dynamism off. Only in this case it is
always off. There is no eval/perform. You can't have programs that require
you deliver the compiler.
Yes, you can define lisp programs that don't require you deliver the compiler
also. But can the tools figure that out definatively? Or do you just
not ship the compiler, so when the code hits an eval it just dies?
This is something that you really can't remove from Lisp and still really
call it Lisp. However, in some contexts it is baggage. I am NOT saying
CL is "broken" in this respect, just perhaps inappropriate in some contexts
that Dylan was suppose to address. ]
5. Regularity. For example, draw the line on every kind of argument under the sun.
Is the following really a good idea?
(defun foo ( a &optional b c &key d &rest e )
.... )
[ Is "Wierd READ-FROM-STRING error" a FAQ yet? :-) ]
Dylan tossed the optional arguments, keyword and rest remain. It harder to write
the function with the problematical usage interface.
Dylan tries to take the approach of having one way to do each thing as opposed
to N ways ( based upon M different legacy systems) to do things. In this
respect it is a more regular (and perhaps easier to learn language).
There may be variations on the syntactical sugar to express, but usually there
is one way to actually do it.
I'm probably forgetting something, but those are the first 5 that come to mind.
Besides point 1, it is probably more a subjective case of whether Dylan allows you
do these better/cleaner than CL. So "broken" may be overstating the point a bit.
> o lacking in low-level OS interface as part of the spec?
> o no standards for multiprocessing
> o no standards for sockets and networking
Those make for nice supplementary libraries. I'm not sure they should be in the
"core" of a language. Again a language "feature" of being able to scale it
done to a "small" required subset.
> o no standard way to compile into an stand-alone executable.
Again this the an "extra" language issue. That depends, in part, upon the OS.
> o CL doesn't use infix (please no one mention this is a weakness).
From a technical standpoint it isn't a weakness.
From a marketing standpoint it is. Well "infix" is only the "tip of the iceberg".
To heavily leverage off the syntax of the language you hope to "steal" people from
would probably be more to the point.
Lisp has it's own established syntax so that discussion of that marketing spin issue
will generate more smoke than heat.
Luckily you can layer whatever you want, given a sufficiently powerful macro, on top of
CL. :-) You'd probably loose the ability to easily write that sufficiently powerful
macro if you had a different syntax.
[ I've bit my tongue on most of this Dylan debate. I go back and forth about
Dylan's infix syntax.
I think it significantly contributed to the long gestation period for "Dylan"
to arrive. Whether the "broaden audience" was worth the time delay is
perhaps open to debate. I think that not have the constraint of closely
matching a previous language may have been as much of a liability as it was
an asset. ]
----
Lyman
From: Fernando Mato Mira
Subject: What's wrong with Lisp? (was: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!))
Date:
Message-ID: <378D9F44.14AD9691@iname.com>
David Bakhash wrote:
> Can someone list some of the major problems with CL? Are they:
I'd like to hear what the Ericsson people have to say. After evaluating "Lisp" and
others, they came to the conclusion they had to invent their own impure functional
language (Erlang). Why not just a new Lisp dialect/implementation?
From: Rainer Joswig
Subject: Re: What's wrong with Lisp? (was: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!))
Date:
Message-ID: <joswig-1507991105560001@pbg3.lavielle.com>
In article <·················@iname.com>, Fernando Mato Mira <········@iname.com> wrote:
> David Bakhash wrote:
>
> > Can someone list some of the major problems with CL? Are they:
>
> I'd like to hear what the Ericsson people have to say. After evaluating "Lisp" and
> others, they came to the conclusion they had to invent their own impure functional
> language (Erlang). Why not just a new Lisp dialect/implementation?
AT&T/Lucent used Common Lisp for switching systems.
From: Raymond Toy
Subject: Re: What's wrong with Lisp? (was: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!))
Date:
Message-ID: <4nn1wy9hhz.fsf@rtp.ericsson.se>
>>>>> "Rainer" == Rainer Joswig <······@lavielle.com> writes:
Rainer> In article <·················@iname.com>, Fernando Mato Mira <········@iname.com> wrote:
>> David Bakhash wrote:
>>
>> > Can someone list some of the major problems with CL? Are they:
>>
>> I'd like to hear what the Ericsson people have to say. After evaluating "Lisp" and
>> others, they came to the conclusion they had to invent their own impure functional
>> language (Erlang). Why not just a new Lisp dialect/implementation?
Rainer> AT&T/Lucent used Common Lisp for switching systems.
Used? Not any more?
Ray
In article <·················@iname.com>,
Fernando Mato Mira <········@iname.com> writes:
|> I'd like to hear what the Ericsson people have to say. After evaluating "Lisp" and
|> others, they came to the conclusion they had to invent their own impure functional
|> language (Erlang). Why not just a new Lisp dialect/implementation?
There is nothing wrong with Lisp.
There were several things we needed in a language.
- Explicit concurrency. I.e the ability to provide explicit threads/processes
and communication (message passing) between threads
combined with distribution, i.e. the ability for threads in one
processor to be able to send messages transparently to threads in other
processors.
- Supervision. The ability one thread to supervise other threads. I.e. find out
if they die, or the processor on which they are executing dies. This
is the basis of fail-over/hand-over mechanisms.
- The ability to change code on the fly. (i.e. to change code in
running systems). This has implication on the language design and on
it's implementation.
We obviously needed either a new language or a new dialect of an
existing language. In any case we needed a new implementation of
whatever language / dialect we chose. Of course we could have done
this by creating a new implementation and dialect of Lisp. However we
found that a functional syntax with pattern matching allowed, in the
opinion of our guneapig users, a more clear and easy to understand
code. If these users had had a greater exposure to Lisp, maybe we
would have chosen a more Lisp-like approach?
In any case, Joe designed the language and decided how it was to
be compiled (so ask him for all the details :-), Robert wrote
the first libraries and I wrote the first virtual machine (JAM =
Joe's abstract machine). Later Klacke added distribution to the
JAM and the primitives needed for implementing extremely fast
distributed real time databases. Bogdan made a new faster implementation
(BEAM = Bogdan's Erlang Abstract Machine) and Robert tried another
approach (VEE = Virding's Erlang Engine). Now things have stablised
and JAM is used in most Ericsson products except the ATM switch which
uses BEAM.
Klacke, Joe and Robert have all moved on to start a new company
Bluetail AB (http://www.bluetail.com), to exploit Erlang technology
and become rich. Bogdan is now in the Multi media area in another
lab. I am a stick in the mud, so I became a manager. One of the
departments reporting to me is in charge of the Erlang implementation
(and OTP - the libraries and environment). This department has 24
people, so all is secure despite Robert, Joe and Klacke's interest in
becoming rich!
/mike
From: Robert Virding
Subject: Re: Some Erlang History (was: Re: What's wrong with Lisp?)
Date:
Message-ID: <378f2203@news.pi.se>
In article <············@news.du.etx.ericsson.se>,
····@erix.ericsson.se (Mike Williams) writes:
>In article <·················@iname.com>,
> Fernando Mato Mira <········@iname.com> writes:
>|> I'd like to hear what the Ericsson people have to say. After evaluating "Lisp" and
>|> others, they came to the conclusion they had to invent their own impure functional
>|> language (Erlang). Why not just a new Lisp dialect/implementation?
>
>There is nothing wrong with Lisp.
>...
>We obviously needed either a new language or a new dialect of an
>existing language. In any case we needed a new implementation of
>whatever language / dialect we chose. Of course we could have done
>this by creating a new implementation and dialect of Lisp. However we
>found that a functional syntax with pattern matching allowed, in the
>opinion of our guneapig users, a more clear and easy to understand
>code. If these users had had a greater exposure to Lisp, maybe we
>would have chosen a more Lisp-like approach?
One thing Mike forgot to mention was that at the time development
of Erlang started (mid 80's) we had been working alot with logic
languages and we got many impulses from them. You can still see it in
the syntax. Erlang actually started out as an extension of Prolog and
only later became functional.
That is also probably the main reason why we have dynamic typing. In
retrospect I can honestly say that I don't miss typing. :-)
Robert
--
Robert Virding Tel: +46 (0)8 692 22 12
Bluetail AB Email: ··@bluetail.com
Hantverkargatan 78 WWW: http://www.bluetail.com
SE-112 38 Stockholm, SWEDEN
"Folk s�ger att jag inte bryr mig om n�gonting, men det skiter jag i".
On 16 Jul 1999 06:12:35 GMT, Mike Williams <····@erix.ericsson.se> wrote:
>- The ability to change code on the fly. (i.e. to change code in
> running systems). This has implication on the language design and on
> it's implementation.
I'm really interested in Erlang's introspective features like dynamic code
change, but I can't find any really good documentation on it. I have looked
at the Erlang site and the first part of the Erlang book, but there simply
doesn't seem to be enough documentation for the language for this humble
student to get by. Then again, I'm hardly in your target market...
--
Jason Stokes: ·····@bluedog.apana.org.au
Jason Stokes (·····@bluedog.apana.org.au) wrote:
: On 16 Jul 1999 06:12:35 GMT, Mike Williams <····@erix.ericsson.se> wrote:
: > The ability to change code on the fly. (i.e. to change code in
: > running systems). This has implication on the language design and
: > on it's implementation.
: I'm really interested in Erlang's introspective features like
: dynamic code change, but I can't find any really good documentation
: on it. I have looked at the Erlang site and the first part of the
: Erlang book, but there simply doesn't seem to be enough
: documentation for the language for this humble student to get by.
If you buy the book, you get the section that describes code
replacement. Also the on-line book (PDF?), "Erlang in Real Time", by
Maurice Castro, has a chapter on code replacement. Search for it at
serc.rmit.edu.au, I downloaded it and do not have the URL handy.
The gist of it is you can have up to two versions of a module loaded
at one time. The older version will be replaced by the newer version
whenever a reference is made to a fully qualified
(e.g. module:function) name of one of the module's functions. So even
the old module can replace itself with a new module whenever it uses a
fully qualified name as opposed to simply the function name without
the module prefix.
Then there are a handful of functions for managing the loading and
browsing, etc. of modules in a node.
--
Patrick D. Logan ····················@home.com
From: Craig Dickson
Subject: Re: Some Erlang History (was: Re: What's wrong with Lisp?)
Date:
Message-ID: <7mo7qe$e4t$1@shell3.ba.best.com>
·············@home.com wrote:
>If you buy the book, you get the section that describes code
>replacement. Also the on-line book (PDF?), "Erlang in Real Time", by
>Maurice Castro, has a chapter on code replacement. Search for it at
>serc.rmit.edu.au, I downloaded it and do not have the URL handy.
I'll have to look for that one.
>The gist of it is you can have up to two versions of a module loaded
>at one time. The older version will be replaced by the newer version
>whenever a reference is made to a fully qualified
>(e.g. module:function) name of one of the module's functions. So even
>the old module can replace itself with a new module whenever it uses a
>fully qualified name as opposed to simply the function name without
>the module prefix.
This is why it is important that a server's main loop should recurse with a
fully qualified call, e.g.:
server_loop() ->
receive
.
.
.
?MODULE:server_loop()
end.
This way, if a newer version of the module has been loaded, the server will
switch to it after the next message it processes.
Of course, if in the newer version, the server loop's arguments are
different (more, fewer, different order, different types), the new module
will have to have a way of converting the arguments from the old format,
e.g.:
%% old module:
-export([server_loop/1]).
server_loop(x) when list(x) ->
receive
.
.
.
?MODULE:server_loop(x)
end.
%% new module:
-export([server_loop/1, server_loop/2]).
server_loop(x) when list(x) -> % for hot upgrades from old version
server_loop(x, []).
server_loop(x, y) when list(x), list(y) ->
receive
.
.
.
?MODULE:server_loop(x, y)
end.
In this example, the old version of the server loop was of arity 1, while
the new version's loop has arity 2, and a special version with arity 1 is
provided to handle a hot upgrade. Without this, the process would exit
abnormally when switching to the new module, because the call to
server_loop/1 would not be resolvable.
Similar problems can arise if the new version's loop has the same arity as
the old one, but the arguments don't match in some other way -- if an
argument's type changed, for example. The new module simply has to be able
to handle these situations, or the hot upgrade will fail.
Craig
Craig Dickson (···@best.com) wrote:
: >The gist of it is you can have up to two versions of a module
: >loaded at one time. The older version will be replaced by the newer
: >version whenever a reference is made to a fully qualified
: >(e.g. module:function) name of one of the module's functions. So
: >even the old module can replace itself with a new module whenever
: >it uses a fully qualified name as opposed to simply the function
: >name without the module prefix.
: This is why it is important that a server's main loop should recurse
: with a fully qualified call, e.g.:
: server_loop() ->
: receive
: .
: .
: .
: ?MODULE:server_loop()
: end.
: This way, if a newer version of the module has been loaded, the
: server will switch to it after the next message it processes.
Or if you don't want to test for the module on *every* pass through
the loop you could test after N passes through the loop, or on the
first pass through the loop after time T, or on the first pass through
the loop after some specific message has been received, etc.
--
Patrick D. Logan ····················@home.com
From: Ulf Wiger
Subject: Re: Some Erlang History (was: Re: What's wrong with Lisp?)
Date:
Message-ID: <xcz7lnxkojg.fsf@etxb.ericsson.se>
>>>>> "Craig" == Craig Dickson <···@best.com> writes:
Craig> ·············@home.com wrote:
>> The gist of it is you can have up to two versions of a module
>> loaded at one time. The older version will be replaced by the
>> newer version whenever a reference is made to a fully qualified
>> (e.g. module:function) name of one of the module's functions. So
>> even the old module can replace itself with a new module whenever
>> it uses a fully qualified name as opposed to simply the function
>> name without the module prefix.
Craig> This is why it is important that a server's main loop should
Craig> recurse with a fully qualified call, e.g.:
Craig> server_loop() -> receive
Craig> .
Craig> .
Craig> .
Craig> ?MODULE:server_loop()
Craig> end.
Craig> This way, if a newer version of the module has been loaded,
Craig> the server will switch to it after the next message it
Craig> processes.
When using the Erlang/OTP (Open Telecom Platform), the standard
behaviours (client-server, event notification, FSMs, etc.) all
support "system messages", which allow for finer control of code
change.
In OTP, code change is orchestrated by a scriptable Release Handler,
which sends instructions to the processes in a controlled sequence.
A typical upgrade would be:
1. pre-load the code modules for a certain application
2. suspend all processes using a particular code module
3. activate (load) the code module
4. instruct the suspended processes to convert internal state
5. instruct the suspended processes to resume operation.
Everything is done behind the scenes, invisible to the user of a
standard behaviour (and fairly straightforward for others).
The responsibility of the programmer is to support step 4 above
with a "code change" function, e.g.:
code_change(NewModuleVsn, OldInternalState, ExtraArgs) ->
NewInternalState = ...,
{ok, NewInternalState}.
This is all documented in the OTP SASL User's Guide:
http://www.erlang.org/doc/doc/lib/sasl-1.6.3/doc/html/release_handling.html#4
/Uffe
* * * * * * *
PS The "suspend" function is accomplished basically as follows:
receive
{system, From, suspend} ->
sys:suspend_loop(..., State);
...
end.
Since Erlang processes buffer messages automatically, the suspend
loop simply becomes a receive loop which only cares about
system messages, like resume, change_code, etc.
From sys.erl:
http://www.erlang.org/doc/doc/lib/stdlib-1.5.2/doc/html/sys.html
%%-----------------------------------------------------------------
%% When a process is suspended, it can only respond to system
%% messages.
%%-----------------------------------------------------------------
suspend_loop(SysState, Parent, Mod, Debug, Misc) ->
receive
{system, From, Msg} ->
handle_system_msg(SysState, Msg, From, Parent, Mod, Debug, Misc);
{'EXIT', Parent, Reason} ->
apply(Mod, system_terminate, [Reason, Parent, Debug, Misc])
end.
--
Ulf Wiger, Chief Designer AXD 301
Ericsson Telecom AB tfn: +46 8 719 81 95
Varuv�gen 9, �lvsj� mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden fax: +46 8 719 43 44
In article <····················@news.rdc1.wa.home.com>,
·······@c837917-a.potlnd1.or.home.com () writes:
> ...
> If you buy the book, you get the section that describes code
Which book?
> replacement. Also the on-line book (PDF?), "Erlang in Real Time", by
> Maurice Castro, has a chapter on code replacement. Search for it at
> serc.rmit.edu.au, I downloaded it and do not have the URL handy.
I tried to look it up, but the technical document section didn't have
any downloads, and a section that seems to have Erlang related documents
is only accessible to serc members.
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
Hartmann Schaffer (··@inferno.nirvananet) wrote:
: In article <····················@news.rdc1.wa.home.com>,
: ·······@c837917-a.potlnd1.or.home.com () writes:
: > ...
: > If you buy the book, you get the section that describes code
: Which book?
Concurrent Programming in Erlang. The first section is online at
http://erlang.org/download/erlang_book_toc.html but that is just a
tutorial on the language per se and not all the great distributed and
concurrent programming features.
BTW this book costs $40 USD at Powell's in Portland, Oregon
(http://www.powells.com) but it costs $52 USD at Amazon
(http://www.amazon.com). Watch out for Amazon. They have a great UI
for user reviews, but their prices will sometimes sting you.
--
Patrick D. Logan ····················@home.com
Hartmann Schaffer (··@inferno.nirvananet) wrote:
: > Also the on-line book (PDF?), "Erlang in Real Time", by Maurice
: > Castro, has a chapter on code replacement. Search for it at
: > serc.rmit.edu.au, I downloaded it and do not have the URL handy.
: I tried to look it up, but the technical document section didn't
: have any downloads, and a section that seems to have Erlang related
: documents is only accessible to serc members.
http://www.serc.rmit.edu.au/~maurice/erlbk/
--
Patrick D. Logan ····················@home.com
From: R. Matthew Emerson
Subject: Re: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <873dyqk7la.fsf@nightfly.apk.net>
David Bakhash <·····@bu.edu> writes:
> ········@hummel.ai.univie.ac.at (Bernhard Pfahringer) writes:
>
> > As Kent has pointed out in a former message, Dylan tried to
> > improve on quite a few things which are not so nice in CL.
>
> what exactly are these things that Dylan tried to improve upon? What was
> "broken" in CL? I still don't know.
From what I can glean from Apple's preliminary (infix) Dylan book
printed in 1992, the Dylan people wanted:
something practical on small machines
to provide Pascal, C, C++ users with a dynamic alternative; they were
not aiming at the Lisp users; Apple had MCL for that (and
very nice it still is, too).
something Lisp-like, but having "objects all the way down" like Smalltalk
(thus sealing became necessary so that numbers, strings, vectors, lists,
etc., wouldn't have to go though the whole method dispatch game)
One quotation from the preface says "CL is oriented more towards
exploratory programming with delivery capability, while Dylan
is oriented more towards delivery with exploratory capability."
That's what they were (initially) aiming for anyway. Though now,
with low-end iMacs coming with 96MB of memory, I find it hard
to see how MCL (which has *tons* of room with a 15MB memory
partition) wouldn't be considered to run well on small machines.
-matt
From: David Bakhash
Subject: Re: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <cxj4sj6v6lw.fsf@acs5.bu.edu>
Though I appreciate this post, it's not what I was looking for. maybe b/c I
wanted to see more than the obvious drawbacks that people mention, like the
size of Lisp.
anyone know the specifics?
Anyway, I believe that what would help the reputation of Lisp would be:
if you have a significant piece of code (preferably using OO, i.e. CLOS), if
you specify to Lisp all of the information that you would have to give a C++
program, and the executable runs just about as fast (less than a factor of 2
difference), then I'd say that Lisp is a big win. Note that I too don't care
much for the memory, which is cheap.
I actually don't know how Lisp would fare in such a test. It would be hard to
try this. I can't imagine writing a Lisp program in which I specified the
types of every datum :-)
dave
From: Lyman S. Taylor
Subject: Re: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <378D9D3D.90B3817A@mindspring.com>
David Bakhash wrote:
...
> Anyway, I believe that what would help the reputation of Lisp would be:
>
> if you have a significant piece of code (preferably using OO, i.e. CLOS), if
> you specify to Lisp all of the information that you would have to give a C++
> program, and the executable runs just about as fast (less than a factor of 2
> difference), then I'd say that Lisp is a big win. Note that I too don't care
> much for the memory, which is cheap.
The problem is that for a heavily OO program you may not be able to do that without
either:
i. Relying on Whole Program Analysis (WPA). Lisp doesn't have the strict def-before-use
that C++ has. It also doesn't have the Dylan-like ability to place "I've seen
everything (the whole world that is interesting)" contraints on the code.
The problem with WPA is that it doesn't scale. Sure it may work for a 100,000 line
program, but for 800,000 or 1,000,000 lines.... not.
[ You can do some lightweight WPA analysis quickly, but not the heavy lifting
the Lisp code may require. ]
There is information being propogated in some of those glacially slow C++ recompiles. ;-)
or
ii. a Self-like/profile feedback dynamic compilation solution.
[ in a sense amortized WPA. ]
I'd also say that the factor of 2 is a problem. Even though Erik may resissue one of
his posts on tweaking performace out of Lisp, this is more of a problem of perception
than of technical significance. If performance is a potential problem does surface
someone will lob the "but C++ will be half as slow". If it is a matter of building
consensus in the face of resistance to using Lisp that's enough to tip the balance.
Of course "premature optimization is the root of all (most) programming evil", but it
is usually around.
---
Lyman
In article <·················@mindspring.com>, "Lyman S. Taylor" <············@mindspring.com> wrote:
> David Bakhash wrote:
> ...
> > Anyway, I believe that what would help the reputation of Lisp would be:
> >
> > if you have a significant piece of code (preferably using OO, i.e. CLOS), if
> > you specify to Lisp all of the information that you would have to give a C++
> > program, and the executable runs just about as fast (less than a factor of 2
> > difference), then I'd say that Lisp is a big win. Note that I too don't care
> > much for the memory, which is cheap.
>
> The problem is that for a heavily OO program you may not be able to do that without
> either:
>
> i. Relying on Whole Program Analysis (WPA). Lisp doesn't have the strict def-before-use
> that C++ has.
The Liquid CL and the CMU CL system have capabilities in this direction.
Liquid CL basically has two different compilers. One for interactive
use and one (more sophisticated) for batch compile.
CMU CL has some ideas of modules - details are available in the docs.
From: Lyman S. Taylor
Subject: Re: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <378E1C94.92F0396@mindspring.com>
Rainer Joswig wrote:
>
> In article <·················@mindspring.com>, "Lyman S. Taylor" <············@mindspring.com> wrote:
...
> > The problem is that for a heavily OO program you may not be able to do that without
> > either:
> >
> > i. Relying on Whole Program Analysis (WPA). Lisp doesn't have the strict def-before-use
> > that C++ has.
>
> The Liquid CL and the CMU CL system have capabilities in this direction.
> Liquid CL basically has two different compilers. One for interactive
> use and one (more sophisticated) for batch compile.
> CMU CL has some ideas of modules - details are available in the docs.
WPA is more than a "-04" setting on the compiler. "Whole Program" is meant to
connote that there are some "closed world assumptions" are used to make some
optimizations (e.g., "virtual functions" really aren't virtual). There is no
mechanism to enforce the correctness of these assumptions even if the "batch" compile
made them. Note that with a dynamic language the enforcement has to be present
at "runtime" also.
Now a CL compiler could make "closed world" persumptions anyway and if violated
would result in errant code ( sort of like dynamic redefinition of a function after
it has been inlined). However, I don't find that very satisfactory. With
proper care I could weave my way around keeping the tool from making a mistake.
However, that isn't very likely going to scale to large/complex programs.
At some point when you drift too far to the "left" toward dynamism (anything can
be redefined anytime, anywhere ) you can render making closed world observations
at an interesting program fragment level, at least interprocedural, impossible
( .... well maybe not impossible, but definately Herculean ). I think Dylan
was trying to find the spot just to "right" of the event horizon.
Finally Dylan, the language, has mechanisms to permit this. An implementation isn't
required to take advantage of these, just to enforce any specified restrictions.
---
Lyman
* Lyman S Taylor wrote:
> WPA is more than a "-04" setting on the compiler. "Whole
> Program" is meant to connote that there are some "closed
> world assumptions" are used to make some optimizations (e.g.,
> "virtual functions" really aren't virtual). There is no
> mechanism to enforce the correctness of these assumptions
> even if the "batch" compile made them. Note that with a
> dynamic language the enforcement has to be present at
> "runtime" also.
CMUCL is capable of making these kind of assumptions. You can block
compile bits of code which will do (I think) type inferencing between
functions and also cause functions to call each other by some
mechanism which forbids redefinition. This is more than
(OPTIMIZE SPEED)!
I don't think it does any of this for CLOS, but then, it doesn't
really do anything for CLOS anyway, so.
--tim
From: Lyman S. Taylor
Subject: Re: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <378EE34A.296184A0@mindspring.com>
Tim Bradshaw wrote:
>
> * Lyman S Taylor wrote:
...
> > Program" is meant to connote that there are some "closed
> > world assumptions" are used to make some optimizations (e.g.,
...
> CMUCL is capable of making these kind of assumptions. You can block
> compile bits of code which will do (I think) type inferencing between
> functions and also cause functions to call each other by some
> mechanism which forbids redefinition. This is more than
> (OPTIMIZE SPEED)!
There is a difference between "closed world" and "ignoring the outside world". :-)
That block (which I vaguely remember reading about in the Python paper which I can't
find at the moment) simply makes those functions "internally" consistant. Unless
there is enforcement outside that block it means nothing to the rest of the application.
In short, it is a cool/useful hack. However, "as is" that isn't a generally
applicable solution, IMHO. It is a start though.
This is tougher to do in the context of OO since classes and generic functions are
intended to be extended. Knowning you've reached the bounds of the extention is
what is useful. That means what happens on the "outside" of the boundary is
just as important as what is done on the "inside".
---
Lyman
From: Nick Levine
Subject: Re: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <7mkdsm$4dq$1@epos.tesco.net>
>Liquid CL basically has two different compilers. One for interactive
>use and one (more sophisticated) for batch compile.
It is true that LCL ships with two compilers. You switch between them by
proclaiming compilation-speed. Your stated reasons (interactive vs batch)
have become historical.
The faster offering ("SFC" = Simple Fast Compiler) produces massive code,
unoptimised, nothing inlined, etc, but it really does generate it very fast.
The other ("PQC" = Producation Quality Compiler, I think) is fully
optimising and very good at its job. When it comes down to the crunch, it
isn't desperately slow in its work, so there are less good arguments for the
existance of the SFC now than there were (say) 10 years ago when machines
were slower and interactive compilation could take hours if you weren't
careful about it.
Until recently, LCL images started up switched to the SFC by default. We
were talking of changing the default to PQC over the last year or so (though
I cannot guarantee that the change was made for 5.1 - maybe someone still at
Harlequin can check up on this?). There are now very few reasons for keeping
the SFC at all. The best I can think of is that occasionally (and this being
the real world, such things can happen) some user stumbles across a bug in
the depths of the PQC: some chunk of code just won't compile. OK, so bugs
can be fixed. But a dead easy workaround and one which often does the job is
to wrap that code in a (compilation-speed 3) declaration and temporarily
switch compiler. Neat, though almost certainly not what the original Lucid
hackers had in mind.
- n
From: Gareth Rees
Subject: Re: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <siemiap4nu.fsf@cre.canon.co.uk>
Nick Levine <···········@tesco.net> wrote:
> There are now very few reasons for keeping the SFC at all.
Having two compilers means that you can test them against each other.
--
Gareth Rees
From: Andy Freeman
Subject: Re: How does Lisp benefit from Dylan (was Re: Harlequin Is Back!)
Date:
Message-ID: <7mkq2u$go8$1@nnrp1.deja.com>
In article <···············@acs5.bu.edu>,
David Bakhash <·····@bu.edu> wrote:
> Anyway, I believe that what would help the reputation of Lisp would
be:
>
> if you have a significant piece of code (preferably using OO, i.e.
One of the advantages of getting old is that you see "reasonable"
things again, and if you remember what happened last time, you
realize that they're missing some important point.
There are plenty of examples of important problems where the lisp
solution was better (not just "competitive") on every technical
measure that the participants were willing to admit to, yet they'd
still reject it and, for good measure, lie about the lisp
implementation. (I've even seen folks get rid of working lisp
code for broken C code whose failure killed the whole project.)
Technical factors have, if you're really lucky, a 2nd order effect.
Usually they're third order or further into the noise.
People stay within the skill-set that they've got. If that skill-set
is "c programming", then that's what they'll do. If that skill-set
is "managing C projects", that's what they'll do. Unfortunately,
a lot of people define their skill-set by the tools they use,
not by the things that make them successful with those tools,
things which would make them successful with other tools.
-andy
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
In article <·············@www.univie.ac.at>, ········@hummel.ai.univie.ac.at (Bernhard Pfahringer) wrote:
> Also, do you believe Harlequin would have funded a development
> team the size of both the Lisp and Dylan group for solely
> CL development? I bet not.
It wouldn't be necessary.
> So this way we got more people
> working on developing dynamic languages, for some time at
> least. And I doubt that this effort will be lost, until
> now the open-source Gwydion Dylan folks and Harlequin's
> Dylan group seemed to have cooperated sensibly.
I have a different opinion on that.
> As Kent has pointed out in a former message, Dylan tried to
> improve on quite a few things which are not so nice in CL.
> My impression was that the initial goal of Dylan was to be
> a lisp-like language enabling small, efficient, stand-alone
> applications.
You might want to read the preface of the first
Dylan publications for a good summary of the
motivations of Apple.
> This was something not possible with 1990's
> Lisps.
Which is wrong. It was possible with Common Lisp
on the Mac. Apple saw that, bought the stuff and
let them develop Dylan and Macintosh Common Lisp.
Just read the first Dylan book.
People were writing Lisp apps with 5MB RAM in Mac SEs.
I did. We have an AI lab here in Hamburg which developed
sophisticated Lisp applications on Mac IIs with 8MB
RAM. Things like configuration systems with its
own object system and its own portable UI
framework.
I guess it was also possible with Golden Common Lisp
on the PC - which I haven't used much.
> There is interesting stuff for C only, you are right. E.g. the
> automatic interface generator Melange, which processes standard .h files.
> (somewhat outdated info to be found at:
> http://www.gwydiondylan.org/old-docs/maker-out/melange.htm)
MCL has a converter that eats Pascal style interface files from
Apple's libs. There are several thousands of OS level
calls directly acessible. Melange might do a bit better,
but in principle stuff like that is available since
a decade (or even more).
> >Sorry, but DUIM is a straight successor of CLIM. Nothing new here.
> >Instead CLIM remains largely unmaintained. Arghhhh. It
> >seems policy of almost all Lisp companies to not develop
> >any common GUI toolkit. In the case of CLIM I have
> >the feeling of sabotage.
> >
> Exactly, whereas with DUIM who'd have a common GUI toolkit
> (provided it is ported to Gwydion Dylan), definitely an
> advantage for Dylan.
CLIM does it already on the Lisp side - but poorly maintained.
> I see a lot of Scheme research, but not that much CL research,
> CL too is mostly commercial development, so Dylan and CL seem
> on equal footing.
Pardon? Much of the OO-research in Lisp has been done
in Common Lisp for almost a decade. CLOS was the
role model for a lot of research. Nowadays there
is for example a lot going on in areas like description logics -
with active development going on in several groups
with Lisp systems.
> To conclude, I accept you being more skeptical about Dylan
> than me, and only time will tell who's right, as they say.
I'm following this stuff since years. I remember hoping
that Apple would release the Newton with a Dylan-based
environment - at that time various rumors were floating
around - but nothing happened. So, I learned over the
years not to hold my breath...
> Bernhard
>
> PS: Self and Cecil are interesting language developments which
> should have impact on CL implementation technology as well.
Yep.
In article <·············@www.univie.ac.at>,
········@hummel.ai.univie.ac.at (Bernhard Pfahringer) writes:
> In article <·······················@pbg3.lavielle.com>,
> Rainer Joswig <······@lavielle.com> wrote:
>>> let (p, v) = find-position-and-velocity(rock, time);
>>
>>How was it done in the prefix syntax?
>>
> Good question, I'll see if I find anything in my old Apple Dylan copy
> about it. It's shelved at home, so maybe tomorrow.
(bind ((p v (find-position-and-velocity rock time)))
<body>)
Mike McDonald
·······@mikemac.com
In article <············@spitting-spider.aracnet.com>, ·······@mikemac.com wrote:
> In article <·············@www.univie.ac.at>,
> ········@hummel.ai.univie.ac.at (Bernhard Pfahringer) writes:
> > In article <·······················@pbg3.lavielle.com>,
> > Rainer Joswig <······@lavielle.com> wrote:
>
> >>> let (p, v) = find-position-and-velocity(rock, time);
> >>
> >>How was it done in the prefix syntax?
> >>
> > Good question, I'll see if I find anything in my old Apple Dylan copy
> > about it. It's shelved at home, so maybe tomorrow.
>
> (bind ((p v (find-position-and-velocity rock time)))
> <body>)
Not an exact presentation of infix advantages. ;-)
Rainer Joswig <······@lavielle.com> wrote:
+---------------
| ·······@mikemac.com wrote:
| > >>> let (p, v) = find-position-and-velocity(rock, time);
| > >>
| > >>How was it done in the prefix syntax?
| > >>
| > (bind ((p v (find-position-and-velocity rock time)))
| > <body>)
|
| Not an exact presentation of infix advantages. ;-)
+---------------
MzScheme's "let-values" is even a little cleaner, I think, by using
ordinary "let" syntax but making the destructured vars be a list, e.g.:
(let-values (((p v) (find-position-and-velocity rock time)))
<body> )
And since it's a let-like form, you can do multiple destructurings
at once [rather than a bunch of nested "multiple-value-bind"s]:
(let-values (((p0 v0) (find-position-and-velocity rock0 time))
...
((pN vN) (find-position-and-velocity rockN time)))
<body> )
I don't know Dylan's infix at all; does its "let" allow more than one
multi-valued binding in one "let"? If so, what's the syntax?
-Rob
-----
Rob Warnock, 8L-855 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. FAX: 650-933-0511
Mountain View, CA 94043 PP-ASEL-IA
Rob Warnock wrote:
>
> Rainer Joswig <······@lavielle.com> wrote:
> +---------------
> | ·······@mikemac.com wrote:
> | > >>> let (p, v) = find-position-and-velocity(rock, time);
...
> I don't know Dylan's infix at all; does its "let" allow more than one
> multi-valued binding in one "let"? If so, what's the syntax?
No.
A better way of putting is probably that it doesn't allow doing bind to more than result.
(let ( (a 1 )
(b 2 ) )
body )
would probably be written as:
let a = 1 ;
let b = 2 ;
Only that really not quite right since the more exact Lisp equivalent would be
(let ( (a 1 ) )
let ( ( b 2 ) )
body ))
The other factor here is that Dylan's let "reuses" the body terminator of the body it
appears within. So
block
let a = 1 ;
let b = 2 ;
..body...
end block ; // which really ends both the block and the two lexical scopes started
// by the lets.
So "let ..... ; " is really just a prelude to an implied body.
To do the parallel bindings, you have to use mutliple values. That negates
any of the parallel bindings being themselves multiple values ( well not without some
really messy stuff).
let ( a b ) = values ( 1 2 ) ;
The upside is that you don't need to introduce something like LET*. You save on
specifying more "end" statements. So you don't end up with sections of code that look like
end;
end;
end;
end;
[ Personally, I would have prefered to just bite the bullet since they body would be
explicitly delimted and reinforces that this construct's impact extends past the
semicolon. ]
The downside, IMHO, is that this is modeled after some sort of assignment statement.
It is not an assignment statement.
let a = 1 ;
if ( predicate ) then
let a = 2 ;
...
else
...
end if;
A newbie who's mental model is an assignment statement is likely to conclude that A is
equal to 2 after that IF.
The good news is that you could use the Dylan macro facility to write something
like:
let-values ( p1 v0) = find-position-and-velocity ( .. ) ,
....
( pN vN) = find-position-and-veclocity ( .. ) ;
which would expand into
let ( p1 v0) = find-.... ;
....
let ( pN vN) = find-..... ;
This isn't "parallel", but it would likely "get the job done". :-)
---
Lyman
> (let ( (a 1 )
> (b 2 ) )
> body )
>
> would probably be written as:
>
> let a = 1 ;
> let b = 2 ;
This reminds me of Lisp++ (I think that's what it's called - there is a link
from the ALU pages somewhere). It's a lisp implementation written in C++,
and "let" is the base class which is how you can get away with code such as
the above.
If memory serves, Lisp++ is used for the implementation of Autodesk's
"Visual Lisp".
- n (in getting-facts-wrong mode today, no doubt)
On 13 Jul 1999 19:40:54 GMT, Bernhard Pfahringer
<········@hummel.ai.univie.ac.at> wrote:
>In article <·······················@pbg3.lavielle.com>,
>Rainer Joswig <······@lavielle.com> wrote:
>>In article <·············@www.univie.ac.at>,
>>········@hummel.ai.univie.ac.at (Bernhard Pfahringer) wrote:
>>> Well, competition stipulates research, e.g. Dylan caused the following
>>> gem (IMHO):
>>>
>>> http://www.webcom.com/haahr/dylan/linearization-oopsla96.html
>>
>>I really don't think that Dylan in this case was making
>>finding this solution possible. It just happened
>>that several Lisp wizards (Moon!) were working on Dylan
>>instead on improving Lisp. At the same time many
>>people
>
>Well I don't know for this particular case, but sometimes it is easier
>to be funded for something that seems radically newer than for
>something being perceived as merely an incremental improvement. So
>this research may have been funded because it was Dylan, and might not
>have been funded had it been merely CL (wild speculations, of course).
It is *possible* that effort would be better spent on improving CL.
It is also possible that effort is best spent on something
*substantially* different so as to create a prototype that might
provide insights that wouldn't be found by doing "mere" incremental
improvements.
There needs to be room for both approaches.
It seems reasonably likely that the commercial "failure" of Dylan is
not forcibly:
a) The result of any particular "dumbness" on Harlequin's part, or
even
b) Related to the business problems at Harlequin.
From a "Lisp" point of view, Harlequin was basically a "Lisp company"
making inroads into Dylan/ML.
From the "business" standpoint, there are other views that may be far
more relevant to the business failure.
>>> Just like having two or more vendors of CL is better than one, having
>>> both CL and DYLAN seems preferable to me.
>>
>>Why?
>
>Because Dylan seems to address some points differently, like having
>an infix syntax (I prefer sexprs anytime, but I know there are people
>you would never consider sexprs). Dylan trades off some dynamicity for
>better optimization possibilities. Whether this is essential, I don't know,
>but it is interesting to have people try it out.
>Dylan also seems to try to make integration of C/C++ libraries easier.
>Harlequin developed a GUI kit called DUIM, the Gwydion Dylan folks plan
>to support/port this as well, so Dylan may soon have "standard" GUI tools.
>
>I bet, should we ever see CL3, it sure will include (swallow up) a lot
>of the good ideas developed due to Dylan. And quite some of this work
>would have been funded because of Dylan and would have never happened
>for merely CL.
These are some interesting possibilities.
>>Personally, I think the ITERATE macro stylistically much better.
>>LOOP is broken.
>>
>I should look into ITERATE, it is on my todo-list, maybe I'll convert
>:-)
LOOP is rather scary.
--
Rules of the Evil Warlord #30. "I will maintain a realistic assessment
of my strengths and weaknesses. Even though this takes some of the fun
out of the job, at least I will never utter the line "No, this cannot
be! I AM INVINCIBLE!!!" (After that, death is usually instantaneous."
········@ntlug.org- <http://www.hex.net/~cbbrowne/langlisp.html>
········@news.hex.net (Christopher Browne) writes:
> >I should look into ITERATE, it is on my todo-list, maybe I'll convert
> >:-)
>
> LOOP is rather scary.
Ever see what a +5-clause LOOP form looks like if it's manually
transformed into equally efficient code using DO, DOTIMES and DOLIST
that does the tail-pointer optimizations and everything else that LOOP
does for you???
I gave SERIES a decent time investment and I was never too impressed,
though I really wanted to be at the time because of the generally
perceived "unlispiness" (and thus perceived inferiority) of LOOP's
syntax. If I find time in the coming weeks I'll give John Amsterdam's
ITERATE a good time investment as well and if I'm not impressed then
maybe it will be time for a good ol' fashioned showdown with all these
c.l.l LOOP bashers. [i.e. "I'll transform any pure ITERATE/SERIES
routine you post into more efficient and concise ANSI LOOP code.]
One annoying thing about using LOOP is that all of the IDEs I've used
and GNU and X Emacs can't indent LOOP properly. Zmacs seems to be the
only editor in existence with this capability.
Another annoying thing - a definite weakness - of ANSI LOOP is that
there is no simple way to extend it. I remember a while back when
people here criticized LOOP for not having a way to iterate across
SEQUENCE objects, only objects of their disjoint subtypes LIST and
VECTOR. SYMBOLICS-COMMON-LISP:LOOP has DEFINE-LOOP-PATH and
DEFINE-LOOP-SEQUENCE-PATH macros to support user-extension. Here's an
example of the latter:
(define-loop-sequence-path sequence-element
(lambda (sequence index)
(elt sequence index))
length)
=> NIL
(dolist (sequence '(("we" "are" "list" "elements")
#("we" "are" "vector" "elements")))
(loop for element being the sequence-element of sequence
as format-string = "~:(~A~) " then "~A "
repeat (1- (length sequence))
do (format t format-string element)
finally (format t "~A.~%" element)))
>> We are list elements.
>> We are vector elements.
=> NIL
Hopefully the issue of user-extensibility of ANSI Common Lisp's primary
facility for iteration will be revisited by J13 in the months/years to
come....
Another gripe: I wish [FOR|AS] clauses understood a FINALLY binding
clause. I've written many LOOP forms and more often than not they could
be one to three clauses shorter for "free" if this was supported. As an
example, look at what a version of one of the above LOOPs would look
like:
(loop for element being the sequence-element of sequence
as format-string = "~:(~A~) " then "~A "
repeat (1- (length sequence))
do (format t format-string element)
finally (format t "~A.~%" element)))
==>
(loop for element being the sequence-element of sequence
as format-string = "~:(~A~) " then "~A " finally "~A.~%"
do (format t format-string element))
[Of course if you're using FORMAT you may as well use its iteration...]
(format t "~:(~A~)~{ ~A~}.~%" (car #1=(coerce sequence 'list)) (cdr #1#))
[Hopefully that kills the impact of my presentation... but maybe it
makes a case for FORMAT needing VECTOR iteration facilities.... :-) ]
Another thing is that there should be conditional execution clauses that
complement INITIALLY and FINALLY in a natural way, by executing only
when INITIALLY and FINALLY clauses do not execute. You often want to say
in a LOOP "execute this clause everytime except the first and last
iteration" and in order to do that you have to introduce a counter or
get the length of the sequence you are dealing with and then do a test
to manually check if it's not the first or last iteration. A lot of code
could be clearer if there was a way to just say that is what you wanted
to do.
Christopher
······@2xtreme.net (Christopher R. Barry) writes:
> Hopefully the issue of user-extensibility of [LOOP] will be
> revisited by J13 in the months/years to come...
That would be good, and shouldn't be hard to implement, either.
> I wish [FOR|AS] clauses understood a FINALLY binding clause.
That's quite difficult, because determining when you've come to the
last iteration is hard to do without breaking some other property of
LOOP.
> (loop for element being the sequence-element of sequence
> as format-string = "~:(~A~) " then "~A "
> repeat (1- (length sequence))
> do (format t format-string element)
> finally (format t "~A.~%" element)))
> ==>
> (loop for element being the sequence-element of sequence
> as format-string = "~:(~A~) " then "~A " finally "~A.~%"
> do (format t format-string element))
In that example, you can tell when the last iteration starts, because
you can use LENGTH, but if the termination condition is WHILE or
ALWAYS, you don't know until after executing (a part of) the body. If
an extension facility such as you wanted is also added, then it would
have to support this detection specially, which would make it rather
incompatible with existing facilities. Or you could break some of the
execution order rules -- not good.
> [Of course if you're using FORMAT you may as well use its iteration...]
> (format t "~:(~A~)~{ ~A~}.~%" (car #1=(coerce sequence 'list)) (cdr #1#))
You don't want to copy the COERCE expression, but its value. Anyway,
FORMAT can pick items off a list and then iterate down the rest:
(format t "~{~:(~A~)·@{ ~A~}~}.~%" (coerce sequence 'list)).
--
Pekka P. Pirinen
(the new) Harlequin Limited
A feature is a bug with seniority. - David Aldred <david_aldred.demon.co.uk>
"Christopher R. Barry" wrote:
> people here criticized LOOP for not having a way to iterate across
> SEQUENCE objects, only objects of their disjoint subtypes LIST and
> VECTOR. SYMBOLICS-COMMON-LISP:LOOP has DEFINE-LOOP-PATH and
> DEFINE-LOOP-SEQUENCE-PATH macros to support user-extension. Here's an
> example of the latter:
>
> (define-loop-sequence-path sequence-element
> (lambda (sequence index)
> (elt sequence index))
> length)
> => NIL
>
> (dolist (sequence '(("we" "are" "list" "elements")
> #("we" "are" "vector" "elements")))
> (loop for element being the sequence-element of sequence
> as format-string = "~:(~A~) " then "~A "
> repeat (1- (length sequence))
> do (format t format-string element)
> finally (format t "~A.~%" element)))
That looks pretty, and I suppose it works, but it changes looping
over a list into an O(n^2) operation for an n-element list.
A more realistic implementation would keep track of the current element
(for lists) or the current index (for vectors) and use #'cdr for finding
the next element of the list and #'elt for vectors. All of this behind
the scenes, of course.
Would that be possible using Symbolics loop extensions (or, for that
matter, any other implementation of LOOP)? If so, how?
> Hopefully the issue of user-extensibility of ANSI Common Lisp's primary
> facility for iteration will be revisited by J13 in the months/years to
> come....
Yes. But if general user extensibility is too complicated, it may be a
good idea to just add an extension for looping over sequences. It's
rather odd that there's a whole chapter in the ANSI spec devoted to
sequence functions, and LOOP doesn't know how to handle one.
Arthur Lemmens
Arthur Lemmens <·······@simplex.nl> writes:
> "Christopher R. Barry" wrote:
>
> > people here criticized LOOP for not having a way to iterate across
> > SEQUENCE objects, only objects of their disjoint subtypes LIST and
> > VECTOR. SYMBOLICS-COMMON-LISP:LOOP has DEFINE-LOOP-PATH and
> > DEFINE-LOOP-SEQUENCE-PATH macros to support user-extension. Here's an
> > example of the latter:
> >
> > (define-loop-sequence-path sequence-element
> > (lambda (sequence index)
> > (elt sequence index))
> > length)
> > => NIL
> >
> > (dolist (sequence '(("we" "are" "list" "elements")
> > #("we" "are" "vector" "elements")))
> > (loop for element being the sequence-element of sequence
> > as format-string = "~:(~A~) " then "~A "
> > repeat (1- (length sequence))
> > do (format t format-string element)
> > finally (format t "~A.~%" element)))
>
> That looks pretty, and I suppose it works, but it changes looping
> over a list into an O(n^2) operation for an n-element list.
The LENGTH accessor is O(1). It does not traverse the sequence on each
iteration. Conceivably, there could be a Lisp in which it wasn't O(1)
(I don't know of any), but there are C compilers that can determine if
each call to strlen() in a loop is constant and leave its return value
in place.
> A more realistic implementation would keep track of the current element
> (for lists) or the current index (for vectors) and use #'cdr for finding
> the next element of the list and #'elt for vectors. All of this behind
> the scenes, of course.
This one _does_ uses ELT for finding the next element of the sequence
"behind the scenes". The "behind the scenes" code is the
DEFINE-LOOP-SEQUENCE-PATH call before the LOOP that defines iteration
for a SEQUENCE-ELEMENT. Reread it again.
> Would that be possible using Symbolics loop extensions (or, for that
> matter, any other implementation of LOOP)? If so, how?
That's what I did!
> > Hopefully the issue of user-extensibility of ANSI Common Lisp's primary
> > facility for iteration will be revisited by J13 in the months/years to
> > come....
>
> Yes. But if general user extensibility is too complicated, it may
> be a good idea to just add an extension for looping over sequences.
General user extensibility is not too complicated. I guess you really
didn't see what my example above demonstrated. DEFINE-LOOP-PATH is
more complicated....
Christopher
Christopher R. Barry wrote:
>>> (define-loop-sequence-path sequence-element
>>> (lambda (sequence index)
>>> (elt sequence index))
>>> length)
>>> => NIL
>>>
>>> (dolist (sequence '(("we" "are" "list" "elements")
>>> #("we" "are" "vector" "elements")))
>>> (loop for element being the sequence-element of sequence
>>> as format-string = "~:(~A~) " then "~A "
>>> repeat (1- (length sequence))
>>> do (format t format-string element)
>>> finally (format t "~A.~%" element)))
>>
>> That looks pretty, and I suppose it works, but it changes looping
>> over a list into an O(n^2) operation for an n-element list.
>
> The LENGTH accessor is O(1). It does not traverse the sequence on each
> iteration. Conceivably, there could be a Lisp in which it wasn't O(1)
> (I don't know of any), but there are C compilers that can determine if
> each call to strlen() in a loop is constant and leave its return value
> in place.
It's O(N^2) because accessing each element of a list using ELT
takes time of order N^2 to access every element of the list,
because (elt list n) takes time of order N.
>> A more realistic implementation would keep track of the current element
>> (for lists) or the current index (for vectors) and use #'cdr for finding
>> the next element of the list and #'elt for vectors. All of this behind
>> the scenes, of course.
>
> This one _does_ uses ELT for finding the next element of the sequence
> "behind the scenes". The "behind the scenes" code is the
> DEFINE-LOOP-SEQUENCE-PATH call before the LOOP that defines iteration
> for a SEQUENCE-ELEMENT. Reread it again.
Note that he said "use #'cdr for finding the next element of the list".
Doesn't your code use ELT when it's given a list?
> General user extensibility is not too complicated. I guess you really
> didn't see what my example above demonstrated. DEFINE-LOOP-PATH is
> more complicated....
If the code above really loops over an n-element list in time of
order n, I'm both impressed and confused.
--
Gareth McCaughan Dept. of Pure Mathematics & Math. Statistics,
················@pobox.com Cambridge University, England.
Gareth McCaughan <················@pobox.com> writes:
> Christopher R. Barry wrote:
>
> >>> (define-loop-sequence-path sequence-element
> >>> (lambda (sequence index)
> >>> (elt sequence index))
> >>> length)
> >>> => NIL
> >>>
> >>> (dolist (sequence '(("we" "are" "list" "elements")
> >>> #("we" "are" "vector" "elements")))
> >>> (loop for element being the sequence-element of sequence
> >>> as format-string = "~:(~A~) " then "~A "
> >>> repeat (1- (length sequence))
> >>> do (format t format-string element)
> >>> finally (format t "~A.~%" element)))
> >>
> >> That looks pretty, and I suppose it works, but it changes looping
> >> over a list into an O(n^2) operation for an n-element list.
[...]
> It's O(N^2) because accessing each element of a list using ELT
> takes time of order N^2 to access every element of the list,
> because (elt list n) takes time of order N.
You can only use DEFINE-LOOP-SEQUENCE-PATH to iterate across indexable
data. DEFINE-LOOP-PATH gives more control, but is difficult to use. With
DEFINE-LOOP-PATH you define a handler-function for a LOOP interation
path that returns a really crufty list describing the details of the
iteration. It is difficult to efficiently dispatch totally different
iteration operations based on the type of the sequence because of the
strictness and constraints of creating and processing the list the
handler-function returns.
Nevertheless, I wrote a version that did all of the type-dispatching
in the LOOP prologue (using FUNCALL and closures), but it was a lot
slower than the one I have posted below, particularly for small
sequences do to the overhead of setting all that stuff up. The one
below does type checks on each iteration to determine what to
increment and do, and I don't consider it usable because of this but I
don't know how to write it any faster after wasting more time then I
should have trying.
(scl:define-loop-path sequence-element sequence-element-path
(of))
(defun sequence-element-path (path-name variable data-type
prep-phrases inclusive?
allowed-prepositions data)
(declare (ignore path-name inclusive? allowed-prepositions data))
(unless data-type
(setq data-type t))
(let* ((sequence (gensym "SEQUENCE"))
(vector? (gensym "VECTOR?"))
(index (gensym "INDEX"))
(size (gensym "SIZE")))
`(((,variable nil data-type) ;Bindings
(,sequence ,(cadar prep-phrases))
(,vector? nil)
(,index nil)
(,size nil))
((setq ,vector? (vectorp ,sequence)) ;Prologue
(setq ,index 0)
(setq ,size (if ,vector? (length ,sequence) nil)))
(if ,vector? (= ,size ,index) (null ,sequence)) ;Pre-step endtest
(,variable (if ,vector? ;Steps
(aref ,sequence ,index)
(car ,sequence))
,index (if ,vector?
(1+ ,index)
(prog1 ,index (setq ,sequence (cdr ,sequence)))))
nil ;Post-step endtest
nil))) ;Pseudo-steps
Christopher
Arthur Lemmens <·······@simplex.nl> writes:
> A more realistic implementation would keep track of the current element
> (for lists) or the current index (for vectors) and use #'cdr for finding
> the next element of the list and #'elt for vectors. All of this behind
> the scenes, of course.
>
> Would that be possible using Symbolics loop extensions (or, for that
> matter, any other implementation of LOOP)? If so, how?
Well, all sanely implemented sequence mapping functions do this, so it
shouldn't be a problem to do this in a loop path/clause/whatever.
OTOH you'd have to do a type dispatch at run-time to choose the
correct stepping forms, etc., which would probably make this a tiny
bit slower than using for-as-in/across. If done correctly probably
only a constant overhead.
(Good you bring this up, though, this reminds me that I wanted to get
back to the new implementation of sequence-mapping functions for CMU
CL ;).
> > Hopefully the issue of user-extensibility of ANSI Common Lisp's primary
> > facility for iteration will be revisited by J13 in the months/years to
> > come....
>
> Yes. But if general user extensibility is too complicated, it may be a
Well, general user extensibility isn't technically complicated, since
most LOOP implementations have some form of this (and those that
haven't probably still have this capability internally, since it
greatly eases implementation/maintenance). And if your implementation
doesn't have an extensible LOOP, you can almost always load a version
of the MIT LOOP implementation, which is user extensible[1].
The problems would mostly lie in figuring out the right way to do
this, in the face of multiple systems in one image. Since LOOP
doesn't care about packages, you can't use the package system to keep
different systems from trampling on each other's feet when extending
LOOP. MIT LOOP has something called loop universes, which might solve
the problem, but you would probably need some nice syntax to specify
which loop universe to use for a particular loop expansion. Probably
something similar to *package* and in-package. But then the question
comes up whether introducing yet another "partitioning" concept (in
addition to the package system and readtables) is such a great idea.
Especially since loop universes are such a special case.
Then there's of course the usual political problems of standardizing
something, for which existing, incompatible versions exist already...
And finally all those who find LOOP already quite confusing and
overladden will object (not without reason) to adding a mechanism for
addind yet more ill-defined, strange clauses to LOOP, thereby
making loop constructs even more difficult to read. Especially, since
there exists no mechanism of finding out about the arguments,
documentation and specification of unknown loop clauses, without
searching for the source which added them (by hand). This scales far
less than the usual extension constructs of CL, which are integrated
far better with the existing machinery, i.e. package system,
documentation strings, environmental support for displaying lambda
lists and documentation, etc.
The more you think about it, the more it seems that there must be a
better way of doing it. OTOH LOOP is here, and user-extension of LOOP
is such a neat idea, so maybe this might be worth standardizing...
Maybe as a layered component (similar to the ADA95 Appendices), so
that not everyone has to have this, but everyone that has, has to
provide it the same way...
> good idea to just add an extension for looping over sequences. It's
> rather odd that there's a whole chapter in the ANSI spec devoted to
> sequence functions, and LOOP doesn't know how to handle one.
Yes, this seems unfortunate, in a way...
Regs, Pierre.
Footnotes:
[1] Though the interface is not documented (at least to my
knowlegde), and the code is quite convoluted, so it took me an hour or
so to clearly figure out the interface conventions. If you want my
notes on this, mail me. MIT-LOOP is the standard (complex) loop
implementation for CMU CL and ACL, and can be loaded without problems
into Harlequin's LWW. For sources, check out the version from the CMU
CL source.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
>
> | Global Graphics is currently assessing Harlequin's recent
> | investments in the Information Management and Software Tools
> | business to determine opportunities and strategic direction.
You're rigth and it is not decided yet but if I put it in the context of
where money is earned ...
Regards
Friedrich
Friedrich Dominicus <···················@inka.de> wrote:
>>
>> | Global Graphics is currently assessing Harlequin's recent
>> | investments in the Information Management and Software Tools
>> | business to determine opportunities and strategic direction.
>
>You're rigth and it is not decided yet but if I put it in the context of
>where money is earned ...
then this should give us some food for thought:
"Harlequin also provides a wide range of other software development
tools. They are mostly used for internal development support and
represent only 1-2% of sales."
together with "Given the re-structuring and cost reduction efforts
already undertaken,..." with having layed off 97 people.
"...staff has been reduced from 230 people on January 1st, 1999 to 133
people today, and business therefore returned to profitability..."
this doesn't look too good for the languages.
--
Reini