From ... From: Erik Naggum Subject: Re: (not really about) MCL Date: 1998/03/08 Message-ID: <3098338324395826@naggum.no>#1/1 X-Deja-AN: 331910044 References: <34F79B28.5EFA411C@inav.net> <97864763@geodesy.inka.de> <6dkr32$4r1$1@shell5.ba.best.com> <97864786@geodesy.inka.de> <6dq0dt$1qu$1@shell5.ba.best.com> <350241B2.3F85@ix.netcom.com> mail-copies-to: never Organization: Naggum Software; +47 8800 8879; http://www.naggum.no Newsgroups: comp.lang.lisp * Raymond Laning | I am curious why there is such pressure to enforce tool choices - with | the adoption of CORBA and/or ActiveX, and Lisp vendor support of such | standards, why should a particular application be concerned with which | language it is written in, apart from its suitability to the task at | hand? in brief: the blue-collarization of programming. managers don't need _programmers_, anymore, they need coders, lots of them. programming is not an art, it's just skilled labor. lots of coders sitting at an assembly line putting together some bulky, crappy application in C/C++ is cheap, easy to manage, and fits right in with how MBAs have learned to run factories. | BTW, I wrote an application in ACL for a PC - my client was very nervous | because "Lisp is slow, a memory hog, yada, yada, yada." My initial | software package was as he feared - it took 7 minutes to process a 6 MB | file, but when I spent two weeks doing memory management and strong data | typing, that time fell to 40 seconds - a time that would have been | considered fast in C/C++. My point here is not to toot my own horn, but | to point out that Lisp should be able to hold its own in the market place | if it is evaluated on its merits, not on someone's prejudice. this parallels my experience. initial cuts on solutions are developed fast, run slow, and allow the customer (or the developer) to assess the various designs and approaches. then I profile, rewrite, and shine the code up, and it runs faster than the dumb C code some cheap labor would have written. at lower costs. of course, some management gets nervous just because the development cycle is different from that of C/C++ -- and there are usually enough unknowns in the development process already to give anybody good reason to be nervous, especially since it's no fun to do what already has a known, simple solution. there _are_ managers out there who care more about the results than about being control freaks and reducing irrelevant uncertainty factors, but they aren't in the majority. the majority optimize for costs and time schedules prematurely. come to think of it, that's just what C/C++ programmers do, too... I guess they deserve each other. :) #:Erik -- God grant me serenity to accept the code I cannot change, courage to change the code I can, and wisdom to know the difference.