Thanks,

As most purchases include one year of support, I'd guess the product
line is continuous as nobody complained about buying LW and not getting
support.

Robert

  what is generally known is that the company that bought Harlequin had no
  idea what Lisp was good for, but started a learning process some time ago
  to figure it all out, which is a very good sign: there is no evidence to
  suggest that they will treat the Lisp side of the business lightly or to
  dismiss it out of hand.  Lisp made good money for Harlequin, and there is
  ample reason to believe in the sanity of the people who bought Harlequin
  -- and they aren't in it for the quick buck, so it is very unlikely that
  they will be attempting to sell it off to somebody who is willing to pay
  as much for it as the current owners could make over the next few years.

  ML and Dylan were scuttled because they actually failed to make money.
  what I understand from what I have heard, and not all of that has been
  fully public or officially supported, is that ML and Dylan sucked the
  value out of the language group, which Lisp funded well for itself, but
  not sufficiently for a sibling language, let alone two.  (it's ironic
  that Lucid died for the same stupid reason: some quick-bucketeers tried
  to make Lisp pay for C++ development, not out of a healthy surplus, but
  out of the operations budgets.)

  although I think you should use Franz Inc's Allegro CL because I find it
  technically superior in ways that are important to me, but which may not
  be important to you, so I won't bother you with them, you should have no
  fear for the future of Lispworks and should base your decision on equal
  trust in the staying power of both Franz Inc and Harlequin.  after all,
  Lisp was but a part of Harlequin, and the problems they had were not due
  to Lisp in any way.  once again, actually, Lisp has suffered somewhat
  from being in less-than-optimal company through no fault of its own.

One indicator for the future is that our own Common Lisp-based end-user
products are winning awards --

        http://www.harlequin.com/news/press/hints_1099_1.html

-- so LispWorks has important value to other parts of Harlequin.

--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))

Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

Royalty isn't inherently bad, as it allows profit sharing with your
vendors, ensuring more aggressive product development and support, and
it may allow lower initial cost of development.

The real difficulty is to optimize pricing conditions so that you reach
the widest possible audience (customers), but you do not cannibalize
your revenue base in the process.  Royalty can be a good means of
achieving it, as the vendor's profit is dependent on your success and
profit.

Of course, it's possible that royalties are prohibitive, especially when
the ratio of royalties to your _profit_ (rather than revenue) is high.
Other conditions may also be a barrier: if there is a high price of
entry to start development or delivery, it may cancel much or all your
profits, and is a deterrent especially if you aren't sure your future
application will bring in any money.

Unrelated to this, it would be great to see vendors moving into new
market segments, like high volume and low costs.  Someone mentioned that
Franz is considering a compilerless version of their product for
scripting and similar purposes, but LWW would also be attractive if its
GUI was nicer and its image size smaller.

[pro-royalties argument with caveats deleted]

Forget about buyout if you're starting a company with your own money. Even
something as low as $25000 is a no-no.
Why should they be on charity? They already charge more than what C++
vendors do.
Royalties are only  justifiable when embedding a compiler (and NOT just to
be able to use LOAD: that's one of the main arguments for using Lisp. If I
can't do LOAD, I might just as well use Eiffel, for example (modulo macros
and stupid syntax)).

--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))

Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

  royalty is all about making application and system vendor work together,
  and as long as that is the core principle, people usually find ways to
  work together to mutual benefit.  people who do not understand this,
  don't want the vendors to succeed, or are short-sighted enough to think
  only about themselves, would, however, be likely to interpret royalty as
  a means of screwing the application vendor.  in my view, people who think
  only about themselves in any business relationship do not deserve to have
  anybody else think about them, so vendors who ignore people who present
  the case that they don't want to work together are justified in doing so.

  I seriously wonder why people think in terms that implies system vendor
  working against application vendor.  even if you think that people are
  _that_ braindamaged, you have an obligation towards others to ask them
  whether they see the world differently and have made decisions that you
  might understand if you knew about them.  people who do stuff to make
  money are generally acutely aware of a number of issues that people who
  are mainly in the business of not paying for anything never think about,
  and I personally find it incredibly insulting to have one of those latter
  people come tell me what to do with money that isn't even theirs to make
  or waste in the first place.  in other words: you may give away your own
  work at will, but just SHUT UP about the work of others.

| Royalties are only justifiable when embedding a compiler ...

  opinion noted.

