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