>>>>> "Thant" == Thant Tessman <th...@interramp.com> writes: > 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.
though turbo-charged, the SML concoction has a disgusting, medicinally sweet aftertaste, somewhat like cough syrup. in the future, direct injection will render this irrelevant, but in the mean time those who use SML insist enduring the flavour is `good for the soul'.
Ah, wonderful, the `Java does everything better than anything' thread again.
> If you want a graphical database client, why > kludge one together with GIFs, CGIs and client pull? Why not just send a > real client down the pipe?
If you want a graphical database client, why kludge one together with Java and whatever communication you can wheedle out of Sun? Why not do it properly, with a query interface?
Fact is, the HTML forms facility is very good for the same sort of stuff Apple's Hypercard was good for. I have programmed in Java, and the sheer difficulty involved in setting up /any/ interface within AWT is staggering, let alone a good one. With HTML, I can just do a <FORM> and go from there.
With the proper CGI libraries (available for Perl, Python, Common Lisp, Scheme, probably Dylan, etc.), parsing CGI data is very easy. More importantly, it's very easy to use <fill in your favorite language here>. I am not boxed into using Java for something it is fundamentally unsuited for*.
Put another way, how is sending a Java client to the Web surfer going to make his database queries better, unless you send the entire database `down the pipe', too?
* BTW, I'm not claiming here that Java is not suited for database queries. I simply haven't worked with it enough along those directions to know. But I'm pretty bloody certain that it can't match Lisp for list processing, nor Perl for text manipulation. - -- Graham Hughes (gra...@resnet.ucsb.edu) finger for PGP key ``Unix is many things to many people, but it's never been everything to anybody.'' Home page at: http://www.cs.ucsb.edu/~ghughes/
-----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
In article <51omug$...@snotra.harlequin.co.uk>, m...@pobox.com (mathew) wrote: > In article <jbrewer-1709962246510...@news.mcs.com>, > John Brewer <jbre...@spyglass.com> wrote:
> >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?
The benefit to the user is web pages that are orders of magnitude more interactive. They don't have to know that it's because there's a Java program running on the page. If you want a graphical database client, why kludge one together with GIFs, CGIs and client pull? Why not just send a real client down the pipe?
> 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.
What if there was a standard native 3d library for Java? Better yet, what if it used something like QuickDraw 3D RAVE, so it could take advantage of hardware accelleration. I haven't written 3D games in something like a decade, but I seem to recall all the CPU time was taken up in 3D transforms and polygon rendering. Code the game logic in Java, and now you have one binary that can run on everything. Then you don't have that one-year lag to port to all the other platforms. Could be very compelling.
> 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.
I personally thought the Java Z interpreter was the neatest thing since sliced bread. As we speak, Infocom is letting people download Zork I for free off the web. Why all that mucking about with ".sea" and ".zip" files? Why not just have a page at www.infocom.com that runs Zork I inside your browser?
> 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.
This can be remedied by patching HTML. Yes, it's a hack, but you can't throw out a terabyte of installed base.
-- 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".
In article <3052030527425...@naggum.no> e...@naggum.no "Erik Naggum" writes: > 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 also like this feature of Lisp. Sadly, it appears that not many non-Lisp people appreciate it. I'm not even sure if many non-Lisp programmers _know_ that Lisp can do this.
Of course parsing languages like C is hard. That's why few people bother doing it. How many programmers miss being able to write code can parse the code they write? I'd bet that there are very few, considering how many programmers have yet to discover Lisp.
It's a viscious circle. How can they appreciate Lisp until they use it, and why should they use it unless they can appreciate it? There may be free Lisps for most (if not all) platforms, but you know how hard some programmers will resist new languages. They'll need a good reason to install and play with a Lisp.
We're the enlightened ones. I think we should consider how Lisp looks to the unenlightened, but I've said that already. ;) -- <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
>>>>> "John" == John Brewer <jbre...@spyglass.com> writes:
John> What if there was a standard native 3d library for Java? John> Better yet, what if it used something like QuickDraw 3D John> RAVE, so it could take advantage of hardware accelleration.
Why is it that everyone is ffoles by Sun into thinking Java and Java bytecode are identical? There's a Scheme to JavaBC compiler. Why is it that no one can imagine an universal bytecode, that is equally suitable for all languages?
| There may be free Lisps for most (if not all) platforms, but you | know how hard some programmers will resist new languages.
some, perhaps, but the rush to C++ and Java showed me that programmers will drop their "favorite" language in the blink of an eye and embrace something new and "hot".
however, I think the problem is more likely that text book authors are doing Lisp an enormous disfavor by mentioning it at all. recently, I had a look at David Harel : Algorithmics : The Spirit of Computing, from 1992, and its treatment of Lisp might as well have been written in 1962.
and then there's the entries in Encyclopædia Britannica, which I have mentioned here previously:
LISP (List Processor) is a language that is powerful in manipulating lists of data or symbols rather than processing numerical data. In this sense, LISP is unique. It requires large memory space and, since it is usually processed by an interpreter, is slow in executing programs. LISP was developed in the late 1950s and early 1960s by a group headed by John McCarthy, then a professor at the Massachusetts Institute of Technology. At that time, LISP was radically different from other languages, such as FORTRAN and ALGOL. Several versions have been developed from the LISP 1.5 introduced by McCarthy; Common LISP, released in 1984, is becoming the de facto standard of LISP.
Other languages are functional, in the sense that programming is done by calling (i.e., invoking) functions or procedures, which are sections of code executed within a program. The best-known language of this type is LISP (from List Processing), in which all computation is expressed as an application of a function to one or more "objects." Since LISP objects may be other functions as well as individual data items (variables, in mathematical terminology) or data structures, a programmer can create functions at the appropriate level of abstraction to solve the problem at hand. This feature has made LISP a popular language for artificial intelligence applications, although it has been somewhat superseded by logic programming languages such as Prolog (from Programming in Logic).
LISP (List Processing) can be used to manipulate symbols and lists rather than numeric data; it is often used in artificial-intelligence applications.
| They'll need a good reason to install and play with a Lisp.
that good reason is called "curiosity". a programmer who does not possess curiosity should not be allowed to write code for others. and if we cannot trust the curiosity of programmers, nothing will ever happen. however, the curious programmer should be able to find some _correct_ and _updated_ information about Lisp where he might be likely to look.
#\Erik -- those who do not know Lisp are doomed to reimplement it
In article <3052030527425...@naggum.no>, Erik Naggum <e...@naggum.no> wrote:
>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.
Of course, when using lisp "read" you lose comments and other formatting. So it's suitable, perhaps, for writing source-code munging tools which are expected to produce results for machine consumption only.
But if you want to write a source-code formatter like "indent", or a pretty printer, it's just about as difficult in Lisp as any other language, because of the non-syntactic stuff you have to deal with.
In article <y8ad8zjl9cr....@hertie.artcom.de>, Andreas Bogk <andr...@artcom.de> wrote:
>>>>>> "John" == John Brewer <jbre...@spyglass.com> writes:
> John> What if there was a standard native 3d library for Java? > John> Better yet, what if it used something like QuickDraw 3D > John> RAVE, so it could take advantage of hardware accelleration.
>Why is it that everyone is ffoles by Sun into thinking Java and Java >bytecode are identical? There's a Scheme to JavaBC compiler. Why is it >that no one can imagine an universal bytecode, that is equally >suitable for all languages?
> In article <y8ad8zjl9cr....@hertie.artcom.de>, > Andreas Bogk <andr...@artcom.de> wrote: > > >Why is it that everyone is ffoles by Sun into thinking Java and Java > >bytecode are identical? There's a Scheme to JavaBC compiler. Why is it > >that no one can imagine an universal bytecode, that is equally > >suitable for all languages? > I believe that would be something like UNCOL? ;)
I believe that uncol was rather designed as an Intermediate Representation format for compilers. That is, it was not designed with direct execution/interpretation in mind. Check ANDF (http://www.gr.osf.org/papers/gren_ri_andf_papers.html) for a new attempt at an universal IR.
Now for a universal bytecode, you should rather look at Omniware, a product of Colusa software that was bought in march by ... guess who... Microsoft! (http://www.w3.org/pub/Conferences/WWW4/Papers/165/). Colusa software still had a web page a few days ago (http://www.colusa.com/) with only a press release from Microsoft but it seems to have disappeared.
I don't know what Microsoft plans to do with this technology but I would rather use the Omniware virtual machine than Sun's java-biased one. Note that the Gwydion group at CMU was (is?) looking at Omniware to distribute platform-neutral Dylan programs. If Microsoft manages to release this VM without crippling it with its own technologies (COM/DCOM) it might kill the Java VM (but not Java or the Java API) and we would have a language-agnostic VM to play with.
| Of course, when using lisp "read" you lose comments and other | formatting.
a reader-macro bound to #\; may gobble up the the rest of the line and return it as a list (|;| "rest of line"). similarly for #|...|#. the formatting would be lost, but if it was generated by machine, it can be regenerated without loss, which is my second point...
| So it's suitable, perhaps, for writing source-code munging tools which | are expected to produce results for machine consumption only.
there is very little variation in formatting styles for Lisp compared to other languages. when there is variation, the pretty-printer can be customized by the same programmer that wrote the source code. I don't think a Lisp programmer would indent by hand, and even those that don't follow customary formatting styles modify the pretty-printer to suit their needs. in effect, the code that they write is already indented by machine.
| But if you want to write a source-code formatter like "indent", or a | pretty printer, it's just about as difficult in Lisp as any other | language, because of the non-syntactic stuff you have to deal with.
you really should take a look at GNU Emacs' lisp-mode and cc-mode. you betray ignorance of existing systems that implement "indent" for numerous languages and their relative sizes and complexity. cc-mode is at least an order of magnitude more complex than lisp-mode, including the support mechanisms.
#\Erik -- those who do not know Lisp are doomed to reimplement it
| From: Andreas Bogk <andr...@artcom.de> | Date: 19 Sep 1996 00:57:40 +0200 | | >>>>> "John" == John Brewer <jbre...@spyglass.com> writes: | | John> What if there was a standard native 3d library for Java? | John> Better yet, what if it used something like QuickDraw 3D | John> RAVE, so it could take advantage of hardware accelleration. | | Why is it that everyone is ffoles by Sun into thinking Java and Java | bytecode are identical? There's a Scheme to JavaBC compiler. Why is it | that no one can imagine an universal bytecode, that is equally | suitable for all languages? | | Andreas
There is one. It is called x86 binary code.
Advantages:
1. It is dense (often denser than Java byte codes). 2. It can be interpreted very quickly -- no JIT or anything else needed. :-) 3. There are compilers from virtually all languages to it. 4. It is already supported by most general purpose computers in the world, and the number and fraction keeps growing. 5. It has native interfaces to most OS and GUI libraries. :-)
Disadvantages:
No byte-code verifier.
Now, it's pretty clear to me that it is not inherently hard to establish constraints for x86 code that allow a Java-like code verifier to run, and to publish such constraints and get (some/many) compiler writers to abide by them than it is for them to retarget their compilers to Java byte codes.
I think Java and Java byte codes are a great thing. Too bad it was not done with Scheme, CL, or Dylan. However, in their present form Java byte codes are not really suitable as a target for many languages and applications, and it will be a while before performance and interoperability are at the level expected.
> 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.
on this note, an essay in Gabriel's new book[1] titled "The End of History and the Last Programming Language" may be of some interest: it tries to figure out why many languages go through a stagnation period, and how languages succeed. [he does not mention oodles of darpa money as a key to success, alas. :]
oz --- [1] Richard P. Gabriel Patterns of Software: Tales from the Software Community Oxford University Press, 1996 --- simplicity is only skin deep. | electric: o...@border.com - peter roosen-runge | or [416] 368 0074 x 294
Their is such a book it is called "Common Lisp: A Gentle Introduction to Symbolic Computation" by David Torskitey. What really drew me to LISP was LISP had no pointers but could write all the applications that you can wright in C/C++ with a uniform syntax (programs and data are Lists.) Trying to use pointers is like being disembowled : [ :) not too plesent --
+--------------- | 1970s C -- UNIX (ability to port an OS to new hardware just as number of | platforms started exploding). +---------------
You're off by a decade, and have causality backwards. Until circa 1980 the *only* platforms Unix ran on (in any quantity) were DEC PDP-11s and VAX-11/780. The number of platforms started exploding in 1981 *because* -- almost *ENTIRELY* because -- of the introduction of the AT&T Unix "Binary Sub-License, Limited Number of Users", which for the first time made (re)selling Unix affordable on small platforms.
At the same time, Unix was the *only* operating system for which you could "buy" (license) the source outright *and* which was written in a fairly portable language (the PCC compiler was the key to portability, not C syntax), thus meaning that tons of small start-ups [such as one I worked for] could save about a megabuck by "buying" Unix instead of writing an O/S.
A secondary driving force that caused the "explosion" to occur at first on Mc68000-based platforms was the availability "for free" (well, you had to show you'd already paid AT&T for a license) of a mostly-working 68k port from Steve Ward's group at MIT, including a PCC for the 68k that cross- compiled from a PDP-11 or VAX.
So... $25000 to AT&T for a V.32 license, a magtape and a plane ticket [and a copy of your AT&T license] to visit MIT, another magtape [& copy of your AT&T lic.] to get BSD 4.1a (or so), and you had (almost) everything you needed to be a "Unix systems vendor" on a J-random 68K platform.
*That's* why the number of platforms exploded: A change in Unix licensing, a portable compiler, and a handy reference port. Without them -- and especially without the licensing change, the "explosion" wouldn't have happened... then.
[It would have happened sooner or later, certainly, when some other O/S was available in source form with a portable compiler and reasonable licensing...]
-Rob
----- Rob Warnock, 7U-550 r...@sgi.com Silicon Graphics, Inc. http://reality.sgi.com/rpw3/ 2011 N. Shoreline Blvd. Phone: 415-933-1673 FAX: 415-933-0979 Mountain View, CA 94043 PP-ASEL-IA
In article <GJR.96Sep19152...@hplgr2.hpl.hp.com> g...@hpl.hp.com "Guillermo (Bill" writes:
> I think Java and Java byte codes are a great thing. Too bad it was > not done with Scheme, CL, or Dylan. However, in their present form > Java byte codes are not really suitable as a target for many languages > and applications, and it will be a while before performance and > interoperability are at the level expected.
I thought it _was_ being done with Java? I don't know how efficient is it, but I'm very glad the Kawa Scheme compiler is there. Perhaps it'll grow into big system with a friendly user interface, tools like an interface builder etc. I'm more concerned that such a compiler should exist than whether or not it can compete with the performance of MIT Scheme on any particular platform.
MIT Scheme is wonderful, and I love the compiler, but it's very far from the kind of Scheme I can easily use, mainly coz MIT Scheme for Windows, the platform I'm using, doesn't have a friendly user interface or an FFI yet. Nor can it produce stand-alone apps. It doesn't have to.
On the other hand, perhaps Kawa can. I'm hoping to try it at the weekend. Even if it doesn't do much at the moment, it could easily become something much more impressive in the relatively near future. MIT Scheme for Windows hasn't changed much in the last 3 years.
My point here, unlike in other posts (see below), is not that I'd like better Windows support, but that the JVM can give us a better cross-platform Scheme, on _every_ platform that's it's available for. Not just those platforms that support X Windows or whatever.
This is what I've been waiting about 15 years for. It has nothing to do with Lisp, but everything to do with writing and using portable software, and on as many platforms as possible. How else are you going to do it in Lisp? IMHO this is it.
Ok, I _have_ said this all before. ;-) Perhaps I'll shut up now! I've got some Java books to read... -- <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 <3052137838003...@naggum.no> e...@naggum.no "Erik Naggum" writes: > | There may be free Lisps for most (if not all) platforms, but you > | know how hard some programmers will resist new languages.
> some, perhaps, but the rush to C++ and Java showed me that programmers will > drop their "favorite" language in the blink of an eye and embrace something > new and "hot".
If there's good enough support for it, yes they will. A lot of people I know who are using Java are doing it with "workbenches" like Cafe. If there was a Lisp that looked like this, most Lisp people would hate it, but a lot of Lisp-haters might prefer it. We tend to prefer what we're used to, or so I suspect.
All the C++ compilers I've used or read about used similar enviroments, if that's the right word for them. A few were terrible, but no worse - exactly the same, in fact - as what that vendor had previously offered for C.
The keyword, I feel, is compromise. When you try a new language, you have to compromise by giving up a few habits you've used with other languages. Lisp systems tend to demand that we do a lot of things differently from C/C++. We see that as a feature, but many will see it as a bug. Smalltalk has the same problem.
It's _different_ from C++. Very different. That means we have to introduce the ideas gently - which Java appears to be doing.
> however, I think the problem is more likely that text book authors are > doing Lisp an enormous disfavor by mentioning it at all. recently, I had a > look at David Harel : Algorithmics : The Spirit of Computing, from 1992, > and its treatment of Lisp might as well have been written in 1962.
Yes, I'd expect Lisp in 1962 to be totally irrelevant to today's Lisps. There may possibly be some historical interest, but apart from that, very few of us should need to know about such relics. Just like Fortran 66! Today, Fortran programmers can (or should) be using F90. Modern Lisp programmers might easily be using CL or Scheme. Not the Lisps that came before these modern dialects. Even CL and Scheme reflect more than their age. Most non-Lispers won't understand the point of the syntax, and without that, the enture language looks silly. I know, semantics should come before syntax, but that's _not_ how most people look at Lisp. I know, coz I remember being in that position myself, in the early 80s.
The difference is that I gave in to my curiousity. Too many others will, as I've said before, just argue over the differences between C and Pascal. <sigh> _What_ differences? Compared to Lisp, these two languages are practically the same!
What hope does Lisp have, with its archaic syntax? I know it's useful, but is that enough to win even one percent of the hordes rushing to emrace Java? I think not. It's a syntax that _feels_ like something from 1962. The only reason I love it is that I've never felt comfortable with infix. Ok, I'm odd.
> and then there's the entries in Encyclopdia Britannica, which I have > mentioned here previously:
> LISP (List Processor) is a language that is powerful in manipulating > lists of data or symbols rather than processing numerical data. In > this sense, LISP is unique. It requires large memory space and, since > it is usually processed by an interpreter, is slow in executing > programs. LISP was developed in the late 1950s and early 1960s by a > group headed by John McCarthy, then a professor at the Massachusetts > Institute of Technology. At that time, LISP was radically different > from other languages, such as FORTRAN and ALGOL. Several versions have > been developed from the LISP 1.5 introduced by McCarthy; Common LISP, > released in 1984, is becoming the de facto standard of LISP.
> Other languages are functional, in the sense that programming is done > by calling (i.e., invoking) functions or procedures, which are sections > of code executed within a program. The best-known language of this > type is LISP (from List Processing), in which all computation is > expressed as an application of a function to one or more "objects." > Since LISP objects may be other functions as well as individual data > items (variables, in mathematical terminology) or data structures, a > programmer can create functions at the appropriate level of abstraction > to solve the problem at hand. This feature has made LISP a popular > language for artificial intelligence applications, although it has been > somewhat superseded by logic programming languages such as Prolog (from > Programming in Logic).
> LISP (List Processing) can be used to manipulate symbols and lists > rather than numeric data; it is often used in artificial-intelligence > applications.
Yes, even Prolog has a more sophisticated parser than Lisp. ;-)
> | They'll need a good reason to install and play with a Lisp.
> that good reason is called "curiosity". a programmer who does not possess > curiosity should not be allowed to write code for others. and if we cannot > trust the curiosity of programmers, nothing will ever happen. however, the > curious programmer should be able to find some _correct_ and _updated_ > information about Lisp where he might be likely to look.
I agree that curosity is vital, but there's a very short supply of it. Plus, advertising and marketting people are working to make damn sure that any curious programmers discover C++, Java, or whatever the vast piles of money thrown their way by MS etc.
Where's the advertsing to promote Lisp? Which mainstream programming mags can it be found in? I'd like to know so I can buy those mags. It's an informatation war. I like Richard Dawkins idea of memes. The Lisp memes are currently heavily outnumbered by the C++ and Java memes being spread by all those adverts, junk mail, etc. I don't remember receiving _any_ junk mail for Lisp products that I didn't explicitly ask for, and yet piles of paper covered in C++ and Java memes go into my bin almost daily.
BTW, the uk.comp.lang.lisp newsgroup may soon be removed, due to a lack of posts for the last 3 months. <sigh> -- <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 <3241A46F.3...@cs.ucla.edu> egour...@cs.ucla.edu "Eric Gouriou" writes:
> Now for a universal bytecode, you should rather look at Omniware, a > product of > Colusa software that was bought in march by ... guess who... Microsoft! > (http://www.w3.org/pub/Conferences/WWW4/Papers/165/). Colusa software > still > had a web page a few days ago (http://www.colusa.com/) with only a press > release > from Microsoft but it seems to have disappeared.
There's also Taos. See <URL:http://www/taos.co.uk> for details. It's a distributed OS that uses 'VP' code.
I'd love it if there was a Scheme to VP compiler. Still, a Scheme to C compiler should do just as well, for now. ;) -- <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
| I agree that curiosity is vital, but there's a very short supply of it.
if you actually think this is true, it would explain why you have so many problems as seem to have. if there is _anything_ that can be used to sort a programmer from your random joe, it is a monumentally higher level of curiosity. people who aren't curious _enough_ don't pursue programming.
| BTW, the uk.comp.lang.lisp newsgroup may soon be removed, due to a lack | of posts for the last 3 months. <sigh>
I removed it from the Newsgroups line.
"Cyber Surfer" (what a moronic net name!), whatever your real persona is like, please consider whether the only relevant issue in this world is popularity. please consider whether anything of importance is shared by the masses. start with your own personal convictions, ideas, likes and dislikes. would you _want_ them to be in the middle of mainstream? take political ideas -- would you want the political landscape to be _flat_? take practical politics -- would you want the average joe to decide your country's military strategy?
and please consider quitting that incessant whining of yours. some of us write ten times as many lines of Common Lisp code for every one of your lines of posted whining. if you don't hear about it, it may well be because any serious Lisper is not interested in suffering your endless list of "buts" and your incredible negativism. maybe Lisp just isn't for you, but by now it is bordering on the bloody obvious that it is not Lisp's fault or even related to Lisp.
#\Erik -- those who do not know Lisp are doomed to reimplement it
In article <3052297391247...@naggum.no> e...@naggum.no "Erik Naggum" writes: > if you actually think this is true, it would explain why you have so many > problems as seem to have. if there is _anything_ that can be used to sort > a programmer from your random joe, it is a monumentally higher level of > curiosity. people who aren't curious _enough_ don't pursue programming.
Perhaps we could say that there're relative degrees of curiousity? I'm not sure. I'm told that there are "9 to 5" programmers, and they sound very much like programmers without much, if any, curiousity.
For those of us who're definitely not "9 to 5" programmers, it may simply depend on how much pressure a programmer is under. How far should a programmer look? As I've said, there's massive amounts of advertising offering tools that use C++, and a very significant part of the software industry saying that software should be written in C/C++. Even when this is not being said, it's being implied by the lack of coverage of alternative languages in the mainstream mags.
I can remember a time when mainstream magazines would write about Lisp and even more esoteric languages. Today, it's more like to be Perl and Java. If you read Lisp Pointers or Forth Dimensions, you'll find plenty of alternate memes, but I've never seen these publications on newstands.
I'd love this to change. That's why my favourite developers mag (for Windows developers, anyway) is Windows Tech Journal. This is the mag which MS withdrew their advertising from, just coz the editor has a free mind, and doesn't wish to play by the biased rules that MS prefer. The editor himself reviewed ACL for Windows, favourably, so this is not somebody who thinks that Lisp sucks.
> | BTW, the uk.comp.lang.lisp newsgroup may soon be removed, due to a lack > | of posts for the last 3 months. <sigh>
> I removed it from the Newsgroups line.
RIP uk.comp.lang.lisp.
> "Cyber Surfer" (what a moronic net name!), whatever your real persona is > like, please consider whether the only relevant issue in this world is > popularity. please consider whether anything of importance is shared by > the masses. start with your own personal convictions, ideas, likes and > dislikes. would you _want_ them to be in the middle of mainstream? take > political ideas -- would you want the political landscape to be _flat_? > take practical politics -- would you want the average joe to decide your > country's military strategy?
> and please consider quitting that incessant whining of yours. some of us > write ten times as many lines of Common Lisp code for every one of your > lines of posted whining. if you don't hear about it, it may well be > because any serious Lisper is not interested in suffering your endless list > of "buts" and your incredible negativism. maybe Lisp just isn't for you, > but by now it is bordering on the bloody obvious that it is not Lisp's > fault or even related to Lisp.
The reason I don't write much Lisp code is because I don't have the time - I'm too busy writing bloody C++ code. I'm not alone, either.
You're lucky that you can afford to use Lisp, If you think that it's just a matter of choice for the rest of us, then you're either blind or a stubborn elitist. The hordes of C++ programmers use this monstrosity because _they can_. You use Lisp because _you can_. I'd like to join you, but I'm damn lucky to have the job I'm in today, so it's just not an option. Yet.
You can call this whining if you like, but can you show that there isn't a huge demand for C++ programmers? Most people I know would think you're daft if you're using Lisp. I'd say they think this coz they're paid to code in C/C++. Memes. Perhaps you think what you do because you're paid to program in Lisp, but I don't know that. I _agree_ with you, but it makes no difference to the people with C++ memes in their heads.
Lisp _is_ for me, but only when I'm programming in my own time. I'd like to change that. Do you have anything contructive to offer? Does anybody? I'm serious, You've done nothing but convince me that my fears were not groundless.
Thanks. This hurts, but it's important to know these things. Now I have even less hope than before, but more determination to write my own Lisp compiler. It's a way of saying fuck you all - esp MS and all the bastards who insist we use C++. I've hated these people for years, for killing my dreams.
Of course, I can write and use my own compilers, and I've been doing it for some time now, but I want to share these things. I want to share the _memes_. Other people can write far better compilers than I can - but they won't, unless have the Lisp memes in their heads. That's my vision - not to make more money, but to make programming more fun and satisfying. That'll make _somebody_ more money, but I don't care who it is, so long as it happens. I don't believe it'll happen while a few elists insist that there's no problem, that the memes are only for the select few who can appreciate them.
I believe that a great deal more of us could appreciate them, if we're given the chance. _If_ we're given the chance.
Hopefully, this is more of a rant than a whine. I can easily rant about the virtues of Lisp, if anybody will listen. ;-) At least you have some idea what I'm talking about. -- <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
Check the viewpoint of the Garnet developer's in the Garnet faq. Their consensus was that the C++ code (at least with the compilers in use on the platforms they tested on) was simply faster for a given programming task than the lisp code. (Incidentally, there is a patch on the clisp ftp site for improving performance with garnet). You only have to program it a few times (development plus maintenance). Your customers have to use it a million times.
I like lisp for the lack of syntactic idiosyncrasies. It may look strange to the newbie on first sight, but one can learn it faster than a C-like language, because there are less syntactic details and context-dependent semantic gotchas to remember. A few simple constructs, and you can build anything with it (though I wouldn't use it for systems code that runs directly on the metal).
But I don't expect it to outperform C/C++ or Ada or Fortran or Prolog; I just expect it to be working sooner with less of my time spent to get it debugged. Lisp makes it easy to manage scope.
But if I have a commercial product for ram- and cpu-limited hardware, my customers don't care how difficult or expensive the development process is for me. They only look at the price tag and the job they want done. If my competitor writes a program in C/C++ that does the same thing correctly three times faster for the same price, that is what they will buy.
Lisp's commercial strength seems to be in complex code that would take a prohibitively long time to develop and debug in procedural languages, running on hardware well beyond the average desktop (with doubtless some exceptions). As the average desktop gets faster, lisp may find a resurgence of popularity in commercial programming environments. Fast enough for the customer is fast enough, and programming labor costs should be lower than for a C++ shop.
But that only applies to desktops as they are now. If you look at machines like "network computers", the perspective is going to be similar to that for embedded systems programming. Ram/rom is part of unit cost, and lisp in most implementations makes more luxurious use of than other languages that can get the job done.
In article <3052297391247...@naggum.no>, e...@naggum.no says...
>and please consider quitting that incessant whining of yours. some of us >write ten times as many lines of Common Lisp code for every one of your >lines of posted whining. if you don't hear about it, it may well be >because any serious Lisper is not interested in suffering your endless list >of "buts" and your incredible negativism. maybe Lisp just isn't for you, >but by now it is bordering on the bloody obvious that it is not Lisp's >fault or even related to Lisp.
So sorry dude, but your compliants are far more annoying than his. I know I don't use Lisp or Smalltalk or any other real language for 99% of the code I put out; unfortunatly I don't have a whole lot of choice in the matter. I keep bitching for a _real_ windoze implementation. Now, if I had the money and time, I'd buy a source license to Medley & do a real win32 port of the best environment I've used. But the closest I'll get to that is my copy of Allen's "Anatomy of Lisp"...So chill. I'm glad you can use Lisp for your real work. I've got Visual Basic & Oracle's Developer 2000; yeah, freaking, thrill...so pardon me if I'm more sensitive to CS's position than yours.
>#\Erik >-- >those who do not know Lisp are doomed to reimplement it
| I'm glad you can use Lisp for your real work. I've got Visual Basic & | Oracle's Developer 2000; yeah, freaking, thrill...so pardon me if I'm | more sensitive to CS's position than yours.
(Geez.) I first saw The Little Lisper in 1978 or so, and I found it about twice as neat and cool as the world now finds "Java". I acquired a new way of thinking about problems, instead of yearning for the unachievable. In practical terms, what I came away with was very close to what Paul Graham writes about his books on Common Lisp: build the language up towards your problem, and build the solution in that (new) language; I have implemented numerous tiny, application-specific languages over the years, both to be able to think better, but also to simplify the often boring and uninspiring programming tasks. To me, one program's input is just another program's output, unless I care to feed it by hand, and often I don't, and whether that program is the compiler or an application program is irrelevant.
If you hate your language of "choice" and love Lisp, write tools in Lisp to write your programs for you in that language. Nobody ever forced you to do all that programming as manual labor, anyway, did they? Incidentally, that was how I _started_ programming in Lisp for real, three years ago, when I was forced to use C++ (an abomination if there ever is one). The Lisp side of my work just grew until I could stop caring about _stupid_ issues in C++ -- my C++-code "generator" took care of them, and then I could drop C++.
Over the years since 1978, I have used Lisp systems that were not usable for delivery, for obvious reasons such as being too expensive memory- or money-wise. I chose languages that could deliver, but I never lost sight of the idea that a _program_ is just another form of _data_. Finally, when I got a real computer, several Lisp systems were available, and some of them even produce small executables (e.g., Wade Hennessey's WCL). I began using GNU Emacs for real (i.e., programming GNU Emacs to do what I did manually), and have added a function or two a day to my C-generator that is supposed to write C that works on all systems by virtue of being compiled into C on that system according to the system's configuration parameters. (This as opposed to writing for all systems at once, which one has to do with GNU `configure', as smart as that solution is.)
What I see from those who whine about the tools they can use are people who has been explained all the rules of chess, but who complains that it is a stupid game because one cannot win in one, big move. Failure to appreciate that many moves are necessary, indeed that the beauty of the game is the combinatory effect of the moves, seems to be the underlying cause of a large number of ills in the computer world, including the need to use only one tool or language to generate "small executables". And, yes, I think that's stupid, and no, I don't think I'm a genius -- I was probably just lucky enough not to be "destroyed" by excessively stupid computers when I was young. (The first real computer I used was a DECSYSTEM-10 running TOPS-10, and I wrote table-driven programs and interpreters in MACRO-10, too. Come to think of it, the MACRO system in MACRO-10 may also have had a serious influence on my later programming style.) However, I doubt that "first exposure" has that much power of people's perceptions, and _luck_ shouldn't play that big a part in people's life when the experiences are communicable if only people would listen.
Put it another way, learning about Lisp, and then learning Lisp, was like reading a novel with grand, heroic characters who solved big problems with efficient, effective weapons, strategies, and skills. From many kinds of art, I can see an image of how the world _could_ be and in a sense _should_ be that I can carry into a world filled with violence, pestilence, death, manual labor, and taxes, and set a meta-goal for myself: realizing the best kinds of of goals I should set for myself.
Still, I get seriosly annoyed when people complain for months on end about some problem that I have been able to solve for myself, and others seem to have solved for themselves. Maybe is there no market for these kinds of programming tools, possibly because they are so personalized, but that does most emphatically _not_ mean that the world is horrible place dominated by Bill Gates, with him dictating people's every move.
#\Erik -- those who do not know Lisp are doomed to reimplement it
In article <Pine.SUN.3.95.960922111121.9319B-100...@eskimo.com> cgw...@eskimo.com "Clayton Weaver" writes:
> Check the viewpoint of the Garnet developer's in the Garnet faq. Their > consensus was that the C++ code (at least with the compilers in use on the > platforms they tested on) was simply faster for a given programming task > than the lisp code. (Incidentally, there is a patch on the clisp ftp site > for improving performance with garnet). You only have to program it a few > times (development plus maintenance). Your customers have to use it a > million times.
I've never looked closely enough at Garnet to discover a performance difference between C++ and Lisp. In fact, performance differences between these two languages don't even remotely interest me. If I could use Lisp as an alternative to C++, then I might.
As for Garnet, I suspect I might easily prefer it to MFC. ;-)
> I like lisp for the lack of syntactic idiosyncrasies. It may look strange > to the newbie on first sight, but one can learn it faster than a C-like > language, because there are less syntactic details and context-dependent > semantic gotchas to remember. A few simple constructs, and you can build > anything with it (though I wouldn't use it for systems code that runs > directly on the metal).
There's no need to sell me the Lisp meme - I've had it for years. Even before I discovered Lisp, I was looking for something very much like it. I just didn't know that Lisp was it.
> But I don't expect it to outperform C/C++ or Ada or Fortran or Prolog; I > just expect it to be working sooner with less of my time spent to get it > debugged. Lisp makes it easy to manage scope.
Yep, I know. I love it. That's why I'm so frustrated.
BTW, is there some CL code for doing FTP for ACL for Windows? I'm don't know if ANSI CL has any support for sockets, but that might help make some CL FTP code portable enough that I can use use it without having to understand it (and edit it) first.
Meanwhile, Perl does exactly what I want, so that's what I'm using today. It makes me sick, but it's there and it works. Today. If I had the ActiveX SDK, I might be using C/C++ instead. Perhaps I'm lucky that I don't, but I already have some C code to do most of what I want, except for the FTP bit. That's why I'm rewritting it in Perl instead of C or even Lisp.
Obviously, I should just spend the $2500. That's a lot of money for just one utility, but I'm sure there'll be others. It'd be great fun to say, "Yeah, you can do it like that, but when _I_ upload loads of files, I can do it using this neat util I wrote in Lisp. Why Lisp? Coz it was dead easy." That doesn't explain the high price, but I don't have to mention that, do I?
I just wonder, tho. If a colleague then wants to use my ftp utility, does that count as a commercial application? This is only an issue for some development systems, but I wonder if, let's say, I'm doing this in a few years time, using a system like Gwydion that makes a distinction between commercial use and non-commercial use (like a personal utility?), would that count? It wouldn't be for a client, exactly. Not unless the file upload was done for a client, anyway.
That may be why I'd have to pay for ACL myself. Unless the Lite version includes sockets, I can't write the util. However, I can do it in Java or Perl _today_, for "free".
What would you recommend that I do? I know I can do it in Perl - I'm doing it right now. I bet I could do it in Java, eventually. Someday I'll be able to do it in Lisp, like when I get comfortable enough with sockets to translate the Perl code I've got into CL. Right now, that would demand too much of my time, which is supposed to be devoted to C coding at the moment.
This is not an unusual choice. Programmers have to make choices like it everyday. It's not always easy. While I might be able to take a risk, in my own time, I can't do it with somebody else's time. That's not what they want. We all have to use our judgement in these matters.
> But if I have a commercial product for ram- and cpu-limited hardware, my > customers don't care how difficult or expensive the development process is > for me. They only look at the price tag and the job they want done. If my > competitor writes a program in C/C++ that does the same thing correctly > three times faster for the same price, that is what they will buy.
Sadly, this is true. Sometimes there's so much misinformation floating about that a client might be forgiven for feeling that C++ is "safe", so they should buy that produce and not the one written using some "unknown" tool(s). Lisp isn't "unknown", but it's not as well known as C++. Also, some of the other tools needed for an app might not even be designed with Lisp in mind. This shouldn't be a problem, but it can be. MS are very good at arranging that kind of thing. Hence the Anti Trust issue.
Perhaps the answer is to not use MS products, but if that's what the client wants, we dares to argue with them? Only those who can choose their clients.
> Lisp's commercial strength seems to be in complex code that would take a > prohibitively long time to develop and debug in procedural languages, > running on hardware well beyond the average desktop (with doubtless some > exceptions). As the average desktop gets faster, lisp may find a > resurgence of popularity in commercial programming environments. Fast > enough for the customer is fast enough, and programming labor costs should > be lower than for a C++ shop.
That's the kind of software I'd love to be writting. We're getting there. If ACL for Windows supported OCX controls, then I might be using it today, if only for demos. Finding the right app for Lisp isn't easy when you're doing multimedia, but I'm looking for it. Perhaps the answer is a totally different app domain, since I have no direct contact with our clients (haha, a programmer? talking to clients?), I'm not sure what they might need.
I would dearly love to do a DirectX demo using ACL for Windows. The only way I can see it being done today would be to call DirectX indirectly, via functions in a DLL. When I get the time, the DirectX SDK, upgrade the OS on my machine so it can use it, and a couple of other things, then I may begin to work on it.
> But that only applies to desktops as they are now. If you look at machines > like "network computers", the perspective is going to be similar to that > for embedded systems programming. Ram/rom is part of unit cost, and lisp > in most implementations makes more luxurious use of than other languages > that can get the job done.
Yep. I recently compared the code size of the final image produced by my Scheme to C compiler, with the image size of a very simple C program. The difference was barely one that you could measure! That's one advantage of using Win32 and VC++ - there's a hell of lot of overhead! I serious expect to be able to take my toy compiler, when it gets a little more capable, and its mark/sweep GC, and use it write multimedia apps that nobody can tell came from a Lisp compiler. What people should notice is what the app _does_, not which tools were used to create it. Strangely, that might be easier to do in a multimedia app... -- <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
> Check the viewpoint of the Garnet developer's in the Garnet faq. Their > consensus was that the C++ code (at least with the compilers in use on the > platforms they tested on) was simply faster for a given programming task > than the lisp code.
My second implementations of a given system can be faster, too. This is no surprise to me.
Unless we see a better comparision with more data I can't say that much about it.
> (Incidentally, there is a patch on the clisp ftp site > for improving performance with garnet).
CLISP is not what I have in mind when I think of speed.
> You only have to program it a few > times (development plus maintenance). Your customers have to use it a > million times.
You use it daily. You may have to maintain it many many years. Much of the cost of software is maintenance.
> But I don't expect it to outperform C/C++ or Ada or Fortran or Prolog;
Why not? There are enough examples where people showed that certain Lisp implementations can generate fast code, comparable to C++ and Fortran.
Lisp is a family of languages with many diverse strengths and weaknesses. I won't expect the tiny interpreter (design as an extension language) to have the same performance characteristics than a compiler-based implementation doing type inference.
Btw., if you have a complaint about the speed of MCL, let the developers know - write to tune-...@digitool.com and describe your problem.
> But if I have a commercial product for ram- and cpu-limited hardware,
These are two constraints: few ram and slow processor. Lisp already has found uses in this field. As I indicated in a previous post the programming language for the HP calculator took a lot of the ideas of Lisp. The Newton has also a runtime system with Lisp-like semantics (typed data, functions and closures, objects, GC, symbols, ...). There are more examples. These were specially designed with the memory and speed constraints in mind.
> competitor writes a program in C/C++ that does the same thing correctly > three times faster for the same price, that is what they will buy.
What's a price? The price to develop it? To make it run in a way users may think the software is correct? To prove correctness? To change the software to make it run correct? To enhance the software? To redesign the software? To port the software? The price to understand the source two years later? The price to ship updates or new versions?
Which of these price factors do you or your customers calculate?
> Lisp's commercial strength seems to be in complex code that would take a > prohibitively long time to develop and debug in procedural languages, > running on hardware well beyond the average desktop (with doubtless some > exceptions).
I strongly doubt that this is the only strength. Personally I was able to do useful work in Lisp on 68k machines which are slow by today's standards. Look at the Lisp machines from Xerox. Very nice. Tiny by today's standards. As I already said, Lisp is diverse. We have Lisp for embedded systems, extension languages, portable implementations, Lisp-based operating systems, expert-system shells, MPP-computers, ... Each of these has very different space/speed/... constraints.
> for embedded systems programming. Ram/rom is part of unit cost, and lisp > in most implementations
Lisp has already being used for small embedded systems. For an newer system see the "L" system by ISR.
> makes more luxurious use of than other languages > that can get the job done.
Java and the Java VM are strongly tied to each other. This is what it makes a **bad** candidate for a cross platform architecture supporting more than Java. Sure if you have the whole Java system in ROM it looks like it is small. Still the Newton OS can work with even tougher memory constraints (the Newton's ROM is larger because it already has more functionality in it) due to its prototype-based object system.