The comparison with Eiffel is a bit bold, but it's possible that for you
and some people it is indeed an alternative (with the exceptions you
noted).  It would take a long time to list other significant
differences, like features, multi-vendor support, standard etc.

An alternative market model was so clearly expressed by Kent in detail a
few months ago. With some simplification, he argued that CL vendors
should charge for what makes CL special, rather than commodity stuff.  A
few examples:

Commodity features:
- sockets
- ODBC or OODB connection (alternatives from Paul Meurer and Pierre Mai)
- CORBA or DOM interface (ILU and CLORB exist as alternatives)
- ffi
- COM integracio
- threads

Specialty features:
- compiler in delivered image
- MOP (may not work as lower quality alternatives exist like Closette)

Superior Lisp features that are difficult not to include
- Macro system
- CLOS (multi-everything)
- Conditions

It is the interest of the vendor to optimize conditions such a way that
it maximizes the net present value of all future cash flows.  CL's
perceived optimum point is far from that of C++, and we haven't even
mentioned subsidies from hardware or OS vendors.  Determining who is a
poet and who is a technical writer is no easy or inexpensive task.

Summa summarum: if you can tell poets from corporate writers without
royalty and bargaining, or how to make a lot of people want to use a
word processor when they have the state-of-the-art titanium-made
typewriters, let us know.

There are signs, though: cool chrome on ACL 5, consideration of
compiler-less environments, limited Windows versions (ACL more so than
LWW) for $600.  Rather than pushing Dylan and ML, vendors could have
jumped on the Java bandwagon, leveraging their knowledge on GC, bytecode
compilers, JIT compiling, platform independence etc., selling $300
suites to hundreds of thousands.  (I'm wondering if Steele and Gosling
told about the upcoming Java push to Lisp vendors, or if Lisp vendors
were at least paid to assist in building Java compilers.)

My problem is not that someone might want to charge royalties but:

1. Perceiving that because it was OK at some point, it should always be so.
2. Ignore the existence of substitution products.
3. Trying to impose a model adapted to a high-price, low-volume specialty
market to the general one.
4. Milking your loyal customer base raising your prices by 4X, and maintaining
an (IMHO) unadapted delivery policy taking advantage of your position as
market leader.
5. Support of such policy by customers conforming to the traditional model, in
detriment of the other vendors and non-traditional customers.

In essence, I don't think it's right for people to go saying "use X (the
leader) because it's technically superior", failing to emphasize the fact that
vendor Y produces a product which is also good, and makes a serious effort to
try to adapt to the current market reality.
I believe that one makes a better service to Lisp not by sharing profits with
the market leader, but by buying the `underdog' product, and in case you reach
a point where the implementation fails to suit your requirements in some way,
then switch to the other vendor.
Of course, everything depends on scale. If you have 200 developers such a
switch would be quite expensive, and a royalty buyout that is cheaper than
that
might be feasible. You are in essence paying insurance.
Veryfing your program against two different compilers can help, too
(especially if the verifier is CMUCL), so if you're alone and you have to
shell out another, say, $5K, that's not that bad.
The `redundant' licenses could still be used for development, at least for the
protable stuff [What? You use vendor-specific modules?]

