Dobes Vandermeer <do...@mindless.com> writes: > More important issues are things like packaging; many lisp environment > do not compile executables
Huh? Both major commercial Common Lisp vendors (for Windows and UNIX) have compilers that produce executables. At least one of them can also produce DLLs.
Paul Rudin <pa...@shodan.demon.co.uk> writes: > Vassil Nikolov <vniko...@poboxes.com> writes:
> > In article <m3so9cgjlq....@shodan.demon.co.uk>, > > Paul Rudin <pa...@shodan.demon.co.uk> wrote: > > > Kent M Pitman <pit...@world.std.com> writes:
> > > > Nothing in CL forbids you from type-declaring every variable.
> > > It might be nice to have some standard, succinct syntax for this. > > > Maybe something like:
> > I don't think we need a new standard for that. The DEFMETHOD > > syntax: ``(parameter class)'' can be reused, so that the above > > example becomes:
Making the syntax be (foo integer) is bad, though. There is an issue a lot of people don't talk about but that many of us old-timers know which is that Meta-. (definition lookup in Emacs/Zmacs) really wants the cadr position of definition forms to be "names". Unless you're planning to make dispatch dependent on the return value (which you can really only do in a strongly typed language and which I'd argue is conceptually ill-defined even then), then (foo integer) is not the name. A better syntax is (defun foo ((list cons) (x integer) ... &return integer) ...)
Btw, DEFSTRUCT violates the rule about the CADR being just a name and causes lots of problems in text editors.
Christopher C Stacy <cst...@world.std.com> writes:
> Dobes Vandermeer <do...@mindless.com> writes: > > More important issues are things like packaging; many lisp environment > > do not compile executables
> Huh? Both major commercial Common Lisp vendors (for Windows and UNIX) > have compilers that produce executables. At least one of them can also > produce DLLs.
Maybe he only meant to say "many lisp environments produced for casual use are suitable only for casual use, and only those lisp environments that intend to be commercial quality address this commercial concern". ;-)
I agree. Quite a lot of Lisp implementations address this issue, some in more turnkey ways than others. That some implementations don't is merely a commercial choice--if those implementations find a following, their users presumably are able to cope without this. At some point maybe they'll add the feature too, or maybe they'll lose customers. That's the way the market works. The market is intentionally and appropriately pluralistic. Saying that some implementation doesn't suit your need is just saying you should be shopping; saying no implementation suits your need is just saying there's a market opportunity waiting for you.
In article <sfwaevgebl2....@world.std.com>, Kent M Pitman <pit...@world.std.com> writes:
> Making the syntax be (foo integer) is bad, though. > There is an issue a lot of people don't talk about but that many of > us old-timers know which is that Meta-. (definition lookup in Emacs/Zmacs) > really wants the cadr position of definition forms to be "names".
That sounds like a pretty poor reason. It's not that hard to get emacs to take the car if the cadr is a list. In zemacs, you'd just have your new defun macro make a call to that function that registers the definition. (Sorry I can't remember the name of it and my Schema sources are off line at the moment.)
> CLOS provides a world view where we have extended functions to > overload based on the class of its operators.
You mean 'operands' presumably? The function itself is the operator according to conventional use of these terms.
> The object abstraction of data and methods has been lost;
It has not been lost. In fact, it is much stronger than in most OO languages. In typical use, all access to an object's state is via functions, called accessors. The client of a class doesn't have to know whether an attribute is stored as data (corresponding to a C++ data member), or is computed by a function. the implementation can be changed from data member to function and vice versa without affecting clients.
Lisp doesn't enforce information hiding in the same strict manner that C++ does, which is simply a different philosophy. It has nothing to do with abstraction, though. Also note that classes are not the primary tool for information hiding in Lisp. Lisp uses classes as types, and packages for modularity.
> CLOS methods are not methods, but functions,
C++ methods are also functions. Just think about it a little more: When you call a C++ (non-static) method the outcome is a function (in the mathematical sense) of the target object and all other method arguments. C++ syntax simply puts one of the function arguments in a different place from others. The argument singled out in this way is the one used for dynamic dispatch. Note, that nobody would have proposed using this syntax if the more general case of multiple dispatch had been considered from the start.
> and CLOS does not protect encapsulated data from the "outside world" > of functions and methods.
Common Lisp lets you circumvent abstraction layers if you insist, but this is also true in C++, just requires a little more effort. Abstraction doesn't require dictatorial enforcement.
> A "better" object world view would allow for only acessing fields in > the object directly inside of methods for the object, thus providing > the mystical "encapsulation" that is currently underpromoted in > CLOS.
You may not realize that CLOS accessors are, in fact, methods. You can choose not to generate any accessors, in which case the corresponding slots are not considered part of the class' interface.
Encapsulation is not underpromoted, Lisp simply takes the more general view that methods can be sent to more than one object. Look at binary functions: the natural way to express the semantics of the binary function + doesn't single out one argument over the other. In C++ and other single-dispatch languages one must awkwardly make such functions methods of one or the other argument.
> The syntax, although it is often trivialized by many people, is also > fairly important.
Syntax is a metter of taste.
> In a LISP function call, all arguments are weighted equally, and so > you are led to think about specialising based on any or all of the > parameters.
Yes. why, in general, would you want to force us to single out one of them?
> And object-oriented version, i.e. "(send-msg-to obj (do-something a > b c d))" shows you which object is being operated upon,
But sometimes you operate on more than one!
> and although you could (easily) still specialize on the remaining > variables (i.e. a b c and d) to call a different method,
Not as easily as you make it out, it is certainly much more painful than with multiple dispatch. And on this point the whole issue of covariant argument redefinition raises its head, you may want to read some of the heated discussions in comp.lang.eiffel on this topic. As I mentioned before, even Stroustrup believes multiple dispatch is a good feature to have.
mike...@mikemac.com (Mike McDonald) writes: > In article <sfwaevgebl2....@world.std.com>, > Kent M Pitman <pit...@world.std.com> writes:
> > Making the syntax be (foo integer) is bad, though. > > There is an issue a lot of people don't talk about but that many of > > us old-timers know which is that Meta-. (definition lookup in Emacs/Zmacs) > > really wants the cadr position of definition forms to be "names".
> That sounds like a pretty poor reason. It's not that hard to get emacs to > take the car if the cadr is a list. In zemacs, you'd just have your new defun > macro make a call to that function that registers the definition. (Sorry I > can't remember the name of it and my Schema sources are off line at the > moment.)
I don't agree. It's not just Emacs but all potential programs that operate on this. And it's not just cadr, but a table that the program would have to magically have and which there is no mechanism to provide.
On the Lisp Machine, there is an elaborate protocol for informing the system of how to extract the name from the other stuff. But I have to say that I think it's infinitely better just to have that be unnecessary.
Lisp has gotten a huge amount of its power not out of "picking the best or most interesting way to do things" but out of "picking a known, predictable way of doing something". The power comes NOT from the goodness of the choice, but from the lack of infinite quibbling over it. I claim that this is an example of such. Pushing for a change is pushing for a life of infinite quibbling.
Don't accept that taking cadr to get the name is the right thing because we've always done it that way. Accept that we've always done it that way because it's really the right thing.
Paul Rudin <pa...@shodan.demon.co.uk> writes: > Yes, picking your own syntax is fine up to a point, but other code may > have used the same syntax for a differnt purposes and you then run > into problems if you want to combine your code with such.
But with Vassil's solution, the package system would solve those problems for you[1], whereas with reader-macros, you'd have to do much more to keep out of trouble.
The only problem the package system can't solve IMHO is that code not written by you will most likely not have the amount of type declarations you'd like, which in some circumstances will weaken your implementation's ability to do type-inference and type-checking considerably. But short of changing the standard to require type declarations, no solution will help you here. Of course you can still declaim ftype's for those functions from the outside, but I'd consider this practice fairly rude...
BTW: Vassil's syntax (optionally extended to allow specifiying a return type) is not a lot of work to implement, since you can most probably snarf a defun-lambda-list-parser from either CMUCL or PCL.
Regs, Pierre.
Footnotes: [1] In fact I'd claim that this area of use is one of the main strengths of the package system. See the Symbolics Lisp machines, which for a long time had a large number of different dialects available at the same time, in the same address space...
You'd just define a package "RUDIN-CL", which would import&re-export all the CL symbols, with the exception of defun&co., which would get their own definitions in RUDIN-CL. In fact in a previous discussion some time ago, Tim Bradshaw posted a nice macro, which makes the task of defining dialect packages a lot nicer. Just search via DejaNews for Message-ID <ey3g1frs0wc....@todday.aiai.ed.ac.uk>.
PS: I'd agree with anyone who might find the above syntax slightly perplexing. I still prefer (declare ...) inside the function body. The only addition I think would be nice was a "values" declaration like CMU CL's, which would allow me to declare the return type of my function within the body as well.
> The syntax, although it is often trivialized by many people, is also > fairly important. In a LISP function call, all arguments are weighted > equally, and so you are led to think about specialising based on any or > all of the parameters. And object-oriented version, i.e. "(send-msg-to > obj (do-something a b c d))" shows you which object is being operated > upon, and although you could (easily) still specialize on the remaining > variables (i.e. a b c and d) to call a different method, the > message-passing paradigm is preserved.
So in effect you are complaining that CLOS doesn't restrict your world view enough. Interesting complaint. This reminds me of the following two prayers (see Douglas Adams, Mostly Harmless):
Protect me from knowing what I don't need to know. Protect me from even knowing that there are things to know that I don't know. Protect me from knowing that I decided not to know about the things that I decided not to know about. Amen.
Lord, lord, lord. Protect me from the consequences of the above prayer. Amen...
Regs, Pierre.
PS: Hmmm, somehow I get the feeling we are in the middle of another Turing-Test again. Craving for restricted world views might be what AIs dream of at night... ;)
In article <sfwvhe4e99s....@world.std.com>, Kent M Pitman <pit...@world.std.com> writes:
> mike...@mikemac.com (Mike McDonald) writes: > Lisp has gotten a huge amount of its power not out of "picking the > best or most interesting way to do things" but out of "picking a known, > predictable way of doing something". The power comes NOT from the goodness > of the choice, but from the lack of infinite quibbling over it. > I claim that this is an example of such. Pushing for a change is > pushing for a life of infinite quibbling.
I wasn't arguing that the standard should be changed to that but that if one wanted to make their one "extension", that's a fairly reasonable way to represent it.
> Don't accept that taking cadr to get the name is the right thing because > we've always done it that way. Accept that we've always done it that way > because it's really the right thing.
But there is precedance to the CADR being a list, namely DEFSTRUCT. (Didn't one of the New/Old Flavors also have the CADR to defmethod being a list at times? Seems like I remember it having somethingto do with specifying before or after methods. Gnuemacs didn't like them either but a simple hack to ctags fixed that.)
<pit...@world.std.com> wrote: >Maybe he only meant to say "many lisp environments produced for casual >use are suitable only for casual use, and only those lisp environments >that intend to be commercial quality address this commercial concern".
Being able to build an executable program which can run on different computers that don't have Lisp is not just a commercial concern. Even if you just want to write educational software for your kids, you want them to be able to run it on their own computer. The reason why most people never even bother to learn Lisp is because they perceive it as being an elephant when they want a tiger. Having to pay $3000 to be able to build simple executable programs is part of that perception.
> > > I don't think we need a new standard for that. The DEFMETHOD > > > syntax: ``(parameter class)'' can be reused, so that the above > > > example becomes:
> > For this to be valid surely the standard would need to be modified?
> I'm not sure this was meant to be a question, but if so, the answer is, > I think, "no".
OK I didn't express myself clearly. I know that you can modify the default definition of defun, but I meant for the above to be valid in the absence of such modification.
* m...@spam.not | Being able to build an executable program which can run on different | computers that don't have Lisp is not just a commercial concern.
but if you want to run it on such computers, won't they _get_ a Lisp?
please remember that C executable are _not_ standalone unless you go to a very serious effort and bloat your executables tremendously. the whole idea with shared libraries is to capitalize on common parts of what was once in a number of executables, and it has made life seriously simpler for large libraries. the idea is no different than what was once done on mainframes, with massive amounts of good stuff in the operating system so each program wouldn't need it.
I regard the .fasl files as Lisp's "executables", and the fact that I might need to run them from inside a "real" Lisp executable that does what would otherwise be shared libraries is a meaningless quibble -- people seem to accept having to run multiple programs to start their applications already. if it really is such a big deal, making a .fasl file become an .exe file that did this on its own seems like such a no-brainer I really wonder why people think it's a show-stopper that others haven't done it for them. (yes, I assume this is under Windows -- Unix people are used to so much weird shit being "executable", in practice whatever the system call execve(2) is happy with.)
* Kent M Pitman <pit...@world.std.com> | At some point maybe they'll add the feature too, or maybe they'll lose | customers. That's the way the market works. The market is intentionally | and appropriately pluralistic. Saying that some implementation doesn't | suit your need is just saying you should be shopping; saying no | implementation suits your need is just saying there's a market | opportunity waiting for you.
this assumes that the issue in question is sufficiently important that the open market will be where the decisions are made. I'm wary of the call for the market to decide issues that are generally irrelevant -- it would mean I had to choose from a million different products and would spend more time figuring out which irrelevant feature was supported by which miniscule vendor's product than it would take to build it on my own -- sort of like how the Microsoft third-party market works for people who cannot or legitimate refuse to program the incredible insanity Microsoft calls products. to get to the point where the market can satisfy all sorts of small issues would mean such a huge demand for stupid things that _any_ small issue would get attention. I don't want a world like that. it's one of the many reasons I don't subscribe to the Microsoft world view and its model of competition between umpteen broken things that have to be so cheap to make because of the fierce competition they could not possibly be of any quality.
neither competition nor the market are any better than the customers and their decisions. I think the Jenny Jones case is relevant in this regard -- to pick randomly from the current news. there's a _huge_ market for talk shows that drag people's personal life into the public despite the many bad consequences and the many good reasons not to air such shows. the people who ensure that this market exists are ultimately the viewers who buy the products that are advertised during those shows, which means that the shows exist because of business decisions of the advertisers. there are similar remote relationships between most products and their markets, and most of the interrelationships between market and marketing are amazingly unpalatable and even downright ugly, and the more mass market you get, the uglier it gets.
I'm frankly not sure it's a good idea to call forth these forces without a very good grasp of the repercussions. I prefer to work with the people who have already done some significant amount of good work over going off and do my own thing (create a new market), or choose somebody else. only if my current vendor does something really stupid that I cannot live with will I feel like going elsewhere. this obviously holds only for products whose acquisition carries a meaningful investment with them -- like learning to use them or the relationship with the developers. should the acquisition be free of such investment, the cost of choosing something else will be low enough that the market will begin to work for small issues. otherwise, it will work only for issues larger than the cost of changing product. and do we really want a competition between products so similar that any small issue will be bigger than the cost of changing?
> > > I don't think we need a new standard for that. The DEFMETHOD > > > syntax: ``(parameter class)'' can be reused, so that the above > > > example becomes:
> Making the syntax be (foo integer) is bad, though. > There is an issue a lot of people don't talk about but that many of > us old-timers know which is that Meta-. (definition lookup in Emacs/Zmacs) > really wants the cadr position of definition forms to be "names". > Unless you're planning to make dispatch dependent on the return value > (which you can really only do in a strongly typed language and which > I'd argue is conceptually ill-defined even then), then (foo integer) > is not the name. A better syntax is > (defun foo ((list cons) (x integer) ... &return integer) ...)
I have always wondered why this is not an accepted solution (modulo syntax of course). I sort of understand that having simply VALUES as a 'declaration identifier' (3.3.3 ANSI CL) may cause some problems at the DECLAIM/PROCLAIM level (it wouldn't be clear what the declaration would apply to), but the idea seems correct. CMUCL has an implementation of this scheme.
> Btw, DEFSTRUCT violates the rule about the CADR being just a name > and causes lots of problems in text editors.
Well, also the
(defmethod zut :after ((....
wrecks havoc in cl-indent in Emacs.
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
> I believe I remember seeing someone use an infix syntax package (in > this group?) and it looked something like #I(2 + foo * pi ...).
Yes; the package INFIX written by Mark Kantrowitz supports the obvious infix notation, as well as a bunch of extensions. For instance:
> '#I( x^^2 + y^^2 )
(+ (EXPT X 2) (EXPT Y 2))
> '#I(if x<y<=z then f(x)=x^^2+y^^2 else f(x)=x^^2-y^^2)
(IF (AND (< X Y) (<= Y Z)) (SETF (F X) (+ (EXPT X 2) (EXPT Y 2))) (SETF (F X) (- (EXPT X 2) (EXPT Y 2))))
Unfortunately, the license for use is apparently non-commercial:
;;; Copyright (c) 1993 by Mark Kantrowitz. All rights reserved. ;;; ;;; Use and copying of this software and preparation of derivative works ;;; based upon this software are permitted, so long as the following ;;; conditions are met: ;;; o no fees or compensation are charged for use, copies, ;;; distribution or access to this software ;;; o this copyright notice is included intact. ;;; This software is made available AS IS, and no warranty is made about ;;; the software or its performance. [... warranty disclaimer ...]
mike...@mikemac.com (Mike McDonald) writes: > But there is precedance to the CADR being a list, namely DEFSTRUCT.
DEFSTRUCT is always an editing disaster IMO when it is a list, not because it's a list but because the list is not the name.
> (Didn't one of the New/Old Flavors also have the CADR to defmethod being a > list at times?
I haven't said anything about the problem being that it is a list. Indeed flavors did have (defmethod (frob foo) ...) and (defmethod (frob foo :after) ...) but that was *better* than what we have now becuase the name was the whole list. It's actually more confusing now where the name is spliced into the top level of the defmethod. But at least with the present defmethod, foo is also arguably a name.
> Seems like I remember it having somethingto do with specifying > before or after methods. Gnuemacs didn't like them either but a > simple hack to ctags fixed that.)
But at least it was a general-purpose hack to the notion of names that allows the cadr to be the name, even if it takes list syntax to jump over it and find the other end. (There is some problematic part if whitespace has multiple spaces or tabs, and they have to be canonicalized by editors that use textual representations, but that can also be dealt with.) My point is that the same single fix makes it work for (defun (setf foo) ...) where (setf foo) is in the cadr and is the name.
This is all just a personal opinion, mind you, not a law. But it's a personal opinion I know others hold as well and I have not seen written down anywhere in recent times, though we all talked about it long ago. It is not something you can't violate--it's just something I personally recommend you don't and I won't vote in favor of when it comes to that in committees.
(I'd like to see old-style DEFSTRUCT syntax flushed, but I won't vote to flush it without first deprecating it and providing a long transition period. But in the creation of new operators, where there is no compatibility issue involved, I'll push for things that make life simpler, not because it's impossible to do the other way but because it introduces needless and avoidable pain to do it the other way. As such, this particular piece of simplicity is one I think is important and worth pushing for where possible.)
Marco Antoniotti <marc...@copernico.parades.rm.cnr.it> writes: > Well, also the
> (defmethod zut :after ((....
> wrecks havoc in cl-indent in Emacs.
> Cheers
They seem to have gotten a fix for this in xemacs. I was *quite* pleased :-) (Though I wonder if it will deal with arbitrary method combinations correctly...)
Paul Rudin <pa...@shodan.demon.co.uk> writes: > OK I didn't express myself clearly. I know that you can modify the > default definition of defun, but I meant for the above to be valid in > the absence of such modification.
Maybe I didn't express myself well either. Just about nothing you can do in the language is valid in the absence of accomodation by other programs. You can't do (defun foo ...) without assuring you are in a namespace that doesn't have FOO already there. Saying that (defun foo ...) is valid always assumes you have done this check. Sometimes you "implement" this by saying (shadow 'foo) and sometimes by (in-package "SOMETHING-ELSE") and sometimes by (fmakunbound 'foo) but always you do something, even if the something is the null thing because nothing is required.
Even to bind a variable as in (let ((x 3)) ...) is invalid if the "..." needs to access an outer x. But we don't say you can't access both x's at once without a change to the language, we just write (let ((x 2)) (flet ((outer-x () x)) (let ((x 3)) (+ x (outer-x))))) and suddenly we are on our way again without a need to involve the language design committee.
You didn't merely say "for this to be valid you'd have to add a call to shadow" you made the following claim (quoting whole paragraph):
> For this to be valid surely the standard would need to be modified?
Had you not made your statement this strong, I would not have bothered to reply at all.
I just want to make it very clear that the language is a lot more accomodating than that, and as a rule, I doubt there's much of anything for which the above statement is true, in the sense that the language permits you to build whole new languages inside it (unlike many other languages). And I get frustrated when people push back on the language to solve problems they could solve themselves, especially when the "solution" is about 1-line long.
> I have always wondered why this is not an accepted solution (modulo > syntax of course). I sort of understand that having simply VALUES as a > 'declaration identifier' (3.3.3 ANSI CL) may cause some problems at > the DECLAIM/PROCLAIM level (it wouldn't be clear what the declaration > would apply to), but the idea seems correct. CMUCL has an > implementation of this scheme.
So does Genera. It's not valid CL, because you're not naming what you're declaring. VALUES is intended for use in FTYPE declarations and in THE expressions. But it was commonplace in Genera to see both this and ARGLIST declarations, which were both very handy for Control-Shift-A, the thing that tells you the args and values of a function.
> > Btw, DEFSTRUCT violates the rule about the CADR being just a name > > and causes lots of problems in text editors.
> Well, also the > (defmethod zut :after ((.... > wrecks havoc in cl-indent in Emacs.
I don't like this defmethod syntax, but I don't think it would be a problem for cl-indent if they implemented indent the way I implemented it in Teco. They ported a lot of my and others' Teco libraries to gnu-emacs when they brought it up, but they left behind a lot of features. The Teco-based indenter assumed anything starting with (def... ) should do body-indent on the first line after the (def...) that was not a continuation line of a subform that started on the first line. [There were ways to override this if you had definitions that didn't match the default, but this was not a problem. def expressions vary widely in the number of forms they have, and having a rule like "body starts at 2nd or 3rd form" is a bad one. The right DEFAULT rule is "definitions have junk on the first line and body on the rest of the lines". Incidentally, this rule even accomodates defstruct in its full-blown form.
I think I might have the code somewhere to the old teco-based indenter. Maybe sometime for grins I'll publish it. Teco was a wonder to behold.
m...@spam.not writes: > On Fri, 7 May 1999 23:01:39 GMT, Kent M Pitman > <pit...@world.std.com> wrote:
> >Maybe he only meant to say "many lisp environments produced for casual > >use are suitable only for casual use, and only those lisp environments > >that intend to be commercial quality address this commercial concern".
> Being able to build an executable program which can run > on different computers that don't have Lisp is not just a > commercial concern. Even if you just want to write > educational software for your kids, you want them to be > able to run it on their own computer. The reason why most > people never even bother to learn Lisp is because they > perceive it as being an elephant when they want a tiger. > Having to pay $3000 to be able to build simple executable > programs is part of that perception.
This supposes that you have to pay $3000 to build a simple executable. You do not. This is WILDLY far off the mark and grossly misleading to suggest as a straw man. I can think of almost no commercial implementations full of goodies that cost this much. Most high-quality commercial implementations have at least one offering in the $500-600 range, and those implementations usually have an accompanying free version [in which you cannot dump images not because it wouldn't be fun but becuase they NEED the revenue to be able to continue supplying cheapskates (not saying that's you, but I believe they're out there) with free implementations becuase they never want to ever pay a dime in support of whowever brought them happiness/success]. Vendors have to feed themselves. But there are numerous smaller/freer lisps out there, probably most of which have the capability you ask for and don't cost a dime. If you really think that it costs $3000 to build a simple executable, I suggest the possibility that you have not done your homework before speaking. And if you don't think it does, I SUGGEST YOU CONSIDER THE POSSIBILITY THAT EXTREME STATEMENTS LIKE THE ONE YOU MADE ABOVE ARE AS MUCH OR MORE THE CAUSE OF A PERPETUATED BELIEF THAT LISP IS TOO EXPENSIVE FOR PERSONAL USE THAN THE ACTUAL FACT OF THE MATTER.
It does cost more to make a commercial redistributable app, and I think there are some real issues there. But you have specifically said that is not your issue. And I just don't think that in the space of "for personal use" Lisps, your criticism is even remotely fair.
People can, with their kids, teach them to click on the "lisp" icon and then teach them to type (load "..."). That's all that's needed. If that is not a fair exchange for a free implementation, I have to say your public awaits your contribution of something better. If kids don't have the attention span required to do a two-step loadup instead of a one-step loadup, they are not candidates to ever be lisp programmers. I daresay the path to being a serious programmer involves more than just a few such steps, and anyone not willing to take them might as well start lining up right now for a job in another industry with fewer steps leading to it rather than diving in on the mistaken assumption that everything will be handed to them on a silver platter for free with no burden that they do even the slightest thing. Geez, even getting my linux to run at my house (and it wasn't wholly free-there was a substantial media cost) took me a billion (ok, only probably a hundred) recompiles of the kernel (which I should remember to go delete sometime :-). Was THAT a barrier to linux success? I just don't think so.
Erik Naggum <e...@naggum.no> writes: > * m...@spam.not > | Being able to build an executable program which can run on different > | computers that don't have Lisp is not just a commercial concern.
> but if you want to run it on such computers, won't they _get_ a Lisp? > ... > I regard the .fasl files as Lisp's "executables",
Excellent points.
Certainly within the freeware arena, they are no less painful to start than x windows is to get running on linux. Some people might think starting a program from a shell instead of clicking with a mouse means it's not a "real" program, but by that argument, linux out of the box is such a system. I still have to type startx manually because I haven't found the place to edit in the thing that says xdm should run by default at startup. [hints by private e-mail are welcome].
> this assumes that the issue in question is sufficiently important that > the open market will be where the decisions are made.
Yes, I agree this is an issue. I don't think the market will decide small things well--only coarse-grain things. But many of these discussions are over "What's Really Important" and I do think the market's failure to spawn new variant products over certain issues is a quasi-proof that those were not the key things people saw as important.
