What Lisp to choose?
Eugene Vasin
I'm a newbie here and don't know what Lisp/CLOS compiler to choose.
Is there a fast, free, cross-platform (Linux/Solaris/Windows)
implementation
with cross-platform GUI library? By the word "free" I mean GPL/BSD/LGPL
or a
similar licensed software.
Thanks in advance.
Best regards,
Eugene.
mailto:kam...@altavista.net
Eugene Zaikonnikov
"Eugene Vasin" <kam...@altavista.net> wrote in message
news:39256F8E...@altavista.net...
> Hello.
>
> I'm a newbie here and don't know what Lisp/CLOS compiler to choose.
> Is there a fast, free, cross-platform (Linux/Solaris/Windows)
> implementation
> with cross-platform GUI library? By the word "free" I mean GPL/BSD/LGPL
> or a
> similar licensed software.
>
has Linux and Solaris ports (but no Windows).
You may also take a look at free CLISP - though not that fast as CMU CL, it
has a Windows port.
--
Eugene.
at ncal point verio point com x@x.x tom
> IMO your only choice is CMUCL (http://www.cons.org/cmucl). It's free and it
> has Linux and Solaris ports (but no Windows).
> You may also take a look at free CLISP - though not that fast as CMU CL, it
> has a Windows port.
CMU CL is a good choice. AKCL and GCL are also nice in some
applications because they are fairly simple and portable and still
manage to compile to native code.
Tom.
Thom Goodsell
alternate back and forth between CLISP and CMUCL on Linux; I've found
(informally) CMUCL to generally be faster, but CLISP to be
"friendlier". I'd recommend starting with CLISP, then trying CMUCL once
you're gotten the hang of Lisp. CLISP is, however, missing a few
features (like INSPECT).
CLISP can be found at http://clisp.cons.org and it runs on Unix boxen
and Windoze (and DOS, OS/2, and Amiga 500-4000).
As far as GUIs go, the situation is pretty grim. CLX will get you X
server graphics, but it's pretty low level. There are several toolkits
built on top of it, check http://www.lisp.org/table/tools.htm#windows .
CLISP has bindings for gtk+, which is cross platform, but I'm not sure
if the bindings are crossplatform or how robust the bindings are.
Thom
vsync
> I'm a newbie here and don't know what Lisp/CLOS compiler to choose.
I am too, and couldn't decide, so I just picked CLISP at random.
Having had a good experience with it, I am now downloading CMUCL to
see which I like better.
> Is there a fast, free, cross-platform (Linux/Solaris/Windows)
> implementation with cross-platform GUI library? By the word "free" I
> mean GPL/BSD/LGPL or a similar licensed software.
I don't know exactly how cross-platform this is (read: probably not
much), but here's what I did in a recent project. I needed to create
a generic "splash screen" application, to display warnings, messages,
and upgrade notices. It needed to have clickable URLs, buttons to
execute programs, and other such niceties.
I couldn't find any GUI toolkits that would allow me to build such a
thing with low overhead, so I ended up using with-wish. Since a) this
was going to be used by non-technical people, who shouldn't have to
know TCL/Tk (ew), b) the layout needed to be created completely at
runtime, and would have different elements each time, and c) the Tk
widget set has some horrible inconsistencies which made a quick hack
difficult, I ended up basically writing my own widget set on top of Tk
and with-wish.
It's the first thing I've done in Lisp, so I don't know how good it
is, but in my biased opinion, I think it's rather nice. It is
somewhat specialized to my particular app at this point, but I think I
should be able to break the GUI stuff out fairly easily. It's all
based on CLOS, so creating a widget is as simple as doing
(make-instance 'type-of-widget) and then passing a list of these to
the creator function.
I'll post a URL in a few days and you can all discover my newbie
status in greater detail.
--
vsync
http://quadium.net/ - last updated Wed May 24 22:17:12 MDT 2000
Orjner.
Mark Watson
re:
> Eugene Vasin <kam...@altavista.net> writes:
> I don't know exactly how cross-platform this is (read: probably not
> much), but here's what I did in a recent project. I needed to create
> a generic "splash screen" application, to display warnings, messages,
> and upgrade notices. It needed to have clickable URLs, buttons to
> execute programs, and other such niceties.
>
> I couldn't find any GUI toolkits that would allow me to build such a
> thing with low overhead, so I ended up using with-wish. Since a)
this
> was going to be used by non-technical people, who shouldn't have to
> know TCL/Tk (ew), b) the layout needed to be created completely at
> runtime, and would have different elements each time, and c) the Tk
> widget set has some horrible inconsistencies which made a quick hack
> difficult, I ended up basically writing my own widget set on top of
> TK and with-wish.
You might want to check out LispWorks (free personal edition) at
http://www.xanalys.com/software_tools/
It runs nicely under Windows and Linux (for Linux, install either
LessTif or Motif) and has a nice GUI API called CAPI that is easy
to use. I have the example programs from my (rather old) Springer-
Verlag Common LISP book on my web site, converted to use CAPI, if
you are interested.
I liked LispWorks enough to buy the commercial version,
which also supports the standard CLIM GUI API, and makes compact stand
alone executables(nice!).
-Mark
--
Mark Watson www.markwatson.com
Sent via Deja.com http://www.deja.com/
Before you buy.
Martin Thornquist
> It runs nicely under Windows and Linux (for Linux, install either
> LessTif or Motif) and has a nice GUI API called CAPI that is easy
> to use. I have the example programs from my (rather old) Springer-
> Verlag Common LISP book on my web site, converted to use CAPI, if
> you are interested.
Having wrestled some with CAPI, I have to say it is good for simple
applications, but sadly too simple (or at least too badly documented)
for more advanced use. I find writing my own interfaces hard, as the
documentation is very restricted on anything but using the standard
components in a relatively simple way.
Martin
--
"Plus I remember being impressed with Ada because you could write an
infinite loop without a faked up condition. The idea being that in Ada
the typical infinite loop would normally be terminated by detonation."
-Larry Wall
Friedrich Dominicus
>
> Having wrestled some with CAPI, I have to say it is good for simple
> applications, but sadly too simple (or at least too badly documented)
> for more advanced use. I find writing my own interfaces hard, as the
> documentation is very restricted on anything but using the standard
> components in a relatively simple way.
And the docs are obvious out of date and the examples as one can find
do not workt that way, and there is not documentation for the
Interface Builder (which I guess relies) on CAPI and possibly on CLIM
too.
Regards
Friedrich
Martin Thornquist
Yeah, well, as I wrote, I wrestle with it to make it do anything like
what I want. I looked at CLIM too, but either I did something
fundamentally wrong, or Harlequin has really made an effort in making
the CLIM objects so visually ugly (I'm working with LispWorks 4.1.0)
that I won't use it, even though CLIM seems sensibly both designed and
documented.
Fernando
wrote:
>Having wrestled some with CAPI, I have to say it is good for simple
>applications, but sadly too simple (or at least too badly documented)
>for more advanced use. I find writing my own interfaces hard, as the
>documentation is very restricted on anything but using the standard
>components in a relatively simple way.
And what about CLIM? Are there any other alternatives for
cross-platform GUI development? :-?
TIA
//-----------------------------------------------
// Fernando Rodriguez Romero
//
// frr at mindless dot com
//------------------------------------------------
Martin Cracauer
>[ Friedrich Dominicus ]
>> Martin Thornquist <mar...@ifi.uio.no> writes:
>>
>> > Having wrestled some with CAPI, I have to say it is good for simple
>> > applications, but sadly too simple (or at least too badly documented)
>> > for more advanced use. I find writing my own interfaces hard, as the
>> > documentation is very restricted on anything but using the standard
>> > components in a relatively simple way.
>>
>> And the docs are obvious out of date and the examples as one can find
>> do not workt that way, and there is not documentation for the
>> Interface Builder (which I guess relies) on CAPI and possibly on CLIM
>> too.
>Yeah, well, as I wrote, I wrestle with it to make it do anything like
>what I want. I looked at CLIM too, but either I did something
>fundamentally wrong, or Harlequin has really made an effort in making
>the CLIM objects so visually ugly (I'm working with LispWorks 4.1.0)
>that I won't use it, even though CLIM seems sensibly both designed and
>documented.
I once had Lispworks CLIM for pre-sales testing. Documentation,
speed, examples were just jokes. I thought they made mistakes in
delivery (especially since the rest of Lispworks with docs and
examples is excellent), but no.
The commercial CLIM source is probably high in the list of software
pieces that are market-damaged by doing nothing but the initial
coding.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Francis Leboutte
>Martin Thornquist <mar...@ifi.uio.no> writes:
>
>>[ Friedrich Dominicus ]
>
>>> Martin Thornquist <mar...@ifi.uio.no> writes:
>>>
>>> > Having wrestled some with CAPI, I have to say it is good for simple
>>> > applications, but sadly too simple (or at least too badly documented)
>>> > for more advanced use. I find writing my own interfaces hard, as the
>>> > documentation is very restricted on anything but using the standard
>>> > components in a relatively simple way.
>>>
>>> And the docs are obvious out of date and the examples as one can find
>>> do not workt that way, and there is not documentation for the
>>> Interface Builder (which I guess relies) on CAPI and possibly on CLIM
>>> too.
>
>>Yeah, well, as I wrote, I wrestle with it to make it do anything like
>>what I want. I looked at CLIM too, but either I did something
>>fundamentally wrong, or Harlequin has really made an effort in making
>>the CLIM objects so visually ugly (I'm working with LispWorks 4.1.0)
>>that I won't use it, even though CLIM seems sensibly both designed and
>>documented.
>
>I once had Lispworks CLIM for pre-sales testing. Documentation,
>speed, examples were just jokes. I thought they made mistakes in
>delivery (especially since the rest of Lispworks with docs and
>examples is excellent), but no.
Hello Martin,
Is that to say that you don't agree with what has been said about CAPI (not
powerful , not well documented)?
>The commercial CLIM source is probably high in the list of software
>pieces that are market-damaged by doing nothing but the initial
>coding.
>Martin
--
Francis Leboutte
f...@algo.be www.algo.be +32-(0)4.388.39.19
Marco Antoniotti
Francis Leboutte <f.leb...@algo.be> writes:
#+gripe-on
I believe Martin ia right on all accounts. CLIM was never really
supported by the vendors. The complexity of the beast is definitively
a drawback, and Common Graphics and CAPI would both offer the lock-in
of customers contrary to the standard CLIM.
As per CAPI, I toyed around with it some time ago and I found more
rigid than lacking. (The famous problem: how do I set the font of a
button *without* inserting it in a layout). Documentation was
somewhat ok, but it could improve.
Cheers
--
Marco Antoniotti ===========================================
dlin...@my-deja.com
Martin Thornquist <mar...@ifi.uio.no> wrote:
I looked at CLIM too, but either I did something
> fundamentally wrong, or Harlequin has really made an effort in making
> the CLIM objects so visually ugly (I'm working with LispWorks 4.1.0)
> that I won't use it, even though CLIM seems sensibly both designed and
> documented.
What types of experiences have users had with Franz's CLIM?
Is it stable? Is there decent documentation? Good performance?
What types of problems have people had?
I am thinking of buying the product, but my Franz rep tells me I need
to sign a letter of intent to purchase the product before getting a 30
day trial of it!! In this case, I will wait to ACL 6 and see if their
Java link will provide an adequate GUI.
Assuming a seemless Lisp<->Java product, would anybody wish to speculate
the advantages that CLIM would provide over building GUIs using Lisp
with a Java GUI?
Thanks,
Dave Linenberg
Martin Cracauer
>crac...@counter.bik-gmbh.de (Martin Cracauer) wrote:
>>Martin Thornquist <mar...@ifi.uio.no> writes:
>>
>>>[ Friedrich Dominicus ]
>>
>>>> Martin Thornquist <mar...@ifi.uio.no> writes:
>>>>
>>>> > Having wrestled some with CAPI, I have to say it is good for simple
>>>> > applications, but sadly too simple (or at least too badly documented)
>>>> > for more advanced use. I find writing my own interfaces hard, as the
>>>> > documentation is very restricted on anything but using the standard
>>>> > components in a relatively simple way.
>>>>
>>>> And the docs are obvious out of date and the examples as one can find
>>>> do not workt that way, and there is not documentation for the
>>>> Interface Builder (which I guess relies) on CAPI and possibly on CLIM
>>>> too.
>>
>>>Yeah, well, as I wrote, I wrestle with it to make it do anything like
>>>what I want. I looked at CLIM too, but either I did something
>>>fundamentally wrong, or Harlequin has really made an effort in making
>>>the CLIM objects so visually ugly (I'm working with LispWorks 4.1.0)
>>>that I won't use it, even though CLIM seems sensibly both designed and
>>>documented.
>>
>>I once had Lispworks CLIM for pre-sales testing. Documentation,
>>speed, examples were just jokes. I thought they made mistakes in
>>delivery (especially since the rest of Lispworks with docs and
>>examples is excellent), but no.
>Hello Martin,
Hi, Francis
>Is that to say that you don't agree with what has been said about CAPI (not
>powerful , not well documented)?
I never used CAPI. When I bought Lispworks, I was interestedt, but
the manual showed enough of its primitiveness and I also feared
portability problems.
I make it short, the experiences together with the narrowed feature
set and bad portability of CLIO/CLUE caused me never to use Lisp for
GUI programs. I wish I had been stubborn enough to just use Garnet,
but at the time I wanted a CLOS-based solution for some reason.
Martin
P.S. Castafiore is going back to Belgium (I moved to a smaller house)
to a Lisper you might know (he said he got a Symbolic mouse from you).
vsync
> Assuming a seemless Lisp<->Java product, would anybody wish to speculate
> the advantages that CLIM would provide over building GUIs using Lisp
> with a Java GUI?
drool...
--
vsync
http://quadium.net/ - last updated Wed May 31 18:42:35 MDT 2000
Orjner.
vsync
> It's the first thing I've done in Lisp, so I don't know how good it
> is, but in my biased opinion, I think it's rather nice. It is
> somewhat specialized to my particular app at this point, but I think I
> should be able to break the GUI stuff out fairly easily. It's all
> based on CLOS, so creating a widget is as simple as doing
> (make-instance 'type-of-widget) and then passing a list of these to
> the creator function.
>
> I'll post a URL in a few days and you can all discover my newbie
> status in greater detail.
As promised, here is the package:
http://quadium.net/code/splash/
I know that a couple sections of code need a rewrite; there's a bit of
redundancy in the PACK code, etc. Anyway, I would appreciate a
critique both of the program itself and of the widget implementation.
It's my first Lisp program, though, so please don't be _too_ harsh...
=)
Will Hartung
>crac...@counter.bik-gmbh.de (Martin Cracauer) wrote:
>
>>Martin Thornquist <mar...@ifi.uio.no> writes:
>>I once had Lispworks CLIM for pre-sales testing. Documentation,
>>speed, examples were just jokes. I thought they made mistakes in
>>delivery (especially since the rest of Lispworks with docs and
>>examples is excellent), but no.
>
>Hello Martin,
>
>powerful , not well documented)?
>
I agree with both. I also played a little with the pre-sales CLIM and found
it lacking. The CAPI is particularly frustrating because you have so little
(apparent) control, and it's also difficult to create your own widgets. I
think Marco had a rant on this topic several months ago. I don't know if he
ever got it resolved.
There's certainly power there, and I believe flexibility, but the
documentation is completely lacking. I always wondered how the LW CAPI
differed from the system they designed for Dylan, which seems to have been
routinely praised. I get this feeling that there's a lot of potential in the
CAPI, but the reality is that it's seems to be lacking in many areas.
Will Hartung
(vft...@home.com)
Erik Naggum
| I am thinking of buying the product, but my Franz rep tells me I
| need to sign a letter of intent to purchase the product before
| getting a 30 day trial of it!!
This is scary stuff to the legally naïve, but a letter of intent is
not a contract. You are under no obligation actually to purchase
anything if you don't want to after the trial period is over, but
you have to notify the other party of a change of intent. This is a
means of maintaining control over who receives trial versions and
ensures that they either return or purchase it within a reasonable
time.
There are lots of unnecessary legal papers to sign or deal with in
most transactions, but they become necessary in a dispute. If you
haven't arranged for them beforehand, you're basically hosed. In an
over-litigious society like the American, this probably makes a lot
more people than necessary feel like they are suspected of cheating,
or at least thought capable of cheating, which by itself causes some
to cheat in anger or spite, which sort of proves the point that the
paperwork is necessary to protect oneself from such people...
#:Erik
--
If this is not what you expected, please alter your expectations.
Marco Antoniotti
"Will Hartung" <vft...@home.com> writes:
> Francis Leboutte wrote in message ...
> >crac...@counter.bik-gmbh.de (Martin Cracauer) wrote:
> >
> >>Martin Thornquist <mar...@ifi.uio.no> writes:
> >>I once had Lispworks CLIM for pre-sales testing. Documentation,
> >>speed, examples were just jokes. I thought they made mistakes in
> >>delivery (especially since the rest of Lispworks with docs and
> >>examples is excellent), but no.
> >
> >Hello Martin,
> >
> >Is that to say that you don't agree with what has been said about CAPI (not
> >powerful , not well documented)?
> >
>
>
> I agree with both. I also played a little with the pre-sales CLIM and found
> it lacking. The CAPI is particularly frustrating because you have so little
> (apparent) control, and it's also difficult to create your own widgets. I
> think Marco had a rant on this topic several months ago. I don't know if he
> ever got it resolved.
In all fairness, I must say that I do not know whether the people at
Xanalys (ex-Harlequin) fixed it. The (kludgy) work around for my
problem (setting a button dimensions) was to wrap a layout around
every little object you created.
> There's certainly power there, and I believe flexibility, but the
> documentation is completely lacking. I always wondered how the LW CAPI
> differed from the system they designed for Dylan, which seems to have been
> routinely praised. I get this feeling that there's a lot of potential in the
> CAPI, but the reality is that it's seems to be lacking in many
> areas.
I hold an extreme position in this respect. I believe you need a
truly cross-platform GUI development system.
Paolo Amoroso
> As promised, here is the package:
>
> http://quadium.net/code/splash/
I have added a short page describing SPLASH:
http://ww.telent.net/cliki/SPLASH
to the CLiki site recently started by Daniel Barlow:
Since SPLASH is your baby (and since everybody has write access to CLiki :)
feel free to correct what I have written. Likewise, I encourage other
authors of free Lisp software to contribute information about their
projects to this new community resource.
Concerning your request for compatibility patches for increasing the
portability of SPLASH, you may check the subprocess management routines of
cllib, which is part of CLOCC (Common Lisp Open Code Collection):
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/
Paul Tarvydas
I've spent the last decade wasting my time involved in Windows development using
MFC.
CAPI, with all of its faults, is wildly more productive.
The flexibility of CAPI seems to be underdocumented - it looked too limited when I
first read the documentation. As I dig into it (with some frustrations) I find
that it can do everything I've asked for so far.
I spent a bit of time trying to decide whether to use Tcl/TK or CAPI or try to
attach TK to Xanalys lisp. As an experiment, I transliterated a lump of Tcl/TK
into CAPI and found that the models weren't that far apart. I ended up just using
CAPI.
CAPI's main problem is OOP-disease: documentation is sparse and abstract, you can
never nail an answer down without experimention. This, unfortunately, is par for
the course - I've had this same frustration with Smalltalk and have had it in
spades with Java (and those bloody JavaDocs).
As far as portability goes, it is sad but true, that when I think of a product
that I want to sell/give to someone else, the only "portable" way to do it is to
develop it for Windows. From this point of view, portability matters only if you
choose to develop on a non-Windows machine, then port the result over to Windows
before selling it. [I wish it weren't true]. CAPI is well-suited for that.
pt
Martin Cracauer
>I'm beginning to like CAPI.
>I've spent the last decade wasting my time involved in Windows development using
>MFC.
>CAPI, with all of its faults, is wildly more productive.
And what will you do if the vendors gives up the product, develops the
product in a direction you don't like (i.e. it becomes unstable), if
the vendors dies and noone picks up the product, if the vendor simply
raises the price - maybe even for redistribution of runtimes - or if
you need to support a platform the vendor does not support?
Setting yourself on a single-vendor API with only one implementation,
with no source you may redistribute in an emergency case, is suicide,
time-invenstment wise. I've been programming for long enough to know
this and who the specific vendor in question is couldn't matter less.
I have no doubt it's more productive than MFC, though...
Martin
Tim Bradshaw
> Setting yourself on a single-vendor API with only one implementation,
> with no source you may redistribute in an emergency case, is suicide,
> time-invenstment wise. I've been programming for long enough to know
> this and who the specific vendor in question is couldn't matter less.
> I have no doubt it's more productive than MFC, though...
Isn't MFC an example of just this?
--tim
Erik Naggum
| And what will you do if the vendors gives up the product, develops the
| product in a direction you don't like (i.e. it becomes unstable), if
| the vendors dies and noone picks up the product, if the vendor simply
| raises the price - maybe even for redistribution of runtimes - or if
| you need to support a platform the vendor does not support?
This has a very simple and obvious answer: You do what you always do
when "the world" dissolves underneath a programmer: You reimplement
your software with the best available tools and people at that time.
It's a strange illusion that just because it's in some "free" form,
it's going to stay useful forever. Operating systems come and go,
languages change and their compilers and development tools with them
-- including such fickle things as the support libraries that change
in subtly incompatible ways all the time. And let's not forget the
people who can actually make use of the specific combination of all
of these things -- people have two nasty habits: (1) they forget,
and (2) they die. All of this happens all of the time -- regardless
of whether you have source code to something. Even the hardware on
which the last system in the world ran will deteriorate and die.
What does using stuff that follows standard buy you? _More_ time,
not eternity, and not even necessarily _much_ time, either. If the
standard is _excellent_ and it's universally adopted by someone who
is not so cavalier about standards as Microsoft, it may buy you a
lot of time, like 15 years. If it's a bad standard, it will also be
improved.
Reimplementing is part of the maintenance costs of a project.
You're a damn fool if you don't calculate it into the price of
something that is going to be in use for a long time. It's very
much like longevity in data storage: If you don't plan to have
someone copy data off of old media onto new media to keep it alive,
possibly converting it in the process, it _will_ wither and die.
| Setting yourself on a single-vendor API with only one implementation,
| with no source you may redistribute in an emergency case, is suicide,
| time-invenstment wise. I've been programming for long enough to know
| this and who the specific vendor in question is couldn't matter less.
Then you should also admit that there is _no_ cure. Just about
everything is suicide, time-investment-wise: Everything dies in the
end and under more miserable conditions the longer it has been kept
alive artificially, I might add. The question is how much time you
lose or fail to lose (but that is not "gain") with each move you
make. There is nothing to indicate that having source code access
buys you any more time than not having source code access does, in
the general case. Specific cases may of course be cited the same
way alternative medicine cites its successes.
Joe Marshall
> And let's not forget the people who can actually make use of the
> specific combination of all of these things -- people have two
> nasty habits: (1) they forget, and (2) they die.
I, for one, do not intend to make a habit out of item 2. (although I
might be persuaded to try it once....)
Fernando RodrÃguez
Martin Cracauer escribió:
> Setting yourself on a single-vendor API with only one implementation,
> with no source you may redistribute in an emergency case, is suicide,
> time-invenstment wise. I've been programming for long enough to know
> this and who the specific vendor in question is couldn't matter less.
>
> I have no doubt it's more productive than MFC, though...
>
Well... It seems that the vendor of that particular product is more likelly to die,
get splitted, sued to death, etc.. that Xanalys. Throw away those MFC books and get
yourself a copy of Lispworks before it's too late! };-D
Now seriously, I got into HUGE trouble be relying in a badly supported propietary
product, but I still think that going open source only for everything isn't always
practical... :-(
Mark Watson
There are some good "free" and Open Source LISP systems, but there is
something very satisfying about a commercial, supported LISP
environment (I chose LispWorks Professional because of the price, but I
think that the Franz system is also great, because I tried their free
evaluation versions for Windows and Linux). Anyway, everytime I try to
do something new with LispWorks (e.g., CAPI, multi-threading, socket
programming, etc.) and life is easy, it is a very satisfying feeling!
BTW, I work for an AI company, but we do everything in Java. Even
though I wrote a "Java AI" book 5 years ago (and actually, I have
another in production), I must say that Java is simply not as good at
doing AI-ish things as LISP. There are, certainly, good marketing
reasons for using Java :-)
Hopefully, people will realize the tremendous advantages of developing
in LISP and continue to support the fine LISP commercial vendors.
Best regards,
Mark
In article <393D3B85...@wanadoo.es>,
Fernando =?iso-8859-1?Q?Rodr=EDguez?= <f...@wanadoo.es> wrote:
>
> Well... It seems that the vendor of that particular product is more
likelly to die,
> get splitted, sued to death, etc.. that Xanalys. Throw away those MFC
books and get
> yourself a copy of Lispworks before it's too late! };-D
>
> Now seriously, I got into HUGE trouble be relying in a badly
supported propietary
> product, but I still think that going open source only for
everything isn't always
> practical... :-(
--
Mark Watson www.markwatson.com
Erik Naggum
| I, for one, do not intend to make a habit out of item 2.
:) FWIW, ~/.project reads: "Immortality in our lifetime".
Martin Cracauer
>Martin Cracauer escribió:
>> Setting yourself on a single-vendor API with only one implementation,
>> with no source you may redistribute in an emergency case, is suicide,
>> time-invenstment wise. I've been programming for long enough to know
>> this and who the specific vendor in question is couldn't matter less.
>>
>> I have no doubt it's more productive than MFC, though...
>>
>Well... It seems that the vendor of that particular product is more likelly to die,
>get splitted, sued to death, etc.. that Xanalys. Throw away those MFC books and get
>yourself a copy of Lispworks before it's too late! };-D
>Now seriously, I got into HUGE trouble be relying in a badly supported propietary
>product, but I still think that going open source only for everything isn't always
>practical... :-(
It doesn't have to be open-Source, just a Standard that is implemented
by more than one Vendor.
Martin Cracauer
>* Martin Cracauer
>| And what will you do if the vendors gives up the product, develops the
>| product in a direction you don't like (i.e. it becomes unstable), if
>| the vendors dies and noone picks up the product, if the vendor simply
>| raises the price - maybe even for redistribution of runtimes - or if
>| you need to support a platform the vendor does not support?
> This has a very simple and obvious answer: You do what you always do
> when "the world" dissolves underneath a programmer: You reimplement
> your software with the best available tools and people at that time.
Yes, but you can reduce the frequence of being forced to.
Since I'm using...
- somewhat Posix 1003.[12] - complaint Unixes
- ANSI C 89
- Common Lisp (no GUI programming)
I have a much better time than before with...
- DOS ==> Windows 3.0
- moving-target C++
- NeXT
- Smalltalk
> It's a strange illusion that just because it's in some "free" form,
> it's going to stay useful forever.
The things I listed can also be avoided by a standard that is
implemented by several vendors (non-free).
> Operating systems come and go,
> languages change and their compilers and development tools with them
> -- including such fickle things as the support libraries that change
> in subtly incompatible ways all the time.
Yes, this happens all the time and even the Unix platforms I support
still do this. Hoever, they do it in ways that are somewhat obvious
and can be traced down fast. What counts is that they usually force
you to change a simple function call and maybe to all a little
bookkeeping stuff.
You don't have to rework major parts of your program design, as you
would have to when your Object-Oriented GUI framework goes away.
The same applies for Common Lisp. CMUCL is far from being ANSI CL
compliant, but the differences usually require a few #+, not different
programming style as it would when CL was a one-Vendor standard only,
went away and I would be forced to do Interlisp instead.
> And let's not forget the
> people who can actually make use of the specific combination of all
> of these things -- people have two nasty habits: (1) they forget,
> and (2) they die. All of this happens all of the time -- regardless
> of whether you have source code to something. Even the hardware on
> which the last system in the world ran will deteriorate and die.
> What does using stuff that follows standard buy you? _More_ time,
> not eternity, and not even necessarily _much_ time, either. If the
> standard is _excellent_ and it's universally adopted by someone who
> is not so cavalier about standards as Microsoft, it may buy you a
> lot of time, like 15 years. If it's a bad standard, it will also be
> improved.
I agree about your scepsis about Standards, in fact Posix 1003.1 and
1003.2 (Unix C interface and Unix shell utils) are quite stupid in a
number of ways and the free Unix derivates declared that they will not
implement some of the annoying parts.
Still, these Standards raised the livetime of my own code to something
I doubt CAPI will have.
> Reimplementing is part of the maintenance costs of a project.
> You're a damn fool if you don't calculate it into the price of
> something that is going to be in use for a long time. It's very
> much like longevity in data storage: If you don't plan to have
> someone copy data off of old media onto new media to keep it alive,
> possibly converting it in the process, it _will_ wither and die.
Well, I think some of our different opinions are grounded in our past
experience. I wasn't programming 15 years ago and I avoid some areas
of computing that forces many reimplementations, i.e. I don't do GUI
programming escept for some Web applications.
>| Setting yourself on a single-vendor API with only one implementation,
>| with no source you may redistribute in an emergency case, is suicide,
>| time-invenstment wise. I've been programming for long enough to know
>| this and who the specific vendor in question is couldn't matter less.
> Then you should also admit that there is _no_ cure.
I do, but the toolchain change I outlined at the beginning of my
posting reduced the problem by an order of magnitude.
> Just about
> everything is suicide, time-investment-wise: Everything dies in the
> end
That can't be proven in the mathematical sense :-)
> and under more miserable conditions the longer it has been kept
> alive artificially, I might add. The question is how much time you
> lose or fail to lose (but that is not "gain") with each move you
> make. There is nothing to indicate that having source code access
> buys you any more time than not having source code access does, in
> the general case. Specific cases may of course be cited the same
> way alternative medicine cites its successes.
Well, I think I have quite a number of such specific cases. I would
have lost CMUCL and FreeBSD if I didn't act, and I could only act
because I had the source to fix technical or other problems without
going as far as working for the vendor.
I think your point bites in a quite different way: if I had more
pressure on the "real" projects I did a few years ago and therefore
less time to study the tools I use, I wouldn't have been in the
position to do something about the tools.
However, now that I already invested the time to be able to act on
problems with my tools (by fixing them, not throwing them away), I
think I and my employer are both in a good situation, even when time
pressure on "real" stuff is acute.
I won't even start how much my programming style and capabilities
improved by having my propposed changed stumbled over by experienced
people in on OpenSource-Projects. The will and ability for
correctness and elegance in some OpenSource projects is much larger
than in any commercial environment I know.
William Deakin
> Erik Naggum writes:
> > Just about everything is suicide, time-investment-wise:
> > Everything dies in theend
>
> That can't be proven in the mathematical sense :-)
But it is true in a physical sense[1]
;) will
[1] I think it is called second law of thermodynamics.
Erik Naggum
| It doesn't have to be open-Source, just a Standard that is
| implemented by more than one Vendor.
Why isn't a publicly available specification sufficient?
Why does it have to be implemented by more than one vendor?
How do you bootstrap this process for new products/ideas?
Ian Wild
>
> Erik Naggum <er...@naggum.no> writes:
> > Everything dies in the
> > end
>
> That can't be proven in the mathematical sense :-)
Of course it can - it's a simple reduction ad absurdum:
If something hasn't died in the end it must have lived
on past the end, in which case it wasn't the end at all.
William Deakin
> Why isn't a publicly available specification sufficient?
> Why does it have to be implemented by more than one vendor?
> How do you bootstrap this process for new products/ideas?
This hits the nail on the head[1]
;) will
[1] and is a key point made by Rob Pike (see Rob Pike article thread for
ref.)
Martin Cracauer
>* Martin Cracauer
>| It doesn't have to be open-Source, just a Standard that is
>| implemented by more than one Vendor.
> Why isn't a publicly available specification sufficient?
If complete, it would be. However, when writing code for things like
CAPI, more or less of it can only be written down the right way by
using other sources than the specification (try'n'error, support
calls, reverse engeneering, existing examples).
> Why does it have to be implemented by more than one vendor?
When one dies, you can take your existing source and continue to use
it on the other vendor's implementation.
Of course, that's not a general solution, since maybe you're now left
with one vendor again, but it helps a lot.
> How do you bootstrap this process for new products/ideas?
The whole point only applies when the new things you want are in your
source code, not the APIs you use.
Your point is probably that your can't do really new things in
existing frameworks.
On the other hand, when I try to do new things on new
platforms/apis/languages, I am usually stopped by problems with the
implementation of these new building blocks before the thing I build
reaches a state where it is something "new".
I wonder why you prefer using things like existing vendor-specific
APIs over doing everything yourself from ground up. It takes time,
but so does reimplementing your (direct) project when you are forced
to build on new grounds.
Erik Naggum
| If complete, it would be. However, when writing code for things
| like CAPI, more or less of it can only be written down the right way
| by using other sources than the specification (try'n'error, support
| calls, reverse engeneering, existing examples).
It seems you should retarget your efforts to improve specifications.
| When one dies, you can take your existing source and continue to use
| it on the other vendor's implementation.
When a vendor dies, what exactly prevents you from continuing to use
the product? It doesn't evaporate. You can call them up and tell
them you want to purchase the whole thing for a trifle amount of
money. Trust me, this happens _all_ the time when companies fail.
It's actually part and parcel of the liquidation process.
| The whole point only applies when the new things you want are in
| your source code, not the APIs you use.
That seems awfully irrelevant. Your source code is somebody else's
"API" and vice versa.
| Your point is probably that your can't do really new things in
| existing frameworks.
Yes, I'm subtly and implicitly criticing you for that position,
since what you are saying is fairly hostile to real innovationน.
| On the other hand, when I try to do new things on new
| platforms/apis/languages, I am usually stopped by problems with the
| implementation of these new building blocks before the thing I build
| reaches a state where it is something "new".
If so, it seems you should retarget your efforts to improve quality
in the components you use.
| I wonder why you prefer using things like existing vendor-specific
| APIs over doing everything yourself from ground up.
Pardon me? When and where did I say any such thing? Why the hell
do you wonder why? I'm arguing against _your_ position, because I
think it lacks all relevant merit.
| It takes time, but so does reimplementing your (direct) project when
| you are forced to build on new grounds.
If it takes N amount of time to build on vendor-specific "API"s, it
will take M*N amount of time to reimplement it M times. Your
argument is that M will be so high that the value of N is immaterial
in the equation T < M*N, where T is the time it takes to reinvent
the wheel and do it all yourself. I find this a rather curious
position, to say the least.
#:Erik
-------
น as opposed to Microsoft innovation
Paul Tarvydas
Martin Cracauer wrote:
> Setting yourself on a single-vendor API with only one implementation,
> with no source you may redistribute in an emergency case, is suicide,
What is your specific suggestion for tools that I should use in my case?
I need to develop a 2-D interactive graphics application (not just GUI, but 2-D
graphics) in the least amount of time and fuss (including learning curve,
experimentation time, implementation time) that has to run on machines/OS'es
constituting a large market.
I am truly interested in good, specific suggestions.
pt
Martin Cracauer
>* Martin Cracauer
>| Your point is probably that your can't do really new things in
>| existing frameworks.
> Yes, I'm subtly and implicitly criticing you for that position,
> since what you are saying is fairly hostile to real innovationน.
>| On the other hand, when I try to do new things on new
>| platforms/apis/languages, I am usually stopped by problems with the
>| implementation of these new building blocks before the thing I build
>| reaches a state where it is something "new".
> If so, it seems you should retarget your efforts to improve quality
> in the components you use.
And how do I do it when I can't change them without working full-time
for the vendor?
>| I wonder why you prefer using things like existing vendor-specific
>| APIs over doing everything yourself from ground up.
> Pardon me? When and where did I say any such thing?
Sorry, I should have worded differently: if you want innovation you
can't get when working inside existing multi-vendor frameworks, isn't
it preferrable to implement a thing like CAPI on your own, basing just
on Common Lisp, Posix/Win32 and X11/basic windows draw routines?
(Over using existing frameworks you cannot control).
>| It takes time, but so does reimplementing your (direct) project when
>| you are forced to build on new grounds.
> If it takes N amount of time to build on vendor-specific "API"s, it
> will take M*N amount of time to reimplement it M times. Your
> argument is that M will be so high that the value of N is immaterial
> in the equation T < M*N, where T is the time it takes to reinvent
> the wheel and do it all yourself. I find this a rather curious
> position, to say the least.
I say that using an existing API (over doing it yourself) saves A
time, but it costs B time that it is not specilized for your needs, it
costs C time to work around bugs in implementation or documentation,
it may cost D time to do something about it when the vendors fails to
continue the product in an appropriate manner. And that B + C + D
easily > A. And when it it, it often is in annoying quantity,
including risks for your own project or company.
Since I started programming professionally (1991), there were few
frameworks for which this formular wasn't true. NeXT and the
Smalltalks are propably the best examples. The only innovate
frameworks that you could continue to use until today are from
microsoft... Also, since 1991, most successful things I did were
implemented in exsting multi-vendor tools, as success was defined
mostly not by innovate features in my products, but people were happy
that the things worked at all, had few bugs and were fast.
I don't know how the situation was before 1991 and I could easily
believe that customer's expectations were different. But today - from
my point of view - most people have so many problems with lack of
throughput, bugs, bloat, incompatibilities that they are happy when
you do something about these, they don't expect innovative features
and they are even so sceptical about them that they refuse offers of
them or don't use them when they are available.
That is a bad situation, and there are several ways to approach a
solution.
One is to use innovative environments to produce innovate products and
hope that the result speaks for itself.
The other is to do the current things right, so that users and
customers will be freed of the "doesn't-work-anyway" expectation and
will have their head free to even recognize advanced concepts.
I think that the OpenSource community did a lot in the latter regard
and that using single-vendors APIs will lead to forced changes in your
software that is contrary to it.
Paul Tarvydas
Martin Cracauer wrote:
> And what will you do if the vendors gives up the product, develops the
> product in a direction you don't like (i.e. it becomes unstable), if
Apply effort.
This is the same risk as for the case when the open source community doesn't yet
support a device I need, or I find a customer who, for good reasons, insists on using
a machine/OS/configuration that I don't yet support.
The trick is to minimize the risk & cost of unexpected new effort. The way to do
this is to stop obsessing about code and to start obsessing about blazingly clear
architecture.
You can use many methods to make architecture clear:
- choose simple models for aspects of your system (Tcl/TK is simple, CAPI is simpler
than CLIM)
- insulate - yeah, I know that CAPI is single-sourced, so I endeavour to scurry away
CAPI calls in routines that have expressive sentences as their names
- write application-specific code - it's easier to understand a single
clearly-written application (and, therefore to reengineer it and to port it) than it
is to understand an abstract class library (this bit of experiential advice should
raise some eyebrows :-)
- use tools that cause you not to tangle implementation with architecture; Lisp has a
psychological effect on me that almost no other language does - I find it mentally
easy to chop applications up into inanely small pieces while not worrying about
efficiency (and commercial Lisp compilers give me the warm-and-fuzzies by having good
compilers), whereas with C/C++ I can't get my mind out of the micro-efficiency gutter
and can't get any useful work done, likewise, with Smalltalk/Eiffel I spend all of my
time honing class libraries instead of doing useful work - with
C/C++/Smalltalk/Eiffel, the final code is so polluted with implementation &
abstraction details that it becomes expensive to consider a rebuild; garbage
collection hides a huge amount of non-architectural detail
- use tools that require fewer (clear) lines of code in the implementation (so, even
if you blow the architecture, the amount of time to reverse-engineer it is lowered
since there's less to read and understand)
- build tools (e.g. small languages (Kernighan, Pike, et al)) that generate parts of
your application from tool-independent specifications.
pt
Will Hartung
2-D
>graphics) in the least amount of time and fuss (including learning curve,
>experimentation time, implementation time) that has to run on
machines/OS'es
>constituting a large market.
>
>I am truly interested in good, specific suggestions.
It's all a matter of how autonomous (i.e. how much it must interact with
other, unspecified applications on the client platform) your application is.
If it's fairly autonomous, then something (anything) based on X would
probably be your best choice. Every major desktop platform of note can run
an X Server.
CAPI is supposed to port between X and windows, I imagine Open Graphics does
as well. There's alway the basic CLX stuff.
Seriously, you can write the app on an Intel unix solution, the hardware is
dirt cheap, particularly compared to the software, and you can serve several
clients from one machine (depending on the application of course). $1000/3
users for hardware, $300 for an X-Server client for their personal machine,
and $30,000 per seat for your software! :-)
The machine lives either in a machine room, or under the desk. Hunt down
some "embedded" PC options to get nice form factor for your app servers.
Cost will go up a little, but the users will appreciate the space saved.
Make sure you ship a bootble CD ROM to reload the machines when they
explode. Share your files on a NFS or Window/Samba file server. Back up
those file servers, not your app servers.
"Oh, it's not a computer, it's a $1000 dongle!"
Mass market is a different story.
Have fun.
Will Hartung
(vft...@home.com)
Erik Naggum
| ... it seems you should retarget your efforts to improve quality in
| the components you use.
* Martin Cracauer
| And how do I do it when I can't change them without working
| full-time for the vendor?
You talk to the vendors (plural) that you could purchase something
from and choose the one (oh, no! :) that listens to you.
I wonder where the notion that you cannot affect a software product
except by tinkering with the source code comes from. It's bogus.
| Sorry, I should have worded differently: if you want innovation you
| can't get when working inside existing multi-vendor frameworks,
| isn't it preferrable to implement a thing like CAPI on your own,
| basing just on Common Lisp, Posix/Win32 and X11/basic windows draw
| routines? (Over using existing frameworks you cannot control).
No, I don't think so. I want to be good at what I do, and I have
found, after having become good at perhaps 20 different things in as
many years, that if I can find somebody else with like attitude, or
better yet, a whole bunch of people with like attitude, we don't all
have to be good at the _same_ things. Sometimes, I'd like to go to
a doctor and say: "Hey, I broke this, can you fix it?" and let him
do his work, instead of studying the parts of medicine that I need
to fix it and hope I learned it in time not to have done ill worse.
| I say that using an existing API (over doing it yourself) saves A
| time, but it costs B time that it is not specilized for your needs,
| it costs C time to work around bugs in implementation or
| documentation, it may cost D time to do something about it when the
| vendors fails to continue the product in an appropriate manner. And
| that B + C + D easily > A. And when it it, it often is in annoying
| quantity, including risks for your own project or company.
What a sad, paranoid view of the world! Here's a suggestion: Drop
the crap you're working on and take a week's vacation right now,
during which you ponder seriously whether you ever again want to
work with incompetent suppliers. If you conclude that, yes, you
want to work with incompetent suppliers, go back to work. If you
conclude that, no, you do not ever want to deal with any supplier
who is incompetent, buy firearms and ammo and go back to work :)
_or_ get a new job. According to the newspapers and the screaming
idiots in the IT business, there is a shortage of people who know
just about _anything_. (Never mind that there are unemployed IT
people, too, we don't want to be honest while marketing, do we? :)
If you can't get a new job where you don't have to deal with a lot
less incompetent suppliers, do something else that you're good at.
| That is a bad situation, and there are several ways to approach a
| solution.
Some situations have only one solution, and it's the opposite of
"approach": it's "butt out!". I honestly don't think people should
try to solve the problems created by using Microsoft products.
| The other is to do the current things right, so that users and
| customers will be freed of the "doesn't-work-anyway" expectation and
| will have their head free to even recognize advanced concepts.
I'm worried about your fixation on "advanced concepts" and
innovation, so I'm sorry I brought it up to begin with. There's
such a mind-numbing lack of competence in any IT field that you
don't have to be brilliant to be extraordinary, and you don't have
to excel to deliver consistently high quality. People don't do
quality work because they can get away with not doing it, and all
you need to do is to make sure nobody gets away with around you.
I know: I do just this.
| I think that the OpenSource community did a lot in the latter regard
| and that using single-vendors APIs will lead to forced changes in
| your software that is contrary to it.
Some day, I hope to find out what Open Source _really_ is a solution
to. So far, the only thing that really stands out is "at least it's
not Microsoft", and I was pleased that Rob Pike seems to have the
same insight. I don't think we have solved anything of importance
with Open Source, except how to threaten software development in the
long term to the point of extinction or utter non-innovation. The
sad fact is: people don't contribute for free to anything that they
can't charge to a "surplus/luxury account", and in programming,
that's what they know _too_ well. Add the pain of solving some
really hard stuff to the equation, and a lot fewer people will want
to contribute for free. To engage the masses of people that Open
Source relies on, you can't _do_ really hard stuff for long. At
some point, those who give away will want a return on investment.
If they find out that they killed a lot of software companies or
blocked a lot of ways to make money by giving too much stuff away,
they will turn on Open Source and blame it for the reduction in
their options. So Open Source is a luxury phenomenon, to vanish or
be sharply reduced when we can no longer afford that luxury.
#:Erik
at ncal point verio point com x@x.x tom
> | implemented by more than one Vendor.
>
> Why isn't a publicly available specification sufficient?
I think CommonLisp is a good example why this doesn't work for many
people. The CommonLisp spec leaves many important areas of the
language and the environment unspecified, and writing code (in
particular, numerical code) that works efficiently across
implementations is hard.
> Why does it have to be implemented by more than one vendor?
Implementations from only a single vendor put customers at the
complete mercy of that vendor once they have built a product. The
vendor can charge up to the customer's pain threshold, and if they
drop the product, the customer is left stranded. Few people who are
responsible for a large software development project want to accept
that kind of risk, even if the tool is quite a bit better.
> How do you bootstrap this process for new products/ideas?
Well, vendors need to take the concerns of their customers more
seriously: many customers don't want to become dependent on a single
vendor and simply won't buy.
Open source is a reasonably good way of ensuring that when coming up
with a new language. Detailed open specifications also help. Vendors
should not put proprietary extensions into their tools without
separating them clearly from the core, open specification and giving
customers the option of turning them off completely. And building
industry support around the language is important as well.
Sun did several of those things with Java, which is why people jumped
on it. Critics of Java often seem to assume that people picked it out
of ignorance of the alternatives. In my experience, people who helped
get Java off the ground and pushed it into the mainstream (at IBM and
other places) knew the alternatives full well, but they supported Java
because it addressed those practical concerns; often, this meant
dropping support for languages they preferred technically.
Tom.
Erik Naggum
| Implementations from only a single vendor put customers at the
| complete mercy of that vendor once they have built a product. The
| vendor can charge up to the customer's pain threshold, and if they
| drop the product, the customer is left stranded. Few people who are
| responsible for a large software development project want to accept
| that kind of risk, even if the tool is quite a bit better.
Sounds good! Now explain Microsoft.
Craig Brozefsky
> * Martin Cracauer
> | And how do I do it when I can't change them without working
> | full-time for the vendor?
>
> You talk to the vendors (plural) that you could purchase something
> from and choose the one (oh, no! :) that listens to you.
>
> I wonder where the notion that you cannot affect a software product
> except by tinkering with the source code comes from. It's bogus.
I think the issue of influencing venders of propietary software is
more complex than a "yes you can, no you can't". So in short I agree
that it's bogus to say that you can't affect a proprietary product.
As a professional programmer, you can influence proprietary products
in several ways. Being a customer gives you the vendors ear to some
extent, and having direct contact with the engineers working on the
product can give you even greater control. If the product is tracking
a public standard, then being on the standards commitee helps too.
I'm sure we can think of a dozen more ways that require varying levels
of time or financial investment.
As a hobbiest, or perhaps a professional programmer with only a
minimal amount of capital, many of these mechanisms for influencing
proprietary software are not available to you. Your capital is
largely limited to your labor power. I would argue that Free Software
*usually* presents the most direct translation of labor power into
project influence/improvement when it comes to influencing third party
projects. This is because your labor power can be directly applied to
the project itself, and not have to be translated thru capital.
I qualified that statement with "usually" for a reason. There are
various licenses and distribution models which aren't Free Software,
but would still provide the benefit of a more direct translation of
labor power into project advancement. There are even proprietary
vendors who provide the same advantage after the initial outlay of
capital for the product license.
In my life as a professional programmer, I look at this as a
complication of the "build or buy" question. How much I buy, and how
much I build depends on how much capital I have for the project, and
how much labor power I can apply to it. The ratio of the two often
determines wether I use proprietary or Free Software. This is not the
only influence on the decision tho. The available vendors have to be
evaluated for their longevity, "enlightenment" factor, product
quality, and support efficacy. The Free Software projects are
evaluated along the same lines.
My personal preferences are much different. I prefer Free Software
for ethical reasons directly related to Freedom and the return of the
results of a socialized production process to the control of the
people whose labor produced it. I am not going to attempt to argue
for that position if we're limiting ourselves to "professional
programmers" tho.
--
Craig Brozefsky <cr...@red-bean.com>
Lisp Web Dev List http://www.red-bean.com/lispweb
--- The only good lisper is a coding lisper. ---
Tim Bradshaw
> Implementations from only a single vendor put customers at the
> complete mercy of that vendor once they have built a product. The
> vendor can charge up to the customer's pain threshold, and if they
> drop the product, the customer is left stranded. Few people who are
> responsible for a large software development project want to accept
> that kind of risk, even if the tool is quite a bit better.
This is plausible, but there's a glaring counterexample -- microsoft.
How does that work (not a rhetorical question).
> Sun did several of those things with Java, which is why people jumped
> on it. Critics of Java often seem to assume that people picked it out
> of ignorance of the alternatives. In my experience, people who helped
> get Java off the ground and pushed it into the mainstream (at IBM and
> other places) knew the alternatives full well, but they supported Java
> because it addressed those practical concerns; often, this meant
> dropping support for languages they preferred technically.
I think there are two very interesting things about Java (not in any
order):
1. Sun are *very* good at marketing. Whatever they did to make Java
apparently such a success is worth close study. (I say `apparently'
because I don't think I've ever used a significant Java program in
anger, so it's not hit my particular bywater yet, though it may
well yet do so)
2. It had some easy competition. C++ had been causing serious &
ongoing pain for some time when Java started appearing, and in
which many large and failed or failing projects had been attempted.
Targetting Java as a better C++ was smart.
--tim
John Doner
>* tom wrote:
>
>> Implementations from only a single vendor put customers at the
>> complete mercy of that vendor once they have built a product. The
>> vendor can charge up to the customer's pain threshold, and if they
>> drop the product, the customer is left stranded. Few people who are
>> responsible for a large software development project want to accept
>> that kind of risk, even if the tool is quite a bit better.
>
>This is plausible, but there's a glaring counterexample -- microsoft.
>How does that work (not a rhetorical question).
What tom described is called "Monopolistic behavior." True,
Microsoft has been a monopoly for some time now, but they
never really knew it or took advantage of it. Bill Gates
started with a very small company and built it up. Initially,
his company was one among many, surrounded by fierce
competitors, and Gates behaved accordingly. That's no longer
true, but it seems as if he's not aware of the fact; he
handles Microsoft as if it were still small and could go under
any time. This approach has brought them major problems, of
course, when they confronted Netscape this way, won the
battle, only to find that the government is trying to break
them apart. Great big monopolies just aren't allowed to
behave like little small outfits teetering on the brink of
extinction.
But maybe now Microsoft is finding out that they have to
change their modus operandi. If so, we can anticipate that
they won't make full efforts to exploit their monopoly
situation.
--
John E. Doner, UCSB Math. Dept., do...@math.ucsb.edu
Hartmann Schaffer
Is this an example of Microsoft's PR machine scanning all newsgroups for
any mention of their name and respondong by putting their spin on
current events?
--
Hartmann Schaffer
Friedrich Dominicus
>
> What tom described is called "Monopolistic behavior." True,
> Microsoft has been a monopoly for some time now, but they
> never really knew it or took advantage of it.
You're in the wrong group here better try comp.advocacy....
> Bill Gates
> started with a very small company and built it up. Initially,
> his company was one among many, surrounded by fierce
> competitors, and Gates behaved accordingly. That's no longer
> true, but it seems as if he's not aware of the fact; he
> handles Microsoft as if it were still small and could go under
> any time. This approach has brought them major problems, of
> course, when they confronted Netscape this way, won the
> battle, only to find that the government is trying to break
> them apart. Great big monopolies just aren't allowed to
> behave like little small outfits teetering on the brink of
> extinction.
Microsoft has a monopoly and used it to supress other. Finding of
facts AFAIK
Off-topic and end
Friedrich
Espen Vestre
> Sounds good! Now explain Microsoft.
People thought they had a huge choice of vendors since they were
thinking hardware and not software...
--
(espen)
at ncal point verio point com x@x.x tom
> * tom wrote:
> > Implementations from only a single vendor put customers at the
> > complete mercy of that vendor once they have built a product. The
> > vendor can charge up to the customer's pain threshold, and if they
> > drop the product, the customer is left stranded. Few people who are
> > responsible for a large software development project want to accept
> > that kind of risk, even if the tool is quite a bit better.
>
> This is plausible, but there's a glaring counterexample -- microsoft.
> How does that work (not a rhetorical question).
Yes, I agree that that is a valid question. I think there are a number
of answers:
-- There are so many people in the same boat that if Microsoft falters
suddenly or changes radically, some solution will be found. There
are several independent Win32 API implementations in the wings that
could take over at a moment's notice. The only reason they aren't
mainstream already is because they are always a little behind Microsoft's
deliberate API changes.
-- As for VB, a lot of the code written for it is small, throwaway,
so long term viability of the tool matters less.
-- Microsoft has so much cash, valuation, and monopoly power that
they can linger on for years almost no matter how badly they screw up.
-- From the point of view of an individual decision maker, Microsoft seems
like a fairly safe bet, even if it is technologically risky.
"Nobody gets fired for choosing Microsoft" has replaced "Nobody
gets fired for choosing IBM".
-- People aren't entirely rational: I think many decision makers
overestimate the long term viability of Microsoft and Microsoft's
commitment to backwards compatibility (their track record is
spotty at best).
-- Just because it runs on Windows doesn't mean it uses a lot of
Windows APIs. Much of the NT server stuff is written to C/C++
stdlib and POSIX APIs, and many software developers use various
C/C++ wrapper libraries (homegrown or commercial) that insulate
them from Microsoft's APIs.
I think even Microsoft's power to push new standards is quite limited.
For example, their Java variant was viewed with great suspicion by
many ("Do they really have a long term commitment?"), and that's only
one of a number of their failures to push through something new. They
haven't even tried a lot of really "radical" things: almost all of
their successes have been in the C/C++ API arena, often based on some
existing mainstream standard, and often if there was no widely used
alternative anyway.
In short, I think the difference is largely size and market
domination: Microsoft can get away with some things that small and mid
size software companies simply can't. It's also a question of what
the standard in question is: you can achieve good vendor API
independence if you use a standard language, but if you use a
non-standard language, you are committed to the vendor of that tool.
Tom.
Martin Cracauer
>Martin Cracauer wrote:
>> Setting yourself on a single-vendor API with only one implementation,
>> with no source you may redistribute in an emergency case, is suicide,
>What is your specific suggestion for tools that I should use in my case?
I gave up on Lisp GUI programming long ago, but up the that point
Garnet was the only toolkit I liked and found polished enough.
Martin Cracauer
> Some day, I hope to find out what Open Source _really_ is a solution
> to. So far, the only thing that really stands out is "at least it's
> not Microsoft", [...]
> If they find out that they killed a lot of software companies or
> blocked a lot of ways to make money by giving too much stuff away,
> they will turn on Open Source and blame it for the reduction in
> their options. So Open Source is a luxury phenomenon, to vanish or
> be sharply reduced when we can no longer afford that luxury.
Before I followup to your post supporting my own point, I'd like to
forward the appended message. The latter half more related to the
usefulness of free software, but I didn't want to censor the message.
~From: tlambert@x.x (Terry Lambert)
~Subject: Re: The Ethics of Free Software
~Date: 25 May 2000 03:30:50 +0200
~X-To: ch...@FreeBSD.ORG
~
~> The argument was whether this mechanism of getting rich will be
~> destroyed if all software were free. My argument was that there will
~> always be people willing to pay for work useful to them, and publicly
~> archived "free" software can no more meet a company's software needs
~> than shrink-wrapped software alone can.
~
~Significantly, Whistle has defacto become an Open Source center
~within IBM.
~
~IBM has this concept of "Architect", which really means "consultant
~who is knowledgable about IBM technology and can describe how it can
~be integrated to produce a problem soloution".
~
~From this perspective, Whistle contains "Open Source Architects",
~who are familiar with the available Open Source technology, and can
~describe how it can be integrated to produce a problem soloution.
~
~Certainly not all commercial shrink-wrap software, nor all Open Source
~software, is directly applicable to producing soloutions to any but
~the most trivial problems, taken in a very narrow context. Thus
~"Architects" of either sort have significant commercial value.
~
~But these "Architects" do not themselves produce new, unique, or
~valuable components which can then be integrated as parts of
~soloutions to new problems. And therein lies the connundrum of
~Open Source.
~
~In several projects now, I have acted at least partially, but
~increasingly, in the role of an "Open Source Architect", with my
~current project being almost entirely that, with the only code
~exception being, so far, schema definition. In this, I have had
~at least significant, and, not to toot my own horn, perhaps even
~incredible commercial value.
~
~I fully expect that I will have to take up the code-trowel at
~some point on this current project, and I will enjoy doing that,
~since I will have thought everything out before writing code
~(my personal best is currently 28,000 lines of C++ code in just
~two weeks of elapsed time, with two bugs [one typo, one uncaught
~exception in a rare case, both one-line fixes] reported so far
~after one year; yes, obviously, I unit and integration test).
~It will be like a vacation: no real brain work involved.
~
~
~> I can think of a lot of interesting things that would happen if all
~> software were "free" in the FSF sense, but a shortage of jobs is
~> not one of them. Not even a decrease in salaries.
~
~The value of a job does not lie solely in the salary and other
~tangible/fungible benefits. Indeed, many software engineers
~claim that there is no value whatsoever in these measures, since
~getting another software engineering job is as simple as getting
~on highway 101, driving until a coin flip tells you that you
~should "take this exit", and pulling into the parking lot of the
~first .com company you see, going in, and presenting your C.V.;
~if you are not a poser, you now have a new job, with stock options,
~probably a salary increase, and, if you drove the right direction,
~probably a shorter daily commute.
~
~If you want to be picky, it's a matter of hours or days, depending
~on how picky you are, and how fast you can read web pages combined
~with how well you can run a search engine.
~
~A recent survey of software engineers who posted their resumes on
~"monster.com" resulted in the statistic that the majority of them
~were looking for work which was interesting and challenging (not
~just challenging, so that lets out the "Welcome to the comapny;
~you are now only 6 weeks behind schedule!" crisis-management jobs).
~
~
~> The rich guy above will quite likely hear of your software, give
~> it a spin (without fear of being called a pirate),
~
~No problem...
~
~
~> and then hire you to fine-tune it for him.
~
~And _here_ we have the problem. This is neither long term
~interesting nor challenging, unless you are very happy in your
~cog spaced hole, or your work was not very inspired to begin
~with.
~
~The ultimate result of "if all software were ``free'' in an FSF
~sense", in my opinion, is that there would be a tiny amount of
~publically or philanthropically funded research, and the vast
~majority of the "available work" would fall into the categories
~"maintenance programming" or "glue code". Commercial organizations
~simply _will not_ provide capital outlay for things which they
~can not amortize the outlay, with a sufficient ROI to match the
~time value of money that they are giving up by investing there
~instead of elsewhere.
~
~To shorten that: "Money Talks; Bullsh_t Walks".
~
~You may be highly paid for this, but it would be fairly obvious
~and trivial, and not very intellectually taxing. You would not be
~in a position, really, to grow professionally.
~
~I maintain that the current boom in software engineering is
~because of the creative and intelligent people. When it no
~longer takes creativity and/or intelligence, they will go
~elsewhere, and so will the boom.
~
~RMS's current position is that he is philanthropically funded by
~such things as his "Genius Grant" and similar contributions
~based on his proported intellectual munificence.
~
~I suppose this is what allows him to so zealously hold the views
~which he holds: he's got his, so why do you need yours? If
~you're so good, why, you'd have a "Genius Grant", too.
~
~
~> When RMS wrote those words about being paid less he didn't
~> foresee the current IT boom, particularly the demand for
~> computerisation of businesses, customised software, embedded
~> software, and so on.
~
~Whether he saw it or not is irrelevant to the fact that the vast
~majority of people now engaged in creative, enterprising, and
~perhaps even brilliant work, would be reduced to the status of
~job-shop employees, like window installers and other non-exempt
~professions.
~
~The reason the U.S. exempted most information workers, and
~software engineers in particular, was a result of a study
~commissioned by the U.S. Department of Labor to determine
~whether or not more than 50% of the jobs time was spent in a
~creative act, or whether it was rote work. FYI, I have
~participated in this survey both times that it has been run in
~the last two decades (feel free to blame me in part for long
~hours, so long as you also credit me in part for your incentive
~stock options).
~
~Perhaps it will come to this, and I will have to return to
~my first passion, theoretical high energy and solid state physics,
~or move on to the surface physics of molecular nanotechnology;
~but don't believe that I will not because of the money I can
~get prostituting my intellect in what I view would be worthless
~and useless tasks that some idiot with a skewed view of what is
~important is willing to pay a lot of money to get done, and some
~idiot brought about because of his skewed view on software
~somehow being shackled, enslaved, and in need of protection by
~the software moral equivalent Amnesty International.
~
~RMS might believe that the only permissable commercial software
~world lives to debug his code for him and other people in the
~cabal of a chosen few permitted to write new code because of
~philantropy, but I do not.
~
~
~ Terry Lambert
~ te...@lambert.org
~---
~Any opinions in this posting are my own and not those of my present
~or previous employers.
~
~
Jason Kantz
What Really Scares Microsoft
http://www.reason.com/opeds/vp110899.html
"Friedrich Dominicus" <Friedrich...@inka.de> wrote in message
news:87aegwg...@frown.inka.de...
Jeff Dalton
> * tom wrote:
>
> > Implementations from only a single vendor put customers at the
> > complete mercy of that vendor once they have built a product. The
> > vendor can charge up to the customer's pain threshold, and if they
> > drop the product, the customer is left stranded. Few people who are
> > responsible for a large software development project want to accept
> > that kind of risk, even if the tool is quite a bit better.
>
> This is plausible, but there's a glaring counterexample -- microsoft.
> How does that work (not a rhetorical question).
With Microsoft, at least you know you're in the same boat as a huge
number of other people. And remember "No one was ever fired for
buying IBM"? Well, Microsoft is the new IBM, only even more dominant.
Anyway, I suspect Microsoft's dominance and questions about other
vendors such as "how long will they be around?" and "should we put
ourselevs at their mercy?" are two sides of the same coin.