cyber_sur...@wildcard.demon.co.uk (Cyber Surfer) writes: >In article <joswig-1409961203090...@news.lavielle.com> > jos...@lavielle.com "Rainer Joswig" writes: >> > We have been specific in saying over and over. Those of us who have to >> program >> > for the PC _need_ a truely windows aware Lisp: we need OCX capability, true >> > OLE compatability, dynamic linking to the system's DLLs, and for a price >> > somewhere low side of $500.
>> Sounds interesting. If I'd use a PC I'd certainly would like >> to have it. Would there be a market for it? How big? >> What do you think? >We may never know, unless somebody tries it. Has it been done yet? >If Lisp does indeed make programmers more productive, then it would >appear that a market _does_ exist. >If I appear to be negative about Lisp, it's only because I see so >many examples of negative thinking keeping Lisp where it is today, >in an ivory tower, used by elitists. Remember the Smalltalk balloon >on the cover of the August 1981 issue of Byte? I do. What we don't >see in that picture is the tether keeping the ballon from escaping >from the ivory tower.
Oh boy, do I ever remember that balloon. A friend of mine wants to trade his copy of that issue along with the Blue, Orange and Green book to somebody for an old arcade game. I'm trying to convince him otherwise.
As far as the Ivory Tower, I agree. I'd like to see a book "Lisp for Idiots", "Lisp in 21 Days", "Conquer The World With Lisp", etc. with the Allegro CL Lite, Allegro PDF file, and all of the source pressed on to a CD glued in the back of the book. I'd like the book to focus on what Lisp has in COMMON with other languages in order to bait folks into a the couple of "Advanced Topics" chapters in the back.
Stick some ODBC drivers on it that can create "Access" databases, and folks will be balancing their checkbooks...in Lisp. Writing checkers games...in Lisp. Doing all of those things that folks think they want done, but can't seem to find the right software and they're willing to learn and program themselves...in Lisp. Kind of a Grass Roots thing.
Folks that read these books don't want "Computer Science", they want "Paint By Numbers". If the readers don't finish the book, then they'll believe that Lisp is "Just like the others", so why be afraid of it? If they stick to the end of the books, then they'll discover that not only is Lisp "Just like the others, but it is something more as well. A wolf in cheap clothing." with the ISBNs of Grahams books as a followup.
Lisp has IF statements, so does VB. Lisp has FOR loops, so does VB. Lisp has a dialog builder (Allegro does), do does VB. Lisp can have structures, so does VB. Functions? Subroutines? Lisp and VB are pretty close.
What does VB have that Lisp doesn't have? Volume! Allegro has a FFI, and third parties can ADD widgets if they want, but without the market volume, there is no incentive. There are a zillion VBXs out there.
A book might attract folks to Lisp, which will attract volume to Franz, which may let them lower their price, which will attract more volume, which may attract 3rd parties, yada yada yada.
-- Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com 1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!" 1993 Explorer - Cage? Hell, it's a prison. -D. Duck
In article <svspire-1609960210240...@news.nmia.com> svsp...@telespin.com "Shannon Spires" writes:
> Then you hear about the Dylan cafe, which advertises a wonderful, > perfect, rich cup of espresso, but when you get there, they tell > you they're going out of business but you can have a free sample of > some of their half-brewed stuff that's been sitting in the pot for > a while. It tastes pretty good, even though it's cold and hard to drink > from that awkward revised infix styrofoam cup (the masses just don't like > ceramics, you see), but you will never get any more of it (except > vicariously by reading about it in a Harlequin romance), so you're > on your way back to the Burger King.
That's the bitter flavour, I think. It's best to let it brew for a few years, then you get a much more enjoyable taste. ;-)
Lisp has been brewing for years - perhaps too long - so the taste is a very unusual one. You'll either love it or hate it. <sigh> A few radicals sometimes suggest adding artificial flavouring, but the purists always shout at them until they shut up again.
> At which time you spy, out of the corner of your eye, a place called > "The Smalltalk Bistro"...
Ah, yes. The place that's suspended from a balloon that nobody can find, probably coz it's way too high up. Still, the brightly decorated walls are very attractive, and those bean bags...
But to get there, you have to pass the hotdog stand. Yep, that smells like Basic! I'll have a coke with mine...<gag> -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
cyber_sur...@wildcard.demon.co.uk wrote: > This is true, tho Java has managed to generate a great deal of > interest _without_ an obvious killer app, while Lisp should've > had several by now. If none of the symolic math packages are > "killer apps", then what about HotMetal?
Killer apps for languages are not single programs, but an entire categories of programs that were previously impossible to write. For Java, applets are the killer app. Two years ago there was no way to put live content on web pages. Now there is.
For the record, here is a list of the killer apps for the winners in the language wars over the past 40 years:
1950s COBOL -- business programming in something more legible than assembler. 1960s FORTRAN -- numerical modeling. 1970s C -- UNIX (ability to port an OS to new hardware just as number of platforms started exploding). 1980s C++ -- "object oriented", builds on knowledge of C gained in the 70s. 1990s Java -- Applets.
Note that each new language wasn't just better (or in some cases any better at all) than the previous language. Rather, each language let you do something you previously couldn't do at all.
Note also that the killer app was never "powerful and easy to use programming language."
If you want a Lisp-like language to win in the next round of the language wars, you need to find the next killer app, not the last one. Don't add applet support to Lisp or Dylan and expect the world to beat a path to your door. Do something nobody could do before, but can with your language.
-- John Brewer Senior Software Engineer Spyglass, Inc. Opinions expressed do not necessarily reflect those of my employer. Heck, I'm old enough to remember the _first_ time Apple was "doomed".
Erik Naggum: ... and what's their solution? create another cute little immature thing that shows every sign of being just as bad at scalability and adaptability once it gets out of the maternity ward. ...
i suspect you are referring to plan9, but this is the wrong forum to dump on that topic. if you have something interesting to say, please post it to comp.os.plan9 so that those of us who actually know something about that system can respond appropriately.
In article <wk91aajucz....@laura.ilog.com> da...@laura.ilog.com "Harley Davis" writes:
> Actually, as far as I know the next version of Java does include > closures. You can define an embedded class anywhere, even in a method > body, and it accesses lexically defined variables like a closure.
Excellent. Now all we have to do us tell all those Java people that Lisp has had closures for _years_. After that, we can tell C++ programmers how Lisp has had macros that wipe the floor with templates. ;-)
Perhaps someday Java will have decent higher order functions (err, methods), and it'll look even more like Lisp. Just like Dylan does, today. The difference is that Java is running on a great number of desktops _today_, while Dylan is...not here yet. So, Java gets a head start, Dylan sneaks up on everyone, and Lisp stays just where it is, where very few people notice it.
Hmm. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
In article <vfr750Dxu9Gt....@netcom.com> vfr...@netcom.com "Will Hartung" writes: > Oh boy, do I ever remember that balloon. A friend of mine wants to > trade his copy of that issue along with the Blue, Orange and Green book > to somebody for an old arcade game. I'm trying to convince him > otherwise.
The Green book is my favourite. I learned a _lot_ from that one.
> As far as the Ivory Tower, I agree. I'd like to see a book "Lisp for > Idiots", "Lisp in 21 Days", "Conquer The World With Lisp", etc. with > the Allegro CL Lite, Allegro PDF file, and all of the source pressed > on to a CD glued in the back of the book. I'd like the book to focus > on what Lisp has in COMMON with other languages in order to bait folks > into a the couple of "Advanced Topics" chapters in the back.
Don't forget "Lisp for Dummies". ;) Yes, something like that would be needed to sell Lisp to the masses. There are so many books about Java and C++ using that approach that Lisp books like W&H and SICP wouldn't stand a chance. Being high quality isn't enough any more - you have to speak the same language (no pun intended). You also have to show how relevant Lisp is to everyday programmers, i.e. "dummies".
> Stick some ODBC drivers on it that can create "Access" databases, and > folks will be balancing their checkbooks...in Lisp. Writing checkers > games...in Lisp. Doing all of those things that folks think they want > done, but can't seem to find the right software and they're willing to > learn and program themselves...in Lisp. Kind of a Grass Roots thing.
The only reason I avoid Access programming is that I'd have to use C++ or VB. Now, if I could do it in Lisp, I could test my code at the keyboard. I used to be able to do that once. Ah, but I used Forth back then, on an 8-bit machine.
So, instead, I'm writing CGI code in Perl...Just like a lot of other people. I don't even have time to play in Lisp, never mind doing any programming.
> Folks that read these books don't want "Computer Science", they want > "Paint By Numbers". If the readers don't finish the book, then they'll > believe that Lisp is "Just like the others", so why be afraid of it? If > they stick to the end of the books, then they'll discover that not only > is Lisp "Just like the others, but it is something more as well. A > wolf in cheap clothing." with the ISBNs of Grahams books as a > followup.
Too many C programmers today think that K&R is tough reading. I wouldn't let them anywhere near W&H! Not until they've mastered the basics, that is. That wouldn't even be _half_ of W&H.
> Lisp has IF statements, so does VB. Lisp has FOR loops, so does VB. > Lisp has a dialog builder (Allegro does), do does VB. Lisp can have > structures, so does VB. Functions? Subroutines? Lisp and VB are pretty > close.
"Lisp for VB Programmers", hmm. If I didn't find VB so repellant, I might be tempted to write such a book. I'd enlist a VB programmer to help me, in case I overestimated the abilities of the average VB programmer. It's too easy to forget, even as you're using it, just how primitive a language like Basic really is.
Using more advanced languages can give you a better understanding of less sophisticated languages, but you might also overestimate other people's experience and skills. I see this happening a lot, in all kinds of areas of computing (and elsewhere).
> What does VB have that Lisp doesn't have? Volume! Allegro has a FFI, > and third parties can ADD widgets if they want, but without the market > volume, there is no incentive. There are a zillion VBXs out there.
And many OCXs, too. The Win32 market is growing, while the Win16 market is slowly dying. Widgets like Allegro's are neat, but of less value to most users and developers. Experience tells us that closed systems are of limited interest (to the point where many products just die), and that open systems are more likely to survive, due to third parties developing masses of support, addons, books, and let's not forget my favourite, consultancy.
As you say, there are a zillion VBXs out there. Pretty soon there'll be a zillion OCXs to keep them company, and in time take their place. Can Lisp programmers take advantage of them? Possibly, but if it can be done, it's not easy to discover how.
Meanwhile, every VC++ and VB programmer _knows_ they can use all those fab VBX/OCX tools out there. Remember the "software kit" idea? I used to think that was a Smalltalk thing, but no, it's VC++/VB. You just take the parts and glue 'em together with a little code.
> A book might attract folks to Lisp, which will attract volume to Franz, > which may let them lower their price, which will attract more volume, > which may attract 3rd parties, yada yada yada.
Yep. Why should MS, Borland, Symantec, etc take all the cash? Of course, we have a biased interest here, being Lisp programmers. Naturally we want Lisp vendors like Franz and Harlequin to be more successful! -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
In article <mafm.842864...@cs.uwa.edu.au> m...@cs.uwa.edu.au "Matthew McDonald" writes:
> The installation instructions are at the top of the file `README' in > the top-level directory when you unpack the files. I think that's > pretty obvious, don't you?
It must be missing from the archive I downloaded, coz I can find no such file. There's just stk.exe. In fact, there's not a README file in the entire archive.
Still, it's worth checking for the obvious. Perhaps this file is normally present in STk archives, but not this one? I dunno. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
In article <jbrewer-1609962001020...@news.mcs.com>,
John Brewer <jbre...@spyglass.com> wrote: >For the record, here is a list of the killer apps for the winners in the >language wars over the past 40 years:
>1950s COBOL -- business programming in something more legible than assembler. >1960s FORTRAN -- numerical modeling. >1970s C -- UNIX (ability to port an OS to new hardware just as number of >platforms started exploding). >1980s C++ -- "object oriented", builds on knowledge of C gained in the 70s. >1990s Java -- Applets.
I think it's more than a little premature to say that Java has been the "killer app" winner of the "language wars" for the 1990s.
I suspect Visual BASIC is a much stronger claimant for the 1990s title. A lot of companies are using VB to build graphical front-ends for commercial bespoke applications, and it allowed thousands of people who couldn't previously build graphical Windows applications to do so.
VB thus gave end users Windows interfaces to lots of previously hard to use software. Tcl/Tk would be the UNIX equivalent.
Perl is another strong candidate, letting people do simple scripting, text processing and reporting on data in a quick, easy multi-platform way. The result has been a profusion of useful Perl 'applets' to summarize information, check data, search for things, and so on.
>Note that each new language wasn't just better (or in some cases any >better at all) than the previous language. Rather, each language let you >do something you previously couldn't do at all.
I haven't seen any application built with Java that couldn't be built using something else. By 'application', I mean a piece of software which performs some useful task for an end user.
The thing Java can do which is unusual is run the same code on multiple platforms, and download it from the web; but that's a technical detail, not something end users really care about.
Most of the other items on your list succeeded not because they were 'killer apps' themselves, but because they were linked with 'killer apps'. COBOL's killer app was business software; FORTRAN's was, as you point out, numerical modelling applications; and yes, C's was UNIX and microcomputer OSs in general.
The language itself can be awful if the 'killer app' is compelling; ultimately, it really doesn't matter how bad the language is, much as I hate to admit it. Perl is disgusting, but there were so many useful (not just decorative) Perl scripts around, and so many things Perl could do for me, I had to give in and learn it.
What was the 'killer app' for C++? I don't think it has one. Most people seem eager to ditch it for something else, and users don't see that applications built in C++ give them anything special over applications built in C.
So what's the killer app for Java? What's the thing which will make the people who don't care about implementation details get interested, make them think "I must get Java so I can do this thing I can't do any other way"? I've not seen anything yet which has made *me* feel that I need Java. I downloaded the JDK and Java run time, tried a couple of apps, found that they were ugly and grindingly slow, and haven't touched it since.
And to make the thread relevant to the newsgroups it's posted to, what might be the killer apps for Common LISP, Scheme and Dylan?
My guess for Scheme is that it might be able to ride the SGML/DSSSL wave... Platform-independent content-based machine-processable documents; single source documentation which can be delivered in multiple formats, including intelligent hypertext -- those are new things which a lot of people want.
> In article <meta19960915235...@pobox.com>, m...@pobox.com (mathew) wrote: > We want a cup of coffee. [...] Shannon Spires wrote: > Then you hear about the Dylan cafe, [...]
Meanwhile, at the secret SML Labs, they don't have any coffee, but they have been working on a highly potent form of caffeine. And they don't have any cream or sugar, or cups, but they do have a drawer full of freshly sterilized syringes.
wnew...@netcom.com (Bill Newman) writes: > PS. I haven't seen anything about guile on the Scheme newsgroup for a > while. Does that mean that it's not going anywhere or that people > have decided that guile doesn't belong there?
Guile is actually pushed for the first 'official' release, and you shouldn't wait too long to see one. It moved from Tom Lord to Jim Blandy, and the mailing list seems much more lively since then.
In article <jbrewer-1609962001020...@news.mcs.com> jbre...@spyglass.com "John Brewer" writes:
> If you want a Lisp-like language to win in the next round of the language > wars, you need to find the next killer app, not the last one. Don't add > applet support to Lisp or Dylan and expect the world to beat a path to > your door. Do something nobody could do before, but can with your > language.
It appears that Perl has already conquered the CGI department, and Java has the applet territory (I know about ActiveX BTW). What does that leave? Better OOP than C++, Java, and Smalltalk? Possibly, but very few people know it - yet.
Lisp has other strengths, of course. The problem could be that many of these strengths are not so easy for non-Lisp programmers to understand and, more importantly, appreciate. The ability to develop code rapidly is one that we can all recognise, but I find it's not so easy getting the opportunity to exploit it. Most of the code I'm asked to write specifies the _language_, and very often the compiler, too. While it sometimes may be _possible_ to do it in Lisp, that's not what I'm asked to use.
Look at it this way. When a programmer is asked to write some CGI code, it's more likely that they'll write it in Perl, simply because it's more likely that the server that'll run the code will have Perl installed on it. If more web servers had MzScheme installed as standard, perhaps more programmers would write CGI code using MzScheme.
As for browsers, Scheme could be compiled to code for the JVM, so that's not as hard to do. How many books teach Java (VM) programming using the Kawa compiler? It would be unfair to expect any to be available so early, but how many do you expect to appear during the next 5 years? Obviously we should write them ourselves, and start writing them _now_. We've got a lot of work to do to catch up with Java.
This is why I agree with you about languages that have established themselves in certain problem domains, like Perl and CGI, Java and running code in a web browser (_and_ without a web browser). It's great being able to say "Me too!", but it'll do little to change people's association of an app domain with a particular language. Lisp is associated with AI, and most people think that AI has nothing to do with their app domains.
Obviously we have to create a new app domain, do it in Lisp, and make damn sure everybody knows about it. That means understanding what everbody wants from an app (something popular, like a web browser?), not just a select few (e.g. the taditional AI apps and their users). -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
In article <199609110907.a28...@ms3.maus.de> Georg_Ba...@ms3.maus.westfalen.de (Georg Bauer) writes: >Hi!
>JD>How easy is it to use the :somename package after that? >JD>[Hint: it depends on exactly how SORT works]
>Of course - if you use _destructive_ routines, it destructs the structure. >Works as designed. That has nothing to do with memory-protection. If you >intentionally hit the power-switch, the machine will go down, regardless of >any memory protection scheme.
No kidding. So what?
My point was that type checks, including the run-time checks on Lisp machines, don't prevent me from messing things up in the way I described. Then, on a Lisp machine, all I have is the Lisp. If I mess it up, I have to try to fix it, or I have to reboot or something similarly "heavy". With an ordinary OS, I can quit Lisp and start it again while everything else continues to work. Moreover, my other Lisp processes continue to work. (Yes, I often run > 1 Lisp at once.) Since they don't share memory, messing up a package in one doesn't mess it up in the others.
>The point is, you can't access the memory and bypass the typechecking of >the hardware - like you can do easily in assembler for example. Lisp >doesn't have a notion of a pointer, but more of a reference - it's a >reference to a location in memory (that can be changed, of course), but >that always carries a typetag with it. So you can only access the location >in appropriate ways - and sort is a appropriate way to access a list (and >if it is defined as being destructive, it will sort it in-place).
But that's *why* the type check doesn't stop me from messing things up in the way I described. That's why I picked SORT for my example rather than something that would be stopped by type checks.
>JD>Now, when I mess things up in certain ways, I like being able to >JD>kill Lisp and start over w/o rebooting my machine
>No problem with Symbolics or Interlisp-D. In Interlisp-D for example I have >several ways. One is the undo, ok, that has some limitations. Then there is >the possibiliy to do a (logout t) and drop all changes and revert to the >last saved state. Under Symbolics I can do my experiments in a >incrementally world and just drop the last incremental part. Or on both >systems I can use the versioning facilities (Interlisp-D only on the Xerox >machines and only for files).
Undo is great when it works. Reverting to the last saved state is too much like rebooting and gets me involved with saved states, which I'd rather avoid.
>JD>the reasons I prefer the standard OS approach. (Yes, I know >JD>I could probably patch up the :somename package in various ways.)
>No need to patch up the package, under normal conditions.
How else am I supposed to fix the package-use-list?
> And of course: if >you do a rm -r -f on a unix machine while logged in as root, you surely >will mess up the system a bit, too. If the user breaks the machine it will >be broken. Nothing special about that - happens on all systems.
Come on. That's a _terrible_ argument. I shouldn't care about getting rid of a problem because some other problems remain? Your logic here escapes me, I must say.
And we've been here before:
>JD>So what? Surely you don't believe that imperfect implies useless.
>No. But it's a bit funny to allow your favored OS the imperfectness, but >don't allow it the lisp-machines.
cyber_sur...@wildcard.demon.co.uk (Cyber Surfer) writes: > > At which time you spy, out of the corner of your eye, a place called > > "The Smalltalk Bistro"...
> Ah, yes. The place that's suspended from a balloon that nobody > can find, probably coz it's way too high up. Still, the brightly > decorated walls are very attractive, and those bean bags...
Oh, the balloon--it's a Smalltalk Museum, didn't you know? Where have you been for the last 15 years then? Stop gaping at it and look what is around, just to be fair.
Since September 16, at <http://www.objectshare.com> you can find the Smalltalk Express. It is a full Smalltalk/V Windows 2.0 plus the WindowBuilder. Your application is an .EXE, and development and runtime support stuff is packaged as DLLs. (Or at least they look so). A moderate application (sort of a structured drawing package) produces about 300k executable, a small (15 puzzle)--about 50k. Runtime support DLLs are around 1M, and of course they are shareable by multiple applications. Not bad, huh? As for the FFI: you can call any function from any DLL, create callbacks in your code, create C data structures to pass to Windoze calls. Four years ago when it was released commercially, this ST/V+WB bundle would cost you about $700. (Oh yes, and that "V" is "vee", not "5".) Now it is free and *not crippled*. In fact, it is extended as compared to the old ST/V Win 2.0.
At <http://www.objectconnect.com> you can find Smalltalk MT with even tighter Windows (95 and NT only) integration. It is still in beta, and you can get it free. The planned price is around $300. It provides a full OLE support and is basically equivalent to programming for Windows with Borland C++ 2.0. It can generate native code executables or DLLs, with functions exportable as if there were in C. It feels less like a full-blown Smalltalk, though, and the library is thinner.
At <http://www.intuitive.co.uk/dolphin> you can find a beta of Dolphin Smalltalk. It is closer to the classic Smalltalk in spirit, with a pretty full class library, compatible with the upcoming X3J20 ANSI standard, bytecode-interpreted. They promise a native code JIT compiler soon, as well as the OLE support plus some Internet-related buzz (sorry, I forgot what--don't care much). They also promise to set the price under $200.
On the heavier side of the spectrum, there is LearningWorks <http://sumeru.stanford.edu/learningworks/>: a free Smalltalk using the virtual machine of VisualWorks (which is, in turn, the proverbial Balloon (Smalltalk-80) after 15 years of evolution). It is not a vehicle for conquering Windoze, though: it is multi platform, and support for each specific platform is weak. But it's free, and performance-wise it will beat the hell out of ST/V and Dolphin ST.
I personally was much happier to see CMUCL for Linux than any of the above. But if you are really into that Windoze dominance thing, a CL built and looking *at least* like Smalltalk/V would be a good step forward.
In article <51lvg0$...@snotra.harlequin.co.uk>, m...@pobox.com (mathew) wrote: > I suspect Visual BASIC is a much stronger claimant for the 1990s > title. A lot of companies are using VB to build graphical front-ends > for commercial bespoke applications, and it allowed thousands of people > who couldn't previously build graphical Windows applications to do so.
Visual Basic is definitely a good pick for the language of the 90s. Being a Mac person, I often overlook it. However, visual Java environments are starting to crop up (see for example, Peter Coffee's opinion of a pre-release version of Visual Cafe <http://cafe.symantec.com/reviews/12coff.html>).
> The thing Java can do which is unusual is run the same code on > multiple platforms, and download it from the web; but that's a > technical detail, not something end users really care about.
I must respectfully disagree. When I say live content, I don't just mean the "Tumbling Duke" animation. Think client/server, only you can jam the client down a wire to a remote user, and keep a live connection open to the server. This is going to be big in commerce, and in multi-player games. And there was no good way to do this before Java.
> And to make the thread relevant to the newsgroups it's posted to, what > might be the killer apps for Common LISP, Scheme and Dylan?
> My guess for Scheme is that it might be able to ride the SGML/DSSSL > wave... Platform-independent content-based machine-processable > documents; single source documentation which can be delivered in > multiple formats, including intelligent hypertext -- those are new > things which a lot of people want.
Maybe, but it's not clear to me that HTML hasn't already filled that vacuum. Vacuums that everybody sees don't stay vacuums for long.
-- John Brewer Senior Software Engineer Spyglass, Inc. Opinions expressed do not necessarily reflect those of my employer. Heck, I'm old enough to remember the _first_ time Apple was "doomed".
>> Actually, as far as I know the next version of Java does include >> closures. You can define an embedded class anywhere, even in a method >> body, and it accesses lexically defined variables like a closure.
>Excellent. Now all we have to do us tell all those Java people >that Lisp has had closures for _years_. After that, we can tell >C++ programmers how Lisp has had macros that wipe the floor with >templates. ;-)
>Perhaps someday Java will have decent higher order functions >(err, methods), and it'll look even more like Lisp. Just like >Dylan does, today. The difference is that Java is running on a >great number of desktops _today_, while Dylan is...not here yet. >So, Java gets a head start, Dylan sneaks up on everyone, and >Lisp stays just where it is, where very few people notice it.
I would like to think that this is the "master plan" for Java, as envisoned by Gosling and Steele. They both have a lot of Lisp background, you know.
Maybe they thought that the only way to introduce Lisp is to disquise it underneath the facade of the Web, C++, and visual environments.
If someday Java has closures, hygienic macros, and all of the other Lisp-family goodies, does it really matter if it doesn't have parenthesis? Isn't the semantics more important the syntax?
I think one of the really valuable lessons that Dylan has shown is that you can have a successful infix syntax *and* have all of the Lisp goodies.
I'm hoping that Java does expand in this way.
What would you rather use: Java or Visual Basic? -- Glenn Ehrlich geh...@primenet.com
>>> > We have been specific in saying over and over. Those of us who have to >>> program >>> > for the PC _need_ a truely windows aware Lisp: we need OCX capability, true >>> > OLE compatability, dynamic linking to the system's DLLs, and for a price >>> > somewhere low side of $500.
>>> Sounds interesting. If I'd use a PC I'd certainly would like >>> to have it. Would there be a market for it? How big? >>> What do you think?
>>We may never know, unless somebody tries it. Has it been done yet? >>If Lisp does indeed make programmers more productive, then it would >>appear that a market _does_ exist.
>>If I appear to be negative about Lisp, it's only because I see so >>many examples of negative thinking keeping Lisp where it is today, >>in an ivory tower, used by elitists. Remember the Smalltalk balloon >>on the cover of the August 1981 issue of Byte? I do. What we don't >>see in that picture is the tether keeping the ballon from escaping >>from the ivory tower.
>Oh boy, do I ever remember that balloon. A friend of mine wants to >trade his copy of that issue along with the Blue, Orange and Green book >to somebody for an old arcade game. I'm trying to convince him >otherwise.
>As far as the Ivory Tower, I agree. I'd like to see a book "Lisp for >Idiots", "Lisp in 21 Days", "Conquer The World With Lisp", etc. with >the Allegro CL Lite, Allegro PDF file, and all of the source pressed >on to a CD glued in the back of the book. I'd like the book to focus >on what Lisp has in COMMON with other languages in order to bait folks >into a the couple of "Advanced Topics" chapters in the back.
>Stick some ODBC drivers on it that can create "Access" databases, and >folks will be balancing their checkbooks...in Lisp. Writing checkers >games...in Lisp. Doing all of those things that folks think they want >done, but can't seem to find the right software and they're willing to >learn and program themselves...in Lisp. Kind of a Grass Roots thing.
>Folks that read these books don't want "Computer Science", they want >"Paint By Numbers". If the readers don't finish the book, then they'll >believe that Lisp is "Just like the others", so why be afraid of it? If >they stick to the end of the books, then they'll discover that not only >is Lisp "Just like the others, but it is something more as well. A >wolf in cheap clothing." with the ISBNs of Grahams books as a >followup.
>Lisp has IF statements, so does VB. Lisp has FOR loops, so does VB. >Lisp has a dialog builder (Allegro does), do does VB. Lisp can have >structures, so does VB. Functions? Subroutines? Lisp and VB are pretty >close.
>What does VB have that Lisp doesn't have? Volume! Allegro has a FFI, >and third parties can ADD widgets if they want, but without the market >volume, there is no incentive. There are a zillion VBXs out there.
>A book might attract folks to Lisp, which will attract volume to Franz, >which may let them lower their price, which will attract more volume, >which may attract 3rd parties, yada yada yada.
>-- >Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com >1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!" >1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Excuse me, but:
_YES_!
Those yellow & black books sell lots of copies. And there is precident for a "complex" subject: "ISDN for Dummies"
generally speaking, if this were true, we would not see the syntax-fixation that the whole industry is built on. syntax _distinguishes_ programming languages from each other; the semantics is only a question of how much of the syntax you need to implement it. e.g., if CFRONT can produce C code from C++, so can a human. syntax can help automate the expression of the semantics in very important ways, or serve to frustrate the same process. however, certain operations are possible (that is, sufficiently easy) on certain syntaxes, which leads me to the more specific interpretation.
one part of the reason why I like Lisp is that I and the compiler can use the same functions to read and write the source code, not only in macros, but in codewalkers and automated editing tasks. `read'ing Java or any of the C-family languages is dreadfully painful. writing out what you have read in is somewhat easier, but not much.
| I think one of the really valuable lessons that Dylan has shown is that | you can have a successful infix syntax *and* have all of the Lisp | goodies.
_all_ of the Lisp goodies? except macros, except `read' on source code, except `pprint', except ...
#\Erik -- those who do not know Lisp are doomed to reimplement it
In article <jbrewer-1709962246510...@news.mcs.com>,
John Brewer <jbre...@spyglass.com> wrote: >In article <51lvg0$...@snotra.harlequin.co.uk>, m...@pobox.com (mathew) wrote: >> The thing Java can do which is unusual is run the same code on >> multiple platforms, and download it from the web; but that's a >> technical detail, not something end users really care about.
>I must respectfully disagree. When I say live content, I don't just mean >the "Tumbling Duke" animation. Think client/server, only you can jam the >client down a wire to a remote user, and keep a live connection open to >the server.
Sure, you can - but what's the benefit to the user?
> This is going to be big in commerce, and in multi-player >games. And there was no good way to do this before Java.
Oh, come on. There are loads of multi-player games around already which far surpass anything you can do in Java. Look at DOOM, Quake, SimCity 2000, Bolo, Spaceward Ho!, and so on -- all played across the Internet. Users don't care if they're downloading a single platform-independent client, or a platform-dependent client. What they care about is how good the game is; and I very much doubt anyone will be playing JavaQuake in the near future.
Even in text-based Interactive Fiction, which Java *can* handle, the existence of Java-based Z-code interpreters has had no impact - it seems people still prefer to download a Z interpreter for their system, instead; something which has the UI they're used to, and makes full use of the system's capabilities.
>> My guess for Scheme is that it might be able to ride the SGML/DSSSL >> wave... Platform-independent content-based machine-processable >> documents; single source documentation which can be delivered in >> multiple formats, including intelligent hypertext -- those are new >> things which a lot of people want.
>Maybe, but it's not clear to me that HTML hasn't already filled that >vacuum.
HTML does a restricted subset of what SGML can do. In particular, HTML lacks a rich enough markup scheme to allow data to be marked up according to what it is, rather than just what it looks like. There are a few useful semantic tags like <ADDRESS>, but a lot of gaps: there's no HTML tag for telephone numbers, to pick just one example.
>>>>> "mathew" == mathew <m...@pobox.com> writes: > So reluctantly, we go back to the C/C++ Burger King, and they make > us a cup of instant coffee with non-dairy creamer. And it tastes > pretty foul, but it is at least roughly what we wanted.
And you can take the cup home, and use it to put water, sand, or coffee beans in, for that matter (even if it might not be quite perfect).
I don't know what Common Lisp's application domain might be. Presumably it's popular in AI type things (expert systems and the like)?
I think there's a big market for something like VB for Unix. I think something Scheme-like is probably right for the task, and I have hopes that the Guile project will do it.
At best, it might be an embeddable scripting language with a nice clean interface to Unix functionality (like Perl/scsh has, but with expect functionality too), and with widgets for X (probably Tk based, so it's much cheaper than Motif, with more functionality), and optimally compilable for speed, all with optional dynamic loading on those systems which support it.
So you can have a cheap-and-cheerful instant coffee, in a nice robust plastic cup. But you can also change the coffee and cup if you like (and most of the time they'll interface correctly), and there's enough power and flexibility to allow you to make your own mugs if that's what you want (and if you do, other people can just reuse ones you made earlier).
On the other hand, the cups will probably have small holes in them initially, the coffee will taste almost but not quite like the coffee you were used to, the ingredients list will be incomplete and out of date, and if you try making mugs you'll need to learn again in a year's time because it'll have changed. But at least the price will be right. -- Bruce Stephens | email: B.Steph...@math.ruu.nl Utrecht University | telephone: +31 30 2534630 Department of Mathematics | telefax: +31 30 2518394 P.O. Box 80010, 3508 TA Utrecht, The Netherlands
In article <3052030527425...@naggum.no> Erik Naggum <e...@naggum.no> writes:
| I think one of the really valuable lessons that Dylan has shown is that | you can have a successful infix syntax *and* have all of the Lisp | goodies.
_all_ of the Lisp goodies? except macros, except `read' on source code, except `pprint', except ...
#\Erik -- those who do not know Lisp are doomed to reimplement it
Imagine this:
in 2005 C++ ANSII standart comittee decides to introduce alternate lisp-like syntax to make easier writing complex macros ;-)
In article <323f7b48.3843...@news.primenet.com> geh...@primenet.com "Glenn Ehrlich" writes:
> I would like to think that this is the "master plan" for Java, as envisoned by > Gosling and Steele. They both have a lot of Lisp background, you know.
That thought has occured to me, too. ;-)
> Maybe they thought that the only way to introduce Lisp is to disquise it > underneath the facade of the Web, C++, and visual environments.
That might also be the plan with Dylan, but we'll have to wait and see. Java is happening right now.
> If someday Java has closures, hygienic macros, and all of the other Lisp-family > goodies, does it really matter if it doesn't have parenthesis? Isn't the > semantics more important the syntax?
> I think one of the really valuable lessons that Dylan has shown is that you can > have a successful infix syntax *and* have all of the Lisp goodies.
Certainly! That's the reason why I'm more positive about Dylan than some others. With Java, we have another advantage. Once the JVM is in place on every desktop, we can piggyback other languages, like Scheme. This is already happening. Now, if a few Lisps systems like MIT Scheme, could use a front end using the JVM, we could "standardise" the user interface. MIT Scheme could look the same on every platform it runs on, coz the enviroment's GUI uses a widget server written in Java (or Scheme code compiled for the JVM).
What has syntax got to do with it?
> I'm hoping that Java does expand in this way.
I'm hoping that existing software can exploit it, too.
> What would you rather use: Java or Visual Basic?
Java! Everytime. VB makes me feel sick, but the enviroment is ok. Delphi demonstrates that this kind of thing is not unique to VB. We know that, but it needs to be _demonstrated_. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
In article <m3pw3kraj2....@wintermute.hip.cam.org> vby...@cam.org "Vassili Bykov" writes:
> Oh, the balloon--it's a Smalltalk Museum, didn't you know? Where have > you been for the last 15 years then? Stop gaping at it and look what > is around, just to be fair.
I've been exploring alternatives, like Lisp, for the last 10 years or so, and I was playing with Forth before that. Plus C and assembly language when necessary. When I used CP/M-68K, all I had was C and assembly, so I created my own Forth and Lisp interpreters.
My tiny Pascal compiler generated asm code for a while, but then I became interested in quadruples. Anyway, it was never more than a _very_ tiny compiler - 1500 lines of C isn't much.
> Since September 16, at <http://www.objectshare.com> you can find the > Smalltalk Express. It is a full Smalltalk/V Windows 2.0 plus the > WindowBuilder. Your application is an .EXE, and development and > runtime support stuff is packaged as DLLs. (Or at least they look > so). A moderate application (sort of a structured drawing package) > produces about 300k executable, a small (15 puzzle)--about 50k.
Excellent. I'll take a look at the weekend. It's been a long time since I took any interest in Smalltalk, but this sounds like the kind of runtime I want for Lisp.
> Runtime support DLLs are around 1M, and of course they are shareable > by multiple applications. Not bad, huh? As for the FFI: you can call > any function from any DLL, create callbacks in your code, create C > data structures to pass to Windoze calls. Four years ago when it was > released commercially, this ST/V+WB bundle would cost you about $700. > (Oh yes, and that "V" is "vee", not "5".) Now it is free and *not > crippled*. In fact, it is extended as compared to the old ST/V Win > 2.0.
Yeah, back then $700 was too much for me. Last time I checked ST/V, it didn't impress me. Now it should, esp if it's free. I'm not about to complain about the cost of a download.
It seems like not too long ago when I noticed prices of ST systems in 4 figures. That was when I finally gave up on ST. Now I'll take another look.
Thanks.
> At <http://www.objectconnect.com> you can find Smalltalk MT with even > tighter Windows (95 and NT only) integration. It is still in beta, > and you can get it free. The planned price is around $300. It > provides a full OLE support and is basically equivalent to programming > for Windows with Borland C++ 2.0. It can generate native code > executables or DLLs, with functions exportable as if there were in C.
This sounds even more like what I'm after. I'll definitely grab it at the weekend. I like what I've seen so far.
> It feels less like a full-blown Smalltalk, though, and the library is > thinner.
Well, there's always a downside.
> At <http://www.intuitive.co.uk/dolphin> you can find a beta of Dolphin > Smalltalk. It is closer to the classic Smalltalk in spirit, with a > pretty full class library, compatible with the upcoming X3J20 ANSI > standard, bytecode-interpreted. They promise a native code JIT > compiler soon, as well as the OLE support plus some Internet-related > buzz (sorry, I forgot what--don't care much). They also promise to > set the price under $200.
I think I'll wait for the next beta, unless I can't wait.
> On the heavier side of the spectrum, there is LearningWorks > <http://sumeru.stanford.edu/learningworks/>: a free Smalltalk using > the virtual machine of VisualWorks (which is, in turn, the proverbial > Balloon (Smalltalk-80) after 15 years of evolution). It is not a > vehicle for conquering Windoze, though: it is multi platform, and > support for each specific platform is weak. But it's free, and > performance-wise it will beat the hell out of ST/V and Dolphin ST.
It's worth knowing.
> I personally was much happier to see CMUCL for Linux than any of the > above. But if you are really into that Windoze dominance thing, a CL > built and looking *at least* like Smalltalk/V would be a good step > forward.
I might also prefer CMUCL, based on what I've read about it. As for Linux, I dunno. Perhaps when I get a machine I can run it on, I'll try it (again). I'm not "into" any OS. I just use what I have to.
That just happens to be Win32 right now, not because I chose it, but because it was there. I get it for free, most of my other tools. The exceptions are the tools I use for personal projects. _Those_ tools are either free or way too expensive for my pocket, so a few of them are still on my wishlist.
> Where would it come from, though? I have no idea.
I've no idea, either. Franz? Harlequin? I dunno.
Anyway, many thanks for the links. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
"FORTRAN I John Backus, IBM for the IBM 704. Design begun 1954, compiler released April 1957."
"COBOL COmmon Business Oriented Language. 1960. CODASYL Committee, Apr 1960. Simple computations on large amounts of data. The most widely used programming language today. The natural language style is intended to be largely self-documenting. Introduced the record structure. "Initial Specifications for a Common Business Oriented Language" DoD, US GPO, Apr 1960."
--
William B. Clodius Phone: (505)-665-9370 Los Alamos National Laboratory Email: wclod...@lanl.gov Los Alamos, NM 87545
