In article <97864...@geodesy.inka.de>, Wolfgang von Hansen <w...@geodesy.inka.de> wrote:
>Juergen Nickelsen <jnickel...@acm.org> schreibt über `Re: MCL': >> While I share your sentiments about Lisp, I think FORTRAN and COBOL >> deserve equal credit for persistence. While I don't know what to expect >> from COBOL in the future, FORTRAN will probably stay the preferred >> languague for scientific computing at least for the next decade.
>I am not so sure about that. When I began to study surveying engineering a >few years ago, they did everything happily in FORTRAN 77 and were looking >forward to the advent of a Fortran 90 compiler. Now they have dropped >FORTRAN completely in favor of C (and believe me, the step certainly was >not easy because they had _very_ good software written in FORTRAN).
This is truly sad, an example of the "worse is better" principle in action.
Fortran, for all its idiosyncracies, was an excellent language for its intended purpose: representing mathematical calculations. For a very long time it was the only truly standardized computer language for scientific work. I can remember using portable macro assembler programs written in Fortran back in the early '80s.
C, in contrast, isn't even standardized enough to be portable between differing implementations on the same hardware architecture.
If even surveying engineering has switched to C, what does that say about the future of Lisp and similar languages? -- Chuck, still paid to use Common Lisp, but for how long?... -- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please), chuck...@home.com (MIME enabled), chu...@gateway.idiom.com (SPAM ONLY)
Chuck Fry <chu...@shell5.ba.best.com> schreibt über `Re: (not really about) MCL':
> Fortran, for all its idiosyncracies, was an excellent language for its > intended purpose: representing mathematical calculations.
But a good programming language needs more than just an excellent representation of mathematical calculations. To me, learning FORTRAN was an awful experience. Everything looked very much like BASIC (implicit data typing, fixed array sizes, very limited support of function calls with arrays as arguments) with added idiosy^H^H^H^H^H^Hdisadvantages. One of my early programs crashed on startup because I named it (using that PROGRAM(?) directive) similar to one of its functions. The compiler didn't report that violation of the rules...
> C, in contrast, isn't even standardized enough to be portable between > differing implementations on the same hardware architecture.
It is standardized (ANSI-C), but implementations tend to add their own functions which aren't. Or some implementations warn about implicit type conversions which others don't mind.
> If even surveying engineering has switched to C, what does that say > about the future of Lisp and similar languages?
Nothing. You should start to worry when the AI people drop Lisp (and see what they're converting to).
> -- Chuck, still paid to use Common Lisp, but for how long?...
Gruß
Wolfgang, just beginning with Lisp by programming his own interpreter. -- (_(__)_) Privat: w...@geodesy.inka.de // ~oo~ Uni: vhan...@ipf.bau-verm.uni-karlsruhe.de \X/ (..)
In article <97864...@geodesy.inka.de>, Wolfgang von Hansen <w...@geodesy.inka.de> wrote:
>Chuck Fry <chu...@shell5.ba.best.com> schreibt über `Re: (not really about) >MCL': >> Fortran, for all its idiosyncracies, was an excellent language for its >> intended purpose: representing mathematical calculations.
>But a good programming language needs more than just an excellent >representation of mathematical calculations. To me, learning FORTRAN was >an awful experience. Everything looked very much like BASIC (implicit >data typing, fixed array sizes, very limited support of function calls >with arrays as arguments) with added idiosy^H^H^H^H^H^Hdisadvantages.
There's a good reason for the similarity: BASIC was patterned after FORTRAN!
>> C, in contrast, isn't even standardized enough to be portable between >> differing implementations on the same hardware architecture.
>It is standardized (ANSI-C), but implementations tend to add their own >functions which aren't. Or some implementations warn about implicit type >conversions which others don't mind.
One key aspect that is not standardized is the exact size of int and related types. Then there's byte ordering issues, etc., etc.
>> If even surveying engineering has switched to C, what does that say >> about the future of Lisp and similar languages?
>Nothing. You should start to worry when the AI people drop Lisp (and see >what they're converting to).
I *am* an AI person, and because our applications are on spacecraft, we're seeing a lot of pressure to switch to C and C++.
-- Chuck
-- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please), chuck...@home.com (MIME enabled), chu...@gateway.idiom.com (SPAM ONLY)
> I *am* an AI person, and because our applications are on spacecraft, > we're seeing a lot of pressure to switch to C and C++.
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? 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. -- Raymond Laning 12481 Bentbrook Ln Chesterland, OH 44026 440-729-6206
186,000 miles/second - it's a speed we can live with
* Raymond Laning <rlan...@ix.netcom.com> | 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.
In article <joswig-0703982331120...@194.163.195.66>,
Rainer Joswig <jos...@lavielle.com> wrote: >In article <6dq0dt$1q...@shell5.ba.best.com>, chu...@shell5.ba.best.com >(Chuck Fry) wrote: >> I *am* an AI person, and because our applications are on spacecraft, >> we're seeing a lot of pressure to switch to C and C++.
>Aren't there other Lisp systems on spacecrafts? How about >the DS1 mission?
That's my current project: the Remote Agent Experiment (RAX) for the New Millenium program's Deep Space One mission, an asteroid/Mars/comet flyby, and technology validation mission. Autonomous operation is one of the technologies being validated. I'm a staff programmer for a contractor on the planner/scheduler and smart executive teams at NASA Ames Research Center. NASA Ames is collaborating with the Jet Propulsion Laboratory on the autonomy software. See <http://www.jpl.nasa.gov/ds1/> for an overview of the mission; see <http://ic-www.arc.nasa.gov/ic/projects/Autonomous-Systems.html> for some of my group's work.
And yes, we're flying Common Lisp for a one-week autonomy experiment. Ironically the planner/scheduler portion was halfway ported to C++ before the flight S/W management team pulled the plug on C++ due to political and S/W tools issues. Personally I was dismayed at the lack of maturity of our C++ tools, and the inconsistencies between various C++ implementations. (Sorry, I'm not naming names.)
But getting Lisp onboard has been one hell of a struggle politically, and was possible at all only because our team had strong allies in NASA upper management. About half the autonomy team feels that follow-on projects would have a greater chance of success if coded in C or maybe C++ (assuming the previous technical issues are resolved). Some adventurous folks are even suggesting Java for flight. IMHO Java makes C++ look mature!
In addition to the usual misperceptions about Lisp, commercial CL implementations are still perceived as carrying too much dead weight for spacecraft use, and rightfully so IMHO. Unlike the PC/workstation world, space-qualified megabytes and megahertz are NOT cheap. The radiation would stun most commercial grade processors and reduce memory to gibberish. Available rad-hardened processors lag their commercial cousins by an order of magnitude in speed. And there is a huge incentive for keeping spacecraft mass to a minimum. "Dead weight" in memory translates to literal dead weight in flight!
A commercial CL compiler that fit the usual compile/link/load paradigm and/or produced small executables would make CL a MUCH more viable choice for spaceflight. You don't need compilers in space, and only a lightweight debugger/interpreter is required for changes "on the fly". Alternate approaches like byte-code interpreters may also be viable, if the performance is adequate. Note that these comments apply equally to compact embedded software applications on Earth.
A colleague at another NASA center is working on a CL implementation specifically for spaceflight applications. I'll let him speak for himself if he wishes.
In case it is not abundantly clear, I speak only for myself, and not for NASA, Ames Research Center, or my employer Caelum Research Corporation.
-- Chuck -- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please), chuck...@home.com (MIME enabled), chu...@gateway.idiom.com (SPAM ONLY)
In article <3098338324395...@naggum.no>, Erik Naggum <cle...@naggum.no> wrote:
> 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. :)
.sig quote alert!! -- Chuck
-- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please), chuck...@home.com (MIME enabled), chu...@gateway.idiom.com (SPAM ONLY)
> In article <joswig-0703982331120...@194.163.195.66>, > Rainer Joswig <jos...@lavielle.com> wrote: > >In article <6dq0dt$1q...@shell5.ba.best.com>, chu...@shell5.ba.best.com > >(Chuck Fry) wrote: > >> I *am* an AI person, and because our applications are on spacecraft, > >> we're seeing a lot of pressure to switch to C and C++.
> >Aren't there other Lisp systems on spacecrafts? How about > >the DS1 mission?
> That's my current project: the Remote Agent Experiment (RAX) for the New > Millenium program's Deep Space One mission, an asteroid/Mars/comet > flyby, and technology validation mission. Autonomous operation is one > of the technologies being validated. I'm a staff programmer for a > contractor on the planner/scheduler and smart executive teams at NASA > Ames Research Center. NASA Ames is collaborating with the Jet > Propulsion Laboratory on the autonomy software. See > <http://www.jpl.nasa.gov/ds1/> for an overview of the mission; see > <http://ic-www.arc.nasa.gov/ic/projects/Autonomous-Systems.html> > for some of my group's work.
> And yes, we're flying Common Lisp for a one-week autonomy experiment. > Ironically the planner/scheduler portion was halfway ported to C++ > before the flight S/W management team pulled the plug on C++ due to > political and S/W tools issues. Personally I was dismayed at the lack > of maturity of our C++ tools, and the inconsistencies between various > C++ implementations. (Sorry, I'm not naming names.)
> But getting Lisp onboard has been one hell of a struggle politically, > and was possible at all only because our team had strong allies in NASA > upper management. About half the autonomy team feels that follow-on > projects would have a greater chance of success if coded in C or maybe > C++ (assuming the previous technical issues are resolved). Some > adventurous folks are even suggesting Java for flight. IMHO Java makes > C++ look mature!
Well, you COULD put in a C/C++ Lisp interpreter and claim your lisp is just data....
In article <6dq0dt$1q...@shell5.ba.best.com>, chu...@shell5.ba.best.com
(Chuck Fry) wrote: > I *am* an AI person, and because our applications are on spacecraft, > we're seeing a lot of pressure to switch to C and C++.
Dear Christ in heaven! They want to implement man-critical (meaning: if the software fails, someone dies) software in C and/or C++? Why not just shoot the astronauts and be done with it?
Seriously... I can see moving away from Lisp... but my choice of destinations would probably be something like Standard ML, where I could actually submit the software to theorem provers to ascertain its correctness, etc. And even with that, I'd *still* insist on triple redundancy...
If my software were responsible for keeping people alive, I'd want something better than C or C++ behind it. Something *much* better.
> -- Chuck
> -- > Chuck Fry -- Jack of all trades, master of none > chu...@chucko.com (text only please), chuck...@home.com (MIME enabled), > chu...@gateway.idiom.com (SPAM ONLY)
In article <6duu7m$...@bgtnsc02.worldnet.att.net>, Steve Gonedes <n...@address.net> wrote:
>Chuck Fry wrote: >> You don't need compilers in space, and only a >> lightweight debugger/interpreter is required for changes "on the fly".
>Maybe I'm overlooking the obvious, but can't you dump an image without >the compiler?
Sure you can, and we're doing that. But there is still a substantial amount of unused code (as in megabytes) remaining in the image. I believe this would be true of any of the commercial CL implementations I'm familiar with.
Working around this with large shared libraries a la MCL (getting back to the original topic!) is not a solution IMHO. -- Chuck -- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please), chuck...@home.com (MIME enabled), chu...@gateway.idiom.com (SPAM ONLY)
>> I *am* an AI person, and because our applications are on spacecraft, >> we're seeing a lot of pressure to switch to C and C++.
>Dear Christ in heaven! They want to implement man-critical (meaning: if the >software fails, someone dies) software in C and/or C++? Why not just shoot >the astronauts and be done with it?
You misunderstand. We're sending the AI in lieu of astronauts. The missions in question are unmanned probes.
>If my software were responsible for keeping people alive, I'd want >something better than C or C++ behind it. Something *much* better.
You and me both! -- Chuck -- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please), chuck...@home.com (MIME enabled), chu...@gateway.idiom.com (SPAM ONLY)
What news reader software is everyone using? Isn't it capable of replying to items? There seems to be a proliferation of unnecessary new threads with subjects starting "RE: ... " in this newsgroup.
In article <3503E2E3.7F8CD...@cableinet.co.uk>, Eric S. Ingram <e.ing...@cableinet.co.uk> wrote:
>What news reader software is everyone using? Isn't it capable of >replying to items? There seems to be a proliferation of unnecessary new >threads with subjects starting "RE: ... " in this newsgroup.
Blame me, I re-titled many of the tangential threads. I don't believe in reusing the same subject line if the subject has changed.
As for "unnecessary", that's your opinion. I think this stuff matters to the Lisp community. Don't read it if you don't want to. No one's holding a gun to your head. -- Chuck -- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please), chuck...@home.com (MIME enabled), chu...@gateway.idiom.com (SPAM ONLY)
| Some | adventurous folks are even suggesting Java for flight. IMHO Java makes | C++ look mature!
Tell these people to read the Sun license agreements for Java. Sun specifically disallows use of Java for certain "life or death" kinds of code. If they don't include unmanned space probes in that list, well, they might have just forgot to add it. You should check.
Not to say anything unkind about Java, of course. I'm sure it's the best thing since sliced beets.
But really, is NASA turning into the "trendy programming language of the week" club? Sheesh.
In article <6e1bal$2k...@shell5.ba.best.com>, Chuck Fry <chu...@shell5.ba.best.com> wrote:
> As for "unnecessary", that's your opinion. I think this stuff matters > to the Lisp community. Don't read it if you don't want to. No one's > holding a gun to your head.
To be fair I think the complaint was about the new threads not being necessary, not the postings themselves.
-- __ __ __ __ __ ___ _____________________________________________ |__||__)/ __/ \|\ ||_ | / Acorn Risc_PC | || \\__/\__/| \||__ | /...Internet access for all Acorn RISC machines ___________________________/ dhw...@argonet.co.uk Uploaded to newnews.dial.pipex.com on Mon,09 Mar 1998.21:39:41
I agree... I had forgotten the old days of TI lisp machines - very nice! I would certainly like to start such a project (if one is not already in progress) once I graduate from school (I don't really know enough about OS theory now). I wouldn't mind the performance hit (I never leave emacs anyhow ;). If a project is started now I could at least contribute in areas I know something about, at least testing.
b...@wetware.com (Bill Coderre) writes: > chu...@shell5.ba.best.com (Chuck Fry) wrote: > | Some > | adventurous folks are even suggesting Java for flight. IMHO Java makes > | C++ look mature!
> Tell these people to read the Sun license agreements for Java. Sun > specifically disallows use of Java for certain "life or death" kinds of > code. If they don't include unmanned space probes in that list, well, they > might have just forgot to add it. You should check.
From the license of JDK 1.1.5:
"Software is not designed or intended for use in on-line control of aircraft, air traffic, aircraft navigation or aircraft communications; or in the design, construction, operation or maintenance of any nuclear facility. Licensee warrants that it will not use or redistribute the Software for such purposes."
"Eric S. Ingram" <e.ing...@cableinet.co.uk> wrote: | Chuck Fry wrote: | > | > Blame me, I re-titled many of the tangential threads. I don't believe | > in reusing the same subject line if the subject has changed. | > | | An appropriate change of the subject line by a moderator is just fine | when the subject line no longer reflects the content of the item. | | However, what is the point of breaking the thread between items that do | pertain to the subject line? | | Making each item a thread of length one defeats useful news reader | facilities such as 'watch thread'. | | Chuck Fry further wrote: | > | > As for "unnecessary", that's your opinion. I think this stuff matters | > to the Lisp community. | | I was not suggesting that the item content was unnecessary ... just the | breaking of the threads.
I am guessing, but maybe the news<->mail gateway is not preserving the "References" headers, which are used for threading.
Yes, I have noticed the problem. Sorting the newsgroup by subject line seems like a pretty good hack workaround.
bc (liking broken headers A LOT more than "C is better than Lisp" bull.)
In article <6e022m$kv...@shell5.ba.best.com>, chu...@shell5.ba.best.com
(Chuck Fry) wrote: > In article <chewy-ya02408000R0803981457580...@news.mci2000.com>, > Paul F. Snively <ch...@mcione.com> wrote: > >Dear Christ in heaven! They want to implement man-critical (meaning: if the > >software fails, someone dies) software in C and/or C++? Why not just shoot > >the astronauts and be done with it?
> You misunderstand. We're sending the AI in lieu of astronauts. The > missions in question are unmanned probes.
Oh right right right. Of course. Mea culpa, both for the repeated posts and the brain-damage. I know about this. Eran Gat is working on this at JPL, yes?
> >If my software were responsible for keeping people alive, I'd want > >something better than C or C++ behind it. Something *much* better.
> You and me both! > -- Chuck
Heh! Thanks for setting me straight!
> -- > Chuck Fry -- Jack of all trades, master of none > chu...@chucko.com (text only please), chuck...@home.com (MIME enabled), > chu...@gateway.idiom.com (SPAM ONLY)
Craig Brozefsky <cr...@onshore.com> writes: > "Software is not designed or intended for use in on-line control of > aircraft, air traffic, aircraft navigation or aircraft communications; > or in the design, construction, operation or maintenance of any > nuclear facility. Licensee warrants that it will not use or > redistribute the Software for such purposes."
do we find this notice bundled with your average Basic/C/Fortran/Cobol compiler ? Does this imply anything about *their* safety (and implied liability) as a tool for mission critical stuff?
I think this paragraph is largely there to defuse any unreasonable safety expectations that resulted from the much publicized Java sandbox safety. Not too unreasonable (especially in this overlawyerized day and age). Just my 0.02,
Philip
-- Any coffee stains in this message must have occured in transit --------------------------------------------------------------------------- -- Philip Lijnzaad, lijnz...@ebi.ac.uk | European Bioinformatics Institute +44 (0)1223 49 4639 | Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) | Cambridgeshire CB10 1SD, GREAT BRITAIN PGP fingerprint: E1 03 BF 80 94 61 B6 FC 50 3D 1F 64 40 75 FB 53
> > "Software is not designed or intended for use in on-line control of > > aircraft, air traffic, aircraft navigation or aircraft communications; > > or in the design, construction, operation or maintenance of any > > nuclear facility. Licensee warrants that it will not use or > > redistribute the Software for such purposes."
> do we find this notice bundled with your average Basic/C/Fortran/Cobol > compiler ? Does this imply anything about *their* safety (and implied > liability) as a tool for mission critical stuff?
I wonder if this is true any longer? As you say, the way litigation is going, it seems only a matter of time before the OS and compiler vendor(s) are brought into a product liability suit.
> I think this paragraph is largely there to defuse any unreasonable safety > expectations that resulted from the much publicized Java sandbox safety.
Safety is not the same as security: the java applet sandbox (1) applies only to applets (2) is just an access-control mechanism.
In article <chewy-ya02408000R1003982139220...@news.mci2000.com>, Paul F. Snively <ch...@mcione.com> wrote:
>In article <6e022m$kv...@shell5.ba.best.com>, chu...@shell5.ba.best.com >(Chuck Fry) wrote: >> In article <chewy-ya02408000R0803981457580...@news.mci2000.com>, >> Paul F. Snively <ch...@mcione.com> wrote: >> >Dear Christ in heaven! They want to implement man-critical (meaning: if the >> >software fails, someone dies) software in C and/or C++? Why not just shoot >> >the astronauts and be done with it?
>> You misunderstand. We're sending the AI in lieu of astronauts. The >> missions in question are unmanned probes.
>Oh right right right. Of course. Mea culpa, both for the repeated posts and >the brain-damage. I know about this. Eran Gat is working on this at JPL, >yes?
Yes, Erann Gat (corrected spelling) is part of the DS1 Remote Agent Experiment team.
Erann is also working on the Lisp implementation for spaceflight that I obliquely referred to earlier in this thread, along with Gary Byers, late of the MCL compiler team (tying this back to the original subject line again!).
-- Chuck -- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please), chuck...@home.com (MIME enabled), chu...@gateway.idiom.com (SPAM ONLY)
