Subject: Re: What Lisp to choose? From: Erik Naggum <erik@naggum.no> Date: 2000/06/06 Newsgroups: comp.lang.lisp Message-ID: <3169295502388140@naggum.no> * 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. 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. #:Erik -- If this is not what you expected, please alter your expectations.