I'm considering getting LispWorks for my (NT) computer at
home. I'm aware that Harlequin was recently acquired by
another company. Does anyone have reliable information as
to that company's continued long-term support of LispWorks?
Thanks,
- Eric
Outsider's view: the Dylan business was spun off according to a press
release, but Lisp stayed part of their business. It may be an
indication that they care about it and it is (or is expected to be)
profitable.
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
Eric Scott wrote:
>
> I'm considering getting LispWorks for my (NT) computer at
> home. I'm aware that Harlequin was recently acquired by
> another company. Does anyone have reliable information as
> to that company's continued long-term support of LispWorks?
>
> Thanks,
>
> - Eric
* Eric Scott
| I'm considering getting LispWorks for my (NT) computer at home. I'm
| aware that Harlequin was recently acquired by another company. Does
| anyone have reliable information as to that company's continued long-term
| support of LispWorks?
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.
#:Erik
On 03 Nov 1999 19:19:08 +0000, Erik Naggum <····@naggum.no> wrote:
[snip]
> 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.
I saw that a new company would pick up Dylan, what happened to the
MLWorks implementation?
--
------------------------------------------------------------------
Stig Erik Sandoe ····@ii.uib.no http://www.ii.uib.no/~stig/
Erik Naggum wrote:
> 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
Business-wise Harlequin can make more sense (royalty avoidance).
--
((( DANGER )) LISP BIGOT (( DANGER )) LISP BIGOT (( DANGER )))
Fernando D. Mato Mira
Real-Time SW Eng & Networking
Advanced Systems Engineering Division
CSEM
Jaquet-Droz 1 email: matomira AT acm DOT org
CH-2007 Neuchatel tel: +41 (32) 720-5157
Switzerland FAX: +41 (32) 720-5720
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
"Fernando D. Mato Mira" wrote:
> Business-wise Harlequin can make more sense (royalty avoidance).
I think you need to pay some royalties for the Unix version of
LispWorks, or if you use the Enterprise package in general.
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.
Regards
Robert
Robert Monfera wrote:
> "Fernando D. Mato Mira" wrote:
>
> > Business-wise Harlequin can make more sense (royalty avoidance).
>
> I think you need to pay some royalties for the Unix version of
> LispWorks, or if you use the Enterprise package in general.
In these cases, yes. But the original poster was asking about NT.
[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
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
* Fernando D. Mato Mira
| 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.
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.
#:Erik
[Not specifically answering to Erik, but I have to hang this somewhere]
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
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
* "Fernando D. Mato Mira" <········@iname.com>
| 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.
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.
#:Erik
Now, how do you know I haven't actually spent 1 hour on the phone
constructively talking with the people at X in another continent at our own
expense?
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
www.csem.ch www.vrai.com ligwww.epfl.ch/matomira.html
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.
Oh well.
Jeff Dalton <····@todday.aiai.ed.ac.uk> writes:
> I've always been disappointed, back when we were hearing so much about
> how Dylan would be able to outperform Common Lisp.
Is there any hard data on that claim now? For let's say comparable
code, in both languages with fully declared types etc. Apart from
sealing I don't recall Dylan having all that many features geared
towards optimisation that CL doesn't have.
--
Lieven Marchand <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
In article <·················@todday.aiai.ed.ac.uk>, Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote:
> I've always been disappointed, back when we were hearing so much about
> how Dylan would be able to outperform Common Lisp,
It never did...
>>>>> "Rainer" == Rainer Joswig <······@lavielle.com> writes:
Rainer> In article <·················@todday.aiai.ed.ac.uk>, Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote:
>> I've always been disappointed, back when we were hearing so much about
>> how Dylan would be able to outperform Common Lisp,
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...
Ray
Raymond Toy <···@rtp.ericsson.se> wrote in message
···················@rtp.ericsson.se...
> >>>>> "Rainer" == Rainer Joswig <······@lavielle.com> writes:
>
> Rainer> In article <·················@todday.aiai.ed.ac.uk>, Jeff
Dalton <····@todday.aiai.ed.ac.uk> wrote:
> >> I've always been disappointed, back when we were hearing so much
about
> >> how Dylan would be able to outperform Common Lisp,
>
> 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...
The eternal myth of the Sufficiently Smart Compiler has been a stumbling
block for Lisp for the historical past.
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.
-- Harley
Harley Davis wrote:
> 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.
Self aka "A programming language for crashing computers."
Jonathan Coupe
On Fri, 05 Nov 1999 21:39:15 +0100, ······@lavielle.com (Rainer Joswig) wrote:
> In article <·················@todday.aiai.ed.ac.uk>, Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote:
>
> > I've always been disappointed, back when we were hearing so much about
> > how Dylan would be able to outperform Common Lisp,
>
> It never did...
Ahem. I think the jury is still out. Performance is comparable after
significantly less investment in Dylan compilers compared to CL compilers. And
you get the power of a CLOS-like object-system throughout the language.
You also get automatic separation of environment and application, like a
conventional language: so delivery of applications is straightforward. But at
the same time you still get a listener and interactive development.
I'm not saying Dylan is better than Common Lisp: I'm simply pointing out that
issue of raw performance isn't over and it wasn't the only reason for doing
Dylan.
This newsgroup isn't the intended constituency for Dylan anyway. In a sense,
Dylan is like CL boiled down and given a sugar frosting to make it more
palatable to the masses. It's hardly likely to appeal to people who like
organic food and more fibre in their diet. Ironically, however, (ex-)Lispers
are some of the people best placed to appreciate Dylan's flavour.
__Jason
In article <····························@4ax.com>, Jason Trenouth <·····@harlequin.com> wrote:
> On Fri, 05 Nov 1999 21:39:15 +0100, ······@lavielle.com (Rainer Joswig) wrote:
>
> > In article <·················@todday.aiai.ed.ac.uk>, Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote:
> >
> > > I've always been disappointed, back when we were hearing so much about
> > > how Dylan would be able to outperform Common Lisp,
> >
> > It never did...
>
> Ahem.
I was a bit trying to provoke a response. ;-)
> I think the jury is still out. Performance is comparable after
> significantly less investment in Dylan compilers compared to CL compilers.
Hmm, are there comparisons available? The one I saw was indicating
very good Common Lisp performance...
> And you get the power of a CLOS-like object-system throughout the language.
It is a lot less powerful - though I'd like to see a Lisp system
that consequently uses CLOS for "everything".
> You also get automatic separation of environment and application, like a
> conventional language:
This depends on the development environment and is not inherent
in CL or Dylan as a language?
> I'm not saying Dylan is better than Common Lisp: I'm simply pointing out that
> issue of raw performance isn't over and it wasn't the only reason for doing
> Dylan.
Right.
--
Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
On Mon, 08 Nov 1999 12:32:31 +0100, ·············@ision.de (Rainer Joswig)
wrote:
> > I think the jury is still out. Performance is comparable after
> > significantly less investment in Dylan compilers compared to CL compilers.
>
> Hmm, are there comparisons available? The one I saw was indicating
> very good Common Lisp performance...
I don't think there are any very good ones at the moment.
> > And you get the power of a CLOS-like object-system throughout the language.
>
> It is a lot less powerful - though I'd like to see a Lisp system
> that consequently uses CLOS for "everything".
Indeed. But Dylan ditched those parts of CLOS the designers thought were
unnecessary or fringe stuff: e.g. user-definable method combination.
> > You also get automatic separation of environment and application, like a
> > conventional language:
>
> This depends on the development environment and is not inherent
> in CL or Dylan as a language?
In a theoretical sense yes, but in a practical sense no. With Common Lisp (and
Smalltalk) development environments and the applications traditionally
coexist. With Dylan, development environments and applications are
traditionally tethered. This was a deliberate change of tradition to aid
delivery and the Dylan language was kept simpler and less reflective with that
in mind.
__Jason
In article <····························@4ax.com>, Jason Trenouth <·····@harlequin.com> wrote:
> Indeed. But Dylan ditched those parts of CLOS the designers thought were
> unnecessary or fringe stuff: e.g. user-definable method combination.
Even the standard method combination, IIRC.
--
Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
On Mon, 08 Nov 1999 14:22:57 +0100, ·············@ision.de (Rainer Joswig)
wrote:
> In article <····························@4ax.com>, Jason Trenouth <·····@harlequin.com> wrote:
>
> > Indeed. But Dylan ditched those parts of CLOS the designers thought were
> > unnecessary or fringe stuff: e.g. user-definable method combination.
>
> Even the standard method combination, IIRC.
That's right. There are no before, after, or around methods in Dylan. However
you do have the equivalent of call-next-method and you have to code protocols
yourself as required. It is less flexible, but personally I've debugged a
horrendous asynchronous bug as a result of different packages getting into a
muddle about doing some work "at the end" using :after and :around methods.
The fix was to introduce a separate function. I'm not saying I don't sometimes
miss the flexibility in Dylan, but rope is notoriously flexible too... :-j
__Jason
·············@ision.de (Rainer Joswig) writes:
> It is a lot less powerful - though I'd like to see a Lisp system
> that consequently uses CLOS for "everything".
What would be easier to accomplish with such a system? What
benefits do you have in mind?
--
Samir Barjoud
·····@mindspring.com
In article <··············@mindspring.com>, Samir Barjoud <·····@mindspring.com> wrote:
> ·············@ision.de (Rainer Joswig) writes:
>
> > It is a lot less powerful - though I'd like to see a Lisp system
> > that consequently uses CLOS for "everything".
>
> What would be easier to accomplish with such a system? What
> benefits do you have in mind?
Experience shows that many large commercial Lisp applications
are written in an OO-style. Additionally many newer (stuff that's
not in the standard) facilities
in Common Lisp are done using CLOS. Many existing facilities
in Common Lisp are often implemented in CLOS (even though the standard
does not demand that: streams, conditions, ...). The
old Zeta Lisp was in many respects a superset
of Common Lisp and had more facilities implemented using
OO-facilites (-> Flavors).
Biggest benefits:
- uniformity
- extensibility
- introspection
obvious candidates: functions, streams, pathnames, hashtables, arrays,
sequences, readtables, ...
--
Rainer Joswig, ISION Internet AG, Harburger Schlossstrasse 1,
21079 Hamburg, Germany, Tel: +49 40 77175 226
Email: ·············@ision.de , WWW: http://www.ision.de/
Samir Barjoud <·····@mindspring.com> writes:
> What would be easier to accomplish with such a system? What
> benefits do you have in mind?
I got a related question. Does CL have "primitive types"? I mean, can
or can't you write a method for, e.g., numbers that get dynamically
dispatched? What's the deal with the typecase macro?
Jochen
Jochen Schneider <·····@isg.cs.uni-magdeburg.de> writes:
> Samir Barjoud <·····@mindspring.com> writes:
>
> > What would be easier to accomplish with such a system? What
> > benefits do you have in mind?
>
> I got a related question. Does CL have "primitive types"? I mean, can
> or can't you write a method for, e.g., numbers that get dynamically
> dispatched? What's the deal with the typecase macro?
While you can only dispatch on classes with CLOS methods, there exist
a number of built-in classes that correspond to what you might call
primitive types.
So while you can't dispatch on (integer 0 7), which is a type-spec (as
is (satisfies evenp), or (member 0.0 7 a)), you can dispatch on
integer, ratio, rational, float, real, complex, number, character,
sequence, vector, array, string, etc.
typecase is a macro that let's you dispatch on types (described via
type-specs), but that is orthogonal to CLOS' ability to dispatch on
classes.
Here are the definitions of types and classes from the HyperSpec:
type n. 1. a set of objects, usually with common structure, behavior, or
purpose. (Note that the expression ``X is of type Sa'' naturally implies that
``X is of type Sb'' if Sa is a subtype of Sb.) 2. (immediately following the
name of a type) a subtype of that type. ``The type vector is an array type.''
type specifier n. an expression that denotes a type. ``The symbol
random-state, the list (integer 3 5), the list (and list (not null)), and the
class named standard-class are type specifiers.''
class n. 1. an object that uniquely determines the structure and behavior of a
set of other objects called its direct instances, that contributes structure
and behavior to a set of other objects called its indirect instances, and that
acts as a type specifier for a set of objects called its generalized
instances. ``The class integer is a subclass of the class number.'' (Note that
the phrase ``the class foo'' is often substituted for the more precise phrase
``the class named foo''---in both cases, a class object (not a symbol) is
denoted.) 2. (of an object) the uniquely determined class of which the object
is a direct instance. See the function class-of. ``The class of the object
returned by gensym is symbol.'' (Note that with this usage a phrase such as
``its class is foo'' is often substituted for the more precise phrase ``its
class is the class named foo''---in both cases, a class object (not a symbol)
is denoted.)
class designator n. a designator for a class; that is, an object that denotes
a class and that is one of: a symbol (denoting the class named by that symbol;
see the function find-class) or a class (denoting itself).
Regs, Pierre.
--
Pierre Mai <····@acm.org> PGP and GPG keys at your nearest Keyserver
"One smaller motivation which, in part, stems from altruism is Microsoft-
bashing." [Microsoft memo, see http://www.opensource.org/halloween1.html]
* Jochen Schneider <·····@isg.cs.uni-magdeburg.de>
| I got a related question. Does CL have "primitive types"?
yes, but we name them accurately "system classes". a _type_ is a set of
values of a given class. some languages don't have any means to express
this, so conflate "type" with "class". some languages don't have type
hierarchies and think "primitive type" is a good idea to make different
from all other types. this is an issue of forcing the user to be acutely
aware of implementational considerations on the hardware, so the types
should be more accurately be called "hardware types" and "software types"
in such languages.
| I mean, can or can't you write a method for, e.g., numbers that get
| dynamically dispatched?
yes, NUMBER is a system class. so are its two disjoint subtypes REAL and
COMPLEX, the two disjoint subtypes RATIONAL and FLOAT of REAL, and the
two disjoint subtypes INTEGER and RATIO of RATIONAL, but the subtypes
FIXNUM and BIGNUM of INTEGER and {SHORT,SINGLE,DOUBLE,LONG}-FLOAT are not
system classes. you can still dynamically dispatch on them in most CLOS
implementations, however, because they form implementation classes.
| What's the deal with the typecase macro?
it is to TYPEP what EQL is to CASE. (I don't think this answered your
question, but it is not a very answerable question -- it seems to say,
because of the preceding tone, that you disapprove of it because it isn't
OO, which is a silly reason. I can't make you approve of something you
don't yet understand, and won't waste my time to help you understand when
approval precedes understanding. back up a bit and desire to understand
before you want to approve or disapprove, and this might change.)
#:Erik
--
Attention Microsoft Shoppers! MS Monopoly Money 6.0 are now worthless.
Samir Barjoud wrote:
> ·············@ision.de (Rainer Joswig) writes:
>
> > It is a lot less powerful - though I'd like to see a Lisp system
> > that consequently uses CLOS for "everything".
>
> What would be easier to accomplish with such a system? What
> benefits do you have in mind?
You could do more smalltalkish-things. For example, if array access
was implemented via some CLOS AT method, the mapping functions
could use it. Than means your own containers could implement AT and
could be the sources for MAP commands. ( in actuality, being able to
get
iterators from everything is probably better ).
Perodically, I wish object-orientation was shot a bit more into the core
of lisp. Of course, there are speed issues, so it'd want it to be
optional.
dave
* Fernando D. Mato Mira
| Now, how do you know I haven't actually spent 1 hour on the phone
| constructively talking with the people at X in another continent at our
| own expense?
geez. just tell me what you did, and I might approve, but this is just
getting silly. if you think you can argue based on keeping stuff secret
until you think you can win an argument by disclosing it in a way that
implies that somebody ought to have known what you kept secret, you're
sadly mistaken and less constructive that I suspected to begin with.
| 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.
as far as I can see, nobody is doing that, and anyone who bases their
decisions on a single criterion aren't worth spending time on, anyway,
since you are _very_ unlikely to be the next single criterion and are
probably not going to multiply the criteria, either.
| A final note: immediately after their Lucid acquisition, Harlequin had
| maybe even more Top Gun talent than Franz.
which might imply that Franz Inc is the "underdog" in some people's view,
and that it is just as silly to base your decisions on which product to
buy on a single criterion as to choose which is the "underdog" on a single
criterion. (it seems to me as if "underdog" is your criterion of choice.)
| 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.
I fail to see how you could possibly conclude that I think or imply or
even want to communicate that their TECHNOLOGY is not good. Harlequin
has made some technical decisions that I don't approve of, and Franz Inc
has made some of their own, which should come as no surprise to anyone --
neither I nor any company can be expected never to make mistakes or even
dumb decisions for which "do not approve" is the only viable sentiment
either way -- but these are usually _survivable_ differences, especially
in a language as good as Common Lisp. that I don't like IDEs has been a
motivation for me to urge Franz Inc to keep Emacs for the Windows port of
Allegro CL (I was worried they would scuttle it from all the hype about
the IDE for Windows), but I'm open to learning what IDEs can offer and I
try them out every once in a while to see whether they suffer from the
typical GUI illness: anti-scalability of functionality.
however, Harlequin has made several _political_ and _financial_ decisions
that I don't like at all, and Franz Inc hasn't made any such decisions.
on the contrary, both their free and commercial Linux (and FreeBSD) ports
were decisions I approved of very strongly, and they do other stuff that
is concurs with my sentiments. I have also been worried at times, such
as when 5.0 took a _long_ time to come out, and I'm always afraid that
people who flirt with the Evil Empire and begin to depend on their APIs
will wind up killed in the insane rush to keep up with whatever the Evil
Empire decides to break between releases and fixes. however, they have
_not_ wasted enormous amounts of energy on failing endeavors that nearly
killed them, and that, to me, is quite important. fiscal responsibility
is important. that Harlequin laid off a bunch of excellent people in a
pretty rash move and nearly croaked soon thereafter is _not_ something I
consider beneficial when deciding whether to trust somebody, and I'm not
going to pity them with an "underdog" label, either. trust in companies
is a really big deal to me -- it's why I don't ever want to use anything
that comes out of Microsoft, for instance.
your "underdog" may be in a position right now to make a lot of easy
money from products whose costs are no longer a part of the company
budgeting because of the acquisition. I'm very critical of the process
wherein a company badly run ends up having their creditors (not their
investors and customers) pay for development projects that can then be
priced way below any competitor's ability to compete without going
through a reorganization of their own to scuttle their debts. I am not
privy to the exact process that Harlequin went through, but I have seen
companies that sell stuff too cheaply cut their costs through deliberate
reorganization sufficiently often and the attendant ramifications for
their competitors are so grim that I'm not at all pleased with the point
of view that such people are also worthy "underdogs" because they got
their creditors to bail them out. I am very happy that they survived
this ordeal intact, but they should be prepared to prove that they did
learn from the experience and are now fiscally responsible and ensure
that they get enough income from their sales so as not to have to repeat
the same stunt later. going for too low prices is not reassuring to me.
I'd be much happier with a more level playing field than this talk about
"underdogs" and the negative attitudes towards policies that _haven't_
caused anybody financial problems.
also, as I have said before and might as well repeat: I don't think Lisp
can win by competing with unprofessional languages. Common Lisp is a
language you mature into, after you've fought a bunch of other languages
and come to understand something much more complex and lasting than how
to make individual functions run fast with machine integers and addresses
(which is a valuable thing, of course, but like potty training, you don't
stop there). as a "graduate" language, I don't want it to be something
you choose out of low entry costs. students of the language should be
able to pick it up for free, essentially, but should also realize what
they have got their hands on and be willing to share their productivity
gains and the values they create because of this superior tool with the
tool-maker. it's when the tool is essentially a commodity on its own
that it makes sense to demand no royalties or cooperation with the tool
vendor, and Lisp doesn't stand a chance of becoming a commodity language,
so it's counter-productive in the extreme to attempt to jump-start the
process by removing the means of ensuring cooperative success between
system and application vendor.
this obviously doesn't mean that I think people shouldn't make small Lisp
applications and find ways to sell them at a rewarding profit -- after
all, I have grown up in a country with >50% tax on reasonable incomes,
28% corporate tax, and a 23% sales tax, so I'm not going to suggest that
any companies adopt similar measure to kill their future -- but it is
entirely appropriate to set the expectations at sharing, since small Lisp
applications haven't been the norm so far, and that's _not_ because of
the royalties policies, like some would have you believe.
#:Erik
On 06 Nov 1999 03:56:35 +0000, Erik Naggum <····@naggum.no>
wrote:
> vendor, and Lisp doesn't stand a chance of becoming a commodity language,
It's slowly becoming a commodity language, as is Smalltalk.
Corman Lisp is probably the best example of a Lisp with
a commodity attitude. Dolphin Smalltalk has the same
attitude, and is slowly taking over the Smalltalk market.
The essence of a commodity language is that it works with
a commodity operating system and has similar pricing and
support. Corman Lisp is too new to know how it's going to
do, but I would not be surprised to see it skyrocket to
become the leader in a few years.
Lisp and Smalltalk are likely to become more and more
popular as the hardware they work best with becomes less
and less costly. Dolphin Smalltalk and Corman Lisp might
become the two most popular development environments,
even more popular than Java, some number of years in the
future.
* ·············@not.for.spam (someone from Earthlink Network, Inc)
please identify yourself and then re-post your opinion. thank you.
#:Erik
--
Attention Microsoft Shoppers! MS Monopoly Money 6.0 are now worthless.
On 07 Nov 1999 00:42:59 +0000, Erik Naggum <····@naggum.no> wrote:
>* ·············@not.for.spam (someone from Earthlink Network, Inc)
>
> please identify yourself and then re-post your opinion. thank you.
>
>#:Erik
>--
> Attention Microsoft Shoppers! MS Monopoly Money 6.0 are now worthless.
Yes, I think maybe I should hire this person. :-)
Roger Corman
In article <··················@nntp.best.com>,
·····@xippix.com (Roger Corman) wrote:
> On 07 Nov 1999 00:42:59 +0000, Erik Naggum <····@naggum.no> wrote:
>
> >* ·············@not.for.spam (someone from Earthlink Network, Inc)
> >
> > please identify yourself and then re-post your opinion. thank you.
> >
> >#:Erik
> >--
> > Attention Microsoft Shoppers! MS Monopoly Money 6.0 are now
worthless.
>
> Yes, I think maybe I should hire this person. :-)
>
> Roger Corman
I thought this guy must be Mr. Corman, himself, using an alias. I guess
not. From his posting history he has consistently said nice things about
Lisp and Smalltalk. A year ago he was 45 years old and was to marry a 22
year old woman. Wonder how it turned out. :-)
--
John Watton
Alcoa Inc.
Sent via Deja.com http://www.deja.com/
Before you buy.
John Watton wrote:
>In article <··················@nntp.best.com>,
> ·····@xippix.com (Roger Corman) wrote:
>> Yes, I think maybe I should hire this person. :-)
>> Roger Corman
>I thought this guy must be Mr. Corman, himself, using an alias. I guess
>not. From his posting history he has consistently said nice things about
>Lisp and Smalltalk.
Not very likely.
Roger uses only this posting host: nntp1.ba.best.com and has a different
posting history than this guy.
Anonymus used earthlink.net and has an account there.
A quick small survey over previous posters came up with this solution:
- ·@nospam.net from <···················@news.earthlink.net> and also
<···················@news.earthlink.net> has the same posting host and
software as <··················@news.earthlink.net>. he never showed up
again in all three threads.
The other suspects have a very low probability:
- Andy freeman <······@earthlink.net> but he usually posts via deja.
- Michael Koch <·····@earthlink.net> uses a different software.
- Erann Gat or any jpl colleague (Matt Wette) because jpl.nasa.gov is a
customer of earthlink. (but this very unlikely)
--
Reini
* Fernando D Mato Mira wrote:
> Why should they be on charity? They already charge more than what C++
> vendors do.
Which C++ vendors? How much do vendors who *just* sell compilers
charge? Remember that many or all of the `C++ vendors' are actually
underpricing the compiler to encourage you to use their other
products.
--tim
"Fernando D. Mato Mira" wrote:
...
> 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)).
You have a point here - I assumed a fully dynamic image delivery, except
for a license to develop additional functions by the user.
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
> Why should they be on charity? They already charge more than what C++
> vendors do.
Imagine that word processing programs (a la WordPerfect&co) are not used
by everybody, only by writers. As it is a much smaller community,
vendors have to charge more to be financially successful. Obviously,
some writers could afford to pay multiple $k-s, for example, technical
writers and creative writers working for companies. The high prices,
however, exclude mathematicians who are poets on weekends. If vendors
lower the price so that 90% of people can buy their product, they may
realize just a fraction of the revenue compared to shooting for 20%.
(Vendors would have to strive for making word processing widespread, but
that's another story.)
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.)
Robert
Robert Monfera <·······@fisec.com> wrote in message
······················@fisec.com...
> "Fernando D. Mato Mira" wrote:
>
> > Business-wise Harlequin can make more sense (royalty avoidance).
>
> [Various apologia for license fees (which are essentially true) snipped]
One other disadvantage to license fees is that it essentially requires a
fair amount of extra book-keeping and legal expense to make sure that the
vendor is getting its payments on time. There could also be legal issues
about distributing trial or evaluation versions of the software (Does this
count as a licensed version? How are you sure the user has gotten it off
their system?) if the licensor is a stickler.
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.
faa
Frank A. Adrian <·······@uswest.net> wrote in message
·························@news.uswest.net...
>
> Robert Monfera <·······@fisec.com> wrote in message
> ······················@fisec.com...
> > "Fernando D. Mato Mira" wrote:
> >
> > > Business-wise Harlequin can make more sense (royalty avoidance).
> >
>
> > [Various apologia for license fees (which are essentially true) snipped]
>
> One other disadvantage to license fees is that it essentially requires a
> fair amount of extra book-keeping and legal expense to make sure that the
> vendor is getting its payments on time. There could also be legal issues
> about distributing trial or evaluation versions of the software (Does this
> count as a licensed version? How are you sure the user has gotten it off
> their system?) if the licensor is a stickler.
In my experience this extra aggravation is often countered by a one-time (or
yearly) buyout for a certain number of licenses based on sales estimates for
the end product. In exchange for the up-front money rather than exact
accounting, the library/language vendor gives the customer a substantial
discount.
This is convenient for high-volume products with fairly predictable high
demand. For low-volume products, the accounting is not much of an issue.
In all cases, customers balk (understandably) at royalties and will only pay
them if they feel the technology they are acquiring is indispensable and
cannot be gotten elsewhere or written by the customer. It always creates
some amount of hard feeling by the customer.
This is unfortunate to some degree. When you think about it, if you embed
lots of complicated code in your application that was written by somebody
else, it's reasonable to pay a per-piece fee as you would pay a supplier of
hardware components. On the other hand, the marginal cost of software
copying is so low that it's easy to see why one would feel ripped off for
having to pay royalties that end up being more-or-less pure profit for the
vendor.
In the end, it's all a question of supply and demand. If a vendor can get
away with charging a large annuity stream rather than a one time payment,
they will. If they can't, they won't.
-- Harley
"Fernando D. Mato Mira" <········@iname.com> writes:
> Erik Naggum wrote:
>
> > 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
>
> Business-wise Harlequin can make more sense (royalty avoidance).
Some Unix editions still have royalties. Also note that hiring a
single Lisp programmer to get a difficult job done in 6 months and
paying royalities for using Lisp can "make more sense business-wise"
than paying 3 C++ programmers for 2 years to do it....
Christopher
On Wed, 03 Nov 1999 10:32:10 -0800, Eric Scott <········@schemas.sdsu.edu>
wrote:
> I'm considering getting LispWorks for my (NT) computer at
> home. I'm aware that Harlequin was recently acquired by
> another company. Does anyone have reliable information as
> to that company's continued long-term support of LispWorks?
Despite our recent troubles, Harlequin's Common Lisps are very much alive and
kicking.
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.
__Jason
Jason Trenouth <·····@harlequin.com> writes:
> Despite our recent troubles, Harlequin's Common Lisps are very much alive and
> kicking.
So the Lucid one is still alive? Cool.
On 05 Nov 1999 17:01:24 +0000, Jeff Dalton <····@todday.aiai.ed.ac.uk> wrote:
> Jason Trenouth <·····@harlequin.com> writes:
>
> > Despite our recent troubles, Harlequin's Common Lisps are very much alive and
> > kicking.
>
> So the Lucid one is still alive? Cool.
Yup and you can use our cool IDE, Common LispWorks, to develop on it.
__Jason
Jason Trenouth wrote to Jeff:
> > So the Lucid one is still alive? Cool.
>
> Yup and you can use our cool IDE, Common LispWorks, to develop on it.
Jason,
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?
Thanks,
Robert
On Fri, 05 Nov 1999 21:36:41 -0500, Robert Monfera <·······@fisec.com> wrote:
> Jason Trenouth wrote to Jeff:
>
> > > So the Lucid one is still alive? Cool.
> >
> > Yup and you can use our cool IDE, Common LispWorks, to develop on it.
>
> Jason,
>
> Could you tell me why there are two concurrent CL implementations from
> Harlequin?
LispWorks is our original product line, and Liquid Common Lisp is the product
line acquired from Lucid when they went under.
> What are their strengths compared to one another? Are there
> plans to merge code? How should a customer choose between these two?
These are things you should discuss with Harlequin directly as it depends on
your needs, but in general existing Liquid customers are happy to continue
using it, while new customers generally choose LispWorks. In part the latter
is often because LispWorks supports the currently popular platforms (Windows
and Linux) while Liquid does not.
__Jason