--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))

Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

  the reason you don't think it's right is that you falsely and staunchly
  believe that "market reality" is a singularity.  it isn't.  "the market"
  is a collection of an enormous amount of conflicting considerations and
  needs.  that's what makes it a market.  what you are complaining about
  (and it is complaining since you don't talk to the people in question to
  have a problem _solved_, which is what I was alluding quite strongly to
  when I said WORK TOGETHER and hinting as best as I could that you aren't
  making any effort to do that -- now you are actively working AGAINST
  somebody's decisions) is that _some_ users or customers or would-be
  customers or you are unable or unwilling to express a business case for
  yourself.  this is not somebody else's fault -- it is entirely your own
  problem that you are unable to convince somebody.  taking it out on them
  in public is unfair and also stupid: it means people who listen to you
  will not want to make any deals with you, either, in case you are unable
  to get a deal you want out of them because that would mean you go public
  with your complaints.  you are acting very unprofessionally with this
  issue.

  competitors have no reason at all to fight in the same market segments,
  by the way -- they frequently have a desire not to.  so just because you
  are in one segment that is profitable and deemed more valuable to one
  vendor does not mean you have a case for somebody else to compete with
  them on their terms in your market segment.  there are number of hard
  decision here for which I think you fail to appreciate the ramifications
  of making mistakes when making fairly arbitrary choices.  it is always
  impossible to use hindsight as a criterion for decisions, but I'll tell
  you one thing, about a great Norwegian hardware maker that tried to break
  into the U.S. market with their decidedly superior hardware:  they could
  not figure out how to price their products, so they went promiscuous and
  sold units to people with enormously varying prices.  instead of being
  happy that you could get a great deal if you pushed hard enough or were
  big enough, they were virtually chased out of the market for dumping and
  unfair business practices.  the principle at work is that people want to
  be able to have _certainty_ about your pricing model and how to influence
  it in whole or in part.  this means that some people will not be able to
  get what they want because it would be detrimental to the vendor to be
  seen as unreliable.  rather, a vendor and customer needs to WORK TOGETHER
  (there those words come up again) if they want special deals.  royalties
  is ONE WAY of doing this, for CERTAIN market realities.  if they can't or
  won't do it with royalites, they have to make the same money somehow.  if
  you have a SUGGESTION to them for how to do that, one good way to do this
  would be to approach them and tell them about your grand new scheme that
  will make them loads of money.  however, if all you are concerned about
  is getting a product at a lower price and you are not actually working
  with the concept of vendors making money, you're not dealing with ANY
  market reality, but are egoistically, short-sightedly worried about your
  own wallet, only, and as long as that is your only concern, nobody should
  listen to you, because there's never going to be anything in it for them.

| I believe that one makes a better service to Lisp not by sharing profits
| with the market leader, but by buying the `underdog' product, and in case
| you reach a point where the implementation fails to suit your
| requirements in some way, then switch to the other vendor.

  some people always think the "underdog" needs special treatment.  I don't
  believe in underdogs.  however, I do believe in special treatment where
  there are clearly long-term benefits that are hard to measure or realize
  with the standard shorter-term deals that reflect normal behavior.  this
  is what working together means.  how closely determines how special.

  however, if you don't want to work with the vendor, feel free to use a
  vendor that think this is normal, and by all means, use one that doesn't
  give you much support, either.  there are lots of languages to choose
  from where you take all the responsiblity for everything yourself and
  where you pay for upgrades and incompatibilities and whatnot.  I think
  such languages create a working-against environment between user and
  vendor, and my favorite company to dislike intensely for this is also the
  one company that people mistakenly assume is the singular market reality:
  anyone who chooses a different strategy should be chosen because they
  cause a much healthier market structure and better relationship between
  programmers in its chosen market segments.

  also, it seems unreasonably short-sighted to me that some programmers do
  not even look at the business side of their OWN work and realize that the
  less friendly their vendor, the more likely that they will have to work a
  lot harder with stuff that they are much less well equipped to handle
  well.  my quality concerns are causing huge alarms to go off when I see
  people sit down and write their own database interconnection support (to
  take but one random item I have heard about) _primarily_ because they are
  pissed at the vendor's pricing model -- and if these guys are actively
  working against the vendor, I know that the vendor and the developers
  aren't communicating to their mutual best interest, which _I_ will pay
  for by not being able to upgrade one or the other, a situation which will
  be exacerbated exponentially with the number of such packages used this
  way.  the same concern once prompted me to reject free software when it
  was obvious that there was a significant fight between vendors and the
  free software producers.  that has changed considerably and free software
  is now _often_ better than commercial software (but not always), and some
  (hardware) vendors are judged based on how well they enable cooperation
  with free software producers.  the only concern I have with any such deal
  is that the software that comes out of the process is trustable and that
  the parties involved are in it for the duration.  otherwise, it's better
  for me to use something else if I'm in it for the duration.

  if not, and it's only a short-term thing for me, too, long-term quality
  assessment is a waste of time, and I'd immediately grab the cheapest
  product with zero royalty and no support or upgrade policy and then I'd
  see what to do when I want to make another quick buck.  for some people,
  this is what constitutes "market reality", and I loathe them for it,
  because it makes it more expensive up front to get quality goods, yet so
  much easier to get cheap goods that cost more to own in the long run,
  which is a downward spiral that benefits only the cheap-product vendors,
  which are by this reasoning far from underdogs, but instead undercutters
  of a sustainable business environment.

  there is also a serious concern with companies whose assets are valuable
  enough to be salvaged from bankruptcies, but whose business strategies
  are not good enough to make the customers pay for their development: they
  instead make their creditors and investors pay for it.  this is not good
  for anybody and it is particularly bad if a product whose development
  costs have been written off in this way are then very profitable to the
  vendor at _any_ price -- the result is that bankruptcy becomes a part of
  the _survival_ process of smaller companies and longevity becomes a joke.

  I'm not going to live forever, either, of course, but it always seemed to
  me that by optimizing so heavily for the short term, there would be an
  enormous waste over the course of several short terms, and since we're
  all going to live for quite some time, _only_ thinking about what is
  possible in the youth of any short term seems completely idiotic to me,
  yet that is what people seem to delight in.  this leads me to wonder what
  values they actually get from what they are doing, but I'm digressing.

I wouldn't have to take this out in public if others weren't hinting people
to make their own decisions based on a single criterion.

You say I'm worried about my wallet. What I'm really worried about is to
have only one vendor to choose from. Supporting `the underdog',

if it's technically good enough for you and provides you with some
other benefits will hopefully help them to improve, which in turn creates
pressure for the leader to continue improving.

A final note: immediately after their Lucid acquisition,
Harlequin had maybe even more Top Gun talent than Franz.

Your comments may sometimes give someone the impression that their
technology is not good, and unless you've also seen their source code
(I know you've seen Franz's), I believe a bit more of tact is in order.

It's very important not to make Harlequin look as inept, which is not the
case.

If their code generation is not so tight as Franz, is because they have:

- Let their best drift about in projects that never ended up in a product [
you could call that research]

- Put an enormous amount of effort in alternative languages
[I don't care about Dylan either, but again, some of the things learnt while
doing that might be useful for Lisp]

- Focus from day 1 in providing an IDE for Lisp
[again, at least in its present form, I'd rather use Xemacs. But I was told
that's the reason some customers choose LispWorks]

Did I choose LispWorks in the past because of a royalty issue?
No. Because it provided a C++ interface that Franz didn't offer.
It was cool MOP technology now deprecated in favor of ORB connectivity (same
deal as Franz).
Guess what? I don't buy that.

Now, for this new project to be confirmed, do I need the ultimate allround
best in code generation?
No.

Would avoiding royalties help?
Yes.

But wouldn't it be nice to make a monolithic app including ITASCA
in its core, instead of as a separate server?
Yes.

Do I like being forced in my choice of implementation because of issues
dealing with a third-party product?
No.

Would the third party provide a choice of runtime (as they did in the past)
if there was a big enough Lisp customer base using that one?
That's the question.

--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))

Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1                   email: matomira AT acm DOT org
CH-2007 Neuchatel                 tel:       +41 (32) 720-5157
Switzerland                       FAX:       +41 (32) 720-5720

