>>>You presented your talk and paper not out >>>of a sense of selfless service but ...
What's with the hair-splitting of the bloke's use of the the verb "to serve"? You have started a fight over a choice of words, not the idea of JS-qua-CL. Typical useless NG digression into word wrangling.
--
kenny tilton clinisys, inc --------------------------------------------------------------- ""Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it."" Elwood P. Dowd
Doug McNaught wrote: > Erik Naggum <e...@naggum.no> writes:
>> Thank you for pointing out the misuse of "take" over "make", a remnant of >> my native tongue which I now cannot imagine how slipped in there.
> AFAIK, "to take a decision" is perfectly standard British English. > Americans tend to use "make" instead.
I was reminded of the affected (here in the US) but acceptable "let's take lunch" or "take a meeting". Quite catchy, those.
--
kenny tilton clinisys, inc --------------------------------------------------------------- ""Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it."" Elwood P. Dowd
Erik Naggum wrote: > I have been holding out on this, but you, sir, are an idiot.
Oh, Christ.
--
kenny tilton clinisys, inc --------------------------------------------------------------- ""Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it."" Elwood P. Dowd
> > > You seem to blame it on the nebulous "political" problems, ideas > > > or the pressures of failing projects and tight timelines. But > > > from reading it it seems quite obvious that the problems are > > > from personal failings of the development groups at JPL.
> > Oh dear, I hope it's not obvious because that's definintely not true. JPL > > is full of very smart, very good, very busy people. But many of them are > > not computer scientists, they are *real* scientists -- the kind who do > > science. Or they are "rocket scientists", which is to say, spacecraft > > engineers. Many of them know just enough about programming to be > > dangerous (much like I know just enough about spacecraft to be dangerous) > > :-) The situation is a microcosm of the world at large. The problems > > really are political, which is to say, they arise from the complex > > dynamics of many people working together to try to get something very hard > > done. There is almost nothing going on that I would attribute to anyone's > > "personal failings." Or perhaps a better way to say that would be that > > everyone has personal failings, including myself, and they all contribute > > more or less equally to the situation.
> But the top manager getting up and esposuing that getting rid of > Lisp is the one thing that he would like to improve things shows a > lack of introspection and thoughfulness.
That wasn't a top manager, that was an engineer. (You need to go back and read what I wrote again more carefully.) The managers listened to this engineer, which most of the time is exactly what we engineers want our managers to do.
One of the most frustrating things about what is going on is that a lot of resources are being wasted, but there isn't really a villain. There is no one doing anything malicious, or even untenable based on what they know. There are no PHBs. (Well, actually there are some, but the system is surprisingly effective at shunting them into deputy positions where they can't really do very much harm. Which is not to say that all the deputies are PHBs either.)
The real problem is that the spacecraft people don't trust the software people, and so we get spacecraft people trying to do software themselves, which makes the software get done badly. But frankly the spacecraft people's mistrust is not entirely without foundation.
> > Well, the "top managers" *are* the people in control of the money, so that > > doesn't really make any sense. What would you expect them to do > > differently?
> I thought the people in control was the Congress (or whatever other branch of > government).
Congress has control over our budget at a very coarse level of granularity. They can turn the spigot on and off, but they can't excercise very much direct control over what we do with the money. (They excercise indirect control by threatening to turn the spigot off if certain things don't happen their way, but their level of interest usually stops at the borders of their Congressional districts.)
Even top management doesn't really have much direct control over how things are done technically. What they do have control over is who gets appointed to the project management positions. Project managers in turn have control over who gets appointed to the system engineering positions. The system engineers have the most direct control over technical decisions.
Sullivan) wrote: > Erik Naggum <e...@naggum.no> wrote:
> > * Erann Gat > > | And "not altogether positive" is just a diplomatic way of saying that > > | it's been a fucking disaster.
> > What remains to be explained, however, is why "Lisp" gets blamed.
> Yes. It's certainly not clear from your (Erann's) summary that there > was *any* problem caused by Lisp or the use of Lisp, or that "sending it > into space" had much to do with the JPL brass opinion of the language.
> If there's not some other side that we're missing here, it would seem > that the decision not to use Lisp at JPL, was not the result of sending > Lisp into space, or anything whatsoever to do with Lisp, the programers > using it there, or the software they produced with it, but plain and > simple ignorance and FUD.
Ah, I see.
The truth is that I don't really know why Lisp gets blamed. I have my theories, but these are nothing more than speculation on my part. (Informed speculation perhaps, but speculation nonetheless.)
"Why Lisp gets blamed" depends a lot on who is doing the blaming. I think that the overwhelming factor for most managers at JPL is that Lisp is simply not on their radar screen at all. Read current IT periodicals, look at IT conferences, Lisp just isn't there. It's all C++, Java, Perl, TCL, XML... So most managers react to Lisp not with FUD but with "what?" (Then when they get past the "what" they go on to, "Who uses it?" Sometimes my answer is "We do" but that doesn't seem to cut much mustard. The sad fact of the matter is that very few people use Lisp.)
In the specific case of the Remote Agent we had a lot of problems, some of which could reasonably be attributed to the use of Lisp. Most notably, we had the problem of how to get Lisp to talk to C in a multi-platform multi-operating-system environment. This was B.C.: Before CORBA. We adopted an interprocess communication (IPC) system that was developed by Reid Simmons at CMU as part of his TCA robot control architecture. We had no end of problems with the IPC system. It was never really designed to be an IPC, it was designed to be a robot control architecture. And it used a central server (written in C) that kept crashing. Every time it crashed development came to a screeching halt. This was the most visible problem, and it was constantly in everyone's face. So while we did not have very many technical problems with Lisp itself, it was clear that the only reason we had IPC is because we had Lisp. No Lisp, no IPC. No IPC, no central server crashes to deal with. So Lisp got blamed - somewhat justifiably - because of the unreliability of a piece of software written in C. Ironic, isn't it?
(Why didn't we ditch the IPC and replace it with something more reliable? Politics. We were required to have university involvement in the project, and the IPC was the only subsystem that was being contributed by a university. Ironically, even Reid Simmons didn't really want to do the IPC because what he was interested in was autonomy, and all his autonomy stuff got tossed out. He was probably even more frustrated than I was. From his point of view we threw out his baby and kept the bathwater. N.B.: Remote Agent flew with Reid's IPC, so he did eventually get all the bugs worked out. But, alas, not quite soon enough.)
Erik Naggum wrote: > * Erik Naggum > | Thank you for pointing out the misuse of "take" over "make", a remnant of > | my native tongue which I now cannot imagine how slipped in there.
> * Doug McNaught > | AFAIK, "to take a decision" is perfectly standard British English. > | Americans tend to use "make" instead.
> FWIW, this did /not/ help. I pronounce my R's in the right place, and > I'm damn proud of it!
A Brit once asked me why I pronounced my Rs. I guess she'd neveh heahd an Amehican speak befoh. Yeahs later when being instructed in American Standahd English, I received the same correction.
Who knew?
--
kenny tilton clinisys, inc --------------------------------------------------------------- ""Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it."" Elwood P. Dowd
Kenny Tilton <ktil...@nyc.rr.com> writes: > A Brit once asked me why I pronounced my Rs. I guess she'd neveh heahd > an Amehican speak befoh. Yeahs later
^^^^^ A trifle pedantic, old fellow, but I'm shoah you meant 'latuh'.
> (Why didn't we ditch the IPC and replace it with something more reliable? > Politics. We were required to have university involvement in the project, > and the IPC was the only subsystem that was being contributed by a > university.
Wow.
--
kenny tilton clinisys, inc --------------------------------------------------------------- ""Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it."" Elwood P. Dowd
> What's with the hair-splitting of the bloke's use of the the verb "to > serve"? You have started a fight over a choice of words, not the idea of > JS-qua-CL. Typical useless NG digression into word wrangling.
True... my bad. It just raises my hackles when people say things like "I feel we have an obligation to serve" -- not only do I consider this feeling of obligation of serving to be insulting, but to top it off he generalizes it to encompass others (ie: myself) with the use of "we".
> When you open the job section of the paper, how many employers ask for LISP > vs. Microsoft solutions?
> > Lisp does run on almost all stock hardware. What's the problem?
> Most employers don't want it; many that had it dumped it or are in the > process of dumping what little remains. And when they do they suffer no > adverse affects and maybe even see appreciable benefits. I'm talking > reverse success stories here!! That's a big problem.
Most employers want solutions to their problems. If they happened to purchase MS stuff, then that's one of their problems.
The problem is that they think in terms of the tools they have or have seen rather than searching for people to solve the problem. When I call a plumber, I don't look under the Yellow Pages(tm) for "Stanley Monkey Wrench Operator", yet that is exactly what business does every day. "Wanted: Person that can use this tool because I think it will solve my problem." Just like the pharmaceutical companies are trying to turn consumers into physicians with 30 second TV ads, the trades try to convert managers into skilled Information Systems professionals.
When business find people that can actually solve their problems, from a wide and varied tool box, they are just overjoyed at how well it turns out.
Lisp is a tool as much as Javascript is a tool. I used it in a Microsoft shop writing J2EE Java code for Suns to create Java code. The customer was delighted that they were able to change their minds every single day, all the way up to the last minute, and I never batted an eye. "No problem. Certainly. Yes, I can do that. Yes, that will be simple." Of course, the other person they were working with was completely inflexible and whined and moaned at every turn knowing that each change sent his house of cards down to the ground. And ya know what? The client had NO IDEA how I was doing "my magic". Lisp was my tool, yet Java was their solution. The other guy they had was a "Java coder".
So, yes, THEY DO WANT things like Lisp. They just don't know it.
> The scripting host interface is not well documented, and with the > advent of .Net the entire game has been changed with the rug having been > pulled out from the way the game was played in the past.
And you wonder why folks complain about Microsoft. And you chime in on how Javascript is so popular and is being tested by zillions of people.
Javascript has, what, two? three?? implementations? and how compatible are they with each other? They're "close"?
ONE implementation is being tested by a lot of people. The others by fewer people. Ubiquitous Javascript tends to be less portable, and less powerful than the One True Javascript, for the One True implementation.
Perhaps you only care about the MS version. In that case, who cares about standards at all? Oh, wait, there's that "rug being pulled out" thing.
> > This is too funny. Where will JavaScript be if society collapses?
> A lot better off than LISP! If there is a serious depression or deep > recession, Javascript will be a good skill to have; assuming the collapse > isn't total. Things will peal off with the least applied going first. The > more widespread technologies will fare much better.
I like this kind of blindness. I see it all the time, and it's fascinating to watch. You tie the concepts and the technology of something to the actual implementation and, in this case, the language. This, in my experience, always leads to failure in the long term for people.
To be specific, in your scenario, the Javascript skill is not what's important. What is important is an understanding and manipulation of the DOM model and DHTML. Javascript is a detail. Like all of those "experts" who learn their DB technologies from assorted wizards and what not, and not from the actual basics of how databases work, and how to make them perform (whether with SQL or ISAM methods or what have you). As soon as they're dropped out of their environment, they're DOA. They discover in environment Q that the F6 key doesn't do what it did in environment K. And they're at a loss as to why that is, or how to get around it. F6 ALWAYS worked before, so how come it doesn't work now?
With Javascript skills, you can move your talents any place Javascript goes.
With DOM and DHTML skills, you can move whereever THEY go, whether it is in Javascript, VBScript, .NET script, SCHEMEScript, whatever.
And you may rave in wonder at the capabilities of Javascript, and how it's all so popular, and that all of these coders are getting amazing powers out of using it. I can assure you, however, that they're not. A select few, you for example, grok the deeper concepts of Javascript and perhaps push it to new heights. But a VAST majority of these folks are doing cut-n-paste coding with barely a thought as to how the stuff they just pasted in works. They simply don't care.
It's not a Javascript thing either, it's an industry thing. You'd see the same in Java, Smalltalk, COBOL, etc. Anywhere.
To them, "Javascript" skills are important. These folks can not jump off the Javascript wagon and on to the ACMEScript wagon.
And also consider the ubiquitous coders who have been writing in Visual Basic. An environment that has never sat still, that has continued to throw their coders for a loop every single version. An environement that stays on top of whatever MS marketing is pumping out that day. "MS has a new version, so you either learn it all again anew, or stay stuck at where you're at." "I know Visual Basic! Great, what version? Ummm....VB 3! Sorry, can't use you."
I don't dabble much in Javascript, but I think its got a neat model. NewtonScript showed that it could be pretty successful and do interesting things.
Lisp offers more as a tool than most anything else because of the fact that it evokes a different mindset for those who use it. You may be a classic example of this. If you did not know or have experience with Lisp, you may not have seen the depth that the Javascript model has provided. The Lisp environment opens up a lot of eyes in a lot of ways, and I think it can make IT people better problem solvers regardless of their environment.
Lisp promotes this mindset because of its capabilites, and because of how it is used. Javascript, I would guess to say, does not advocate this. I'm sure a majority of the questions are "how to I make my form field BOLD?". That is, how do I manipulate the DOM properly with Javascript. That's pretty narrow thinking, but it's the reality of its environment. Of course, not 100% of folks stop at this level, and some may get deeper into it, but I'd wager that's not what most people are doing, or are interested in.
The problem with what you're advocating, i.e. splitting Lisp into its component parts and cherry picking what you like, misses the power of the entire environment.
As you said, you see Lisp with Javascript, but clearly it's not all there. Something is missing. Maybe nothing substantial for the task Javascript is being used for, but it's still missing. You are just fine with that. It's "lispy" enough for you, and therefore you feel that the stuff you're not using is not important anymore. "Clearly business only needs the parts they are using, so let's toss the rest, and make Lisp popular!".
No. Let's not. It's not effective, and it constrains the view. It's better to have a broader view of tools to view the problem landscape.
For example, if you have issue with the Javascript syntax, there's not much you can do about it. If you used a meta language, with a syntax you like, that perhaps filled in your "function.name" slot for you, perhaps you'd be even more productive, even though it still generates Javascript. One of those systems where even though you need to debug in the Javascript source code, you're aware enough to make your changes in your meta language. Perhaps learning that the more you work in your meta language, the less you have to debug overall. The closer your language gets to your applications meaning that your concepts are more directly conveyed to the computer.
You can do all of that with Lisp very easily. You can not do that with Javascript very easily. Your employer wouldn't know BOO about what you were doing because all they would see is Javascript, debugged, robust, "flawless", "portable" Javascript that, amazingly, seems to get all of those little details right that others keep missing. "How is it that this guy writes code for both IE and Netscape, in half the time of the rest?" THAT is what your employer wants. Really. More productive people, generating better quality deliverables.
And when MS says "Javascript is for sissies, you REALLY need C#Scipt!", amazingly, your stuff is all ported in two weeks. How about that!
That's the Lispy-ness that other systems just can not pick up. This is where they break down, and it is very difficult to describe to people, you can only show them.
This is why if you throw out one piece of Lisp, then you might as well toss the entire baby.
"Andre van Meulebrouck" <vanme...@earthlink.net> writes:
Your answer doesn't really address the point of my post, nor do I see how porting CL to .NET is going to help anyone. As someone who uses CL all day, it's basically the LAST thing I want to see done because it will destroy the very advantage I was talking about. I simply don't see how that concrete manifestation of your "ride the juggernaut" theory is going to be good for me.
> Thus, the philosophy of the ubiquitous I espouse may good for a programmer, > but not so good for some small companies (which get hurt by this strategy).
> Here is my reply:
> That is why I suggest LISP vendors make CL work under .NET as a CLR > language! > That is why I suggest riding the juggernaut rather then being crushed by it > (this goes for everyone from programmers to vendors, to companies).
Patrick W <patrickw...@yahoo.com.au> writes: > Kenny Tilton <ktil...@nyc.rr.com> writes:
>> A Brit once asked me why I pronounced my Rs. I guess she'd neveh heahd >> an Amehican speak befoh. Yeahs later > ^^^^^ > A trifle pedantic, old fellow, but I'm shoah you meant 'latuh'.
^^^^^^ -- fellah
BTW, the 'r' in 'American' is always voiced.
-- Piers
"It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
>> For instance, .Net isn't language centric; how about targeting .Net >> with CL?
> Not language-centric? Where's the support for multiple inheritance? > Where's the support for integers larger than 64 bits in size? How > do I access a global symbol in the .NET CLR? How do I add a new > type of method combination to my C# member function? The CLR may be > *less* language-centric than the JVM, but it still demures to the > tyranny of the (linguistically speaking) norm.
This is certainly the view taken by the people working on the Perl 6 effort; CLR is fine and dandy if you're using a statically typed language, but it's a complete screaming bastard for more dynamic languages.
-- Piers
"It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite." -- Jane Austen?
> Lisp is a tool as much as Javascript is a tool. I used it in a Microsoft > shop writing J2EE Java code for Suns to create Java code. ... > And ya know what? The client had NO IDEA how I was doing "my > magic". Lisp was my tool, yet Java was their solution.
I'd love to hear more about how this is done, either your case in particular or a pointer to some articles/books which describe something like this. I'm intrigued!
Tim Bradshaw <t...@cley.com> writes: > * Michael Hudson wrote:
> > Are there situations in CL where an anonymous function has clear > > benefits over a flet?
> It's concise.
OK, but in Python there are other disadvantages of anonymous functions that overcome *that* benefit.
I think Python's lambda is a bad idea because it encourages a style of programming that's not really appropriate for Python. I know some people disagree with me on this but they're, well, wrong :)
Cheers, M.
-- Not only does the English Language borrow words from other languages, it sometimes chases them down dark alleys, hits them over the head, and goes through their pockets. -- Eddy Peters
On Sun, 10 Nov 2002 11:57:58 GMT, "Andre van Meulebrouck"
<vanme...@earthlink.net> wrote: > The issues LISP faces aren't programming language issues at this juncture. > They are marketing and survival issues! That is what I think you need to
Concerning survival issues, note that Lisp has been around for about 44 years, and it's the second oldest language still in use. The same can't be said of other computing technologies and fads.
On Sun, 10 Nov 2002 15:58:43 GMT, "Andre van Meulebrouck"
<vanme...@earthlink.net> wrote: > I think Microsoft has the coattails to make LISP win and win big; and so I'm > optimistic that Microsoft is LISP's greatest hope of becoming widespread.
[SHUDDER]
> Javascript is so close to LISP it's more than enough to make me a very happy > camper.
Your idea of similarity or proximity is too broad for me.
> .Net also features the best garbage collector ever created (according to the > person in charge of that department at Microsoft and I have no reason to > doubt him). LISP gurus were called in to help craft it (sorry, but I won't
Such a statement about .NET's garbage collector may be accepted as is by a teenager mostly familiar with playing videogames or dowloading MP3 files off the net. But given that it comes from a company with questionable business ethics, and a strong reliance on marketing (would Microsoft's marketing department be equally happy if the guy had stated that they had created a mediocre technology?), you shouldn't be surprised if the members of a technical forum, especially a Lisp forum, take it with a grain of salt.
> So, it would appear that everything is in place for LISP to be very healthy > because of Microsoft.
[SHUDDER]
> I've been condescended to pretty intensely on this list as if I'm not > current on LISP.
The capitalization you use for Lisp is a hint that you are not current with what goes on in the Lisp world.
> That's not entirely the case: I'm just current on different things. I'm > not as interested in what LISP vendors are up to (I do keep tabs on them
This is interesting. Users continually ask for more and better libraries and tools, but you are not interested in what vendors do about this.
> > Lisp is a tool as much as Javascript is a tool. I used it in a Microsoft > > shop writing J2EE Java code for Suns to create Java code. ... > > And ya know what? The client had NO IDEA how I was doing "my > > magic". Lisp was my tool, yet Java was their solution.
> I'd love to hear more about how this is done, either your case in > particular or a pointer to some articles/books which describe something > like this. I'm intrigued!
I would, but it's not super relevant to the group, and you didn't provide an email address (mind you I discovered this AFTER I had written an OPUS in response).
>>Lisp is a tool as much as Javascript is a tool. I used it in a Microsoft >>shop writing J2EE Java code for Suns to create Java code. ... >>And ya know what? The client had NO IDEA how I was doing "my >>magic". Lisp was my tool, yet Java was their solution.
> I'd love to hear more about how this is done, either your case in > particular or a pointer to some articles/books which describe something > like this. I'm intrigued!
Sounds like or at least reminds me of the LispInJ (sp?) tool presented at the conference. Sorry if I am totally misconstruing what Will was talking about, but anyway...
...not that I personally want to do anything other than 100% Pure Lisp, but maybe things like LispInJ could be the killer app for Lisp. If Lisp is the superset of all languages, maybe vendors should just dash off code generators for each new language du jour as they pop up. Suddenly their marketing department can march right into every Mega and MiniCorp in the world and sell product. And they can spin it as, say, "a Java code-generator", not CL. ("Oh, no. It's a Java generator. It only looks like Lisp. We're working on that." Not.)
If we are looking for the Lisp killer app, won't it be something that leverages its most fundamentally amazing feature, its ability to support an embedded language? OK, this is a little different because usually we /implement/ the embedded language in CL and LispInJ just generates Java source. But for a CL vendor that is a necessary marketing ploy to make the Java productivity tool palatable to The Great Unwashed: they still get their beloved Java source.
The LispInJ developer I think conceded, hey, if you muck with the generated source we can't suck that back into LispInJ. I guess the "fix" there is not to muck with generated source. I wager they got into that because they were using LispInJ in-house to do Java consulting for OtherCorp, so the ultimate consumer of the source had little incentive not to worry about going back to LispInJ (if they even knew about the LispInJ). But if a customer can be sold on such a thing, the users would learn soon enough to make changes to the original LispInJ source.
Now we're talking Ubiquitous Lisp. CL vendors can compete over who has the best Java or Python or C++ generator. Instead of trying to implement CL in the VM of Java or CLR, the machines we code to are the source language specifications. (Nice benefit: no need to worry about runtime interoperability between Lisp and whatever).
We win over each community at the source level, because CL is best at syntax. Wait till the best developers in these communities get a taste of procedural macros. No matter what new language comes along, we co-opt it and all the development $$$ that get thrown at its compilers, VMs, and libraries.
C'mon, let's make Java our little bitch.
:)
--
kenny tilton clinisys, inc --------------------------------------------------------------- ""Well, I've wrestled with reality for thirty-five years, Doctor, and I'm happy to state I finally won out over it."" Elwood P. Dowd
g...@jpl.nasa.gov (Erann Gat) writes: > In article <4wunmbjul....@beta.franz.com>, Duane Rettig <du...@franz.com> wrote: > > Lisp has indeed been sent into space.
> I don't really want to take sides because I have very mixed feelings about > the issue, but for the sake of informing the debate I would like to point > out that the net result of Lisp's being sent into space was not altogether > positive. See http://www.flownet.com/gat/jpl-lisp.html for the gory > details.
Was it, in your view, also a technological failure?
And BTW, is that the way they choose their technology at the JPL? A casual "Get rid of X", and that's it? No evidence, no numbers? What did the other guys that where working with lisp say?
Why could he get away with this if - as you say - the reasons did not hold water?
> One of the most frustrating things about what is going on is that a lot of > resources are being wasted, but there isn't really a villain. There is no > one doing anything malicious, or even untenable based on what they know. > There are no PHBs. (Well, actually there are some, but the system is > surprisingly effective at shunting them into deputy positions where they > can't really do very much harm. Which is not to say that all the deputies > are PHBs either.)
Then why are you promoting Lisp use at JPL then, and, having so much of a problem with it? There seems to be no benevolent forces either. Malevolent forces also include doing nothing and expending no energy to get past the obstacles. (I am just following orders! I am just doing what everyone else was doing! or in the case of political disputes, killing your opposition (it takes very little effort)) Benevolence takes great energy to actually make life better.
Your explanation of the IPC problem and it being written C. Did anyone blame it on C and say, "let's get rid of C"? Probably not, they probably blamed it on the developers and their circumstances (in this case needing an IPC to Lisp). They blamed the outside circumstances for their foul-ups. Its everyone else's fault.
Were you at the meeting when the engineer said to get rid of Lisp? Did anyone stand up in rebuttal?
> The real problem is that the spacecraft people don't trust the software > people, and so we get spacecraft people trying to do software themselves, > which makes the software get done badly. But frankly the spacecraft > people's mistrust is not entirely without foundation.
If software development is so un-professional at JPL, of course they do not trust the software people. Trust is earned. Get some new software people. Right now they seem to be in a fantasy world that they are doing a good job (time to put in some metrics to measure what is actually going on).
The only concrete suggestion I have for changing things is that projects have two or more competing streams of development. One in C (or whatever), one in Lisp and any others you might want. Also have a testing group which is independent of the development. See who produces a compliant running system first, use that system in the final product. It might cost more at the beginning, but as time goes by.....
"Andre van Meulebrouck" <vanme...@earthlink.net> writes:
> (BTW, there's a "k" at the end of my name.)
Sorry about that; the gnus Summary outline cuts off the name after 20 characters, and I hadn't noticed the k at the end in the posts.
> I wish you had attended my talk because I covered a lot of stuff.
I will get the Conference Proceedings, and will read it then. I must admit though, that the more you talk here, the less incentive I have to read your paper. Perhaps you can make it available online somewhere, so I can get the points you want to make as you wanted to present them.
> Many on this list are reacting to me as if I'm a traitor to LISP!
Not me. My reaction to you is as one who does not understand Lisp. Common Lisp, that is. Your obvious ties to and understanding of Scheme and the prejudices it has produced in you against Lisp ony solidifies my view that learning Scheme before CL is definitely a Bad Thing. But I don't view you as a traitor to CL; you cannot betray something you were never part of to start with.
> If they had only heard my talk!
If your paper says what your actual talk has, then you can rectify that by publishing it.
> I am even more optimistic about LISP than you are!
Amazing. I have put my livlihood and career on the line for Lisp, and you have not. I have spoken about what is, and you have spoken about what isn't and what should be. Your statement is ridiculous as it stands, because you are not at all optimistic about Lisp, only about its concepts and how it will propagate into the rest of industry (a fact that everyone in the Lisp community has known for many years). Yes, I admit I am not optimistic about Scheme. It will remain, as you say, an academic R&D language; that is what its community seems to desire, and that is not in line with my desires. But we're not talking about the same language, here.
So I'm curious, since you made such a bold statement: what is it that makes you think I'm not optimistic about Lisp?
> Javascript is so close to LISP it's more than enough to make me a very happy > camper.
I'm glad you're happy. But it's not close enough to Lisp to make everyone happy.
> On the server side, the situation is even rosier for LISP via Microsoft. > (On a server, you can do anything you want!)
Of course.
> .Net is not language centric: everything compiles to CLR and there is a > common type system. The common type system means you can catch exceptions > from a module written in a diffent language, and you can extend it (etc.).
> In .Net, you can use Scheme (it has a CLR compiler, created by Northwestern > University). And ML, Haskell, and a lot of other languages are supported > (by 3rd party vendors).
Good for them. Let's see how many people actually buy these as a product. What are the benchmarks for these products?
> .Net also features the best garbage collector ever created (according to the > person in charge of that department at Microsoft and I have no reason to > doubt him). LISP gurus were called in to help craft it (sorry, but I won't > dare drop any names here as I don't think it would be a good idea to do so!)
The discussion about the appropriateness of .NET for CL has already taken place at least twice on this newsgroup, and I don't care to repeat myself yet again. Some have already refuted your claims of CRL's superiority, and if you did just a little googling, you would see similar statements last year and the year before that.
> So, it would appear that everything is in place for LISP to be very healthy > because of Microsoft.
Microsoft give not one rip about Lisp. Microsoft is just another platform, and has nothing to do with the health of Lisp.
> I've been condescended to pretty intensely on this list as if I'm not > current on LISP.
You've been corrected pretty heavily on this list because you are not current on Lisp (though, given your Scheme background and emphasis, I can now see why).
> That's not entirely the case: I'm just current on different things. I'm > not as interested in what LISP vendors are up to (I do keep tabs on them > however!) because I don't think that's ultimately going to be the hope of > LISP.
Being part of a vendor, I cannot comment directly to your statement objectively. However, I can say that our customers all tend to see it differently than you, and are always concerned about what we (the vendors) are doing. I'm sure it is the same with all of the CL vendors' customers, as well.
> I am pretty current on what's going on at Microsoft however; because that's > where I think the big break for LISP is most likely to happen. And on that > count, I'm very optimistic!
You're a man looking under a light pole for a coat he lost in the dark alley. Am I pessimistic because I think you're not going to find your coat? Well, yes, probably so. But when I, using my flashlight in the alley, happened to find your coat, would you even recognize it when I gave it to you?
* Wade Humeniuk | The only concrete suggestion I have for changing things is that projects | have two or more competing streams of development.
Expensive as this may sound, it is probably the /only/ way to reduce the cost of software development and actually acquire the experience we lack on which software development methodology works better than others.
I am in general no fan of competition (I think it makes people optimize for superficial qualities), but if the cost of failure is limited, at the very least people will not run around like headless chicken because they fear for their jobs, which is frequently the consequence of competition.
-- Erik Naggum, Oslo, Norway
Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.
> You're a man looking under a light pole for a coat he lost in the dark > alley. Am I pessimistic because I think you're not going to find your > coat? Well, yes, probably so. But when I, using my flashlight in the > alley, happened to find your coat, would you even recognize it when I > gave it to you?
That's a new take!
A Sage comes across a man searching the ground outside his house. Sage: "What are you looking for?" Man: "I lost a needle, it's very important." Sage: "Well, where did you lose it?". Man: "In the house.". Sage: "Why are you not looking in the house then?" Man: "There is not enough light in there to see."
Erann Gat wrote: > In article <3245861963284...@naggum.no>, Erik Naggum > <e...@naggum.no> wrote:
>> * Thomas F. Burdick >> | That sounds dangerous! Hopefully if he is, it's >> | powered by a 9-volt battery, and not wall voltage...
>> If you can get an arc out of a 9-volt battery, that >> would be spectacular.
> It's actually not that hard. Just hook the battery up to > an inductor, then > disconnect it. The bigger the inductor the better. You > can indeed get some fairly spectacular results this way.
> (What happens is that the inductor is essentially a > short-circuit to the battery, which therefore pumps a lot > of current through the inductor, > which creates a strong magnetic field. When you > disconnect the battery the field collapses, which induces > a very high voltage in the inductor.)
Did you try this? Actually, most batteries have a high inner resistance. I am not sure that it will work. -- JB
