* Guillermo J. Rozas | I would love to see a good Lisp environment for Windows that allowed | complete interoperability with arbitrary libraries. Alas, I don't expect | one soon.
well, _I_ got one delivered to a client of mine just last week, but until then, I could have said "I expect one soon". quit whining and do some research into what is available in the market _today_.
shit, I feel like a marketing person. "look what you made me do."
* Harley Davis | I've looked over the sources of Ilog Talk and I've found exactly the | following uses of eval: | | * Evaluate forms in the debugger. | * Evaluate forms in the top-level interactive loop. | * Evaluate forms when using the built-in test file system. | * Evaluate forms coming from Emacs.
does that mean that Ilog Talk does not support read-time evaluation as in the sharp-dot reader macro?
In article <5lu3phkgc6....@daffy.systemsx.cs.yale.edu>, Stefan Monnier <monn...@cs.yale.edu> wrote:
> pe...@nmti.com (Peter da Silva) writes: > > I've published this stuff on the net, but nobody cares. I've snarfed > > indefinite length arithmetic from the net, when I had a need for it, but > > now I can't find it. And it's vanished into the great write-only world > How about libgmp, available on any GNU site ?
That's not the one I was using, but cool. -- UNIX Koan: Karels typed in his password and said, "To call this a PC is to deny its nature, to call this a workstation denies its substance. What is it?" `-_-' `-_-' `-_-' `-_-' Har du kramat din varg, idag? `-_-' `-_-' `-_-' `-_-' <virus> :ex:?^.*[e]x:?s/.*\( ?^\)[.]/x:\1./|s/^/:e/|.w!>>~/.signature: </virus>
Sorry to reply to one of my own posts, but I have some info to add:
In article <850944313...@wildcard.demon.co.uk> cyber_sur...@wildcard.demon.co.uk "Cyber Surfer" writes:
> Possibly some people (e.g MS) have biased things to make C++ > look more attractive to developers. Possibly this may someday > change - see the MS Research website for details. I seem to > recall Henry Baker refering to an MS paper about "Lisp style" > macro processing for C++, and I suspect that he was thinking > of the MSR work, with some CS people at a certain Texas > university, called "Intentional Programming". This could > eventually introduce a lot of C++ programmers to some of the > ideas supposedly unique to languages like Lisp, e.g meta > linguistic tools.
I may have found "Intentional Programming" whilst looking for that paper on macros, but that probably wasn't the paper that Henry Baker was refering to. Here's a more likely candidate:
Programmable Syntax Macros Daniel Weise and Roger Crew PLDI '93
Abstract: Lisp has shown that a programmable syntax macro system acts as an adjunct to the compiler that gives the programmer important and powerful abstraction facilities not provided by the language. Unlike simple token substitution macros, such as are provided by CPP (the C preprocessor), syntax macros operate on Abstract Syntax Trees (ASTs). Programmable syntax macro systems have not yet been developed for syntactically rich languages such as C because rich concrete syntax requires the manual construction of syntactically valid program fragments, which is a tedious, difficult, and error prone process. Also, using two languages, one for writing the program, and one for writing macros, is another source of complexity. This research solves these problems by having the macro language be a minimal extension of the programming language, by introducing explicit code template operators into the macro language, and by using a type system to guarantee, at macro definition time, that all macros and macro functions only produce syntactically valid program fragments. The code template operators make the language context sensitive, which requires changes to the parser. The parser must perform type analysis in order to parse macro definitions, or to parse user code that invokes macros.
Anyone who thinks that MS are the "Evil Empire" and are doing "no good at all" should look at the MS Research site. Papers like this one might even make C more appealing to those who like to knock it - but I don't expect miracles. ;-)
Followup-To: comp.lang.lisp (this is getting _really_ offtopic!) -- <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 <GJR.96Dec20105...@hplgr2.hpl.hp.com> g...@hpl.hp.com "Guillermo (Bill" writes:
> I would love to see a good Lisp environment for Windows that allowed > complete interoperability with arbitrary libraries. Alas, I don't > expect one soon.
Yes, it makes many of those APIs that MS are so busy creating very hard to use. Look at the development tools that MS sell, see what enables them to use the various APIs, then add those same features to Lisp. If you have a C++ compiler, as almost any serious Windows develop _must_ (MS assume this!), then you can package an API, or the bits of it that you need, into an OLE class. In some cases, like ActiveX, this has already been done.
> The traditional problem with making OS tools and Lisp cooperate does > not have to do that much with Lisp per-se as with memory management. > This problem also plagues ML and could plague Java.
I'm not so sure of this. Somehow VB manages ok. It could be that VB is written in VC++ (and some error msgs suggest this), but I still wonder what makes it so easy for VB, but so hard for Lisp (e.g. ACL for Windows). Can it really be so hard to manage "alien" objects in Lisp?
> You can have a version of Lisp without automatic memory management > (i.e. garbage collection) -- early MIT Lisp machines effectively > worked that way, but it is assumed by most Lisp programmers that > memory management is automatic at least to a first approximation.
There are, I believe, Lisps that can cope with "alien" objects. For Unix, at least. So I guess it's been done.
> The OS, and even more importantly, the libraries that programmers > often want to reuse, make their own assumptions about memory > management, often using explicit allocation and deallocation > (e.g. malloc and free). Furthermore, they sometimes cache pointers to > objects passed as parameters (e.g. strtok, callback functions and > data).
This is true. A lot of assumptions can be made by the "OS" - in the case of Windows, it's sometimes hard to distinguish between the OS and an API _added_ to the OS, when you know that MS may well be shipping the DLLs with the next OS release. Anyway, the problem is not the distribution of the DLLs, but the assumptions made about the language that'll use them.
MS plan to make the entire Windows (that's Win32, of course) API (err, APIs?) OLE based. That implies C++, VB, and any other tool that can use OLE. No Lisp that I know of can do this, so far, but I'm hoping that will change.
> The two _styles_ do not mix well. The best attempts to marry them are > conservative collectors but they are not a complete solution.
Hmm. Smalltalk MT can, I believe, use OLE and OCX. Why not Lisp?
> The traditional answer from the Lisp community is (exaggerating quite > a bit): "We don't care about the other libraries, we'll just > reimplement what's useful and right, and do it better". Of course, > this is shortsighted since it forces the Lisp community to reinvent > the wheel (e.g. CLX).
I remember a major Lisp vendor, only a few years ago, stating that they couldn't support shared libraries, as they couldn't support them on every platform. I hope that attitude has changed! Shared libraries are a little more popular than they used to be, even in the Unix world.
BTW, many Lisp vendors now support CLIM, not CLX. As I understand it, CLX is no longer a part of X Windows. CLIM, the Common Lisp Interface Manager, is a proprietry alternative.
> The traditional answer from the OS and library writers is > (exaggerating only a bit): "Why should we care about you Lispers? > there aren't enough of you". Of course, this is unfortunate since it > is a catch-22 situation.
Hence the death of CLX? Possibly. I wouldn't know, as I don't use X Windows, never mind CLX (historical accident, rather than choice).
> The situation, fortunately, may be changing although perhaps too late > for Lisp.
Too slowly, perhaps. I dunno about "too late".
> Java has automatic memory management of the same sort that Lisp has, > and to make it reliable and efficient, the same sort of constraints in > interoperability appear.
Take a look at Dylan. Dispite reports of Dylan's death (probably due to some bitter Mac developers misinforming a journalist), it's still alive and growing stronger. Dylan is closer to the kind of Lisp that most people want than the kind of Lisp that Erik Naggom uses. Happily, Erik and co will be able to continue to use the "traditional" Lisp, while the rest of us get what we want, too.
> Because the OS and library writers care about Java (or at least they > pay lip service to it), they are likely to accommodate its memory > management needs (e.g. enforcing a discipline of using "handles"), in > the process accommodating Lisp, ML, and perhaps others.
Dylan should be able to cope just as well. Ask Harlequin what DylanWorks can do, today. It's not available yet, but apparantly they've demonstrated what they've got so far, and in public. It sounds like intergration with the "OS" way of doing things will be no problem.
> I expect that if Java lives up to its promise, and Java-compatible > native libraries start appearing, a Lisp (or ML) implementation will > be able to make use of them very easily.
CMU are also working on a Dylan implementation. While I'll be interested to see what can be done with Java, Dylan is much closer to what I'm looking for. This shouldn't be suprising, considering how it was designed - by some Lisp programmers working for _Apple_. I think Apple have (or had) a much better idea of what most developers want today than the designers of Common Lisp, 15 years ago, I'm not knocking CL, but it does show its age.
Dylan and Java, on the other hand, are rather more _modern_ languages. How well they address the needs of modern developers has yet to be seen, but I think we can afford to be be patient. Future generations are relying on us. -- <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 <Pine.OSF.3.95.961220165746.30168G-100...@internet.oit.edu> kegl...@OIT.EDU "Dennis Kegley" writes:
> Someone once said, and I misquote, "Genius is 99% persperation and 1% > intelligence." or someting like that. I've been working on something for > two years. When I started, I looked at the parts and languages available > and chose what worked for me. I'm going to *CREATE* my customers(I hope), > so they don't have anything to do with it. **I** saw the problem, did the > market research, and will solve the problem with what works.
If I were working alone, I might have that kind of freedom. Many developers I know are in a similar position. It's those who can choose their tools that interest me most. It was my interest in _creating_ tools that lead me to Lisp.
For a Windows developer, you can be dazzled by the quality of "off the shelf" tools that are available. This is an area of programming where Lisp has less to offer, as a language. Too much of Windows development is little more than "gluing" other people's tools together, to form an app that does what a client asks for. The "creativity" is in seeing how two or more tools can be combined to form an app.
> This is an another example of how solutions, tools, and problems meet for > the sake of excitement and making the world a better place.
Yep. And if you can find a combinatotion of tools that nobody else has thought of, or if you manage to glue them together in a way that few others can do, then perhaps you have an edge. It might not be exciting to hardcore hackers, coz it'll be too "easy", but I can promise you that if you get it right, then you'll knock the socks of your clients.
> Erik Naggum, who wrote about his may years of struggle and belief in his > choice of solutions and tools he chose to meet his **CUSTOMER'S** problems > is another example.
I have a lot of respect for Erik, dispite our disagreements on one or two issues. I think we're just writing different kinds of software, almost certainly for different kinds of clients.
> To cyber-surfer, if you are solving problems for people and making the > world a better and more rewarding place to hang out, (That --*IS*-- > the definition of an engineer or programmer), then arguing about what > everybody should use probably takes you away from the excitement of > helping the world and solving problems. Use what you like and do some good > things. Find some problems and solve them, if the problems don't come to > you.
Hopfully, I've been making some constructive comments. If they only look like arguments, then I've possibly not made my points clear enough. Possibly the fault lies elsewhere, but I can't say. However, please don't assume that the strength of Erik's opposition to my point of view implies any hostility between us.
> I hope all of us like what we're doing and that we would all share > information that will help us especially talented and creative types do > our thing.
Indeed. I'm getting a massive kick out of what I'm doing! I'm expecting it to get even better, in the New Year. I hope that everyone reading this has as much, if not more, good fortune! -- <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 think what made BASIC key for computing was the fact that it was >>interpreted and interactive. Supercomputers and parallel systems need >>more interpreters, to allow people to prototype ideas (George Michael >>would disagree with me). APL was also interpreted. But we have to try
>Well, as one gentleman at the Applied Physics Lab pointed out to me >back in the Dark Ages (when Cray's Eastern region was thinking about >writing a Cray APL interpreter in order to secure a sale there), if you're >doing enough computation in each statement the overhead of interpretation is >just noise.
The above statement is not always true, due to the nature of commercial APL interpreters. In an expression such as "A+ B times C", where A,B,C are arrays, the usual form of interpretation is a naive, one primitive at a time method. Thus, the interpreter would multiply (element by element) B times C, producing an array-valued temp T1. Then the interpreter would perform "A+T1" (element by element). Although the syntax analysis, conformability checking, semantic analysis, and storage management overheads are indeed amortized over the entire arrays, the array-valued temps can kill your performance. IBM's APL2 interpreter, when executed on a 3090-class machine running the vector facility, WILL effectively loop fuse these operations, with substantial performance improvement. Likewise, APEX -- my APL compiler -- generates loop-fused code for such expressions, producing execution rates than can exceed those of naive execution by an order of magnitude or more.
I do not believe any of the early supercomputer interpreters used such techniques.
>Since then, I've often thought that APL is the most natural language for >vector computers (and perhaps parallel ones, as well).
Me, too. Some of my preliminary measurements of compiled APL on parallel systems tend to confirm this. However, execution speed that is competitive with FORTRAN requires fairly sophisticated compilation and analysis techniques, to eliminate superfluous array generation such as the above, transpositions, reversals, and subarray selection operations.
cyber_sur...@wildcard.demon.co.uk wrote: > Take a look at Dylan. Dispite reports of Dylan's death (probably > due to some bitter Mac developers misinforming a journalist), it's > still alive and growing stronger.
So strong, that it is almost completely invisible and has almost no influence on developer choices at all. Where is Dylan??? Apple Dylan is not really supported (Digitool can only provide bug fixes), CMU hasn't delivered anything exciting yet, Harlequin has not released anything.
But it is getting stronger everyday, huh? Until someone releases something useful, I'll write my code in Common Lisp or maybe even Scheme.
> BTW, many Lisp vendors now support CLIM, not CLX. As I understand it, > CLX is no longer a part of X Windows. CLIM, the Common Lisp Interface > Manager, is a proprietry alternative.
> > The traditional answer from the OS and library writers is > > (exaggerating only a bit): "Why should we care about you Lispers? > > there aren't enough of you". Of course, this is unfortunate since it > > is a catch-22 situation.
> Hence the death of CLX? Possibly. I wouldn't know, as I don't use > X Windows, never mind CLX (historical accident, rather than choice).
Sorry, but you don't seem to know a thing about CLX or CLIM. Better be silent.
CLX is just some source code that gives you basic X support for Common Lisp. It is free and you can port it to any version of Common Lisp with TCP support in a few hours.
CLIM on the other hand is a large User Interface Management System which is independent of the underlying window system. It runs on top of CLX, Symbolics' window system, and some other (Harlequin CAPI, ACL PC, ...).
> CMU are also working on a Dylan implementation. While I'll be > interested to see what can be done with Java, Dylan is much > closer to what I'm looking for. This shouldn't be suprising, > considering how it was designed - by some Lisp programmers > working for _Apple_. I think Apple have (or had) a much better > idea of what most developers want today
So much, that Apple killed the project. Seemed not that important to Apple. They are using C and C++ for their crashing OS (some of their stuff is actually quite cool, but build on a shaky foundation).
> than the designers of > Common Lisp, 15 years ago, I'm not knocking CL, but it does > show its age.
It is so much showing its age. So much that Digitool recently released version 4.0 of its Macintosh Common Lisp. It does support native threads, native shared libraries, almost all OS calls, deals with alien memory, supports finalization, has ephemeral garbage collection, compiles to native PowerPC code, has a large CLOS based and easy to use UI library, has an integrated editor, does tail recursion elimination, has enthusiastic users and excellent support, and, yes, people are developing **real** applications with MCL (some of them you can download on the Net). Applications you can really *buy*. In Lisp. Isn't this interesting?
Guys, I like to see you not waste your time with useless nonsense discussion. We can use Common Lisp (and Scheme) today and we have a *lot* to do.
Better let's get our act together and do something useful:
Useful hacking areas for advancing Common Lisp ==============================================
- CL-HTTP needs your hacking. We have ideas for the entire next three centuries. Ask John Mallery about advice (join www...@ai.mit.edu).
- We like to start a Free CLIM effort. Vendors were not very helpful to advance CLIM. Martin Cracauer (http://www.cons.org/) has started a mailing list, which I think will get some discussion started in the new year. Join now!
- Start thinking about CLIM 3.0.
- Get threads for CMU CL. Ask Martin Cracauer about that.
- Help the ALU to develop their new web presence - a cool prototype is ready (done by Howard R. Stearns). But we want it to run on CL-HTTP. Integrate the FAQ. This is very important for the Lisp community.
- Develop a central code management system for the Common Lisp community on the net.
- Develop an application server for Common Lisp.
- Identify a secure subset of Common Lisp for remote execution.
- Develop a free OODBMS for Common Lisp.
- Write a book about Common Lisp on Windows and MacOS.
- Develop better development tools for CLOS.
- Help developing SOM / QuickDraw 3d / QuickDraw GX / OpenTransport / ... support for Macintosh Common Lisp. Ask Digitool about SMP (symmetric multi-processing) for the new PowerMacs.
- Yes and finally, but on every wishlist, develop an object oriented portable DEFSYSTEM facility.
This would be useful for all of us. What is your contribution? Sitting and waiting for a phone call from some company, while writing completely useless postings to Usenet??? If only people would stop writing device drivers for numerous useless Unix variants and start something real cool.
Lisp User Group Meeting in Germany next Year ============================================
We are currently preparing the second Lisp User Group Meeting in Germany (see http://www.lisp.de/). Soon (hopefully next week) we will announce the agenda. We have got some interesting talks about CL-HTTP application, Site management for the Web, EuLisp, real distributed computing with Scheme, the Statice OODMBS, etc.
We want people to join us in Munich. If you already know that you will attend the Lisp User Group Meeting, send us a note to mailto:lug...@lisp.de .
If you have a contribution, let us know about that. Write to mailto:lug...@lisp.de , too.
Lisp User Group in Germany/Europe =================================
We also want feedback on how to start an active Lisp User Group in Germany/Europe:
**** Mail us your ideas about the **** **** German/European Lisp User Group **** **** at mailto:l...@lisp.de ****
Erik Naggum <n...@naggum.no> writes: > * Guillermo J. Rozas > | I would love to see a good Lisp environment for Windows that allowed > | complete interoperability with arbitrary libraries. Alas, I don't expect > | one soon.
> well, _I_ got one delivered to a client of mine just last week, but until > then, I could have said "I expect one soon". quit whining and do some > research into what is available in the market _today_.
I've been enjoying your flaming with Mr. Surfer for quite a while now. Both of you write in a way that is both educational and entertaining. Flame on, please!
On the other hand, please avoid clobbering innocent bystanders who are observing the fight. I, too, have looked for an existing Common Lisp or Scheme development environment (free or commercial) that integrates well with arbitrary Windows libraries. I've also looked for support for OLE and OS threads. I've spent an enormous amount of time searching for such an environment, both for work and for personal use. Unfortunately, I've come up empty-handed. I've been sending my requests to the most likely Lisp vendor periodically, but I haven't received a substantial response yet.
I would also like to add that Mr. Rozas, among others, put a heroic amount of effort over many years into producing MIT Scheme and porting it to Windows. MIT Scheme is a very good development environment, and includes a compiler that generates native code for i386, HP-PA, MIPS, Alpha, VAX, etc., a complete implementation of an Emacs-like editor written in Scheme, etc. Unfortunately, it doesn't have good support for programs that need to call external libraries and otherwise be integrated with the world outside Scheme, and, because of the way the system evolved over time, a large amount of work would be required to add such support. The reason I mention MIT Scheme is that Mr. Rozas is one of the last people who should be criticized for "whining" and not doing something. The rest of us have to do some work, too.
Before you blast me as well for whining without doing anything, I'll tell you that I've also been working on my own Scheme development environment in the background while I work full time. It is a large undertaking, and I'm not making much progress, but I'm trying. For the most part, I would prefer to have someone else write it, and I'm perfectly willing to pay for it. But I haven't given up on my own meager efforts.
When you say that you "got one delivered to a client," do you mean that you delivered a Lisp environment for Windows that integrates completely with arbitrary libraries, or do you mean that you delivered a successful program written using such an environment? In either case, would it be possible for others to get hold of that environment?
* Arthur A. Gleckler | On the other hand, please avoid clobbering innocent bystanders who are | observing the fight.
you're absolutely right. my apologies to Guillermo J. Rozas.
| When you say that you "got one delivered to a client," do you mean that | you delivered a Lisp environment for Windows that integrates completely | with arbitrary libraries, or do you mean that you delivered a successful | program written using such an environment? In either case, would it be | possible for others to get hold of that environment?
no. what I meant was that we got Franz Allegro Common Lisp for Windows delivered and then spent a day playing with various things we would need for the application, which still remains to be ported to that environment. (much of it has been written on my SPARC for CMUCL before we got Allegro, and the porting effort is mostly due to my accretion of bad habits and my not kwowing much about Windows. I ported it to Allegro for Unix in two hours.) under Windows (NT), DDE is fully supported; we could talk to other applications that we need in the project, and WinEmacs talked DDE to Allegro. OLE2 is not fully supported, but we managed to talk to some applications. we tried linking with a DLL and could list functions, but the foreign function call interface was sufficiently complex that I didn't get to call any functions before we had to leave for the day.
my Windows expert was very pleased with what we could accomplish from inside Allegro, and I don't know the first thing about Windows, so all I can do is trust his judgment for our needs.
In article <usp4zfudp....@zurich.ai.mit.edu> art...@zurich.ai.mit.edu "Arthur A. Gleckler" writes:
> I've been enjoying your flaming with Mr. Surfer for quite a while now. > Both of you write in a way that is both educational and entertaining. > Flame on, please!
It's good to know that one's efforts are being appreciated! ;-) Thanks. However, my intention is not to flame anyone, as that implies disrespect, and I have a great deal of respect for Erik. This is simply an issue that we see differently. Perhaps my view of Lisp is more general (vague?), while Erik's is more focused.
> On the other hand, please avoid clobbering innocent bystanders who are > observing the fight. I, too, have looked for an existing Common Lisp > or Scheme development environment (free or commercial) that integrates > well with arbitrary Windows libraries. I've also looked for support > for OLE and OS threads. I've spent an enormous amount of time > searching for such an environment, both for work and for personal use.
Ah, yes. Threads.
Some people refused to take serious a language implementation that doesn't support threads. While it's true that threading is important for high performance server apps, I think it's a mistake to assume that every app will suffer if threads can't be used.
Still, I'd greatly appreciate threading support in a Lisp for Windows. This is something I frequently use in C++.
> Unfortunately, I've come up empty-handed. I've been sending my > requests to the most likely Lisp vendor periodically, but I haven't > received a substantial response yet.
Someday, someday. I'm encouraged by the thread support in Smalltalk MT. Hopefully, Lisp vendors will follow Object Connect's example. Nobody has a monopoly on such features!
> I would also like to add that Mr. Rozas, among others, put a heroic > amount of effort over many years into producing MIT Scheme and porting > it to Windows. MIT Scheme is a very good development environment, and > includes a compiler that generates native code for i386, HP-PA, MIPS, > Alpha, VAX, etc., a complete implementation of an Emacs-like editor > written in Scheme, etc. Unfortunately, it doesn't have good support > for programs that need to call external libraries and otherwise be > integrated with the world outside Scheme, and, because of the way the > system evolved over time, a large amount of work would be required to > add such support. The reason I mention MIT Scheme is that Mr. Rozas > is one of the last people who should be criticized for "whining" and > not doing something. The rest of us have to do some work, too.
I agree. Anyone who reads the docs for MIT Scheme for Windows will see that an FFI is high on the list of priorities.
> Before you blast me as well for whining without doing anything, I'll > tell you that I've also been working on my own Scheme development > environment in the background while I work full time. It is a large > undertaking, and I'm not making much progress, but I'm trying. For > the most part, I would prefer to have someone else write it, and I'm > perfectly willing to pay for it. But I haven't given up on my own > meager efforts.
You have my sympathy! We shouldn't need to implement our own Lisp simply in order to use the language, esp when we're more than happy to pay for it. Unfortunately, it's hard for a vendor to please everyone.
This doesn't justify Erik's fierce defence of Lisp, as he sees it. A little variety should be possible. This is why there's more than one dialect of Lisp, and not all implementations are interactive.
> When you say that you "got one delivered to a client," do you mean > that you delivered a Lisp environment for Windows that integrates > completely with arbitrary libraries, or do you mean that you delivered > a successful program written using such an environment? In either > case, would it be possible for others to get hold of that environment?
Good questions. ;) Not all apps demand the same things from the OS, nor do all clients demand the same features. It would be foolish to think otherwise, esp given the variety of software available today, and the OS features that support it.
I look at it this way: there's a difference between writing an app for Windows that just happens to be written in Lisp, and writing an app in Lisp that happens to run under Windows.
> hoping not to have offended anyone,
No problem. Welcome to the fray! -- <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 <joswig-ya023180002112962143090...@news.lavielle.com> jos...@lavielle.com "Rainer Joswig" writes:
> > Take a look at Dylan. Dispite reports of Dylan's death (probably > > due to some bitter Mac developers misinforming a journalist), it's > > still alive and growing stronger.
> So strong, that it is almost completely invisible and has > almost no influence on developer choices at all. Where > is Dylan??? Apple Dylan is not really supported > (Digitool can only provide bug fixes), CMU hasn't delivered > anything exciting yet, Harlequin has not released anything.
It would be unfair to expect anything delivered so soon, but if you count Mindy, then there's at least one "Dylan" implementation available.
Some might consider Lisp to be dead, simply because they hear nothing about it. Would that be fair? I think not.
> But it is getting stronger everyday, huh? Until someone > releases something useful, I'll write my code in Common Lisp > or maybe even Scheme.
I wouldn't you to do otherwise! I'm not pretending that what's available today is "industrial strength".
Did I mention patience? I've been looking for a language like Dylan since the early 80s. I can wait a little longer.
> Sorry, but you don't seem to know a thing about CLX or CLIM. > Better be silent.
That's exactly what I mentioned it! I've seen posts from people concerned for the future of CLX. Is that worth flaming me for?
> So much, that Apple killed the project. Seemed not > that important to Apple. They are using C and C++ > for their crashing OS (some of their stuff is actually > quite cool, but build on a shaky foundation).
I think of Apple as the "Evil Empire", mainly coz of their use of "hired guns" to compete with rivals. I didn't say that Apple still supported Dylan, just that they started it.
Does Dylan die with Apple? Ask CMU and Harlequin.
> It is so much showing its age. So much that Digitool recently > released version 4.0 of its Macintosh Common Lisp. > It does support native threads, native shared libraries, > almost all OS calls, deals with alien memory, supports > finalization, has ephemeral garbage collection, compiles > to native PowerPC code, has a large CLOS based and easy to > use UI library, has an integrated editor, does tail > recursion elimination, has enthusiastic users and excellent support, > and, yes, people are developing **real** applications > with MCL (some of them you can download on the Net).
Fortran 77 also shows its age, and yet is still being used. That's no reason not to consider F90.
> Applications you can really *buy*. In Lisp. Isn't > this interesting?
All it tells me is that people still use CL. See above. Lisp isn't dead yet. I don't just mean CL. Perhaps your definition of Lisp is limited to CL, but I doubt that. Anyway, mine certainly isn't. While programmers use a language, there should be room for change.
> Guys, I like to see you not waste your time with useless > nonsense discussion. We can use Common Lisp (and Scheme) > today and we have a *lot* to do.
Yep, but not enough. That's why I'm using C++. I'm not asking for much, just a few things like OCX etc. Threading would be really handy.
> - CL-HTTP needs your hacking. We have ideas for the > entire next three centuries. Ask John Mallery about advice > (join www...@ai.mit.edu).
CL-HTTP does indeed need some hacking.
While it well be possible to do it all in CL-HTTP, it would require a lot of work to do it as well as commercial web servers _and_ all the addon tools for them. I know they cost money, but that's not a problem.
In fact, it may be necessary for CL-HTTP to do all that a commercial web server can do _and more_, just to get noticed. The marketing factor should not be ignored, unless you don't have to convince anyone that CL-HTTP is capable.
A lot of work to do.
> - We like to start a Free CLIM effort. Vendors were not > very helpful to advance CLIM. Martin Cracauer (http://www.cons.org/) > has started a mailing list, which I think will get some discussion > started in the new year. Join now!
Ah, yes. CLX is not enough? This is the concern that I refered to above.
> - Start thinking about CLIM 3.0.
Yes, start early.
> - Get threads for CMU CL. Ask Martin Cracauer about that.
Threads are very tasty. However, I've no chance of using CMU CL any time soon, so I can't help.
You made many other fine suggestions.
> This would be useful for all of us. What is your contribution?
I'm working on a Lisp to C++ compiler, with the intention of supporting any API I need to use. Progress has been slow so far, due to other demands on my time.
> Sitting and waiting for a phone call from some company, while > writing completely useless postings to Usenet??? If only people would > stop writing device drivers for numerous useless Unix > variants and start something real cool.
Actually, I've been coding in C++. I'm not proud of it, but that's what I get paid for.
I don't expect my Lisp compiler to be useful by anyone but me, as the code quality will be relatively poor, compared to the existing Lisp compilers available. (That's why I'd prefer to use a commercial compiler.) It may also have a few quirks, like not being standard. Still, if anyone wants to use it, I expect that the code will be available online.
I was hoping to have a reasonable discussion about what may (or may not) be done with Lisp to make it more "competitive" (in the sense that implementations might be able to compete with C++ compilers), but I guess that's not possible.
Flame away, Rainer. It won't change anything. I'm willing to discuss these things with you, but I'm not sure what the point would be. Why should you care whether a Lisp for Windows supports OCX or not? In fact, why should _I_ care, when Smalltalk MT is available?
Happy New Year, BTW. -- <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
Cliff Click <cli...@ami.sps.mot.com> wrote: }I think perhaps the quote you are looking for is (paraphrased slightly }because I can't remember the exact wording): } "Measuring a programming project by KLOCs is like } measuring airplane construction by weight. -- Bill Gates"
Thank goodness MS does not build planes.
New! MS 737 version 4.0 (requires 64 Million HP engines, not included)
John -- John Hascall, Software Engr. Shut up, be happy. The conveniences you ISU Computation Center demanded are now mandatory. -Jello Biafra mailto:j...@iastate.edu http://www.cc.iastate.edu/staff/systems/john/welcome.html <-- the usual crud
cyber_sur...@wildcard.demon.co.uk (Cyber Surfer) writes: > Programmable Syntax Macros > Daniel Weise and Roger Crew > PLDI '93
> Abstract: > Lisp has shown that a programmable syntax macro system acts as an > adjunct to the compiler that gives the programmer important and > powerful abstraction facilities not provided by the language. Unlike > simple token substitution macros, such as are provided by CPP (the C > preprocessor), syntax macros operate on Abstract Syntax Trees (ASTs). > Programmable syntax macro systems have not yet been developed for > syntactically rich languages such as C because rich concrete syntax > requires the manual construction of syntactically valid program > fragments, which is a tedious, difficult, and error prone process. > Also, using two languages, one for writing the program, and one for > writing macros, is another source of complexity. This research solves > these problems by having the macro language be a minimal extension of > the programming language, by introducing explicit code template > operators into the macro language, and by using a type system to > guarantee, at macro definition time, that all macros and macro > functions only produce syntactically valid program fragments. The > code template operators make the language context sensitive, which > requires changes to the parser. The parser must perform type analysis > in order to parse macro definitions, or to parse user code that > invokes macros.
> Anyone who thinks that MS are the "Evil Empire" and are doing > "no good at all" should look at the MS Research site. Papers > like this one might even make C more appealing to those who > like to knock it - but I don't expect miracles. ;-)
I don't share this sentiment. The problem is that, if LISP-like macros were natural to C/C++, someone would've thought of it already. But to implement even a subset of LISP power, namely, ability to look /into/ the macro body and transform it beyond simply mingling the outer forms, requires 'language-within-language' approach. In fact, this abstract shows that this is exactly what Microsoft people had in mind.
In other words, making it bigger won't make it better.
In article <3060270005539...@naggum.no> n...@naggum.no "Erik Naggum" writes: > you _actually_ said "The fact that you use Emacs speaks for itself."
And it does. While Emacs is a fine piece of software, not everyone likes it. You may be aware of some of the reasons. (I won't go into details here, as I don't care enough, and it might only provoke you into more flaming.) Whether you consider those reasons valid or not is irrelevant, as other people _will_. Flaming them won't change that.
Hence the expression, "Your mileage may vary". It basically means that no matter how strongly _you_ feel that something is fine, and has no problems, other people will disagree.
The use of EVAL in Lisp is another of those issues. Possibly I'm flexible to find uses for Lisp without using EVAL, or perhaps I'm just some heretic who's been currupted by using other languages for too long (C, Smalltalk, ML?) - you choose.
I'm not suggesting that anyone should remove EVAL from Common Lisp, just making it an _option_ at runtime. You seem to be insisting that it always been available, and some of your justifications apply only to _development time_, not runtime. So, perhaps you've been flaming me for things you _think_ I'm saying, when you're actually doing nothing more than misunderstanding or misrepresenting what I'm saying.
Also, I'm talking about _Lisp_, not Common Lisp. I've not yet found any referernce to EVAL in the Scheme reference manual, but perhaps my copy isn't the latest...
However, please don't flame me just for having a minor difference of opinion. Even if I fail to appreciate all the virtues of EVAL, does that invalidate everything I say? Is EVAL all there is to Lisp? I hope not. All I hope to do is question an old practice that may - just possibly - be linked to some of the so called "overheads" that C programmers have used to attack Lisp with for so many years.
So, there should be no way in which I'm hurting you, personally. If this is not so, then please explain how this is possible. Meanwhile, I'm baffled by your hostility. -- <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
Here's a suggestion, CS. Go out on the net and get GAMBIT-C, a /very/ nice Scheme->C compiler, grab yourself DJ C's 32-bit extending compiler if you don't already have it, sit down and start cutting real code. Compiles to executables. Its a wonderfully solid platform for developing /the things you want/. It uses and can create shared libraries on UNIX platforms that support them, only a bit of tweaking by someone as skilled as yourself should enable it to produce DLLs. It can already make use of modules written in C that already exist, you can recycle code that does API'ing if you're so inclined. Write a quick hack interface to ActiveX and impress us all and produce the tool you want to work with instead of lamenting your pain of loss.
I've watched your posts to this newsgroup for some time and, frankly, while I was sympathetic to begin with, you've rapidly shed that degree of slack allowed. Not once have we seen something from you /constructive/ other than `I'm working on my own interpreter.' Reinvent the wheel and cry because your car don't run.
There are tools out there that go most of the way toward doing what you've been crying for; don't expect them under the tree for Yule. You'll have to go out and get them.
-- Alexander Williams {than...@alf.dec.com / zan...@photobooks.com} Prefect of the 8,000,000th Terran Overlord Government Experimental Strike Legion, Primary Transport TOG "Bellatores Inquieti" ======================================================================
jos...@lavielle.com (Rainer Joswig) writes: >Useful hacking areas for advancing Common Lisp >==============================================
And now for something completly different:
Implement a Java virtual machine in Common Lisp. Should not be that hard given a thread interface (most other problems like GC and dynamic loading are solved in every Lisp implementation anyway). Even a Just-in-time-compiler will be easy (and working $#%$^&%^).
The points is of course to use all those advertised little Java modules and/or Java beans components.
Examples: - A http server could provide entry points for servlets like Jeeves and Jigsaw offer. Mix Lisp and Java filters as you like, write your Lisp filters, get some Java filters from the net. - User all the tools advertised to generate Java beans components. - Many Web servers claim to open their execution engine for Java .class files from users. Example: Let two people provide .class files to play a game and have a server that let them play against each other. Java a JVM in Lisp and you can run a Java soltuion against whatever you definde for Screamer in five minutes. - The same applies for application custumization (i.e. killfile-like functionality for newsreaders). With a JVM in Lisp we'd be able to let people give init files as Lisp or .class files (should such a form of application become real, I expect a lot of tools come up to help people doing so). - And - of course - use the .class files lying around. Doing so is a lot more easy than to integrate C object files. A .class files carries all the information you need. Not that there are many I'd like to use...
The kawa project does the other way round (Scheme compiled to Java, all runs insider Java), but that's performance-wise not the right thing.
Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Martin_Craca...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
cyber_sur...@wildcard.demon.co.uk (Cyber Surfer) writes: >In article <joswig-ya023180002112962143090...@news.lavielle.com> > jos...@lavielle.com "Rainer Joswig" writes: >That's exactly what I mentioned it! I've seen posts from >people concerned for the future of CLX. Is that worth flaming >me for?
CLX is just an Xlib mapping for Lisp. There havn't been work on it for a long time and that makes some people upset who needs more advanced Xlib features.
But for me (and - obviously most other), the existing interface is sufficient for what I'm going to do (I don't care for advanced Xlib features, I need something I can use to display basic things and get some feedback).
>> Applications you can really *buy*. In Lisp. Isn't >> this interesting? >All it tells me is that people still use CL. See above. >Lisp isn't dead yet. I don't just mean CL. Perhaps your >definition of Lisp is limited to CL, but I doubt that. >Anyway, mine certainly isn't. While programmers use a >language, there should be room for change.
There are points I don't like about Common Lisp. Therefore, I looked into Scheme and SML and thought about waiting for Dylan.
I decided that Common Lisp is good enough and that the range of availiable tools (cl-http, Screamer, Garnet, maybe someday CLIM, books, other people pushing Lisp etc) is the greatest resource I can think of.
Look at all those Java tools. I happen to like the language, but almost all libraries I can get source for are pure junk (I like having source, I need to learn from it). Not to speak of JVMs exploding under the slightest data load.
Dylan's greatest drawback will of course be the lack of such resources for my needs and without a free environment I can't expect free source to show up.
>> Guys, I like to see you not waste your time with useless >> nonsense discussion. We can use Common Lisp (and Scheme) >> today and we have a *lot* to do. >Yep, but not enough. That's why I'm using C++. I'm not >asking for much, just a few things like OCX etc. Threading >would be really handy.
Lack of threads in free CLs (except ECOLisp) is what I miss most. Problem at hand: The problem is too tough for me to solve.
What's OCX?
>> - CL-HTTP needs your hacking. We have ideas for the >> entire next three centuries. Ask John Mallery about advice >> (join www...@ai.mit.edu). >CL-HTTP does indeed need some hacking. >While it well be possible to do it all in CL-HTTP, it would >require a lot of work to do it as well as commercial web servers >_and_ all the addon tools for them. I know they cost money, >but that's not a problem. >In fact, it may be necessary for CL-HTTP to do all that a >commercial web server can do _and more_, just to get noticed. >The marketing factor should not be ignored, unless you don't >have to convince anyone that CL-HTTP is capable. >A lot of work to do.
Could you give some examples what feature you are referring to? About two third of all Web servers in the world are drive by apache. Apache is just serving files, calling CGIs and pushing contents of Web pages through a C api.
Server-side Java: Servlets look pretty nice, but it's not that cl-http cannot install user code to generate HTML pages.
SLL: Who is actually using it? There's a commercial Apache version with SLL, but as we see, most people can live without it.
What most people driving Web site today want: - Pure file serving with a few gimmicks. Apache is just right
What most people drinving Web servers one-two years from now: - Easiest setup to open your whole windows box to the net. MS will take care of servers doing what they (the serverm not the user) thinks is a nice gimmmick.
What people want who wants to do killer Web applications: - Cleanest way to handle user input from server-side application. Parts of cl-http take care of this. - Cleanest way of presenting outout to the user without overloading network. Parts of cl-http take care of this, as well as CLIM-related projects. - A lot of Web features that work around weaknesses in the stateless HTTP protocol needs a clean programmer interface. Have you seen cl-http's (http:with-cookie-values ...)? Have you see what it takes to do the same from CGI-based C programs? If so, you could imagine what I spent the last year with.
>> - We like to start a Free CLIM effort. Vendors were not >> very helpful to advance CLIM. Martin Cracauer (http://www.cons.org/) >> has started a mailing list, which I think will get some discussion >> started in the new year. Join now! >Ah, yes. CLX is not enough? This is the concern that I refered >to above.
I'm afraid I have to pick up Rainer's previous note and ask you to have a brief look over CLX and CLIM.
To make it short: Yes, CLX is not enough to be counted as the only GUI tool. Xlib isn't, either.
>I was hoping to have a reasonable discussion about what may >(or may not) be done with Lisp to make it more "competitive" >(in the sense that implementations might be able to compete >with C++ compilers), but I guess that's not possible.
While Rainer is quite rough sometimes, he's one who actually pushes Lisp forward (much more than me).
I'll try to say it as polite as I can, but you, Cyber (I'm sure that's not your real name, but anyway) are someone you does acutal damage to the Lisp community.
While you try to point out weaknesses of Lisp (that's a good thing, of course), you suffer from commenting about things you don't know enough about. For some years, if I remember right, this newsgroup sees postings of yours that draw a wrong picture of the usefulness of some of Lisp features. The other way round, of also named advantages of Lisp that were pointless.
Remember, this is a public forum. Many people are looking for a new language to use. In the past, those hint by C++, now those who took the new freedom introduced by Java (its now possible to tell management there *are* other languages).
If someone gets interested in Lisp, he/she usually monitors this newsgroup for a while or even browsing message of a few days once. When you post nonsense about a weakness and someone corrects you, the new reader will have no idea who of you is correct. Those people will count the point discussed as Lisp feature that is even argued over in the Lisp community.
When you post wrong information about positive features, you might lead people to try that out, recognize it was wrong and count it as "the Lisp community either has no idea what is useful" or "All those praised Lisp advantages turn out unuseable for other people".
Nowadays, it is even more important to keep the newsgroup's contents in line. There's a great potential of hackers who actually can contribute to free software. Today, many people are facing problem that cry for a more dynamic language than C++, mostly feeding the Web. When i look over the maintainer list of the current CMUCL effort, I see a lot of people joining from usenet or public mailing lists.
Every newsgroup has people like your, but next to FreeBSD's Jesus Monroe Jr. (he havn't been using his real name either), you are quite outstanding how long you maintain to post about things you don't know about. Sad. How much time did you spend to post to comp.lang.lisp this week? I'm sure you could also had a quick look over the CLX manual and into Ralf Moeller's excellent CLIM introdution on the Web. I'd say that would have been a lot more useful for all of us.
I'll stop and resume reading cl-http's documentation, as I speak of it.
Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Martin_Craca...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Martin_Craca...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
jos...@lavielle.com (Rainer Joswig) writes: >Useful hacking areas for advancing Common Lisp >============================================== >- We like to start a Free CLIM effort. Vendors were not > very helpful to advance CLIM. Martin Cracauer (http://www.cons.org/) > has started a mailing list, which I think will get some discussion > started in the new year. Join now!
Personally, I'm mostly after something to do my Web applications with, but CLIM also is an excellent tool to implement a Web browser in. The CLIM presentation model is a really close fit to HTML.
Imagine: A *working* Web browser with all the HTML features you want. Really customizable. Real startup scripts. Stable, no more coredumps. Comparable output on different platforms. Coupled with some HTML and HTTP tools from cl-http (searching etc.).
I'd say if we want a full-featured HTML/HTTP browser with source, it's more efficient to develop the CLIM subset needed to do so on top of Express Windows, define a fine language to let the user specify a HTML->presentation mapping and put in HTTP support from cl-http to feed the beast. I'd say that takes less time than to start reimplementing Netscape's Navigator.
>- Get threads for CMU CL. Ask Martin Cracauer about that.
Well, first of all I'd like somments on a suitable programmer interface. See http://www.cons.org/cracauer/lisp-threads.html for an overview of existing packages (the page is work in progress).
>- Develop support for Common Lisp in ILU 2.0.
Seconded.
To add one item to Rainer's list:
- Steal a few ideas for scripting from scsh and hack that into CMUCL. The cl-http server (when it finally runs on CMUCL) will get a lot more flexible in environments of existing WWW pages/text-based databases. perl-like regulars expression scanning/replacement is important, using their output from existing code management systems like CVS, GNATS etc. ist important, too and needs the excellent design work Olin Shiver did for scsh. I already have parts of a regex package going, but Olins clever mapping for the port/filedescriptor mapping is quite challenging.
Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% Martin_Craca...@wavehh.hanse.de http://cracauer.cons.org Fax.: +4940 5228536 "As far as I'm concerned, if something is so complicated that you can't ex- plain it in 10 seconds, then it's probably not worth knowing anyway"- Calvin
In article <59m9is...@netnews.alf.dec.com> than...@uxtlaser.alf.dec.com "Alex Williams" writes:
> Here's a suggestion, CS. Go out on the net and get GAMBIT-C, a /very/ > nice Scheme->C compiler, grab yourself DJ C's 32-bit extending > compiler if you don't already have it, sit down and start cutting real > code. Compiles to executables. Its a wonderfully solid platform for > developing /the things you want/. It uses and can create shared > libraries on UNIX platforms that support them, only a bit of tweaking > by someone as skilled as yourself should enable it to produce DLLs.
I've got it. I like it, but I've not yet succeeded in getting the _kernel.c (_kernel.scm, after being compiled by gsc) file to compile without errors. I'd spend more time on this if there was any hope of using Gambit C, but there's a more serious problem. See below.
> It can already make use of modules written in C that already exist, > you can recycle code that does API'ing if you're so inclined. Write a > quick hack interface to ActiveX and impress us all and produce the > tool you want to work with instead of lamenting your pain of loss.
The FFI in the version I have doesn't appear to support callbacks. This is a vital feature. Obviously, the FFI could be extended, but I'll have to study the source code. I'll do that anyway, as there's much to learn from this compiler. Meanwhile...
> I've watched your posts to this newsgroup for some time and, frankly, > while I was sympathetic to begin with, you've rapidly shed that degree > of slack allowed. Not once have we seen something from you > /constructive/ other than `I'm working on my own interpreter.'
It's a compiler, actually.
> Reinvent the wheel and cry because your car don't run.
I think my original point had something to do with how most other people look at Lisp, not how you or I see it. If all these things can be done, why hasn't anyone done it yet? Have you seen how much support there is for C++? I'm merely wondering how Lisp can compete.
In terms of Lisp, Windows is a very obscure and undersupported OS. Meanwhile, there's no Windows feature that isn't supported by C++.
> There are tools out there that go most of the way toward doing what > you've been crying for; don't expect them under the tree for Yule. > You'll have to go out and get them.
Do you mean Gambit C? Sure, after a lot of work. A HELL of a lot of work. That's why I'm more inclined to write my own compiler. Neither will make _any_ difference to the popularity (i.e. success) of Lisp for Windows.
On the other hand, Smalltalk support for Windows is much better. Can anyone tell me what Smalltalk can do that Lisp can't? What makes Smalltalk so special? It's a simple question, but nobody has even tried to answer it! None of the other shit matters, when you need a tool _right now_. That's why so many programmers will choose C++.
Anyway, I can see that this has been discussed to death. Nobody else wants to discuss the real issues. I'm ready to buy a Lisp (please note that: I'd rather spend money than time) that does what I need. I _know_ that I'm not alone. That's why we're always being told that only C/C++ can do this or that.
Ok, I've been letting off some steam. Just a little. Sometimes it's hard for me to believe that Lisp has to be just one thing, instead of many. Gambit C is a good example of one of the alternatives to the "traditional" Lisp, the kind that has a big enviroment. In fact, you can use Gambit C as a batch compiler.
Here's my first point once again: most people will have no idea what EVAL is for, nor will they appreciate the overheads for it, however small we may say they are, however hard we justify them. Some of us may say, "I'm all right jack", and ignore the problem. I refuse to do that. Somebody has to. It's all relative.
If we all insisted that batch enviroments are wrong, and not for Lisp, then Gambit C might be a very different kind of Lisp compiler. It might not exist at all. Discuss... -- <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 <1996Dec23.121729.24...@wavehh.hanse.de> craca...@wavehh.hanse.de "Martin Cracauer" writes:
> CLX is just an Xlib mapping for Lisp. There havn't been work on it for > a long time and that makes some people upset who needs more advanced > Xlib features.
Ah, that must be the "conern" that I refered to, then. I can understand such a concern, tho in this case I can't share it, having no (current) use for X Windows, never mind CLX. I am curious about it, tho.
> But for me (and - obviously most other), the existing interface is > sufficient for what I'm going to do (I don't care for advanced Xlib > features, I need something I can use to display basic things and get > some feedback).
Excellent.
> There are points I don't like about Common Lisp. Therefore, I looked > into Scheme and SML and thought about waiting for Dylan.
I've recently been looking closely at SML, but for now O'caml serves me well - for my personal projects, anyway. It would be harder to use for work, but not impossible. For example, I can write CGI code with it. If I'd discovered O'caml a few months earlier, I might've been able to use it for my last CGI project. In fact, I'm still tempted to re-write the C++ code I have in O'caml, to see how easily (and quickly) it might be done.
> I decided that Common Lisp is good enough and that the range of > availiable tools (cl-http, Screamer, Garnet, maybe someday CLIM, > books, other people pushing Lisp etc) is the greatest resource I can > think of.
Common Lisp has a lot going for it, once you've accepted that Lisp can be used. That's no problem for you or I, of course.
> Look at all those Java tools. I happen to like the language, but > almost all libraries I can get source for are pure junk (I like having > source, I need to learn from it). Not to speak of JVMs exploding under > the slightest data load.
YMMV. Most of the uses of Java that I see are trivial, but this is expected to change, once the quality of JVMs improve. For example, how many JVMs use a generational GC? Yet JVMs that generational GCs are on their way.
I'm not a Java advocate, but if if my choice was between C++ and Java, then I'd like to choose the latter. For many apps today, Java is not a choice. That's why people say it'll change.
> Dylan's greatest drawback will of course be the lack of such resources > for my needs and without a free environment I can't expect free source > to show up.
I recall Harlequin refering to a demo of DylanWorks using OLE. If the strength of support for other Windows APIs is as strong, then I'd expect a lot of people to be interested - or at least very curious. I guess it'll depend on whether you see Dylan as an alternative to Lisp (Common Lisp, Scheme, whatever) or C++.
> Lack of threads in free CLs (except ECOLisp) is what I miss > most. Problem at hand: The problem is too tough for me to solve.
Same here. How many free CLs with native code compilers are there? To avoid licencing problems, I'd prefer a commercial compiler.
> What's OCX?
Like a Widget. (A 32bit VBX? That's a simple explanation, but only if you know what a VBX is...) There's a _lot_ of support for these things, esp in C++. Component based development is the name of the game these days.
I hope that's clear. If not, please let me know, and I'll try harder to explain it. I hesitate to go into details, in case I say too much and bore everyone. ;-)
> Could you give some examples what feature you are referring to? About > two third of all Web servers in the world are drive by apache. Apache > is just serving files, calling CGIs and pushing contents of Web pages > through a C api.
Take a look at some of the web servers for Windows. One of the buzzwords now is ISAPI. This means dynamic linking to code in a DLL, avoiding the overhead of starting a new process for every CGI query.
However, the real problem may just be a marketing one. Most people (using Windows) won't be impressed by CL-HTTP. They may simply be ignorant, but don't underestimate the significance of ignorance! Any learning curve is going to be a black mark against CL-HTTP, and this app has two curves: one for itself, and another for CL.
If you already know of CL-HTTP, know CL, and it's your choice alone to make, then it's easy. For my employer, the first choice of Apache, running under Linux. Unfortunately, a Windows based web server arrived and was running after a simple install, while Apache may or may not have been running. I never found out. The choice was not made due to ignorance, but due to a lack of time. One server took longer to get running than the other (which took _no time at all_).
None of which matters much, as it's only one example. It does, however, illustrate how such important choices may be made, even when Unix is an option, as it was in our case. It's certainly too late to change the server, now, even if I could convince anyone of the virtues of CL-HTTP, which would be unlikely. It would have to compete with the code already written for the current setup, and the fact that if we used Lisp, then I'd be the only one who could maintain the CGI code. That would be unacceptable.
I can't comment on the numbers of servers using Apache, as most people I know with web servers are using NT. The OS seems to me to be almost irrelevant, as the real issue is likely to be the choice of language for the CGI code. as you may be aware, a great many people choose Perl.
It's not all hopeless, but it would be a trully massive task to compete with all that!
> Server-side Java: Servlets look pretty nice, but it's not that cl-http > cannot install user code to generate HTML pages.
See above. CL-HTTP will be very often be competing with existing solutions. If you're starting from scratch, in an area where no existimg toopls exst (rare, but possible), then you may have an edge that'll be enough.
> SLL: Who is actually using it? There's a commercial Apache version > with SLL, but as we see, most people can live without it.
Secure sockets? I assume this is what you mean.
This is a feature that I've had no reason to look at, so far, mainly because there are others who deal with this side of web development at Enrapture. However, I'm sure it'll be used by us in the forseeable future.
I know that others are interested in it, and not all of them are using Apache. Who are they? I can think of a few names...
> What most people driving Web site today want: > - Pure file serving with a few gimmicks. Apache is just right
I hope so - that'll give Enrapture an edge! Many of the web developers that I know are going beyond the basics, but I'm not sure how typical they are.
> What most people drinving Web servers one-two years from now: > - Easiest setup to open your whole windows box to the net. MS will > take care of servers doing what they (the serverm not the user) > thinks is a nice gimmmick.
Gimmick? What gimmick?
> What people want who wants to do killer Web applications: > - Cleanest way to handle user input from server-side > application. Parts of cl-http take care of this.
Form handling is very basic stuff. If that's not enough, then there are tools that can make it obscenely easy. You'd need a well above average app to make _Perl_ necessary, never mind Lisp.
> - Cleanest way of presenting outout to the user without overloading > network. Parts of cl-http take care of this, as well as CLIM-related > projects.
Are you talking about a user over the web, or a local user, configuring the web server? The CLIM reference leads me to suspect that it's the latter.
> - A lot of Web features that work around weaknesses in the stateless > HTTP protocol needs a clean programmer interface. Have you seen > cl-http's (http:with-cookie-values ...)? Have you see what it takes > to do the same from CGI-based C programs? If so, you could imagine > what I spent the last year with.
At Enrapture, we're generally not using C/C++ for our CGI coding. There are domain-specific tools available that make C/C++, Perl, and any other general purpose programming language a complete waste of time.
For Unix, perhaps MetaHTML will do cookies, but I believe it'll do many of things that we're doing. If we were using Unix instead of NT, then MetaHTML might well have been our choice.
CL-HTTP may well make things easier than C, but so do a lot of other tools, and they don't rely on Lisp. Unless you can make CL-HTTP's use of Lisp transparent, the non-Lisp tools have a big edge over CL-HTTP. In the same way, it gives them an edge over the tools that use Perl, so this isn't merely a language issue. It's a question of how transparent the language can be, and what features are available "out of the box".
Of course, I'm making some assumptions. Perhaps the web authors that I know aren't typical. However, if you're hoping to convert C and Perl programmers to Lisp and CL-HTTP, I wish you luck.
I hope I'm not making it sound like any efforts using Lisp will be wasted, as I don't believe that's true. I just have doubts about web software, based on what I've seen done using tools that don't use Lisp. YMMV - and I hope it does.
> While you try to point out weaknesses of Lisp (that's a good thing, of > course), you suffer from commenting about things you don't know enough > about. For some years, if I remember right, this newsgroup sees > postings of yours that draw a wrong picture of the usefulness of some > of Lisp features. The other way round, of also named advantages of > Lisp that were pointless.
I'm _asking_ about things I don't know enough about. Please don't make the "kill the newbie" error!
> Remember, this is a public forum. Many people are looking for a new > language to use. In the past, those hint by C++, now those who took > the new freedom introduced by Java (its now possible to tell > management there *are* other languages).
> IIn article <851272035...@wildcard.demon.co.uk>, cyber_sur...@wildcard.demon.co.uk wrote: > It would be unfair to expect anything delivered so soon, > but if you count Mindy, then there's at least one "Dylan" > implementation available.
"Toy" implementation, I would say. Nice, but a toy.
> > But it is getting stronger everyday, huh? Until someone > > releases something useful, I'll write my code in Common Lisp > > or maybe even Scheme.
> I wouldn't you to do otherwise! I'm not pretending that > what's available today is "industrial strength".
ALMOST NOTHING COMMERCIALLY VIABLE IS AVAILABLE FOR DYLAN.
NOTHING.
EVERYTHING IS PURE VAPORWARE UNTIL NOW.
YOU MAY STILL BELIEVE THE PROMISES - I SIMPLY CAN'T SEE ANYTHING OUT THERE.
> Did I mention patience? I've been looking for a language > like Dylan since the early 80s. I can wait a little longer.
I can't wait. I have to do my work now. And I'm doing with what is available, supported and what is fun. This is excellent software like CL implementations, scsh, SIOD, XEmacs, ...
You may dream on.
> > Sorry, but you don't seem to know a thing about CLX or CLIM. > > Better be silent.
> That's exactly what I mentioned it! I've seen posts from > people concerned for the future of CLX. Is that worth flaming > me for?
I have seen posts from people concerned about all kinds of things. I'm not writing about it, because they do understand more than me about these topics.
> > So much, that Apple killed the project. Seemed not > > that important to Apple. They are using C and C++ > > for their crashing OS (some of their stuff is actually > > quite cool, but build on a shaky foundation).
> I think of Apple as the "Evil Empire",
This is childish.
> mainly coz of their > use of "hired guns" to compete with rivals.
This is even more childish.
> I didn't say that > Apple still supported Dylan, just that they started it.
> Does Dylan die with Apple? Ask CMU and Harlequin.
Yeah, where is it? Can I use, buy it? Where are the libraries? Pure Vaporware until now. I'll consider it again in five years, if it is still around and has stabelized. You may talk on about vaporware, while I prefer to use Common Lisp and Scheme, which I can get from *existing* vendors or from people who really have contributed something, which has real *working* code out there.
> > It is so much showing its age. So much that Digitool recently > > released version 4.0 of its Macintosh Common Lisp. > > It does support native threads, native shared libraries, > > almost all OS calls, deals with alien memory, supports > > finalization, has ephemeral garbage collection, compiles > > to native PowerPC code, has a large CLOS based and easy to > > use UI library, has an integrated editor, does tail > > recursion elimination, has enthusiastic users and excellent support, > > and, yes, people are developing **real** applications > > with MCL (some of them you can download on the Net).
> Fortran 77 also shows its age, and yet is still being used. > That's no reason not to consider F90.
This comparison alone disqualifies you. Most people haven't even realized the potential of Common Lisp.
> > - CL-HTTP needs your hacking. We have ideas for the > > entire next three centuries. Ask John Mallery about advice > > (join www...@ai.mit.edu).
> CL-HTTP does indeed need some hacking.
Have you tried it? I doubt that.
We are starting a project here in Hamburg. We will be using CL-HTTP and are looking to combine KR with a web server. Others are doing this already.
> In fact, it may be necessary for CL-HTTP to do all that a > commercial web server can do _and more_, just to get noticed.
It does already more. What are you talking about?
> The marketing factor should not be ignored, unless you don't > have to convince anyone that CL-HTTP is capable.
For every piece of software I have to convince the customer.
> Ah, yes. CLX is not enough? This is the concern that I refered > to above.
How about looking into the CLX docs and into the CLUE and CLIO docs? Then you may get an idea. Education does not come for free. You have to read yourself to get the picture.
> I'm working on a Lisp to C++ compiler, with the intention > of supporting any API I need to use. Progress has been slow > so far, due to other demands on my time.
Let me guess ... you will fail to come up with anything useful. Why? Because it is not easy. We already have enough Lisp system. We need something where we don't start from zero. Try standing on others shoulders. If you are really good, you may offer others a place on your shoulders.
> Actually, I've been coding in C++. I'm not proud of it, > but that's what I get paid for.
Hey, coding in C++ is not the problem. It can be fun. You can create cool software. That's what brings us forward.
> I don't expect my Lisp compiler to be useful by anyone > but me, as the code quality will be relatively poor, > compared to the existing Lisp compilers available. > (That's why I'd prefer to use a commercial compiler.) > It may also have a few quirks, like not being standard. > Still, if anyone wants to use it, I expect that the > code will be available online.
Tell us about that, and I'll think about shutting my Symbolics down (o.k. not really ;-) ) and selling Macintosh Common Lisp when your Lisp arrives.
Btw., how many man years do you think the respective companies have invested in their tools?
> I was hoping to have a reasonable discussion about what may > (or may not) be done with Lisp to make it more "competitive" > (in the sense that implementations might be able to compete > with C++ compilers), but I guess that's not possible.
They are already competetive. You have not realized it yet. LispWorks on a workstation gives you excellent productivity and if you ever have seen a Lisp wizard using a Symbolics you'll like to adjust your ratings. People are actually working hard to make Lisp environments good citizens in today's computing infrastructure. I just like to mention the guys from Igortech who are creating support for QuickDraw GX from within Macintosh Common Lisp. There you can see how CLOS will make it easy to access a complicated and feature rich graphics library. This brings developers forward. Not your useless postings.
> Flame away, Rainer. It won't change anything. I'm willing > to discuss these things with you, but I'm not sure what > the point would be. Why should you care whether a Lisp > for Windows supports OCX or not? In fact, why should _I_ > care, when Smalltalk MT is available?
That's the difference, I'm using this stuff today (actually I'm typing this in a Lisp-based editor - no its not Emacs). You may dream on.
Btw., Smalltalk MT may be a good choice. Once you have experience with it, you could write a short report how it compares to other development tools (Visual C++, Visual Basic, Parcplace Smalltalk, Delphi, Allegro CL, ...).
Btw.2, just played my first levels of Crash Bandicoot. While doing that, I was thinking about the none existent use of Lisp in the commercial world you often like to point out.
In article <1996Dec23.134611.24...@wavehh.hanse.de> craca...@wavehh.hanse.de "Martin Cracauer" writes:
> Implement a Java virtual machine in Common Lisp. Should not be that > hard given a thread interface (most other problems like GC and dynamic > loading are solved in every Lisp implementation anyway). Even a > Just-in-time-compiler will be easy (and working $#%$^&%^).
I like the idea of using a user interface (IDE?) built using Java, comunicating with the Lisp system via sockets. That way, you get an IDE that runs on every platform that has a JVM. If you don't wish to use Java, an alternative might be Kawa compiler, for compiling Scheme to JVM bytecodes.
It might be nothing more than a JVM-based widget server, but that's a great (and cheap) way to make an IDE portable.
> The points is of course to use all those advertised little Java > modules and/or Java beans components.
The IDE/JVM idea might also have this advantage.
> The kawa project does the other way round (Scheme compiled to Java, > all runs insider Java), but that's performance-wise not the right > thing.
It should be ok for the user interface, and a JVM that uses JIT should beat any performance concerns. If that's not enough, write a "native" version. This is an old idea, but I don't see why it can't use the JVM, instead of less widely available bytecode engines. -- <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 <joswig-ya023180002412960031460...@news.lavielle.com> jos...@lavielle.com "Rainer Joswig" writes:
> I can't wait. I have to do my work now. And I'm doing with > what is available, supported and what is fun. This is > excellent software like CL implementations, scsh, SIOD, XEmacs, ...
That's why I'm still using C++.
> This is childish.
It's also history, as I recall Apple giving up that battle. Using lawyers like that is not healthy, IMHO. I'm merely making the point that YMMV.
Everyone has "tunnel vision", myself included. We can only see things from the point where we stand. That can have a profound effect on what you see. Look in any advocacy newsgroup, and you'll see this.
For example, scsh and XEmacs don't run on every platform. Nice examples, how many people use them? While that isn't a measure of quality, it is a measure of _success_. Maybe it's not your metric for measuring such things, nor mine.
So, none of this shit matters. Not too long ago, Erik called the kind of software that most people will use "shit". What more do I need to say? He's right, of course, but who gives a shit? C++ is king. Tunnel vision is a good way to cope with this unfortunate state.
Let me know when Emacs is king... -- <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