I've always been disappointed, back when we were hearing so much about
how Dylan would be able to outperform Common Lisp, that Common Lisp
implementors didn't say "no, we can do just as well, although it will
require the following implementation-specific features".  That might
have put a stop to a lot of potentially misleading claims about Dylan
vs Lisp that failed to distinguish between the Lisp language family,
the Common Lisp language, typical Common Lisp implementations,
particular Common Lisp implementation, and possible Common Lisp
implementations.

    Rainer> It never did...

Since some of the CMU Dylan group came from the CMUCL project, I would
think that they would have made Dylan at least as fast as CMUCL,
especially with all of the sealing that Dylan could have done.

Of course, they've stopped working on CMU Dylan, and the focus there
seemed to be on an integrated development environment, not necessarily
a fast language, so we'll never know...

As a Lisp guy now working in Java, I find it interesting that the Java folks
bought into this myth with HotSpot, even though nobody has ever succeeded in
producing this legendary beast despite numerous attempts, and especially in
the particular case of HotSpot, despite the evident deficiencies of Self and
HotSpot's own immediate predecessor wrt overall performance.

It should be a lesson in hubris for all of us, but it probably won't be.

Could you tell me why there are two concurrent CL implementations from
Harlequin?  What are their strengths compared to one another?  Are there
plans to merge code?  How should a customer choose between these two?

This is not to say that license fees are not necessarily a bad thing - I do
like Robert's idea of a license fee being a profit share to the licensor.
And (after all) the code is the property of the licensor and he gets to make
the rules as to the conditions of its distribution.

Ultimately, there are only three places a language vendor can make money -
the direct price of the product, licensing of the run-time, or service and
consulting.  You pay one way or another or your vendor goes out of business.