Harlequin vs. Allegro
David Bakhash
Is there anyone out there who's used both Harlequin and Allegro, and
can talk about some differences, and opinions? I'm about to get a PC
running LINUX *just* so I can program in CL, but I'd like to know
why people choose one or the other.
If there's ever been a thread in this vein, then please lead me to it
in lieu of starting a new one. I do not wish to ask about religion;
just some simple stats and history (and opinions too) for a someone
who's new to CL.
dave
David Bakhash
Rainer Joswig <jos...@lavielle.com> writes:
> David Bakhash <ca...@bu.edu> writes:
>
> development environment for ACL under Linux
> is Emacs/Xemacs. Some like that, some don't.
Personally, not only do I like that, but I require it.
didn't know that Harlequin did it differently. Thanks for that info.
dave
Rainer Joswig
David Bakhash <ca...@bu.edu> writes:
> Is there anyone out there who's used both Harlequin and Allegro, and
> can talk about some differences, and opinions? I'm about to get a PC
> running LINUX *just* so I can program in CL, but I'd like to know
> why people choose one or the other.
I don't think LispWorks is available for Linux.
Have you checked with Harlequin?
ACL 4.3 and ACL 5.0 beta are freely available
for non-commercial use under Linux. The
Rainer Joswig
David Bakhash <ca...@bu.edu> writes:
> Rainer Joswig <jos...@lavielle.com> writes:
>
> > David Bakhash <ca...@bu.edu> writes:
> >
> > development environment for ACL under Linux
> > is Emacs/Xemacs. Some like that, some don't.
>
> Personally, not only do I like that, but I require it.
>
> didn't know that Harlequin did it differently. Thanks for that info.
>
> dave
If I remember right, you can use LispWorks from Emacs, too.
But it also includes a full blown development environment
(multitude of browsers, editor, user interface designer,
documentation tool, etc.). Actually I prefer to
use the IDE. Even better when it comes as an OS
(like on the Lispm). ;-)
Espen Vestre
David Bakhash <ca...@bu.edu> writes:
> Personally, not only do I like that, but I require it.
>
> didn't know that Harlequin did it differently. Thanks for that info.
but be aware that the Harlequin editor _is_ an emacs-style editor!
As far as I remember (haven't used it except for evaluation
5 years ago) it's closer to GNUEmacs than e.g. MCL's FRED
(Fred Resembles Emacs Deliberately), which is one of my favourites
(FRED has a meager built-in command set, but then it's programmable
in CLOS - great fun!).
--
regards,
Espen
Rainer Joswig
Espen Vestre <e...@nextel.no> writes:
> but be aware that the Harlequin editor _is_ an emacs-style editor!
> As far as I remember (haven't used it except for evaluation
> 5 years ago) it's closer to GNUEmacs than e.g. MCL's FRED
That's true. Does it support fonts, color, etc? I have to check.
> (Fred Resembles Emacs Deliberately), which is one of my favourites
> (FRED has a meager built-in command set, but then it's programmable
> in CLOS - great fun!).
Well, and in MCL each text field in windows usually is a FRED.
This is cool.
Don Geddis
On Tue, 16 Jun 1998 16:52:36 GMT, Zeno <ze...@deltanet.com> wrote:
> I am going to begin programming in Lisp also, and have been looking at
> Allegro. But I am a Windows programmer for Win95 and NT. Why is it
> necessary to get a Linux box?
Allegro is available under Windows NT.
> I think there's a royalty [for Allegro] or other fee to be paid for a runtime
> version when distributing the apps.
Correct.
> Does this mean that I cannot write stand-alone applications in Lisp?
I'm not sure what you mean by this. You can certainly create a standalone
image and distribute it. You just have to pay Franz for that.
> If I write a program in C++ or VB and distribute it, the compiled code is
> machine language, and what I used to write it is unimportant to the user. Is
> Lisp different in this respect?
Lisp is a much larger language, with significant built-in libraries. Every
distribution of your application requires the Lisp run-time environment.
If you use some 3rd-party C-based libraries, such as numerical analysis or
GUI code, you'd also have to pay them every time you distributed the libraries
with your application. Lisp is pretty much the same, except that these
extra libraries are always required in every application.
-- Don
--
Don Geddis ged...@tesserae.com
Tesserae Information Systems, Inc. http://tesserae.com
275 Shoreline Drive, Suite 505 (650) 508-7893
Redwood Shores, CA 94065 (650) 508-7891 [fax]
David Hanley
Zeno <ze...@deltanet.com> wrote:
> I am going to begin programming in Lisp also, and have been looking at
> Allegro. But I am a Windows programmer for Win95 and NT. Why is it
> necessary to get a Linux box?
It isn't. These things are available for NT as well. In fact,
there is a free version on the franz site.
> And this stuff is expensive, isn't it? To get run time, Allegro is 6K
> for the Enterprise version, and then I think there's a royalty or
> other fee to be paid for a runtime version when distributing the apps.
> Does this mean that I cannot write stand-alone applications in Lisp?
> If I write a program in C++ or VB and distribute it, the compiled code
> is machine language, and what I used to write it is unimportant to the
> user. Is Lisp different in this respect?
No, lisp isn't different at all in this regard. C++ or VB could
charge you for distribution, they just don't. Franz has decided that this
is a good way to earn some $$ and they are doing this. People who feel it
is worth the money will pay it. Harlequin charges $600 for their product,
with no additional fees; you can distribute until you are blue in the face
and they won't charge you a dime.
Personally, i feel this is amazingly short-sighted and
counterproductive strategy on the part of franz. We sit back an decry
the success of java ( and it has been successful! ) while lisp,
obstinently superior, has languished. Do we think those free compilers,
enviornments, and tools playes a factor? Just a theory.
> Please excuse my ignorance. I have not yet read one book or written
> one line of code with Lisp.
Not at all. Happy hacking.
> On 10 Jun 1998 10:30:35 -0400, David Bakhash <ca...@bu.edu> wrote:
dave
Steve Gonedes
ged...@meta.Tesserae.COM (Don Geddis) writes:
< > If I write a program in C++ or VB and distribute it, the compiled code is
< > machine language, and what I used to write it is unimportant to the user. Is
< > Lisp different in this respect?
I don't really think so (but what do I know), if you compile the
program of course.
< Lisp is a much larger language, with significant built-in libraries. Every
< distribution of your application requires the Lisp run-time environment.
You can dramatically reduce the size of the runtime image by ripping
out the compiler, debugger, the developer environment (forget what
this includes exactly), and toplevel in the new acl though. You can
have a splash window under windows and link to the shared acl library
so you can do your own main (), as well. I think with windows you even
get an IDE with it (which is not emacs - again, maybe it's useful to
some). Someone should find and tell Martin that there's an `OLE'
interface :)
Under windows if you use `\' as a pathname separator you still have to
escape it though. I can't believe that windows uses the escape
character (at least in C++ as well as every other language I know) for
a pathname separator still. (pathname "\\\\somewhere\\in\\") Very odd.
Oh, well - enough late night lisp advocacy.
Eric Scott
David Hanley wrote:
>
> No, lisp isn't different at all in this regard. C++ or VB could
> charge you for distribution, they just don't. Franz has decided that this
> is a good way to earn some $$ and they are doing this. People who feel it
> is worth the money will pay it. Harlequin charges $600 for their product,
> with no additional fees; you can distribute until you are blue in the face
> and they won't charge you a dime.
>
> Personally, i feel this is amazingly short-sighted and
> counterproductive strategy on the part of franz. We sit back an decry
> the success of java ( and it has been successful! ) while lisp,
> obstinently superior, has languished. Do we think those free compilers,
> enviornments, and tools playes a factor? Just a theory.
>
I am also in Zeno's position of deciding between ACL and LispWorks. In
the
case of ACL I am put off by the price, but the project I have in mind
would
require a sizable body of persistant objects, and I am attracted to the
availability of AllegroStore. I am new to OODBMS's, and have only used
MCL's WOOD, so I'm still reading up in this area. How do users of
LispWorks
typically handle their persistant data (on an NT platform?). How happy
are
ACL user's with Allegrostore?
Thanks,
Eric Scott
Cognitive Ergonomics Research Facility
San Diego State University
Paul Meurer
>
>I am also in Zeno's position of deciding between ACL and LispWorks. In
>the
>case of ACL I am put off by the price, but the project I have in mind
>would
>require a sizable body of persistant objects, and I am attracted to the
>availability of AllegroStore. I am new to OODBMS's, and have only used
>MCL's WOOD, so I'm still reading up in this area. How do users of
>LispWorks
>typically handle their persistant data (on an NT platform?). How happy
>are
>ACL user's with Allegrostore?
>
>Thanks,
>
If you want the functionality of WOOD (and much much more) in
LispWorks (4.01 on NT), you should have a look at Heiko Kirschke's
PLOB! (Persistent Lisp Objects)
<http://www.lisp.de/software/plob/Welcome.html>. This is a
full-fledged, fast client-server object oriented database (store) for
lisp objects (with b-tree indexing, transactions etc.).
Regards,
Paul
----------------------------------------------------
Paul . Meurer /at/ hit.uib.no
Humanities Information Technology Research Programme
University of Bergen
Allégaten 27
N-5007 Bergen
Norway
Rainer Joswig
Eric Scott <eric...@schemas.sdsu.edu> writes:
> LispWorks
> typically handle their persistant data (on an NT platform?).
Since LispWorks includes an SQL/ODBC interface, you can
use databases like Oracle 8.
Greetings,
Rainer Joswig
Don Geddis
On Wed, 17 Jun 1998 13:37:08 GMT, Zeno <ze...@deltanet.com> wrote:
> When you say I can distribute stand-alone apps, I take this to mean that the
> runtime version consists of a library to which we link the program? I was
> beginning to get the impression that Lisp needed some sort of shell to be
> started that it could run within.
Again, I'm not sure how technically precise you mean your question to be...
However, the answer is basically yes. Allegro Common Lisp is able to dump
a single binary image that doesn't need a shell to get it started. It would
be pretty tough for an end customer to have any idea what source language you
used to create that standalone binary image.
-- Don
--
Don Geddis ged...@tesserae.com
Tesserae Information Systems, Inc. http://tesserae.com
275 Shoreline Drive, Suite 505 (650) 508-7893
Redwood Shores, CA 94065 (650) 508-7891 [fax]
Chemistry is physics without thought; mathematics is physics without purpose.
Erik Naggum
* Zeno the Anonymous Poster
| There is a huge market of people such as myself who run 1-5 person
| programming/consulting shops and cater to businesses with 5-100
| employees. Contrary to the opinions of the larger software vendors,
| Franz must have decided that there is no market for programming languages
| there, at least not for their version of Lisp, because the pricing and
| royalties put their product out of our reach.
I'm in that market. I don't have a problem with Franz Inc's pricing.
I have several friends in similar positions as myself whose employers or
project leaders appear to have little qualms about paying for a full
license, either. I'm somewhat dismayed to hear that we don't exist and
that we constitute "no market", but I think this must go to show that
your imagination is somewhat restricted to your own immediate conditions
and that you appear to think that what you cannot imagine also cannot
exist. this is the same mental illness that afflicts Microsoft victims,
who think their sorry condition extends to the whole of the universe.
the very fortunate fact is that it doesn't.
if, on the other hand, your supposed "huge market" can present itself to
Franz Inc and be profitable for them, don't think for a minute that they
wouldn't cater to it. much to my dismay, they have already decided to
cater to Microsoft victims with a 40% discount on the Professional
Edition and a 25% discount on the Enterprise Edition, which I personally
think is a disgrace -- I don't want to have to argue against using
Microsoft's demented crudware and suffering their criminal conduct based
on the price difference of the development system, and beancounters can
be trusted to bring this issue up. an Intel box can, however, run Linux
and get away with a support license slightly more espensive than a
Professional Edition license, but it still isn't great to see that people
get rewarded by a company that should reward smart choices for making the
really stupid choice that going for Microsoft is in the long run.
my current client uses Franz Inc's ACL 5.0 for Linux offering and has
purchased a service contract, and more licenses may come as this spreads
to more systems. the service contract for Linux is a little cheaper in
the short run, but not in the longer run since it costs the same every
year instead of just a maintenance fee, so the goal is to get onto a
fully supported license once Franz Inc (hopefully) decides that Linux is
worth supporting fully. in any case, the cost of the license accounts
for less than 5% of the budgeted project costs over its (minimum) 4-year
life-time, and less than 10% of the development costs the first year.
this seems to be fairly constant in my projects.
I don't find Franz Inc's pricing to put _anything_ out of reach, neither
for me nor for my clients -- on the contrary, Franz Inc's offerings have
put some very interesting work _within_ reach for me and some fairly
complex systems within reach of relatively small budgets for my clients.
would this have happened regardless of their pricing and ability to make
money and stay healthily in business? I don't think so, and that's why
I'm worrying about their subsidizing Microsoft users, too. knowing what
tremendous costs Microsoft puts over on software developers for their
cruddy "operating systems", I have a hard time understanding the prudence
of rewarding that market with huge discounts. I'm sure those who have
yet to understand what Microsoft does to the software industry appreciate
the lower entrance costs, however.
#:Erik
--
http://www.naggum.no/spam.html is about my spam protection scheme and how
to guarantee that you reach me. in brief: if you reply to a news article
of mine, be sure to include an In-Reply-To or References header with the
message-ID of that message in it. otherwise, you need to read that page.
Tim Bradshaw
* Zeno wrote:
> There is a huge market of people such as myself who run 1-5 person
> programming/consulting shops and cater to businesses with 5-100
> employees. Contrary to the opinions of the larger software vendors,
> Franz must have decided that there is no market for programming
> languages there, at least not for their version of Lisp, because the
> pricing and royalties put their product out of our reach.
I think there is a market still -- there are small organisations which
are reasonably comfortable paying high prices for software, because
even those prices are actually rather small compared to salary costs,
so if the SW does something reasonably useful it will pay for itself
quite quickly.
However I do wish Franz would not have a run-time license as it's the
source of endless pain.
--tim
Craig Brozefsky
Tim Bradshaw <t...@aiai.ed.ac.uk> writes:
> I think there is a market still -- there are small organizations which
> are reasonably comfortable paying high prices for software, because
> even those prices are actually rather small compared to salary costs,
> so if the SW does something reasonably useful it will pay for itself
> quite quickly.
And they may also be working on projects whose length and budget make
the software purchase a negligible cost. The 15k dollar runtime for
WebObjects (I think it has come down considerably) a client purchased
was such a small portion of the development budget. The 15k dollar
runtime price is still cheaper than the expenses we saved by with
reductions in development time.
> However I do wish Franz would not have a run-time license as it's the
> source of endless pain.
No, I don't think the pain is caused by the runtime license.
A problem I see, and you can determine yourself whether it's a really a
problem, is that a lot of the trade rags and mainstream development
culture is transfixed by the thought of shrink wrap software and
making it rich with a "product" that they only have to produce once
and yet can sell an infinite number of times. If you aren't an
experienced software developer you may get the impression that this is
the only kind of software that ever gets written, and the rest is just
marginalized into non-existence.
That shrink wrap mainstream development market has seen its software
tools drastically drop in price thanks to M$ predatory pricing, the
sheer volume of sales, and general ignorance amongst its users who are
unable to demand anything better than VC++ or VB. It's hard to blame
the people coming from that market considering the sheer power of
those who have cut them off from the rest of the world and engulfed
them in the war of the feature checklists. Visual Interdev is not a
development environment, it's an elaborate torture device designed to
slowly drain the life force of its users by making them pay more and
more money trying to fix the bugs in it so that they can actually get
down to the work of producing software.
A dear friend was nearly killed during one particular mission which
took him to the deepest bowels of the MSDN knowledge base (cough
cough), which base then told him to sit and wait to download the 80
meg patch to his compiler so he could pass a string between two
previously estranged COM components. If everyone is busy trying to
get their compiler to work, and spending money to join the MSDN Mickey
Mouse club, then how are they ever going to compete against Microsoft
applications? It's like trying to beat the devil about the head and
shoulders with sin.
I have personally only ever done very small amounts of development in
that horrid environment, and the trail of tears I had to follow to
spawn and kill a process was so convoluted and laced with antediluvian
traces of OSs of bygone eras, that I swore that the density of
niggling idiotic factoids a developer had to remember to navigate that
baroque (or broken) labrynth of hackery was so great that I feared
attempting to cram them into my head would break my neck.
Now if you were to then tell someone who has suffered thru this that
their dream of taking their 500 meg todo-list manager and charging 50
dollars to every middle management drone with a M$ desktop who felt
that that todo-list manager was just what he needed to acquire the
seven habits of success--pride, lust, avarice, gluttony, sloth, envy,
and anger--requires they pay a runtime license, you could expect some
of that pent up hatred and frustration to be directed at you. It
doesn't matter much what the runtime license fee is, the reaction is
not a rational one but instead is the act of a person who has been
trained thru shock therapy to point and click their way to yet another
desktop productivity app, and your now trying to take a portion of
their food pellet reward.
Sunil Mishra
Paul....@hit.uib.no (Paul Meurer) writes:
> >
> >I am also in Zeno's position of deciding between ACL and LispWorks. In
> >the
> >case of ACL I am put off by the price, but the project I have in mind
> >would
> >require a sizable body of persistant objects, and I am attracted to the
> >availability of AllegroStore. I am new to OODBMS's, and have only used
> >MCL's WOOD, so I'm still reading up in this area. How do users of
> >LispWorks
> >typically handle their persistant data (on an NT platform?). How happy
> >are
> >ACL user's with Allegrostore?
> >
> >Thanks,
You should check with Harlequin. I believe they have a product that
provides a persistent store. I had enquired about this once, and having a
price attached immediately put it out of my league. (Being a graduate
student does put a few restrictions.)
There is also a paper out there about a system which used Oracle as a
persistent store for lispworks. That might be another option worth
following up on. I would try starting at the ALU website (I think at
http://www.elmwood.com/alu/).
> If you want the functionality of WOOD (and much much more) in
> LispWorks (4.01 on NT), you should have a look at Heiko Kirschke's
> PLOB! (Persistent Lisp Objects)
> <http://www.lisp.de/software/plob/Welcome.html>. This is a
> full-fledged, fast client-server object oriented database (store) for
> lisp objects (with b-tree indexing, transactions etc.).
Unfortunately, I believe that PLOB! requires a sun (or at least a unix box)
running the C code that manages the central persistant store. I don't know
if this would work with an NT very well.
Sunil
Dan Higdon
Craig Brozefsky wrote in message <87ra0maj...@duomo.onshore.com>...
>I have personally only ever done very small amounts of development in
>that horrid environment, and the trail of tears I had to follow to
>spawn and kill a process was so convoluted and laced with antediluvian
>traces of OSs of bygone eras, that I swore that the density of
>niggling idiotic factoids a developer had to remember to navigate that
>baroque (or broken) labrynth of hackery was so great that I feared
>attempting to cram them into my head would break my neck.
Really, it's no worse than trying to puzzle through CLOS object creation
and definition. :-) Lisp programmers (in particular Common Lisp
programmers)
have to have a huge base of knowledge to work from in order to work those
environments as well. Pick your poison. Sure, Winblowz is screwy, but
CL doesn't have a lot of room to throw stones, IMHO. Now Scheme, that's
another story. :-)
<snip> [It]
>doesn't matter much what the runtime license fee is, the reaction is
>not a rational one but instead is the act of a person who has been
>trained thru shock therapy to point and click their way to yet another
>desktop productivity app, and your now trying to take a portion of
>their food pellet reward.
But the sad fact is that customers (and I'm speaking of "market customers",
NOT "clients") do feel that way. As long as you're happy to sell only to
clients (as in consulting) and not customers (as in shrinkwrap CompUSA
walk-ins), then you can safely ignore the needs of that market. A pitty
that
the customer market is rapidly growing, very large, and full of money.
----------------------------------------
hd...@charybdis.com
"Throwing fire at the sun"
Rainer Joswig
Sunil Mishra <smi...@peachtree.cc.gatech.edu> writes:
> > If you want the functionality of WOOD (and much much more) in
> > LispWorks (4.01 on NT), you should have a look at Heiko Kirschke's
> > PLOB! (Persistent Lisp Objects)
> > <http://www.lisp.de/software/plob/Welcome.html>. This is a
> > full-fledged, fast client-server object oriented database (store) for
> > lisp objects (with b-tree indexing, transactions etc.).
>
> Unfortunately, I believe that PLOB! requires a sun (or at least a unix box)
> running the C code that manages the central persistant store. I don't know
> if this would work with an NT very well.
I think Heiko has ported it to NT. See www.lisp.de for info on Plob!.
Paul Meurer
On 18 Jun 1998 11:38:40 -0400, Sunil Mishra
<smi...@peachtree.cc.gatech.edu> wrote:
>
>Unfortunately, I believe that PLOB! requires a sun (or at least a unix box)
>running the C code that manages the central persistant store. I don't know
>if this would work with an NT very well.
>
>Sunil
No, the server too runs very well on NT (at least on my NT box ;-).
Look at Heiko´s site (the one i mentioned in my post).
Howard R. Stearns
As people have pointed out, Allegro and Lispworks (and MCL) represent
good value for their cost. They are very good systems with good
development environments.
Our Eclipse Common Lisp was designed and priced to reflect some
attitudes that I saw echoed on this thread:
+ People need to be able to deliver in flexible ways:
+ mixing code written in different languages
+ "delivering" not only as executable image applications, but as
libraries of various kinds.
+ the final application executable might need to be something other
than a Lisp saved image. (i.e. the main() could come from some
arbitrarilly remote part of a project).
+ Different people have different development environment preferences.
As good as emacs/fred and the Lisp vendor's debuggers are, it may be
necessary for people to use make, ld, gdb, etc. on complex,
inter-language projects These tools should be useable at various
stages in the development cycle.
+ Developers need a uniform programming library on all their platforms.
Library and compiler pricing should be the same on all platforms.
+ Finished applications that don't need such dynamic lisp features as
eval and compile at run time should be deliverable royalty-free.
Even those that do need all of the ANSI CL defined capability should
be no more than $500/seat, not $5000.
Accordingly, Eclipse:
+ is $500 per machine, regardless of platform.
+ has a text-based interface and generates human readable, lintable C
code that is compatible with K&R, ANSI C, and C++ compilers.
+ comes with a C-callable library that contains all the ANSI CL
utilities. This library is identical on all platforms. This can be
used by Lisp applications, or directly by hand-written C code.
+ does not require any royalties for applications that don't use eval,
compile and friends.
Nonetheless, we haven't seen the "huge market" described by some. Can
someone convince me that we did, in fact, view the situation correctly
and should not instead charge much more money and royalties?
Pierre Mai
Tim Bradshaw <t...@aiai.ed.ac.uk> writes:
> * Zeno wrote:
> > There is a huge market of people such as myself who run 1-5 person
> > programming/consulting shops and cater to businesses with 5-100
> > employees. Contrary to the opinions of the larger software vendors,
> > Franz must have decided that there is no market for programming
> > languages there, at least not for their version of Lisp, because the
> > pricing and royalties put their product out of our reach.
>
> I think there is a market still -- there are small organisations which
> are reasonably comfortable paying high prices for software, because
> even those prices are actually rather small compared to salary costs,
> so if the SW does something reasonably useful it will pay for itself
> quite quickly.
>
> However I do wish Franz would not have a run-time license as it's the
> source of endless pain.
>
Well, for those who don't need all of the add-on features that Franz
(or Harlequin) offer (like CLIM, Composer, AllegroStore, etc.), there
is Elwood's Eclipse Common Lisp, a full featured Common Lisp
implementation, which compiles CL-Code into readable and
"C-Conforming" ANSI C, for just 500 $ (95/NT, Linux, and IIRC Solaris
or HP versions available).
And because of it's C connectivity, interfacing with databases, GUI
toolkits, etc. should also be possible, just maybe not as easily as
with native Toolkits like those Franz provides.
OTOH one can always implement core functionality in CL, and build
thin interfaces/clients in other languages...
So it would seem, that CL _is_ within easy reach of small
organisations. BTW I'd also like to agree with Erik and Tim, because
I too think that Franz's pricing is not the problem that some people
like to suggest.
Regs, Pierre, who hasn't yet tried ECL, but might do so in the
future...
--
Pierre Mai <de...@cs.tu-berlin.de> http://home.pages.de/~trillian/
"Such is life." -- Fiona in "Four Weddings and a Funeral" (UK/1994)
Erik Naggum
* Zeno the Anonymous Poster
| "no market." You're statements tell me that you are very upset with what
| I wrote, but if you have paid for something, it is consistent with normal
| human nature to become emotional while defending your expenditure as
| worthwhile. I ask you to please accept my apology, as my post was not
| intended to be any kind of attack at all.
apology accepted. I don't think the psychological reasoning is exactly
what you think, though, so in the interest of expanding horizons: I'm
upset with the "huge market/no market" dichotomy of _some_ markets,
notably the Microsoft-infested one, where there aren't winners, only one
winner, and that is whoever cons the rest to their exclusion and demise.
as you have noticed, I'm strongly anti-Microsoft-business-practices and
the attendant rippling effects of dishonesty and shoddy quality. it is
important for me to point out that such is not the whole of the world and
that people need not accept what Microsoft has to offer in any area:
software products, or business practices, or "visions" of the future, or
self-serving redefinitions of the previously useful term "innovation".
so just because a market is not the one winning and crushing the rest
doesn't mean it doesn't exist. e.g., _my_ market is tiny by any measure,
but I'm happy as a clam in my very own little niche. yet, I hear all the
time that this niche that has kept me alive and independent and happy for
15 years cannot possibly exist. _that_ gets me on the defensive.
| I spoke with a representative from Franz today, and explained my whole
| operation: its size, type of tools, customers, etc.. Everything I use is
| Microsoft or plugs into Microsoft in one way or another. I have never
| had to lay my operations out like that to a software vendor before, and
| even after I did, I was not told by the Franz representative that
| discounts existed to woo us "victims" away from this "demented crudware".
ok, that was maybe too flippant an expression on my part. if you compare
the price of a license for ACL 5.0 for Windows (95/NT) with that of the
same product for Unix (apart from Linux), you'll find that it is 40% less
for the Professional Edition and 25% less for the Enterprise Edition on
Windows, and you get the Windows-specific GUI builder, which the Unix
version does not (yet) sport. so, _effectively_, Franz Inc gives you an
unhealthy (in my view) discount for using Microsoft environments when
they _should_ have rewarded the others, instead. it also seems you got
the direction of the discount wrong -- Franz Inc is effectively wooing
people to get _onto_ the demented crudware bandwagon, not off it, which
is what I would have appreciated.
| I assume that when you refer to a "support license," this means there is
| something for the customer to pay on a regular basis. When I talked to
| Franz about royalties today, it never occurred to me to ask if they were
| a yearly fee as opposed to a one-time fee.
well, everybody in the software industry has _some_ sort of fee for
upgrades and new releases. Franz Inc's policy is that you pay a fixed
annual maintenace fee (a percentage of the full license) for unlimited
support, upgrades and new releases and your license fee establishes you
in this program for the first year. then you stay in it by paying the
annual maintenance fee for subsequent years. now, once you're in that
program, there are no other costs involved, and that's the reason I think
this policy is really workable. major releases and minor are treated the
same (for 4.3 -> 5.0, there was even a _major_ price incentive to upgrade
to the Enterprise Edition to get with the runtime deal). you don't have
to pay maintenance fees for subsequent years, though -- nothing bad
happens to you or the software if you don't. e.g., support contract or
no, maintenance fee or not, does not affect your ability to pick up
patches and bug fixes from the Franz Inc FTP site, but older releases are
obviously less frequently patched than newer releases -- after all, their
software is just expected to to _work_, not suffer from disservice packs
that break more and more previously working code.
do you need the support? in my view, yes, but the reason is not that the
product is of shoddy quality -- quite the contrary, it's that it's
enormous and that you're much better off asking for help than to spend
the time delving into the innards yourself when you want to do something
that you think should be possible. not being limited by problems has a
weird tendency to make you want to do a lot more interesting stuff...
with only a few exceptions, I have found both bug-reporting and getting
help in solving problems from Franz Inc personnell to be as good as I
would expect from the free software community, where developers take high
pride in the usefulness of their software for other developers.
| This may be a wonderful product, but upon reading your post after talking
| to Franz today, I'm starting to feel like I'm dealing with used-car
| salesmen over there.
that's odd. I feel more like I'm talking to a custom bike shop where
everybody makes every effort to ensure that I get exactly what I need. I
have actually never dealt with a company (other than my own :) that has
been as willing to spend the necessary time to secure a contract that
fits all parties' needs than Franz Inc, and I can assure you that I
_need_ the security of knowing that I have a vendor's full backing when I
take a project. my business comes from reducing the risk in very high
risk projects (often close to failing by the time I get called in) to
well within normal comfort levels, and I cannot do this without trusting
my development environment and the people behind it. Franz Inc has been
willing to take part in this process with me and they provide me with the
same kind of comfort level that I try to sell my clients. for this, I am
grateful, of course, but I'm still wholly independent of Franz Inc.
| I honestly don't know if it would do me any good to ask them if there are
| yearly fees or not, as I know the answer would be, "we're willing to
| negotiate." I'm starting to think I should have hired an agent or lawyer
| to purchase Lisp for me.
well, my experience is that good lawyers are underutilized, just like
good programmers and good languages, and that they get blamed for the
bugs they try to fix, just like bad programmers and bad languages fail to
be identified as the source of the problems they cause. good lawyers
appear to cost much up front, but they actually save you a lot in the
long run. in effect, a good lawyer who walks through a license agreement
or a contract is debugging it for you before you need to use the
government-provided post mortem analyzer of contract core dumps -- the
courts. I try very hard to optimize for small debugging costs in all my
endeavors, and I find that "debugging" applies to a lot of areas.
medical doctors, for instance, are nothing more than body debuggers when
you think about it, and you'd rather the body stays warm while they debug
it -- just about anybody can learn to patch a human body if they believe
strongly enough in reincarnation, which most programmers seem to do.
by the way, if you had had a good lawyer read your license agreements
with Microsoft before you entered them, you would _never_ have used their
products. more and more companies are finding out the hard way what they
have actually agreed to -- Microsoft is aiming at becoming a legislatory
body all their own. so if you (happily) accept Microsoft's mafia-like
"license" terms, I don't understand why you have problems with Franz
Inc's very decent licensing terms, but maybe you haven't actually seen
them, or you expect to just sign them and smile. professional contract
law doesn't work that way -- both parties have interests that need
protection, and although it has taken some getting used from my country's
legal heritage, such contracts are _supposed_ to negotiated. (I hear
they are moving towards "shrink-wrap" licenses, however, a move to which
I am strongly opposed -- not the least of reasons being that European
courts have argued (and quite strongly) that you cannot be held
responsible for the terms of licenses simply after an unverified click on
some button -- anyone could have done that without the authority that
accepting the legal responsibilities for the license requires, and nobody
can be held legally responsible for license terms that are "accepted"
just because you clicked on a _previous_ version of the same.)
| You seem quite pleased that you will be able to sell more service
| contracts. I am afraid that in my ignorance, I do not know if these are
| your service contracts or service contracts you are selling for Franz.
well, I have my own license, but when I develop software for a client at
their premises or computers, my client must obtain a license for Allegro
CL, as well. if I were to develop the software in-house and sell it to a
client with a run-time license, that would entangle me in a lot of legal
snares in this country, not to mention that it would cost 23% more
because consulting is not (yet) subject to sales tax, but sold products
to which the vendor retains all rights is, even if only one copy is ever
sold. in less idiotically run countries, other conditions might apply.
to me, therefore, a development contract requires an Allegro CL license
for my client, and I usually handle everything except signing the actual
license papers as part of the contract setup. I have handled all the
negotiations with Franz Inc in the past and see no reason to stop doing
that for future contracts, either, but, again, I am not acting as a
reseller for Franz Inc for legal reasons -- I would have had to assume a
number of complicated responsibilities if I were. in a less idiotically
run country, this might again be (very) different.
I don't view myself as selling licenses for Franz Inc. I view Franz Inc
as enabling me to do seriously challenging stuff and make a fun living
doing software development again (after a bunch of years when I felt I
was caged in by C/C++), and all it requires me to do is ensure that my
clients are Franz Inc customers, too. and apparently, Franz Inc is as
happy with this arrangement as I am.
| If they are for Franz, I would be interested to know what service this
| is. I am not trying to be flippant or aggressive here. I honestly do
| not know if Franz goes to the customer's site or not. At this point, if
| you told me that your customers must pay a yearly fee because you
| developed your software with Franz tools, I doubt if I would be
| surprised.
well, be prepared to be surprised, because this is not so at all. nobody
can enforce an annual service fee unless the contract terms are really
hostile -- if you had had a lawyer go through your licenses to check for
such "design flaws", it would not even cross your mind to accept anything
like it. some predatory companies _may_ get away with it because they
don't accept that you want to negotiate their licensing terms with them
if you don't like them. Franz Inc isn't like that.
however, if the customer enters a support contract with me for subsequent
years (and most do -- they provide a comfortable sustained income), they
would need most probably want to pay the maintance fee, because I promise
to upgrade the software and fix bugs and improve performance problems and
ensure that they can switch to new hardware or operating systems if they
so desire, etc, etc, and that means they would need the upgrade policy
from Franz Inc, as well as their cooperation in switching platforms. if
the software performs to their _complete_ satisfaction on hardware that
doesn't need replacement, either, and they decide that they don't need a
support contract with me or with Franz Inc, they would be free to abandon
either of them.
| You see, I must be missing some major pieces of the puzzle, and for that
| I am sorry. If Franz's offerings provide you with work, then you must be
| acquiring clients because they're already sold on the idea of a Lisp
| system, and no one else's comes close to Franz in quality; they're
| already sold of Franz Lisp; or Franz supplies you with customers
| directly. Or perhaps I have missed something yet again.
ah, no, here's how it goes: somebody has a huge problem on their hands
that they cannot solve, and they risk losing lots of money (millions) or
have a moderate amount of money (whatever it takes to keep me and my cat
and optionally a co-worker happy for a year, say) to spend on a freshly
consed solution. so they call me do to project garbage collection.
(pardon the Lisp puns.) I spend some time figuring out whether I can be
entirely safe in promising that I can solve their problems and make their
risks of loss go away. about half the time, I cannot determine that I
would not acquire all the risks instead of removing them, so I decline to
take the project, or decide to help them in other ways, such as expert
witness in a lawsuit against the bastards who defrauded them, so they can
at least recover some of their losses that way. if I take the project,
it's because I have the means to remove their risks and make their
systems work as they expected them to and hoped they would, and often I
discover what people _really_ wanted only after they got what they
thought they wanted (and this is also very rewarding). I have yet to
meet a manager who has not listened to my choices and recommendations for
hardware and software platforms at this point, but as long as people know
that I'm willing to endure Microsoft's version of Hell only when it does
not mean I'm woul compromise any other aspect of the system's performance
or predictable behavior, I guess I just don't get calls from die-hard
Microsoft fans and other Management-by-Magazine-type managers who try to
tell me what I must do when all we know about what they told the last guy
to do got them into all of these problems to begin with. :)
| The part that I don't get is the royalties. When I called Franz about
| this today, they told me it was a percentage of what I sold the software
| for.
as should be clear by now, I am unfamiliar with this part of Franz Inc's
policies since I don't provide anyone with finished applications with a
runtime license. my delivered systems are expected to continue to run in
their development environment. (this is in fact part of the attraction
with the way I work with my clients.)
| I asked what they were willing to invest in my company, because no one
| gets part of the sale if they don't invest something in the business, the
| answer was, "We don't invest in our customer's businesses."
that must have been the purely financial answer and as such it is
probably right on the money. (I find your expectations very strange, by
the way. you have to pay royalties for the dissemintation of copies a
number of other types of intellectual property goods, and you never see
their creators invest in their (re)-sellers. I wonder how you got the
idea that the two would be tied together. was it only that the runtime
license fee is not fixed but a fraction of the price of the application,
or were other factors involved?)
apart from the financial aspects, I think Franz Inc has invested a lot in
my company and my work and my ability to serve my clients well. I have
also placed very high demands on them for my contracts and come to them
with high expectations, which they have consistently been able to fill,
albeit sometimes after intense negotiations, but this is to be expected,
in my view -- the assurances I give my clients aren't trivial, either,
and I am responsible for the whole chain of them when I accept a project.
| Franz calls their customers VARs.
I have not had that term applied to me, so, again, I cannot relate.
| Please try to understand that my goal here is not to argue against
| something I know absolutely nothing about.
I have gathered as much, and I appreciate your willingness to ask and
listen to contrary views. I hope my answers have been helpful. (I do
wish you'd sign with a full name, though.)
Erik Naggum
* Dan Higdon
| But the sad fact is that customers (and I'm speaking of "market
| customers", NOT "clients") do feel that way. As long as you're happy to
| sell only to clients (as in consulting) and not customers (as in
| shrinkwrap CompUSA walk-ins), then you can safely ignore the needs of
| that market. A pitty that the customer market is rapidly growing, very
| large, and full of money.
well, my (admittedly myopic) experience is that the "client" market grows
faster than the "customer" market because of the inherent problems in
being a customer of *huge* mass-marketing corporations who care about as
much about you as they did about he software they sold you, and that
people have acquired a greater taste and expectations for programmability
than they did in the past, ironically both because of and in spite of the
mass-marketed software. because of "scripting" and various programmable
packages, it is no longer a given that people write in assembly-language
or COBOL and spend gobs and gobs of money on trivialties. instead, we
can spend the money on adapting dynamically to the customer's _real_
needs, which differ in progressively starker ways from what some Seattle
outfits appear to think. languages like Common Lisp and Smalltalk, and
to a lesser extent newcomers like Java, are able to do capture this mode
development for "clients". C++ and its ilk are not. today's computers
are finally catching up to the demands of dynamic customer desires, and
those who discover that static software is what they get as "customers"
stop being just plain customers.
Espen Vestre
Erik Naggum <cle...@naggum.no> writes:
> version does not (yet) sport. so, _effectively_, Franz Inc gives you an
> unhealthy (in my view) discount for using Microsoft environments when
> they _should_ have rewarded the others, instead. it also seems you got
> the direction of the discount wrong -- Franz Inc is effectively wooing
> people to get _onto_ the demented crudware bandwagon, not off it, which
> is what I would have appreciated.
ACL actually was _bundled_ with the original NeXt cube!
(...good old days....)
--
(espen vestre)
Stig Hemmer
ze...@deltanet.com (Zeno) writes:
> On 18 Jun 1998 08:33:43 +0000, Erik Naggum <cle...@naggum.no> wrote:
> You are right about my not stretching my imagination enough to
> understand that there are small shops out there who wish to give a
> percentage of their profits to the maker of the tools they use to
> produce their software. I stand corrected and now understand that
> there are.
Profit is income minus expenses.
The fees to Franz is not part of your profit, it is part of your
expenses, like salary, rent, new hardware every few years, etc.
> The part that I don't get is the royalties. When I called Franz about
> this today, they told me it was a percentage of what I sold the
> software for. I asked what they were willing to invest in my company,
> because no one gets part of the sale if they don't invest something in
> the business, the answer was, "We don't invest in our customer's
> businesses."
Do the people you buy hardware from own a part of the company?
If no, why should Franz?
Stig Hemmer, who has no connection to Franz.
Rainer Joswig
Pierre Mai <de...@cs.tu-berlin.de> writes:
> So it would seem, that CL _is_ within easy reach of small
> organisations. BTW I'd also like to agree with Erik and Tim, because
> I too think that Franz's pricing is not the problem that some people
> like to suggest.
Hmm, imagine I want to install a web server based on CL-HTTP and
CL. Would I need to pay for each web server installed?
Imagine I want to use CL as a replacement for the various
sh,csh,Perl,C languages under Unix with some batch
processing running every now and then in CL. Do I need to pay
for every concurrent running batch system on every
machine? Would I need a ***site*** ***license***?
Solaris on Intel - supported?
For one Lisp development system (CL+CLIM+IDE) on Unix I would
have to pay around 15000 DM? Actually the quality of most CLIM
implementations is pathetic. Some of the IDEs are not very
convincing, either. Delivery starts with multi-multi megabyte
images?
Rainer Joswig
Espen Vestre <e...@nextel.no> writes:
> Erik Naggum <cle...@naggum.no> writes:
>
> > version does not (yet) sport. so, _effectively_, Franz Inc gives you an
> > unhealthy (in my view) discount for using Microsoft environments when
> > they _should_ have rewarded the others, instead. it also seems you got
> > the direction of the discount wrong -- Franz Inc is effectively wooing
> > people to get _onto_ the demented crudware bandwagon, not off it, which
> > is what I would have appreciated.
>
> ACL actually was _bundled_ with the original NeXt cube!
>
> (...good old days....)
Symbolics Common Lisp is still bundled with the Symbolics Lisp machines. ;-)
Tim Bradshaw
* Rainer Joswig wrote:
> Pierre Mai <de...@cs.tu-berlin.de> writes:
>> I too think that Franz's pricing is not the problem that some people
>> like to suggest.
> Hmm, imagine I want to install a web server based on CL-HTTP and
> CL. Would I need to pay for each web server installed?
I think that you're arguing at cross purposes. Of course the run-time
royalty *limits* the applications. In particular it limits
wide-spread use of the product for low cost commercial apps. That's
why I think it's a bad thing on the whole.
But, for some purposes (including some `small company' purposes) the
run-time royalty is not a problem. In particular, if the SW is giving
you a significant financial or time benefit then the royalty is just
trivial. If I'm proposing buying a data mining system at L250,000 a
license, I really am not going to stress about the runtime license for
xyz product. If I'm selling some CL-HTTP-based product at L50,000 a
license, then I'm not stressing about the license.
In fact run-time royalties are a bit like GCs. They make your
application rather slower or more expensive than optimal hand-crafted
memory management or a free-runtime. But we put up with the GC!
The crucial difference is that the GC overhead is pretty unavoidable,
while any vendor can opt not to charge a runtime license. But it is
only worth not charging a license if not doing so causes sales of
development licenses to increase enough to cover the lost revenue from
the runtime licenses. I doubt if that is the case for Allegro --
other things are holding CL back. But I could be wrong -- there could
be a whole mass of low-value things which aren't getting written
because of the royalty costs (but why aren't people writing them in
CMUCL/gcl?).
--tim
Will Hartung
Tim Bradshaw <t...@aiai.ed.ac.uk> writes:
>* Rainer Joswig wrote:
>I think that you're arguing at cross purposes. Of course the run-time
>royalty *limits* the applications. In particular it limits
>wide-spread use of the product for low cost commercial apps. That's
>why I think it's a bad thing on the whole.
To me, the biggest limitation of both the high entry cost, and the
runtime distribution policy of Franz is that it limits accessibility
to the experimenting, dabbling, proof-of-concept market.
Franz's Linux release mitigates this somewhat, but if someone wanted
to create a small application for Windoze, and then even give it away
to others, that would not be practical with Franz's Windows based
product.
For some stuff I'm doing, I needed to have connectivity to my database,
and while I may have been able to hack something up using Linux and
ACL, it was far easier to spend the $500 on Harlequins LWW with its
ODBC connection. If that path wasn't available, then I'd be SOL. The
cost of entry would have been lots-o-$$$ or lots-o-time hacking nutty
glueware to get process A to talk to database B, when I'd rather just
be experiementing with the project at hand.
Those were the compelling factors for me choosing LWW.
If my little project has success, then I've got CL making inroads into
a corporate environment. If it doesn't work out, I'm out $500 (though
not really).
And without the low experimenting entry point of LWW, I proabaly
wouldn't have tried the project at all, because I wasn't motivated
enough to do it in a language that does nothing but get in my way
during the entire experiment.
So, win-win IMHO.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Brad Might
So we've seen a lot of debate about the business models. How about
some discussion of the technical merits of these products?
Erik Naggum
* Rainer Joswig
| Hmm, imagine I want to install a web server based on CL-HTTP and CL.
| Would I need to pay for each web server installed?
I think it would make sense to draw up a proposal and present it to the
vendors and see what they say to some concrete work of yours. you can
imagine just about anything, but that doesn't mean anybody else should
take it seriously enough to tell you what they would do _if_ you got
around to do it.
also, I don't think it will work to pose hypothetical questions in an
attempt to embarrass those who obviously think they're doing the right
thing. again, anyone can ask any question -- the important issue is what
they will do with the answers. if "nothing" is the reply, I think it's
disingenious to ask it in the first place.
William Paul Vrotney
In article <w6emwlb...@gromit.nextel.no> Espen Vestre <e...@nextel.no>
writes:
>
> Erik Naggum <cle...@naggum.no> writes:
>
> > version does not (yet) sport. so, _effectively_, Franz Inc gives you an
> > unhealthy (in my view) discount for using Microsoft environments when
> > they _should_ have rewarded the others, instead. it also seems you got
> > the direction of the discount wrong -- Franz Inc is effectively wooing
> > people to get _onto_ the demented crudware bandwagon, not off it, which
> > is what I would have appreciated.
>
> ACL actually was _bundled_ with the original NeXt cube!
>
> (...good old days....)
>
Good old days is right, not only for Lisp but for NeXT! McCarthy and Jobs
were men ahead of their time. It is too bad that society's macho attitude
has to continually doom itself to mediocrity until enlightenment. In the
mean time it is up to us to keep Lisp alive and evolving until
enlightenment. Don't count on Lisp vendors, they are helplessly bound to
market share.
--
William P. Vrotney - vro...@netcom.com
Pierre Mai
Rainer Joswig <jos...@lavielle.com> writes:
> > So it would seem, that CL _is_ within easy reach of small
> > organisations. BTW I'd also like to agree with Erik and Tim, because
> > I too think that Franz's pricing is not the problem that some people
> > like to suggest.
>
> Hmm, imagine I want to install a web server based on CL-HTTP and
> CL. Would I need to pay for each web server installed?
Well, the same applies to running web servers of Lisp Machines, or of
Genera on OSF, IIRC.
Now I don't know how many web servers you install (in your job this
might be many, I know), but most organizations not specialized on
Internet-connectivity would not install that many servers, and thus
might not see a problem with this...
If OTOH you plan to develop a very clever, easy to administer web
server (maybe based on CL-HTTP, though I wonder whether the license
would allow this), and wanted to sell this to xxx customers, each
running on YYYY machines, then you might run into problems
with ACL. But OTOH Franz seems to be quite cooperative if you talk to
them, so maybe a satisfactory deal could be arranged for...
Then again, maybe ACL is not the right choice for _you_, if you plan
on doing this, and other choices might be better, like e.g. MCL, ECL,
LWW, CMU CL, etc. (MCL seems to be a preferred choice for web servers
based on CL-HTTP, see e.g. "Patching onto the Web: Common Lisp
Hypermedia for the Intranet", CACM May 1997, pp. 66).
Of course we all would love to get the whole Allegro suite for a few
hundred dollars, with royalty-free redistribution, and free upgrades,
etc. And we all would love to have Digitool enter the Unix, Linux
and/or WinNT markets with their nice product, or to get CLIM for free,
or to get Sun to modify the JVM to better support dynamic languages,
etc. etc. etc.
Yet these decisions don't seem to make economic sense for the
companies involved (whether this would bear out in reality or not
might be debatable, of course), so they don't do it. And for this I
really cannot blame them, because the last thing I want is that another
Lisp vendor bites the dust.
BTW: The criticism aimed at Franz (too expensive), has been aimed at
Digitool often enough, although their product is an order of magnitude
cheaper. Still it isn't "cheap enough", i.e. it doesn't cost less
than the throw away IDEs for Java currently being offered.
> Imagine I want to use CL as a replacement for the various
> sh,csh,Perl,C languages under Unix with some batch
> processing running every now and then in CL. Do I need to pay
> for every concurrent running batch system on every
> machine? Would I need a ***site*** ***license***?
For this kind of job, I would try CLISP, since it not only is free,
but also has a small foot-print and short startup time. Or maybe
scsh, though this is scheme.
> Solaris on Intel - supported?
Does MCL support Solaris on Intel? No? Yet surely MCL is a usable,
worthy product, or your employer wouldn't be distributing it for the
german market, would he?
> For one Lisp development system (CL+CLIM+IDE) on Unix I would
> have to pay around 15000 DM? Actually the quality of most CLIM
> implementations is pathetic. Some of the IDEs are not very
> convincing, either. Delivery starts with multi-multi megabyte
> images?
Well, then don't buy ACL! I'm surely not promoting ACL for each and every
use. I have recently pointed out ECL as a very attractive alternative
(see also my reply to Howard Stearns) for some applications, and LWW, MCL
and above all things CMU CL and CLISP are also very attractive for some of
the things one can do with CL. One size most surely doesn't fit
all...
But for the things _I_ do with CL, most of the problems you mention
just don't apply: Currently I'm redeveloping an extensive in-house
simulation-suite (originally developed in C++ and tcl/tk with some
perl) in CL for an industrial client[1]. They most surely don't give a
toss about multi megabyte images, because the data-volume produced by
these simulations is > 100MB. User-interfacing is also not a problem,
since this is decoupled from the simulation processes, and could be
handled in any language, and we have some investment in a tcl/tk-based
visualization tool which we will be leveraging in the short-run.
Actually, we currently are using CMU CL, because this is filling our
needs quite well at the moment[2], and most other vendors don't support
all the platforms we need[3]. But currently there are some platform
decisions being taken, and we are still considering alternative
implementations, with ACL and ECL being at the forefront of our
considerations... I would love to consider LWW and MCL, but
non-availability on Linux and/or OSF just precludes this.
So my main argument remains: Although price _is_ an attribute to
consider, there are many more attributes of a product that influence
purchase decisions. Also it would seem, that some of those who can't
afford to or don't want to pay the price for ACL, don't really need
all the features it has to offer, and might be better off with another
product.
Regs, Pierre.
PS: Sorry this response got so long...
Footnotes:
[1] The decision for CL was taken, after it got quite clear, that
this kind of redevelopment was impossible to do in C++, given the
constraints in manpower and time. This of course influences the
willingness to spend some money on the tools needed...
[2] Things might change, maybe because of the need for better
integration with SAP R/3, which might require ODBC connectivity, etc.,
etc.
[3] At least Linux on Intel and Digital OSF on Alpha, though Linux on
Alpha would also be nice..
Rainer Joswig
Pierre Mai <de...@cs.tu-berlin.de> writes:
> > Hmm, imagine I want to install a web server based on CL-HTTP and
> > CL. Would I need to pay for each web server installed?
>
> Well, the same applies to running web servers of Lisp Machines, or of
> Genera on OSF, IIRC.
I guess you can't compare these.
> If OTOH you plan to develop a very clever, easy to administer web
> server (maybe based on CL-HTTP, though I wonder whether the license
> would allow this),
Why not?
> Then again, maybe ACL is not the right choice for _you_, if you plan
> on doing this, and other choices might be better, like e.g. MCL, ECL,
> LWW, CMU CL, etc. (MCL seems to be a preferred choice for web servers
> based on CL-HTTP, see e.g. "Patching onto the Web: Common Lisp
> Hypermedia for the Intranet", CACM May 1997, pp. 66).
The Mac is a poor choice for Internet services in certain areas
due to cooperative multi-tasking, unsafe OS, lack of basic remote
administration facilities, etc. Still I like the OS for its interface and for MCL.
I'm about to get one of those superfast new G3 Powerbooks for
my personal MCL hacking. :-)
> etc. And we all would love to have Digitool enter the Unix, Linux
> and/or WinNT markets with their nice product, or to get CLIM for free,
> or to get Sun to modify the JVM to better support dynamic languages,
> etc. etc. etc.
Actually Harlequin's LispWorks for Windows has that attractive pricing and
royalty free delivery. Their product has good potential but it also
has some rough edges.
> really cannot blame them, because the last thing I want is that another
> Lisp vendor bites the dust.
Actually Lisp vendors seem to be quite stable. The last vendor
(Lucid) got killed by their C++ adventure, if I remember correctly.
Since then Eclipse CL has been added to the list of Lisp implementations.
> Digitool often enough, although their product is an order of magnitude
> cheaper. Still it isn't "cheap enough", i.e. it doesn't cost less
> than the throw away IDEs for Java currently being offered.
MCL is cheap enough, IMHO. One guy bought an educational copy. A month later
he sold his C++ books at a local bulletin board. ;-)
> For this kind of job, I would try CLISP, since it not only is free,
> but also has a small foot-print and short startup time. Or maybe
> scsh, though this is scheme.
We have been using both. Clisp is very nice. Still it lacks some basic
things (no CLIM, no CL-HTTP, no threads, debugging is not that
comfortable, redefinable classes
with updating objects, ...). SCSH is very useful, too. But we are going
away from Scheme if possible to concentrate on one language.
> > Solaris on Intel - supported?
>
> Does MCL support Solaris on Intel? No?
MCL is a Mac-only product specifically targetted at the Mac OS.
> Well, then don't buy ACL!
Sigh. ;-)
> But for the things _I_ do with CL, most of the problems you mention
> just don't apply: Currently I'm redeveloping an extensive in-house
> simulation-suite (originally developed in C++ and tcl/tk with some
> perl) in CL for an industrial client[1]. They most surely don't give a
> toss about multi megabyte images, because the data-volume produced by
> these simulations is > 100MB. User-interfacing is also not a problem,
> since this is decoupled from the simulation processes, and could be
> handled in any language, and we have some investment in a tcl/tk-based
> visualization tool which we will be leveraging in the short-run.
> So my main argument remains: Although price _is_ an attribute to
> consider, there are many more attributes of a product that influence
> purchase decisions.
No doubt about it. I just have the impression of the universality
of the Lispm environment. I would want similar things
on another OS (or better a modern Lispm). The Lispm
offers me the small application footprint, TCP/IP services
and a lot of high-level stuff written in Lisp (well, with
a lot of source). I would like to see more infrastructure
in Lisp with a clear software architecture and good
reusability.
> Also it would seem, that some of those who can't
> afford to or don't want to pay the price for ACL, don't really need
> all the features it has to offer, and might be better off with another
> product.
What makes ACL very attractive to me is that it is widely used and
runs a lot of software.
Btw., sounds like you have an exciting project.
Greetings,
Rainer Joswig
Pierre Mai
"Howard R. Stearns" <how...@elwood.com> writes:
> Accordingly, Eclipse:
> + is $500 per machine, regardless of platform.
> + has a text-based interface and generates human readable, lintable C
> code that is compatible with K&R, ANSI C, and C++ compilers.
> + comes with a C-callable library that contains all the ANSI CL
> utilities. This library is identical on all platforms. This can be
> used by Lisp applications, or directly by hand-written C code.
> + does not require any royalties for applications that don't use eval,
> compile and friends.
>
> Nonetheless, we haven't seen the "huge market" described by some. Can
> someone convince me that we did, in fact, view the situation correctly
> and should not instead charge much more money and royalties?
Although I have argued that ACL's price is not that much of a
problem, I'm equally prepared to try to convince you, that you
should continue ECL's pricing policy. IMHO there are projects and
customers who need the features and pricing ECL is offering, and
ECL _is_ IMHO a very promising[1] product, even for those who
don't need some of the capabilities ECL is sporting, like e.g. me.
So you should IMHO see at least a decent market. As to the "huge
market" seen by some -- I sometimes think that this is just another
instance of the following line of reasoning:
A: Lisp is cool, great whatever, _BUT_ I can't use it, because it
doesn't do X.
B: Ok, here you have an implementation which either does X out of the
box, or can easily be extended to do X.
A: Well yes, but it doesn't provide feature Y...
B: Ok, here you have ....
A: Well yes, but it doesn't interoperate with Tool/BS Z...
B: Ok, but if you do this, you can do ....
A: Ok, Ok, but CL costs way too much...
....
I.e. no matter what features you provide, and what pricing policy you
adopt, there will always be "just another something" that's still
missing, and if you provide that, too, there will be a whole mass of
customers of product XYZ who will be jumping up and down to change
over to your product...
Since ECL has already provided much of the wishlist, the customers
might just be waiting for you to provide a flashy IDE or
(cross-plattform) GUI package. I don't see the problem here, because
using ECL with existing C-based GUIs and even GUI-Builders shouldn't
be much of a problem. Of course CLIM might be nicer from a Lisp POV,
but this is exactly the point: Start using Lisp _now_, and don't wait
for the perfect, ultimate "can-do-everything" tool to appear
magically. Linux wouldn't exist, if more people had thought this way
at the beginning, and most other software, too.
So IMHO ECL is filling an important market place, which maybe has not
yet revealed it's full potential, and it would really be sad, if
Elwood would (have to) change it's pricing strategy.
Regs, Pierre.
Footnotes:
[1] I'd like to say great, or even astonishing here, but I haven't
(yet) had the chance to use ECL in a project, so I'm sadly not in the
position to comment further... ;( But this might change in the near
future... ;)
Pierre Mai
Hi Rainer!
Seems we agree more, than we disagree... ;)
Rainer Joswig <jos...@lavielle.com> writes:
> > If OTOH you plan to develop a very clever, easy to administer web
> > server (maybe based on CL-HTTP, though I wonder whether the license
> > would allow this),
>
> Why not?
I just had the impression that the CL-HTTP license was somewhat
restrictive when it comes to remarketing, but this might just've
been my imagination (haven't looked to deeply at the license for quite
some time)...
> The Mac is a poor choice for Internet services in certain areas
> due to cooperative multi-tasking, unsafe OS, lack of basic remote
> administration facilities, etc. Still I like the OS for its interface and for MCL.
> I'm about to get one of those superfast new G3 Powerbooks for
> my personal MCL hacking. :-)
Seems I should be getting a cheap PowerMac to get a chance to use
MCL <g>. I sure would like Digitool to enter the Unix/Linux arena
(though there probably would be some loss of functionality, since the
Unix arena has nothing to compete with the MacOS's interface
toolkits). Maybe Rhapsody is the solution? Who knows...
> Actually Harlequin's LispWorks for Windows has that attractive pricing and
> royalty free delivery. Their product has good potential but it also
> has some rough edges.
Yes, LWW looks interesting, but sadly there is no version for Linux
(or FreeBSD, ...) which especially my current client is starting to
use more and more...
In the same vain, ECL also looks very interesting, although it focuses
on a slightly different segment of the Lisp market than LWW does...
> MCL is cheap enough, IMHO. One guy bought an educational copy. A month later
> he sold his C++ books at a local bulletin board. ;-)
Well, for me MCL also seems cheap enough, but then again I never
bought one of those throw away IDEs ;)
> We have been using both. Clisp is very nice. Still it lacks some basic
> things (no CLIM, no CL-HTTP, no threads, debugging is not that
> comfortable, redefinable classes
> with updating objects, ...). SCSH is very useful, too. But we are
> going
Well, I wouldn't call most of these things "basic", but your point
is well taken. OTOH CLISP probably would not sport it's small
memory-footprint, if all of those features were included...
> away from Scheme if possible to concentrate on one language.
Yes, I've often come across very nice Scheme implementations (like
e.g. MzScheme/DrScheme), but since I'm more of a CL guy, I haven't
been able to use them for more than personal use...
> MCL is a Mac-only product specifically targetted at the Mac OS.
Yes, I know, I was just trying to make the point...
> No doubt about it. I just have the impression of the universality
> of the Lispm environment. I would want similar things
> on another OS (or better a modern Lispm). The Lispm
> offers me the small application footprint, TCP/IP services
> and a lot of high-level stuff written in Lisp (well, with
> a lot of source). I would like to see more infrastructure
> in Lisp with a clear software architecture and good
> reusability.
<DREAM>
Yes, this is also something I'd like to see, although I'd be weary of
another monolithic niche product like the LispMs (which weren't
"cheap" either). Also it isn't quite clear whether universality is
attainable nowadays, since the Lisp user community has diversified
further, e.g. I don't see how you'd sell the idea of another LispM to
someone who comes from the Windows world, and wants a better
replacement for VB, Delphi or VC++. Offerings like Harlequins Dylan
or LWW seem to be much more in line with their needs...
I'd rather try to get a "LispOS" environment that is not monolithic,
but permits varying depths of "Lispyness", e.g. you could host it on
top of another OS, with varying degrees of integration, and you could
go down to just above the hardware level (e.g. based on a microkernel,
for easy portability). And all of this would still enable your
applications to run unchanged...
Given this, and some really cheap high-powered hardware (like e.g. the
ARM-based NetWinder products from Corel Computing could become), you
could develop on a pure LispOS machine, and deploy on stock Intel/MS
plattforms. And once your client has seen "the light", you could
switch over to "custom" LispOS hardware, for an increase in
power/buck...
</DREAM>
Well, this would probably require more developers than there are
current Lisp users, so maybe not ...
> Btw., sounds like you have an exciting project.
<g> thanks, though I'm of course very jeallous of you, because you get
to play with LispMs, and your current project seems quite interesting,
too... ;)
Regs, Pierre.
Rainer Joswig
Pierre Mai <de...@cs.tu-berlin.de> writes:
> Hi Rainer!
>
> Seems we agree more, than we disagree... ;)
Ja. ;-)
> Seems I should be getting a cheap PowerMac to get a chance to use
> MCL <g>. I sure would like Digitool to enter the Unix/Linux arena
> (though there probably would be some loss of functionality, since the
> Unix arena has nothing to compete with the MacOS's interface
> toolkits). Maybe Rhapsody is the solution? Who knows...
Rhapsody is dead. MacOS X is the plan de jour. Sigh.
> Well, I wouldn't call most of these things "basic", but your point
> is well taken. OTOH CLISP probably would not sport it's small
> memory-footprint, if all of those features were included...
Hmm, MCL always has a very small memory footprint (not as small as CLisp,
though). A lot of people were starting programming with early MCL
versions on early Mac 68k machines with 8 MB RAM.
> further, e.g. I don't see how you'd sell the idea of another LispM to
> someone who comes from the Windows world, and wants a better
> replacement for VB, Delphi or VC++. Offerings like Harlequins Dylan
> or LWW seem to be much more in line with their needs...
True. But I think there are other markets. Btw., what will happen when
somebody (DoJ mabe) stops MS? The monopoly of MS is absolutely damaging
and I'm not going to shovel more money than necessary into
the pockets of Bill.
> I'd rather try to get a "LispOS" environment that is not monolithic,
> but permits varying depths of "Lispyness", e.g. you could host it on
> top of another OS, with varying degrees of integration, and you could
> go down to just above the hardware level (e.g. based on a microkernel,
> for easy portability). And all of this would still enable your
> applications to run unchanged...
Sounds good.
> Well, this would probably require more developers than there are
> current Lisp users, so maybe not ...
I guess one would have to reactivate a lot of knowledgeable people that
have been moving away.
Greetings,
Rainer
Espen Vestre
Rainer Joswig <jos...@lavielle.com> writes:
> Rhapsody is dead. MacOS X is the plan de jour. Sigh.
Steve Jobs wasn't very lucky with his marketing lately.
As I read it, Mac OS X IS Rhapsody 2.0, in fact it has
all the features of Rhapsody 1.0 plus some more. The only important
change is that the now very unsure fate of Rhapsody on Intel.
> Hmm, MCL always has a very small memory footprint (not as small as CLisp,
> though). A lot of people were starting programming with early MCL
> versions on early Mac 68k machines with 8 MB RAM.
8MB RAM was a luxury, I developed experimental natural language software
on a Mac SE (8Mhz 68000) with 2.5MB RAM and (what luxury!) a 16Mhz Mac
IIX with 5MB RAM. The versions before 1.3 would even run, although
with tremendous GCing and room only for toy apps, on 1MB machines :-)
--
(espen)
Tim Bradshaw
* Will Hartung wrote:
> Franz's Linux release mitigates this somewhat, but if someone wanted
> to create a small application for Windoze, and then even give it away
> to others, that would not be practical with Franz's Windows based
> product.
I don't think this is correct -- if you give away the resulting
application I think the runtime license is free. This is the case for
our Solaris license anyway, but it might be some strange academic-only
license or something.
--tim
Rainer Joswig
Espen Vestre <e...@nextel.no> writes:
> Rainer Joswig <jos...@lavielle.com> writes:
>
> > Rhapsody is dead. MacOS X is the plan de jour. Sigh.
>
> Steve Jobs wasn't very lucky with his marketing lately.
> As I read it, Mac OS X IS Rhapsody 2.0, in fact it has
> all the features of Rhapsody 1.0 plus some more. The only important
> change is that the now very unsure fate of Rhapsody on Intel.
See for example this interview with Ken Bereskin, Apple's director of
operating system strategies (an oxymoron?):
http://www.maccentral.com/news/9806/18.x_part1.shtml
My favorite question is the one about the difference between
Copland and Mac OS X.
One of the strengths of Lisp is that it doesn't have to follow
every short term trend. I guess it is very wise not
to follow Apple to early.
Btw., is there any "official" festivity/conference/workshop remembering
the 40 years of Lisp and its influence? What would be the
official date for this?
> > Hmm, MCL always has a very small memory footprint (not as small as CLisp,
> > though). A lot of people were starting programming with early MCL
> > versions on early Mac 68k machines with 8 MB RAM.
>
> 8MB RAM was a luxury, I developed experimental natural language software
> on a Mac SE (8Mhz 68000) with 2.5MB RAM and (what luxury!) a 16Mhz Mac
> IIX with 5MB RAM. The versions before 1.3 would even run, although
> with tremendous GCing and room only for toy apps, on 1MB machines :-)
I started to use Lisp on Macs OS on a Atari ST 1040 (1 MB)
with a Mac emulator. ;-) I guees, I still have Experlisp on floppy
disks.
Pierre Mai
Espen Vestre <e...@nextel.no> writes:
> 8MB RAM was a luxury, I developed experimental natural language software
> on a Mac SE (8Mhz 68000) with 2.5MB RAM and (what luxury!) a 16Mhz Mac
> IIX with 5MB RAM. The versions before 1.3 would even run, although
> with tremendous GCing and room only for toy apps, on 1MB machines
> :-)
Since there are 8MB cards for the PalmPilot (16MHz 68000-based
Microcontroller "Dragonball"), this would enable Common Lisp in your
pocket, maybe called PalmLispMachine? Interesting thought... ;)
Regs, Pierre.
PS: There already is a nice Scheme Implementation for the PalmPilot,
which needs around 60KB ...
Pierre Mai
Rainer Joswig <jos...@lavielle.com> writes:
> Rhapsody is dead. MacOS X is the plan de jour. Sigh.
If Espen read it right, it's only the Intel port which has died, which
is still quite sad, IMHO...
> True. But I think there are other markets. Btw., what will happen when
> somebody (DoJ mabe) stops MS? The monopoly of MS is absolutely damaging
> and I'm not going to shovel more money than necessary into
> the pockets of Bill.
Well, at some time in the future, MS will go the same way IBM and
most other monopolies have gone, although I don't expect the DoJ will
have any real impact on this. It is rather the emergence of some new
technology/market that will break MS' neck... Maybe to only leave us
with some new monopolist (like the change-over from IBM => MS).
But with the emergence of more open standards and open source
software, I think the market reign of monopolists might get ever less
oppressive...
> [LispOS]
I think the strategy of first developing a portable, free GUI library
(like the LispOS project does/did with CLIM/clinc) is on the right
track. Once this is in place, many interesting _development_ tools
could be implemented fairly easily and -- more important -- portably.
Another key project might be the reimplementation of the GNU (X)Emacs
kernel in Common Lisp/CLOS based on the above-mentioned GUI library,
with support for extensions in Common Lisp, and a fairly complete
compatibility package for elisp[1], allowing this implementation to
leverage most of the code available for GNU Emacs.
Having these things in place, I think a truely useful development
environment could be built, which might foster the development of
other parts of the system, like integration of a repository (maybe
based on PLOB!, with ideas drawn from ShapeTools[2]), documentation
system (based on SGML?), etc.
Another important key factor might be the ability to integrate other
languages into this development environment, allowing for development
of thin clients in other languages, like the <HYPE>Java</HYPE>.
OTOH I think we might be making[3] the same mistakes that were made
whilst developing the LispMachine environment, so it would be very
interesting to solicit input from those involved in that "project"...
So, enough dreaming already, it's time to get some "real work"(TM)
done...
Regs, Pierre.
Footnotes:
[1] There has already been a project (at MIT, IIRC), that implemented
a sufficient elisp emulation in a Scheme-based Emacs to let GNUS run
unchanged! The author estimated having implemented around 70% of
elisp to achieve this (although this was sometimes around 1994, so
Emacs and the old GNUS was somewhat smaller and simpler).
[2] ShapeTools was an interesting project on the integration of
Revision/Configuration Management and the build process, done here at
the Technical University of Berlin. Especially the Attributed
Filesystem idea would mesh quite well with an OO repository, I think.
See http://swt.cs.tu-berlin.de/~shape/index.html for more info...
[3] making is quite a strong word here, since this is currently just
a "Gedankenexperiment"...