Harlequin Is Back!
Phil
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
hu...@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: gra...@winwood.co.uk
Harlequin Inc. phone: 617-374-2550
One Cambridge Center fax: 617-252-6505
Cambridge, MA 02142 email: mc...@harlequin.com
==========================================================
Robert Monfera
http://www.glographics.com/pressrelease15.htm
Robert Monfera
Gareth McCaughan
> 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,
Gareth.M...@pobox.com Cambridge University, England.
Gareth McCaughan
> 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.
Rainer Joswig
> 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).
Friedrich Dominicus
> | 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
Martin Rodgers
jos...@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
Tim Bradshaw
> 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
Rainer Joswig
> 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.
Reini Urban
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
Nick Levine
>> 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)
Rainer Joswig
> >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?
Martin Rodgers
jos...@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.
Bernhard Pfahringer
Rainer Joswig <jos...@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.
>
and
>
>1) it has to be clear where the benefit for the Lisp community is
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 bern...@ai.univie.ac.at
Martin Rodgers
bern...@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.
Rainer Joswig
> 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.
Rainer Joswig
> > (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. ;-)
Kucera, Rich
manually indented with a TAB since I'm a rebel without a
training ;)
> From: bern...@hummel.ai.univie.ac.at (Bernhard Pfahringer)
> In article <joswig-1307...@pbg3.lavielle.com>,
> Rainer Joswig <jos...@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?
Kent M Pitman
> 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...
Kent M Pitman
> In article <7mfd09$1sp6$1...@www.univie.ac.at>, bern...@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.
Martin Rodgers
> 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.
Rainer Joswig
> (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
Martin Rodgers
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
Rainer Joswig
> 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.
Tim Bradshaw
> In article <sfwvhbo...@world.std.com>, Kent M Pitman <pit...@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
Martin Rodgers
> > 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.
Bernhard Pfahringer
>
>> 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
Kucera, Rich
> -----Original Message-----
> From: Tim Bradshaw [mailto:t...@tfeb.org]
> Posted At: Tuesday, July 13, 1999 2:53 PM
> Posted To: lisp
> Conversation: Harlequin Is Back!
> Subject: Re: Harlequin Is Back!
>
>
> jos...@lavielle.com (Rainer Joswig) writes:
>
> > In article <sfwvhbo...@world.std.com>, Kent M Pitman
> <pit...@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.
Rainer Joswig
> 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
> > > 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?
Craig Brozefsky
> 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 <cr...@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
Rainer Joswig
> 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
Gareth McCaughan
[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,
Gareth.M...@pobox.com Cambridge University, England.
Robert Monfera
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
Mike McDonald
bern...@hummel.ai.univie.ac.at (Bernhard Pfahringer) writes:
> In article <joswig-1307...@pbg3.lavielle.com>,
> Rainer Joswig <jos...@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
mik...@mikemac.com
Pierre R. Mai
> 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 <pm...@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]
Rainer Joswig
> > 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.
Rainer Joswig
> 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.
Lyman S. Taylor
>
> Rainer Joswig <jos...@lavielle.com> wrote:
> +---------------...
> 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
Rainer Joswig
> In article <7mg4o6$10ai$1...@www.univie.ac.at>,
> bern...@hummel.ai.univie.ac.at (Bernhard Pfahringer) writes:
> > In article <joswig-1307...@pbg3.lavielle.com>,
> > Rainer Joswig <jos...@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
> 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.
Tim Bradshaw
> 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
Tim Bradshaw
> 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
Kent M Pitman
> In article <nkjk8s4...@tfeb.org>, Tim Bradshaw <t...@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.
Christopher Browne
<jos...@lavielle.com> wrote:
>In article <86btdgz...@g.pet.cam.ac.uk>, Gareth McCaughan
>
>> > 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 *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?
cbbr...@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
Christopher Browne
<Gareth.M...@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.
>>
>> or more developers. How many years would you need
>> selling, say, $300 boxes to get that back?
>
>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
cbbr...@ntlug.org- <http://www.ntlug.org/~cbbrowne/lsf.html>
Christopher Browne
<bern...@hummel.ai.univie.ac.at> wrote:
>In article <joswig-1307...@pbg3.lavielle.com>,
>Rainer Joswig <jos...@lavielle.com> wrote:
>>In article <7mfd09$1sp6$1...@www.univie.ac.at>,
>>bern...@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
>
>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."
cbbr...@ntlug.org- <http://www.hex.net/~cbbrowne/langlisp.html>
Gareth McCaughan
>>> 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.
Rainer Joswig
> > 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...
Rainer Joswig
> >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.
Rainer Joswig
> > 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. ;-)
Rainer Joswig
> <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?
Rob Warnock
| > >>> let (p, v) = find-position-and-velocity(rock, time);
| > >>
| > >>How was it done in the prefix syntax?
| > >>
| > <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 rp...@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
Kent M Pitman
> 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.
Tim Bradshaw
> jos...@lavielle.com (Rainer Joswig) writes:
>
> > In article <nkjk8s4...@tfeb.org>, Tim Bradshaw <t...@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
Martin Rodgers
jos...@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
Martin Rodgers
> Example: BBN is moving CLIM GUIs to Java.
ISTR suggesting using Java with Lisp a few years ago, and getting
severely flamed for it. ;)
--
Tim Bradshaw
> In article <ey37lo4...@lostwithiel.tfeb.org>, Tim Bradshaw <t...@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
Chris Double
> - 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.
Chris Double
> 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.
Rainer Joswig
> 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.
Chris Double
> 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.
Rainer Joswig
> jos...@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.
Rainer Joswig
> > - 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?
Chris Double
> 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.
Chris Double
> > 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.
Rainer Joswig
> jos...@lavielle.com (Rainer Joswig) writes:
>
> > In article <ey37lo4...@lostwithiel.tfeb.org>, Tim Bradshaw <t...@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.
Nick Levine
> (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)
Chris Double
> > 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.
Bernhard Pfahringer
Rainer Joswig <jos...@lavielle.com> wrote:
>In article <7mg4o6$10ai$1...@www.univie.ac.at>, bern...@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 bern...@ai.univie.ac.at
Tim Bradshaw
> > 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
Rainer Joswig
> 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.
Rainer Joswig
> 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.
Rainer Joswig
> 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.
Rainer Joswig
> I don't think any of those languages interface to C++ well either (if
> at all).
I'd expect that you are right.
Marco Antoniotti
jos...@lavielle.com (Rainer Joswig) writes:
> In article <nkjaesza6...@tfeb.org>, Tim Bradshaw <t...@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
Rainer Joswig
> jos...@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.
Rainer Joswig
> > 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.)
Tim Bradshaw
> 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
Lars Marius Garshol
* 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.
Rainer Joswig
> 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?
Kucera, Rich
> ...
> > 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
William Deakin
> 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.
Fernando Mato Mira
> In article <wkg12r8...@ihug.co.nz>, Chris Double <c...@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).
Kucera, Rich
> 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
William Deakin
> 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
Kent M Pitman
> - 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
Not really replying to Tim here---but I couldn't find Rainer's original
message to reply to.
> jos...@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.
Rainer Joswig
> > 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.
Kucera, Rich
> 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.
Kent M Pitman
> > 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.
William Deakin
> 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
Rainer Joswig
> jos...@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.
Rainer Joswig
> 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... ;-)
William Deakin
Cheers,
:-) Will
Kent M Pitman
> 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.
William Deakin
> 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.
Rainer Joswig
> 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, ...
Kucera, Rich
> Chris Double <c...@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).
Kent M Pitman
> Kent M Pitman <pit...@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.)