In article <7mksar$hp...@nnrp1.deja.com>, Bernd Paysan <bernd.pay...@gmx.de> wrote:
[snipped]
> I hear this in the Forth community (which is also "dying" with > increasing traffic for 10 years now ;-), too, but IMHO, that's bull.
[snipped]
I'm a bit sad to see one of the most creative clf contributor under the light of the most narrowly minded guy:
> People don't want to think. They don't want to choose one of 23 > user-level implementations of OOP, or even decide to write their own > one. They want to have a single standard OOP. Everybody will request > that his feature need of the day is included in the single standard. And > finally, they'll realize that they need to start over again, because > this particular language converted to an unmaintainible mess. But > they'll never come to the point to allow the user to add his feature of > the day. That would be chaos. And that would be just like the dying > languages, Lisp, etc. ...
If what you are alluding to is that "people" (whoever they are, since no qualification is given) don't want to think about how implementing the division each time they want to compute some ratio, then I guess they are right. If those same people don't want to think about how to implement an array each time they want...err! an array! I still do think they are right. Not even speaking about anything more clever having passed the darwinian selection: records, lists, nodes...
Maybe "People" want to think with _abstractions_ something that Forth can deliver, but that Forthers have consistently failed to deliver over the past 25 years. It doesn't matter whether we have the choice of 23 OOP system, if none of them is either good or documented enough to attract the interest of a wide audience, which, in turn, would promote more attention.
This attitude, "The Users Are Just Stupid Idiots" is so well encroached these days, that I'm wondering if you're not more a Linux geek (Damn the user!) than a Forther (Damn the abstraction!).
Too bad to see talents blinded by selfish, elitist considerations.
On 15 Jul 1999 17:45:43 GMT, mike...@mikemac.com (Mike McDonald) wrote:
>> "Loser" is an old technical term which means roughly "one who is >> unskilled and not bright enough to know it". It is not the same >> pejorative that people throw around today - its a different one :)
> But I thought that version was spelled "luser".
You could be right - I've heard it said a number of times (fortunately not [directly] to me) but the only place I've actually seen it written is in Levy's book "Hackers". He spelled it conventionally.
George Neuner Dynamic Resolutions, Inc. =================================================== The opinions expressed herein are my own and do not reflect the opinions or policies of my employer. ===================================================
> > In article <378e0a9b.157564265@asgard>, > > gneu...@dyn.com (George Neuner) writes: > > > On Thu, 15 Jul 1999 10:02:20 GMT, Andrew Cooke > > > <and...@andrewcooke.free-online.co.uk> wrote:
> > >>I've read all the responses so far, and I'm pretty convinced that Lisp > > >>isn't that poorly (thank-you!). On the other hand, a couple of posts > > >>seem to reflect a certain ghetto mentality, especially this last one:
> > >> Lisp is not the kind of language that insecure losers would use. > > >> people do not want to learn Lisp because they stand a better chance
> > > "Loser" is an old technical term which means roughly "one who is > > > unskilled and not bright enough to know it". It is not the same > > > pejorative that people throw around today - its a different one :)
> > But I thought that version was spelled "luser".
> Doesn't that refer to the user losing in some system call failures?
"luser" AFAIK comes from sysadmin culture e.g, "My lusers are always complaining that disk quotas are too small and that I should install Emacs so that the machine will be slow for everyone else."
In article <87hfn5pvnm.fsf...@2xtreme.net>, cba...@2xtreme.net (Christopher R. Barry) wrote:
> Its funny that an old Lisp Machine is the cheapest way to get your > hands on CLIM.
Additonally: Symbolics Genera 8.3 and Open Genera 2.0 come with CLIM sources. Digitool sells a source+site license for CLIM.
> exposure and knowledge of CLIM. The rare CLIM questions here go > unanswered, or people get referred to this voluminous tome known as > _The CLIM User's Guide_.
There is the CLIM specification and Symbolics has its CLIM documentation.
> If you read some of the posts that touched on CLIM over the past few > days (from Nick Levine and others), it would seem that CLIM is not > profitable for any vendor (gee I wonder why...) and that they would > rather just not maintain it and let it die.
I still have the feeling some have sabotaged it.
AFAIK Harlequin had a CLIM-based development environment - it never surfaced.
Ask one of the frequent posters (from the US ;-) ) - I heard that he has written an Emacs-like editor in CLIM ...
>> EMACS is making the transition to Scheme, I believe, because of a simpler >> (read: easier to maintain) implementation.
>You have obviously never taken a look at eval.c in Guile. I'm not >sure you could argue that it simplifies anything.
I may just be muddying the waters, but I read Csaba's comment as meaning that it's easier to implement Emacs in Scheme than in Lisp, and Craig's as that it's no easier to implement Scheme than Lisp. These seem to be at cross-purposes.
jos...@lavielle.com (Rainer Joswig) writes: > Additonally: Symbolics Genera 8.3 and Open Genera 2.0 come with CLIM sources. > Digitool sells a source+site license for CLIM.
> > exposure and knowledge of CLIM. The rare CLIM questions here go > > unanswered, or people get referred to this voluminous tome known as > > _The CLIM User's Guide_.
> There is the CLIM specification and Symbolics has its > CLIM documentation.
The CLIM specification is less usable as a reference than the CLIM User's Guide. Neither have any tutorial value other than in the HyperSpec sense. The Symbolics CLIM documention is essentially an older, slightly different (from the Harlequin one) copy of the CLIM User's Guide, combined with a very brief tutorial on defining application frames and using presentations. It gives you just enough information so that you can get started and know how to create the support code to try out a function from the User's Guide.
I've seen these before from altavista searches. They either describe CLIM and some of its concepts, or give a little demo/example code but its not that great.
That one is 99.9% German. Remember, not all of us can speak it. :-) There wasn't any source code in it either and it's probably not that great anyways.
These are just some source and technical papers of a lot of the CLIM stuff the BBN is now (I hear) converting to Java. Nothing tutorial or very useful/usable about it.
That looks like the same ancient CLIM demo stuff you can get from the CMU AI Repository.
> > nor is there likely any market for a CLIM book.
> There is.
What makes you think there is? I'd like to believe that that is true, but can find anything to convince myself.
> > If you read some of the posts that touched on CLIM over the past few > > days (from Nick Levine and others), it would seem that CLIM is not > > profitable for any vendor (gee I wonder why...) and that they would > > rather just not maintain it and let it die.
> I still have the feeling some have sabotaged it.
> AFAIK Harlequin had a CLIM-based development environment - > it never surfaced.
> Ask one of the frequent posters (from the US ;-) ) - I heard > that he has written an Emacs-like editor in CLIM ...
Zmacs? :-) After having used a Symbolics so much, I wonder why none of the vendors have ever made a CLIM-based listener and editor so that you can do some of the same cool stuff. The Symbolics Dynamic Windows (same CLIM presentations functionality for those that don't know) UI is pushing two decades of age now. Time for a vendor to offer us one with 1/10th the functionality and coolness and 1/2 the efficiency.
In article <87yagho7xw....@2xtreme.net>, cba...@2xtreme.net (Christopher R. Barry) writes:
> jos...@lavielle.com (Rainer Joswig) writes: >> > If you read some of the posts that touched on CLIM over the past few >> > days (from Nick Levine and others), it would seem that CLIM is not >> > profitable for any vendor (gee I wonder why...) and that they would >> > rather just not maintain it and let it die.
>> I still have the feeling some have sabotaged it.
I thought I was the most cynical about CLIM around here but I wouldn't go quite that far. At least, not deliberately sabotaged. Mostly I think the vendors just didn't know what to do with it. The joint ownership of it may also be complicating things. Just figuring out who owns the thing probably would keep some lawyers busy for quite a while. (I don't know what the contractual agreement was between the original CLIM partners. I'm only speculating that it'd keep any one of them from just releasing the sources. [I do believe that there are other arraingements that could be pursued other releasing the source to everyone if thecontract is this way.] It'd probably require all six of them to agree to it. Finding everyone is probably a major task.)
>> AFAIK Harlequin had a CLIM-based development environment - >> it never surfaced.
>> Ask one of the frequent posters (from the US ;-) ) - I heard >> that he has written an Emacs-like editor in CLIM ...
> Zmacs? :-) After having used a Symbolics so much, I wonder why none of > the vendors have ever made a CLIM-based listener and editor so that > you can do some of the same cool stuff.
CLIM is a complicated system that's expensive to support. The vendors want to see sufficient customer demand before they invest their limited resources in pursuing it. Since it is a complicated system and the potential customers don't know enough about it except the cost, they're not eager to commit their limited resources and demand it. As a result, we have a sort of stand off. Each side is waiting for the other side to blink. It'll take something drastic to break the jam, either a customer with a lot of money and guts or a vendor willing to take a risk. At the moment, I don't have much faith that either will appear.
mike...@mikemac.com (Mike McDonald) writes: > CLIM is a complicated system that's expensive to support. The vendors want > to see sufficient customer demand before they invest their limited resources > in pursuing it. Since it is a complicated system and the potential customers > don't know enough about it except the cost, they're not eager to commit their > limited resources and demand it. As a result, we have a sort of stand off. > Each side is waiting for the other side to blink. It'll take something drastic > to break the jam, either a customer with a lot of money and guts or a vendor > willing to take a risk. At the moment, I don't have much faith that either > will appear.
(Sorry about the rambling note. Its getting late, and the disorganized message merely reflects the swirling confusion in my mind.)
I've had some experience with CLIM, and am one of the poor souls that tried posting to get some answers. The symbolics CLIM 1.0 book that I managed to find is by far the best documentation I have been able to get my hands on. And it certainly is not from lack of searching.
Consider a programmer (even a Lisp programmer) that has never played with CLIM, and has to write an interface. As good as this programmer might be at Lisp, I believe that she/he would have a very difficult time learning CLIM, simply because its approach to building a GUI is very different from current practice.
The one thing that I haven't yet found is a good, clear and concise description of what you can do with CLIM that would be hard with another GUI environment. (I had seen one article, I don't remember where, that attempted this, but knowing what I do now I felt it only touched on a small subset of CLIM's facilities.) Even if you know what CLIM can do for you, it doesn't help if you don't know how to do it. And we get back to tutorials and documentation.
The first couple of times I tried creating a GUI in CLIM, the results were, well, just short of disasterous. I simply didn't understand how the thing worked. In most present day GUI's, you place widgets on screen, and attach code to those widgets. That makes getting a basic GUI together (which is what I wanted) rather straightforward. You can even throw together a GUI builder relatively easily. (Witness Allegro CL and MCL.) Of course, extending it to handle complex interactions of the type presentations enable takes an incredible amount of work.
I once tried to explain to an HCI graduate student CLIM can potentially do, but I had a really hard time convincing her of its utility. Partly because I didn't know enough to do a good job of it. For what I did get across, I got the response, "That paradigm in interface design was abandoned ages ago." Given current practice, CLIM is hard, CLIM is mysterious, and without decent tutorials that clearly get across its strengths, CLIM is worse than GUI's available on non-Lisp environments. I'd like to say I don't agree with this position, but without decent documentation that clearly demonstrates the power of CLIM (as opposed to toy examples and code without any documentation), I find myself in partial agreement. I once tried to create a draggable object on screen in CLIM. Not pleasant.
The second problem, cost, I find equally troubling. If I were not a student, I would not dream of trying to acquire and experiment with a copy of CLIM. And to reiterate what others have said, high price would be a reason to not get my hands dirty. I have a dozen other GUI's out there that I can experiment with for free, and one of them is bound to at least partially meet my needs. What might possibly lead me to believe that CLIM is fantastically better than anything I have tried? Especially in the absence of documentation? I see no reason whatsoever that anyone might consider using CLIM for building an interface.
Soon I shall no longer be a student. I suspect I shall not be fooling around with CLIM that much longer. Most present-day (deliverable) programs are complex enough that a command line interface is insufficient. Lisp potentially has a great GUI environment in CLIM, only it is next to impossible for the average user (programmer) to play with. And for many, this may be reason enough to drop lisp and look at an environment that's more accessible.
In my undergrad school, the professor with whom I was working was *relieved* to be able to abandon CLIM 1.x. He moved to Allegro CL when Lucid went under, and loved the GUI builder. It wasn't more powerful, merely less buggy and obtuse. I can't compare CLIM 1.x and 2.x, but 2.x appears to be usable. But still obtuse.
A closing remark: I want to be able to use a GUI with my lisp programs. I have to work with enough data and such that having a GUI would greatly ease my life. I would also like to be able to interface with non-lisp elements easily and reliably. I have tried running a quicktime movie on an SGI in lispworks, and it is hell. I don't really *care* if I don't have the perfect GUI where I can interact with the underlying objects directly. I'd trade a little simplicity and transparency for that power. (I invite you to read Don Norman's book, "The design of everyday things" I believe is the name, to understand why I believe this is important.) Lisp arguably tends to be on the opaque side, but at least you can get a sense for what the language is about if you have had a good education in CS and are willing to read a book or two. Unfortunately, there is no theory of interfaces that one can learn to understand CLIM. I believe this is a problem that needs fixing, by either making CLIM more available or accessible, or putting some effort into a GUI that is easier to implement, debug and use.
> The first couple of times I tried creating a GUI in CLIM, the results were, > well, just short of disasterous. I simply didn't understand how the thing > worked. In most present day GUI's, you place widgets on screen, and attach > code to those widgets. That makes getting a basic GUI together (which is > what I wanted) rather straightforward. You can even throw together a GUI > builder relatively easily. (Witness Allegro CL and MCL.) Of course, > extending it to handle complex interactions of the type presentations > enable takes an incredible amount of work.
Hmm, I liked the menu user interface what we did in one research project implementing Common-lisp to C Compiler in AIX 6000 and Sunos. Basically the definition of menu looked like
It was quite fun to write user interfaces and test them quickly. heh heh, the compiler beat the s**t out from other CL implementations on that time in gabriel benchmarks. Unfortunately one has to life and cannot affort to spend time going through the code and make the thing to compiler java byte code...
Unfortunately most of the people around doesn't understand, that the CL could be used in very difficult project. Or should we be better to say, that the marketing doesn't like the sound when engineer says "It only interrepts for 1-2 milliseconds to collect GARGABE".. "GARBAGE", how in earth we can sell this thing to customers ???
Currently I have spent a year as a member of team designing and implementing snmp management system with C++,CORBA ,and yack RPC. There are VERYYYYY many configuration files, which basically define how the system behaves in the fly, how traps are converted to alarm notifications, how things are collected, where there are stored etc...
It would have taken maybe 3-6 months to write the whole thing in CL alone. We have spent much more.. PKY
Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.
Samuel A. Falvo II <kc5...@dolphin.openprojects.net> wrote: +--------------- | Also, the GIMP uses Scheme as its native scripting language. +---------------
Yeah, but didn't they use "SIOD" as their Scheme? *Old* syntax, no where near R[45]RS...
-Rob
p.s. Don't get me wrong, SIOD is nice & small, and *fast*-starting. But picking it for the scripting base of a new tool and then saying "uses Scheme" makes about as much sense as picking (say) Lisp 1.6 and then saying "Hey, what are you CL guys complaining about, we used Lisp"...
----- Rob Warnock, 8L-855 r...@sgi.com Applied Networking http://reality.sgi.com/rpw3/ Silicon Graphics, Inc. Phone: 650-933-1673 1600 Amphitheatre Pkwy. FAX: 650-933-0511 Mountain View, CA 94043 PP-ASEL-IA
> Sunil Mishra <smis...@whizzy.cc.gatech.edu> writes: > > > mike...@mikemac.com (Mike McDonald) writes: > > > > > In article <378e0a9b.157564265@asgard>, > > > gneu...@dyn.com (George Neuner) writes: [...] > > > > "Loser" is an old technical term which means roughly "one who is > > > > unskilled and not bright enough to know it". It is not the same > > > > pejorative that people throw around today - its a different one :) > > > > > > But I thought that version was spelled "luser". > > > > Doesn't that refer to the user losing in some system call failures? > > "luser" AFAIK comes from sysadmin culture e.g, "My lusers are always > complaining that disk quotas are too small and that I should install > Emacs so that the machine will be slow for everyone else."
There is of course an explanation of <luser> in the New Hacker's Dictionary. I don't have an electronic copy handy; the essence:
A <user>; esp. one who is also a <loser>. [MIT, ca. 1975]
(See entry for full story, and also entries for <loser> and <user>.)
The word "luser" is not from "the sysadmin culture", or anything else having to do with UNIX, or with systems that required "admins".
It comes from the hackers at the MIT AI lab about two decades ago. It comes from the verb "to lose", which means to not succeed, or to be a bad idea, or perhaps to be slightly clueless, depending on the context.
In particular, the spelling "luser" was a pun on "user", referring to someone who uses the computer, but who is not what might today be called a "system wizard" (a kernel developer). It was not particularly derisive, at least not in a serious way.
The spelling is from the source code of ITS, the PDP-10 (originally PDP-6) operating system written there. ITS stands for "Incompatible Timesharing System", and that name is also a joke (referring to the contrast with the CTSS project.)
There was also an ITS system call "LOSE" (or the UUO version ".LOSE") that terminated a program with an optional error code. On the PDP-10, test instructions and system-calls PC-skipped on success, so typically after a system call (such as "OPEN" a file) would be a call to "LOSE".
LUSER was also the name of an ITS application program. Typing the command "LUSER" would send an interactive message ("Help me -- I'm a luser!") to a special list of logged-in helpers; it summoned a hacker to help you. Most people who used this command wondered what an "el-user" was.
Suggesting that this (or any of the other cutsey "hacker" words and phrases) had anything to do with UNIX, at the time, bring to mind another word that we used to use a lot. Actually, some years later we often used the word in sentences that also contained the word "UNIX". That word is "barf".
The word "luser" is not from "the sysadmin culture", or anything else having to do with UNIX, or with systems that required "admins".
It comes from the hackers at the MIT AI lab about two decades ago. It comes from the verb "to lose", which means to not succeed, or to be a bad idea, or perhaps to be slightly clueless, depending on the context.
In particular, the spelling "luser" was a pun on "user", referring to someone who uses the computer, but who is not what might today be called a "system wizard" (a kernel developer). It was not particularly derisive, at least not in a serious way.
The spelling is from the source code of ITS, the PDP-10 (originally PDP-6) operating system written there. ITS stands for "Incompatible Timesharing System", and that name is also a joke (referring to the contrast with the CTSS project.)
There was also an ITS system call "LOSE" (or the UUO version ".LOSE") that terminated a program with an optional error code. On the PDP-10, test instructions and system-calls PC-skipped on success, so typically after a system call (such as "OPEN" a file) would be a call to "LOSE".
LUSER was also the name of an ITS application program. Typing the command "LUSER" would send an interactive message ("Help me -- I'm a luser!") to a special list of logged-in helpers; it summoned a hacker to help you. Most people who used this command wondered what an "el-user" was.
Suggesting that this (or any of the other cutsey "hacker" words and phrases) had anything to do with UNIX, at the time, bring to mind another word that we used to use a lot. Actually, some years later we often used the word in sentences that also contained the word "UNIX". That word is "barf".
On Thu, 15 Jul 1999 23:08:07 +0200, jos...@lavielle.com (Rainer Joswig) wrote: > AFAIK Harlequin had a CLIM-based development environment - > it never surfaced.
Yonks ago Fry prototyped some browser/inspector ideas for a Dylan environment in CLIM but these ideas weren't an entire environment and never made it into production. I think Scott also wrote a CLIM-based listener to use himself and share with a couple of other like-minded souls (mostly at 1CC). AFAIK we never had a whole Lisp environment in CLIM, but perhaps some other tools existed as well. Most of the CLIM-addicts resided at 1cc, but conversely that place also had its fair share of EMACS-junkies.
BTW The current Dylan Interactor (aka Listener) has a presentation-style interface. E.g. You can right click on the results and recursively inspect them in the listener with successive results being active in the same way.
In article <378B405C.C89AD...@ne.mediaone.net>, Michael Coughlin <m-cough...@ne.mediaone.net> writes:
> Counting versions is not the way to tell the health > of > a computer language. Count the number of textbooks on the > shelves > of bookstores intead. I conclude that Lisp and Scheme are still > alive with about half to one third as many books as Fortran, > while Fortran has about one tenth as many books as the big guys > like C, Java, Visual Basic and C++. Forth comes out at zero.
Your result may be biased by your selection of bookstores. They'll probably have to close MIT before LISP and Scheme books will vanish from the Cambridge (MA) bookstores.
I was just at two bookstores near TU Wien. I did not see LISP, Scheme, or Forth books. Interestingly, I did not even see a Prolog book, although we have an obligatory Prolog course in our curriculum; apparently the course notes are good enough. I saw books for some not so popular languages: Ada, Haskell, Icon, Miranda, ML, Modula-2, Oberon.
Concerning the metric you use to evaluate the health of a language: I think we have now enough experience to conclude that it is wrong. You whined about the lack of Forth books five years ago, but I see no indication that Forth is any worse off than then, on the contrary, other indicators are usually positive: clf traffic has grown, there are fewer "Forth is dying" postings, implementations for new platforms (e.g., PalmPilot, Lego Mindstorms) are demanded and supplied quickly, participation at EuroForth is stable...
> When I meet people who tell me they want to learn all > about computing, including programming, I want to say learn > Forth. But I know that woun't work since they can't even go > to the bookstore and buy a book about it.
And later you claim that Amazon.com is not a book store for this purpose. Why? Sure, they cannot browse, but they have your recommendation, and in the case of the Forth Programmer's Handbook AFAIK they can even download an evaluation copy.
Moreover, there are several on-line Forth courses, so why would they need to buy a book in a bookstore to learn Forth?
Using my metric of postings in comp.lang groups, here are the postings present on news.tuwien.ac.at on July 11, 1997 and July 16, 1999. You will notice that a lot of newsgroups have vanished, that's because this newsserver has dropped groups that nobody here reads:
In article <87yagho7xw....@2xtreme.net>, Christopher R. Barry <cba...@2xtreme.net> wrote:
>Zmacs? :-) After having used a Symbolics so much, I wonder why none of >the vendors have ever made a CLIM-based listener and editor so that >you can do some of the same cool stuff. The Symbolics Dynamic Windows >(same CLIM presentations functionality for those that don't know) UI >is pushing two decades of age now. Time for a vendor to offer us one >with 1/10th the functionality and coolness and 1/2 the efficiency.
A couple of nits to pick:
- As I (vaguely) recall, DW was introduced with Genera 7.0, in about 1986 (or maybe late '85). That makes it a teenager, but not 20 years old.
- I think you mean "Time for a vendor [...] with *twice* the efficiency." Or are you being sarcastic?
- Some of you might recall that the initial release of DW was so inefficient that it brought the mightiest Lisp machines of the time to their knees. It wasn't until the next point release that DW was made remotely efficient, but by that time few people cared, because its previous (lack of) performance had left such a bad impression on many users that they turned it off out of habit. In later releases DW became very speedy, and extremely useful.
Ah, for the good old days... -- Chuck, ex-Symboolean -- Chuck Fry -- Jack of all trades, master of none chu...@chucko.com (text only please) chuck...@home.com (MIME enabled) Lisp bigot, mountain biker, car nut, sometime guitarist and photographer The addresses above are real. All spammers will be reported to their ISPs.
& According to these numbers, both clf and cll traffic has grown a lot & in these two years, so I doubt that these languages are dying.
The true question is, is the growth rate of comp.lang.forth greater than or less than the growth rate of Usenet traffic in general? I wouldn't say that more articles in, for example, talk.bizarre means that the world is necessarily getting more bizarre. I'd say rather that more bizarre people are posting more. What's the average increase in posts in *lang* groups, and where does comp.lang.forth stand on the curve?
-- U. Z. Puckett replace "sendnospam" with "puckett"
For what it's worth I ordered The Forth Programmer's Handbook directly from Forth. Inc (www.forth.inc) on Wednesday and it's been sitting on my desk since this morning. (Friday). So it's available and it looks pretty good so far.
Barry
Michael Coughlin <m-cough...@ne.mediaone.net> wrote in message
> > Michael Coughlin wrote in message <378B405C.C89AD...@ne.mediaone.net>... > > >... Counting versions is not the way to tell the health > > >of a computer language. Count the number of textbooks on > > >the shelves of bookstores intead. I conclude that Lisp > > >and Scheme are still alive with about half to one third > > >as many books as Fortran, while Fortran has about one tenth > > >as many books as the big guys like C, Java, Visual Basic > > >and C++. Forth comes out at zero.
> > > When I meet people who tell me they want to learn all > > >about computing, including programming, I want to say learn > > >Forth. But I know that woun't work since they can't even go > > >to the bookstore and buy a book about it. Well at least they > > >can still get some nice books about Logo to get then > > >started.
> > Is Amazon a bookstore? Several Forth books there.
> Amazon is not a bookstore. You can't drop in and > browse. If you don't know what Forth is, or think that Forth > isn't used anymore, you woun't notice a book about it by > accident when you're looking for some other topic on > programming. You can't just buy a book because you have it > in your hot little hand and it looks interesting. You can't > wrap it up and take it right home. People who don't even have an > account to access amazon.com and the web are the easiest to > influence to at least take a look at Forth. They have not > learned the bad habits of other programming languages and can > immediately appreciate the advantages of Forth.
> I just looked for Forth books on amazon.com. Yes there > are several listings. There is only one listed as being in > print, and they say expect delivery within 4 to 6 weeks. There > are also listings for books by Leo Brodie. When I clicked on > "Thinking Forth" I got nothing but a system error. There are > five separate listings for Leo Brodie's book -- "Starting > Forth". That's reasonable since it is at least five times better > than the average book on programming. But its out of print. Its > available only by a special search. It will take them weeks to > find it or tell you if its not available. They don't tell you to > get it faster from the Forth Interest Group in California, > http://www.fig.org/ (at least until their special printing runs > out). Relying on amazon.com to sell Forth textbooks is not a > good thing. It would be better to have a publisher promoting the > book and getting it into bookstores.
> Elizabeth Rather is much too shy and modest. She failed to > mention her own book the "Forth Programmers' Handbook". So I'll > tell everyone that it is the one Forth textbook that is in print > and for sale at amazon.com. When I go to my local technical > bookstores to see if it has finally arrived on the shelves (it > hasn't), I find instead books on the equally neglected computer > languages Lisp, Scheme and Logo. I think that Lisp and its > relatives are much more lively than Forth since they still have > recently revised textbooks for sale. Since Forth is still being > used, I can deduce that Lisp is still being used, even tho I > don't know where. But how long will Forth last without at least > a few easily found textbooks? > I wish old Forth programmers would become inspired by Lisp > programmers to write textbooks so they would be able to train > their replacements.
> -- > Michael Coughlin m-cough...@ne.mediaone.com Cambridge, MA USA
In article <378e085d.156990400@asgard>, gneu...@dyn.com (George Neuner) writes:
> On Wed, 14 Jul 1999 17:35:09 GMT, Kent M Pitman <pit...@world.std.com> > wrote:
>> ... people should not lament the passing of things they are not >>willing to invest in. This newsgroup has a number of people >>who my sense is both want a lot of free things and want to debug why >>Lisp is in the trouble it's in.
> Agreed.
The problem is that the cost to investigate whether its worth investing in is somewhat steep.
--
Hartmann Schaffer
It is better to fill your days with life than your life with days
> Is "Getting" a perl interface? What's taking them so long? The Python > interface has already been out for quite some time. ;)
They seem to have problems getting the Gtk.pm package compiled and installed properly (although I must say that the last version I tried worked fine - so at least for me, the unstable version of Gtk has a Perl interface).
Jean-Francois Brouillet wrote: > This attitude, "The Users Are Just Stupid Idiots" is so well encroached > these days, that I'm wondering if you're not more a Linux geek (Damn > the user!) than a Forther (Damn the abstraction!).
> Too bad to see talents blinded by selfish, elitist considerations.
This is really getting political. I think the elitism of my generation is a counter-reaction to the egalitarism of the '68 generation. It was a nice idea, but it didn't work. Men are not equal - they are not even created equal (different genes, different upbringing, different teaching, etc.). There are brights and stupids. Talents are rare, and worse, they all limit themselves to one or a few areas. You can't talk to all people using the same language.
There is nothing wrong with the users being "stupid idiots" (compared to the gurus). They may have other talents, and then, we know that they need just a lot of hand-holding. There aren't just as many natural born kernel hackers out. It just works better if your model of the world reflects reality instead of an ideal state.
In fact, the Linuxer's attitude stems from assuming that the users aren't just stupid idiots. That's why Linux is "difficult" to install and has that load of "cryptic" commands, and all the man pages are so hard to read.
I'm not doing MINOS because I need a self-explaining, dumped down GUI to program. I'm doing it because I know that other people need that. You can only reach the masses if you have some of Dogbert's cynicm.
* Pierre R. Mai | So I think there are a number of Lisp jobs out there. OTOH you probably | have to be more flexible to take advantage of them (i.e. relocating, | changing areas of interest, etc.), than for many other languages that are | a tad more popular.
in my experience, which is somewhat limited, but that may actually serve the point, certain areas of interest are best catered to by adding lots of manpower to their solution, areas which will be "popular" in the most obvious sense of the word, while other areas of interest will not attract people in great spades regardless of the monetary rewards, such as those that ask for significant dedication because of such things as very high risks, skill requirements, entry costs, etc. if you choose one of those areas of interest, no manager in his right mind places silly demands on your programming language of choice and he will probably fire you if you choose "popular" languages subject to vendors who care only about the mass market and not about quality, unless his real plan is to fire you, anyway, only to replace you by someone equally uncritical of his tools. e.g., write some software to analyze the quality of the Y2K code that really _stupid_ managers have invested in some 20 years too late and now have lost control over to the point where the solution (fixing broken code with new, largely untested code written by the kind of people who think there's nothing wrong with ripping really stupid people off) opens up for even more costly problems than the problem. if you can manage to write software that can identify vulnerabilities in newly added code by the turn of the century, such that people can use your tool to prepare counter-attacks or invest in security measures or schedule time in the court system when they know whom to sue for what and how much, you could stand to make more money in the remaining 167 days than you could in the whole of the next millennium.
solution: find areas of interest not invaded by populistic opportunists. my suggestion is to avoid _any_ area where the solution space is covered by existing code. on the other hand, generalizations where people make do with "menial" systems because of too varying requirements may be a good place to introduce intelligent programming languages. e.g., while accounting and finance are pretty well known areas, you could figure out a way to plan for budget reallocation according as political conditions change (such as taxes) -- frightening amounts of human intelligence are wasted on beating the idiots who change the rules all the time. such a tool might also help the idiots in power "visualize" the likely effects of their many proposals, which _might_ help us get less political idiocy beta-tested using people's lives.
is it still "artificial intelligence" when the task is to model human stupidity, or would only preventing its devastating consequences get an "AI" rating?
#:Erik -- @1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
* Johan Kullstam <kulls...@ne.mediaone.net> | I've tried CMUCL, clisp and ACL5. I find that they are all awkward at | producing a "hello world" application.
of course they are. however, have you ever seen how much work it takes to boot a modern Unix machine and run a C program just to have it print "hello world" in an xterm running under MOTIF? man, it sucks. and it's even more work if it tries to run NT. the machine should be doing a very limited amount of work for this very simple task, but instead it spends minutes booting and preparing itself to be useful, not to mention all the crap necessary to get a program in C able to produce that output. yea, verily, it sucks.
unfair comparison? not at all. why do you think they chose that phrase? because they were developing Unix and the C compiler. it's appropriate to make a machine print "hello world" to verify that everything works after all the mind-boggling nonsense has interfered with the real purpose of a computer, and you never know which part of booting up will fail due to a minor bug. the delight in a C programmer's eyes when his machine thus booted typed "hello world" back at him would probably parallel that of a Common Lisp programmer when the satellite communications subsystem he designed beams back "hello world" after an almost-aborted launch, a navigation jet which misfired, and the solar panels sustained some damage by space debris. normally, it's unnecessary to have confirmations of basic operations, but it makes perfect sense under C.
there are other simple tasks that require a tremendous infrastructure to make a trivial task come back with a positive result. e.g., you need DNS to be set up right, routers and firewalls must to do their job, the local network and telecommunications links must let stuff through, etc, before you can type "ping elvis" and have the system type "elvis is alive" back at you. this is actually so delighting that there is a disproportionate number of machines called "elvis" for this particular reason. (I think it would be much more fun to have machines called "thelma" and "louise".)
who, these days, would pick up a telephone and consider "hello" to be a landmark event in human history? while there's nothing wrong with a strong sense of fascination with "all that which just _works_ around us", getting excited about "hello world" programs appears to me to be a sure sign of insanity, or at least a fairly constant case of missing the boat.
| it's just that unix and windows are set up to support C and C++. e.g., C | has a largish libc these days.
these two statements are pretty much contradictory. the problem is that neither Unix nor Windows _actually_ support either C or C++, but they manage to make them work, with downright incredible effort. if you look inside the libraries and see how a system call actually works and how much it differs from the C calling convention and usage, you'd be a fool not to revise your opinion. and _does_ an operating system that forces the programmer to check to see whether the operating system did what it was asked to do every damn time you ask it to do anything actually give any relevant form of support to anyone?
in my view, Unix and Windows support Common Lisp better than they support C because C is designed for a 70's style machine and operating system, which modern machines and operating systems have to mimic with all their flaws and misdesigns, while Common Lisp is a modern language that is well suited to be hosted on modern systems, and it just happens to be, too.
the irony here is that Common Lisp has been what these machines and operating systems have aspired to support for all these years and now that they have finally grown to the task, people have so many problems with the software written while they were growing up that day-to-day survival has obscured everything to the point where people who are too young to know that computers were designed to help people think better, not just do the same old menial labor faster, believe there is nothing more to it than luring lots and lots of people to perform menial tasks by mouse instead of by lever.
anyone remember how the fear that machines would take over the world quieted down as Bill Gates started to peddle his limpware? the computers sure did take over the world, but whoever is afraid of toothless little poodles who all wag their tails when they expected monsters? imagine a little icon that said "My Scary Monster" or "My Scary Neighborhood" and a browser that said "abandon all hope ye who click here". wouldn't sell much, would it? and that's why they are called "confidence games".
I remember someone saying that if it hadn't been for automatic switches in the telephone network, the entire population of planet earth would have had to be telephone operators to handle the load of telephone usage in 1993 or thereabout. I get the eerie feeling that because modern computer systems are so incredibly braindamaged in their design and in the tools used to program them, the entire population of planet earth will be programming these idiotic boxes pretty soon if managers don't wise up to the fact that the equivalent of automatic switches already exist and have done so for at least 20 years. yet if Y2K doesn't light up most manager's view of the world of programming, there isn't hope for mankind at all.
so, yeah, Lisp is dying because we all have to program in C++ to Bill Gates' tune, so we don't have time to think about making a better world with better languages and less menial nonsense in programming computers. the same thing happened in the last revolution, but fears in those times caused labor unions and a strong sentiment against all business in some quarters. user unions these days can't even stop the U.S. Congress from enacting more laws to protect the software companies from Y2K lawsuits.
but of course, Lisp isn't dying -- it's just that if you think in terms of the imminent end of the world, _everything_ is soon food for the great garbage collector in the sky and whoever is not scrambling in panic looks like they aren't moving and have been passed by or are dying.
the problem I see is not that Bill Gates has shaped the world of useless trinkets in software, but has also managed to spread his competitiveness and his personal fear of losing to imaginary competitors to businesses and homes everywhere, so now everybody is _afraid_ of losing some battle which isn't happening, instead of getting about their own lives. like, if you aren't using today's fad language in the very latest version of the IDE, you'll be left behind. aaaugh! but it's good that some people run like they are scared out of their wits. if they suddenly disappear over the edge of a cliff, a good number of people will notice in time and _not_ follow them. those are the ones that matter.
you can scare most people most of the time, but you can't scare all of the people all of the time -- some will always use Common Lisp.
#:Erik, who'll stop cross-posting to comp.lang.misc now -- @1999-07-22T00:37:33Z -- pi billion seconds since the turn of the century
* gneu...@dyn.com (George Neuner) | The reason C/C++, and before that Pascal, took off was because forward | looking companies [I'm thinking of Borland in particular, but others were | also involved] took chances and sold their systems at well below cost | hoping to create their markets. It is true that these systems were | typically stripped down relative to "professional" development systems | available, but they introduced people to the language at affordable cost | and built a base of programmers familiar with both the language in | general and the company's products in particular.
the same has been done in the marketing and production of wines. those who sell dirt cheap wine continue to thrive, and we see the same effect as we do in programming languages: large masses of people get intoxicated and dependent and contine to devour cheap wine, while a few people get seriously interested in great wines and easily spend 100 times more money on a bottle of a great wine than regular consumers do. yet, for some bizarre reason, expensive wines make a respected market, nobody in their right mind wants them to be free, and it is not considered a good thing to turn people into alcoholics just to be able to sell more cheap wine.
| Curious newcomers who lack the ability to set up a shareware/freeware | system may be willing to try a low cost commercial system which is easy | to install and use. Commercial Lisp implementors, for the most part, | either didn't offer low cost intro packages or didn't advertise that they | did. Out of sight, out of mind.
right. the commercial Lisp vendors offer anyone who ask a reasonable question a simple and easy way to try their software, completely for free, and free or extremely low-cost systems somehow is not enough to make people interested in serious Common Lisp implementations, in some people's minds. so obviously your analogy doesn't hold at all.
I started with CMUCL myself, but found that Allegro CL offered so much more that the work I would need to put into CMUCL would make it all but impossible to do well-paid work in Common Lisp in CMUCL: after pretty serious exposure to C++, I had come to conclude that I needed to get myself into a position where I would never ever have to write any C++ again, so I set out on a path that removed me almost completely from the mainstream, and if I were to recover the cost of that, only commercial Lisps supported by someone other than myself could work for me. (I would like a commercial Emacs, too, for exactly the same reasons. perhaps I'm just getting old.)
I'd argue that what has kept Common Lisp from wide-spread success is its free implementations -- not only are the implementations that students normally see low quality as development environments go, all the crappy Schemes out there that try really hard to call themselves "Lisp" destroy the name recognition of Lisp completely (why can't they just stick to calling their toys "Scheme"?), and any student who didn't question his professors and peers would have to conclude that Lisp is a bad joke.
the reason C succeeded is that Unix succeeded, and Unix succeeded because of the coolness factor among early 70's computer science students, and that was a coolness factor unrelated to overall technical merits, but very much related to _some_ brilliant ideas. DOS succeeded because it was so broken that any 14-year-old idiot could fix it and brag about it to his peers, causing kids everywhere to "get involved". C++ is riding on the DOS wave that Windows rode in on, too -- most Microsoft victims have _always_ used Microsoft products. Pascal succeded because it was the language of choice on the Apple, which was also "cool", and Macintosh fans don't wander off the narrow path, either. there was a market for these languages completely unrelated to the languages themselves, but these are consumer languages. winning is being stronger than your competition, but as with any relation, becoming "stronger than" either means you get stronger or you find a competition you are already stronger than. Lisp is stronger than any competition in lots of places. it is not stronger than languages optimized for dummies who, inexplicably, believe that they can learn them in 21 days. it is, however, much stronger than professional C/C++.
now, if you think C/C++ is cheap in the professional market, that using professional class libraries is as easy as bragging to some manager that you know C++, and that you can be unskilled in all C++ jobs, you are way out of your mind. there is a professional market for C++ work that costs much more than Common Lisp systems cost, but because this market does as little advertising as Common Lisp does, you never see it, either. and when you hear that a project has moved from Common Lisp to C++, it is _not_ moved from Allegro CL to MSVC++ with MFC -- they move to a language that most C++ programmers wouldn't even know how to begin to understand, using stuff from the language that _actually_ supports large-scale work, not the silly stuff that C++ is sold on at the consumer level. this usage of C++ is much harder than doing the same kind of thing in Common Lisp, as most managers find out as soon as they have made the stupid decision to use C++, only they don't know how to undo their bad decision, so they continue down the very expensive road, probably adding a lot of manpower in the process. (the opportunity for most project managers to learn from their mistakes is severely limited: they get fired and spend a lot of time looking for new work. because of this, languages with large "people bases" are preferred over what will more likely succeed, because managers are people people and most of them are insufficiently technical to assess risks even if they might be risk takers to begin with.)
Lisp's perception in the market has also been rocked by some spectacular cases of bad company. when Lucid folded on its C++ project, its Common Lisp had been a cash cow for a long time, and it continued to produce money enough that it was worth salvaging -- I never heard more about the C++ effort. of course, Lucid was best known for its Common Lisp, so those who already didn't like Lisp got an easy opportunity to knock Lisp again. when Harlequin was in danger of folding recently, it was wholly unrelated to its Lisp business, which appears healthy but out of vogue with venture capitalists and investors, but their problems has already caused people to become scared about Lisp's future.
I think it works like this: if you're clearly better than the rest, you get credit when you win, and you get blamed if you lose. ("if you are so good, how come you don't make a lot of money?" is a typical instance of this sorry situation, as if certain things are inevitably connected.) if you are no better than the rest, you can take credit if you win, but you don't get blamed if you lose. if you are worse than the rest, whoever chooses you and wins did something spectacular, but if you fail, they were just dumb who chose a loser. I think it works this way in many aspects of life, and I think it does so because most people don't actually _like_ winners unless they are certain they'll never be beaten by them themselves. I think that's why watching sports is so popular, too. in my view, fad languages that get all the attention are just like the sports dudes who are very much _temporary_ winners in their fields, earning a lot of money so they can retire to oblivion after a few years of fame. the only way you can actually _win_ is to stay completely away from the mass audiences and above all not depend on popular votes for popularity, not beat the crap out of anyone in a competition (because those that happened to will be certain to try to beat the crap out of you, too), and not even get into fields where the short-term profits are enormous, because that only means a lot of people lose a lot of money and want to recover it, trying again and again.
I'm not sure I'm helping, but I'm willing to say that a project I have worked on succeeded because of Common Lisp, mostly because I'm sure it won't fail for any other reason. I'd be damned cautious to mention a Common Lisp project that succeeded technically, but was in danger of failing for any other reason, however, simply because there are so many stupid people out there who wouldn't know what this meant.
what makes a success is not, has never been, and will never be that the entry to it is free. what makes it a success is that people stick with it. if you can't make people stick with something unless they get the first dose for free, I'd say you have something that people really shouldn't stick with at all. I think people start using stuff because they hear about it, and it really doesn't matter to a lot of people that it may cost money. after all, most people pay for their cars and won't give them up no matter what environmentalists and politicians do to stop them, and don't tell me it's because they got free rides as kids. in my view, access to source code is only a question of education -- it can never be a question of market penetration. Linux did _not_ win because it is free, but because people wanted an alternative to Microsoft on the dirt-cheap computers they could get their hands on. and if you look at all the incredibly crappy software that people actually pay good money for, being free is _obviously_ not necessary for success. nor is being free sufficient, since lots of free software fails, too.
so why the clamoring about stuff being free? and why do I keep hearing "you have a duty to provide me with the tools I need to make a living" from so many of the free software proponents?
