In article <wk919i3bm8....@laura.ilog.com> da...@laura.ilog.com "Harley Davis" writes:
> Ilog Talk generates DLLs on Windows NT and 95. I just checked out the > ISAPI spec to see how hard it would be to support using Talk, and the > answer looks good. Apparently the ISAPI spec requires your DLL to > export two functions: GetFilterVersion and HttpFilterProc. Producing > an ISAPI-compatible DLL with Talk would require you to write stub > versions of these functions in C++ which would call into Talk to do > the actual work. You could then link this tiny stub DLL with a DLL > produced by Talk's module system which does the actual implementation.
Yes, familiar with the ISAPI spec. It sounds like Ilog Talk could be useful to me.
> The structures used in these functions and any auxiliary API which > works on these structures can be bound to Talk using the automatic C++ > binder, and you can also write the callback functions needed in the > _HTTP_FILTER_CONTEXT structure in Talk.
> We're ready to take your order! Please contact i...@ilog.co.uk to > talk with our UK subsidiary.
Excellent! I can't promise to buy anything, as that'll depend on things like the price. As long as it isn't anything silly, then I'll be interested. If I've overlooked Ilog Talk in the past, it may have been because it uses ISO Lisp, a dialect with which I'm unfamiliar. Right now, I'm less concerned about that than the prospect of coding in C++ every day.
I've ordered more info and your demo CD-ROM, via your website.
Thanks. -- <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
: > Write an article. : Sure, but I only get asked to write about C++. Of course I'll : suggest Lisp instead, after pointing out that I'm unable to say : anything positive about C++.
Here's a thought: select some interesting problem that has a small, clean, easy-to-understand solution in Lisp, but would be a horrible mess in C++. Offer (to whomever it is that asks you to write articles) to write about that topic, without specifying what language you'll use. Write the article with both the Lisp listing and the C++ listing. Most people will remain addicted to C++ but a few careful readers will notice that the Lisp listing is smaller and easier to follow.
For extra credit: arrange some means to collect information back from the readers, and find out what the typical reaction was. Find out what people have in mind as legitimate reasons to avoid Lisp. Write a second article, taking into account what you learned from the first. (You can imagine doing several iterations of this, obviously; if it were actually done, it might do a lot to grow the Lisp-using population.)
For super-double-bonus extra credit: write a Lisp program to do all this for you. -- ------------------------------------------------------------- Will Ware <ww...@world.std.com> web <http://world.std.com/~wware/> PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
t...@intentionally.blank-see.headers writes: > (Allegro's FreeLisp is a nice idea, but only runs on Windows.)
Actually there's also a free trial version for several different versions of Unix. You can request it on www.franz.com and they will mail you a CD. It's a version of Allegro CL (actually Composer) 4.3 with a few features disabled, but still useful and certainly sufficient for an evaluation. -- Simon.
cyber_sur...@wildcard.demon.co.uk wrote: > I'd be more interested in how a magazine mainly read by developers > reported software that used ACL.
Sure.
> I'm doing it. I'm writing a Lisp to C++ compiler, and then see > if I can use it instead of coding in C++ directly. I'll then be > sure to tell whoever I can that's what I've done.
Better use some of the existing Lisp systems and get it working. Add multithreading. Write a free version of CLIM. Port CL-HTTP. Add DLL support. Whatever. Find some guys who will help you. But don't develop your own Common Lisp.
Please don't.
> How do you think that _I_ feel? All you're saying is that > you don;t have a problem, coz you can use MCL. Great.
Genera works great for me, too. So would LispWorks or Allegro CL.
> What have we learned? That there are one or two elists here > insisting that there's no problem, coz they're ok.
Or one guy is masturbating over why he can't use Lisp, nobody gives him a job to do in Lisp, Lisp doesn't fit on a floppy, etc.
> Obviously we should all buy a Mac,
That MCL still exists on the Mac did not come for free. It is the work of some very dedicated developers (now Digitool) and fantastic support by the users (who even provided financial support). People saved it from being dumped by Apple.
The discussion still lacks some constructivism. I would like to see a paper where you/we describe what you/we see as status of Lisp on the PC. Let's list the features of various Lisps compare these to the features needed by some various development task on a PC. Then we have sets of features and can match that against what is state of the art.
Next phase would be to determine can or can we not use Lisp for these tasks. If not why? What is needed for Lisp to be useful? What would be the costs to implement them. Would vendors be able to support that? If not can we have a free Lisp that does support a wide range of the needs of a PC/Windows developer. Would there be enough supporters for such a project. How to get in contact, etc.
We could *talk* forever. But until somebody starts an *action* (for whatever reason), nothing will happen. So guys if you are unhappy with the state of Lisp on the PC, change it! Trying to develop Common Lisp on your own in your spare time will likely fail, given that it takes more than a man year for a usable Common Lisp implementation.
In article <joswig-ya023180000810961323320...@news.lavielle.com> jos...@lavielle.com "Rainer Joswig" writes:
> Better use some of the existing Lisp systems and get > it working. Add multithreading. Write a free version > of CLIM. Port CL-HTTP. Add DLL support. Whatever. > Find some guys who will help you. > But don't develop your own Common Lisp.
> Please don't.
I wouldn't dream of it. Why would it have to be CL? When I say 'Lisp', that exactly what I mean. If I meant Common Lisp, then I'd says so.
> > How do you think that _I_ feel? All you're saying is that > > you don;t have a problem, coz you can use MCL. Great.
> Genera works great for me, too. So would LispWorks > or Allegro CL.
Same with me. I'm not that fussy - so long as I can afford it. I may have to wait some time before anybody offers to buy me a Lisp system.
> > What have we learned? That there are one or two elists here > > insisting that there's no problem, coz they're ok.
> Or one guy is masturbating over why he can't use Lisp, > nobody gives him a job to do in Lisp, Lisp doesn't > fit on a floppy, etc.
Are you denying that you're an elitist? I'm not concerned that I'm not currently using Lisp professionally. What pisses me off is having to use _C++_ when I know there are better tools available. If Lisp was used by a few more people, then I might not need to convince anyone that I should be using it.
Or perhaps you don't think that elitism is such a problem? Are you happy that so much software is being writting in C++?
> > Obviously we should all buy a Mac,
> That MCL still exists on the Mac did not come for free.
Of course not. How much is it, BTW? How many developers don't get to use Macs? I'm not knocking it, as I'm sure it's a great machine. I just regret that it's not more popular than it is.
If you think that asking how we can make Lisp more popular as a development tool isn't constructive enough, then fair enough. Perhaps there are more important issues? I dunno. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
In article <DyxI4r....@world.std.com> ww...@world.std.com "Will Ware" writes: > Here's a thought: select some interesting problem that has a small, clean, > easy-to-understand solution in Lisp, but would be a horrible mess in C++. > Offer (to whomever it is that asks you to write articles) to write about > that topic, without specifying what language you'll use. Write the article > with both the Lisp listing and the C++ listing. Most people will remain > addicted to C++ but a few careful readers will notice that the Lisp listing > is smaller and easier to follow.
I was thinking about something very similar recently, as an intro to an imaginary "Lisp for C++ programmers" book. I'd stress the similarities between a Lisp enviroment and the typical command line enviroment familiar to C/C++ programmers. Instead of a shell, you get a Lisp listener. Instead of programs, you get functions. Instead of a shell language, you have functions and source files. And so on.
> For extra credit: arrange some means to collect information back from the > readers, and find out what the typical reaction was. Find out what people > have in mind as legitimate reasons to avoid Lisp. Write a second article, > taking into account what you learned from the first. (You can imagine doing > several iterations of this, obviously; if it were actually done, it might do > a lot to grow the Lisp-using population.)
Now that's what a magazine column is for! One article a month.
> For super-double-bonus extra credit: write a Lisp program to do all this > for you.
Nah, that's AI. ;-)
BTW, Greg Voss has been doing something like this in his OOP Alley column, in Windows Tech Journal. He's even used CLOS code, when most other writers for that mag use C++ or VB almost exclusively. I'm sure it's not a coincidence that the editor's review of ACL for Windows was a favourable one, indicating that he's not an MS Zombie. In fact, he lost the mag all MS advertising last year, by writing an editorial about editorial independance and attempts to comprimise it by MS.
Any Windows developers reading this newsgroup should read this mag, as it's one of the most objective magazines for Windows developers that I've read. On the other hand, I might think that because I like reading reviews of Lisp and Smalltalk systems. Judge for yourself how objective I am. ;-) -- <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
Will Ware wrote: > Here's a thought: select some interesting problem that has a small, clean, > easy-to-understand solution in Lisp, but would be a horrible mess in C++. > Offer (to whomever it is that asks you to write articles) to write about > that topic, without specifying what language you'll use. Write the article > with both the Lisp listing and the C++ listing. Most people will remain > addicted to C++ but a few careful readers will notice that the Lisp listing > is smaller and easier to follow.
> Will Ware <ww...@world.std.com> web <http://world.std.com/~wware/> > PGP fingerprint 45A8 722C D149 10CC F0CF 48FB 93BF 7289
Possible suggestion for a problem topic: A few years ago, I wrote a program to generate topographic maps from sample elevation data ((x1 y1 z1)(x2 y2 z2)...). I think the project went much better in Lisp than it could have in any(?) other language. Just as a small example, one of the functions to come out of it converted a list of points from the list above to ((x1 x2 ...)(y1 y2 ...)(z1 z2 ...)) and was a generic solution which would work on n dimensional data. Although i don't think (apply 'mapcar (cons 'list ptlist)) is understandable to nonlisp people, its certainly more compact than a similar C++ implementation.
-- Sincerly, Doug Wilson(do...@amgen.com) *** The opinions expressed here are my own and not neccessarily *** *** anyone elses **** *** Disclaimer: These are the opinions of the poster not Amgen Inc.***
In article <DyzMEo....@world.std.com> d...@world.std.com "Jeff DelPapa" writes: > One point that I have made before: Do we want lisp to be truly > widespread? I have been building commercial products in lisp for the > better part of 15 years now. (things like factory capacity planning > tools, and IC design suites) One thing I noticed is that using lisp > lets me get them built with far smaller development staff's, or in > less time given identical staff's. Can you say competitive advantage? > Unfortunately development costs are an ever shrinking part of product > cost, so this isn't the lever it once was. Still, if I can get > something to market before the other guy, I am at an advantage now.
Yes, if Lisp can give us an edge, that should be a major selling point. It's sometimes known as Rapid Application Development, of RAD for short. Is anyone marketing a Lisp system as a RAD tool, and what kind of customer responds to such marketing?
> The CAD suite was built with 35 man years of labor. This had > schematic entry, a full layout editor, with automatic construction of > devices (and this did more than just fets, this was an analog design > tool), a block router, a thermal annealing packing tool, simulation > (two, one high accuracy "spice" and a block level "functional" > simulation), and design rule checking. The C/C++ crowd puts more > labor into just one of those tools.
I'm seriously disappointed by how much effort is required to use some very popular C++ tools, and how much praise these tools get from reviewers and developers.
> BTW: Size isn't an argument anymore. MS Visual C++ is some 250 MB if > you take the "no, I don't want to run from CD" option. The unix > lisp's are at their largest 50mb. (and some are smaller than the 30mb > "minimum" install of VC++, where everything comes off the CD. Anyone > know the minimum no CD install? I remember something like ~70mb) I > will also argue that you really have to count some of the OS in the > product size. My 45 mb lispm images included the OS, Emacs, compiler, > mailer, mail reader, hypertext browser, DNS, file server, etc.
I'll have to purchase a new hard drive soon, for all the tools I use for writing Windows code. I'm tempted to make it a 4 GB drive, as I can expect the file bloat to get _much_ worse. A single tool used by one of the apps I maintain occupies 60 MB of diskspace. Most of that is a tutorial, so that's a worst case. However, it's not unusual for an SDK to be so large.
VC++ currently takes about 200 MB of my HD, while ACL is happy with a mere 24 MB. If the cost of hard drives were a dominant factor is software development, then Lisp might easily win.
We're not the only people to notice how greedy for diskspace some development tools can be. It could be that what distingishes us is that we compare the size of these tools with Lisp systems instead of VB, Smalltalk or whatever. There are plenty of tools for us all to choose from, so what's the problem?
I expect that eventually even project managers will notice this problem. That'll be when we have to plug Lisp as the alternative, instead of, let's say, VB. If we simply insist on using Lisp now, when not so many people appreciate the necessity for an alternative, we may hurt our credibility later, when we need it.
At the moment, I'm still gathering info on Lisps that I could use instead of C++. When I'm successfully developing Windows code in Lisp, I'll be happy to share my experiences, probably somewhere in my homepage. I should also be collecting stuff about problems with C++ - there's enough of it being posted to UseNet! -- <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 fact, he lost [...] all MS advertising last year, by writing an | editorial about editorial independance and attempts to comprimise it by | MS.
has this been documented? that is, did Microsoft attempt to compromise his editorial independence, and, did they, upon his refusal to be compromised, drop all advertising?
not that I will ever buy or use a Microsoft product anyway, but I'd like to have my prejudices and my beliefs in the Evil among us confirmed, once in a rare while.
#\Erik -- I could tell you, but then I would have to reboot you.
In article <3054011456695...@naggum.no> e...@naggum.no "Erik Naggum" writes: > [Cyber Surfer]
> | In fact, he lost [...] all MS advertising last year, by writing an > | editorial about editorial independance and attempts to comprimise it by > | MS.
> has this been documented? that is, did Microsoft attempt to compromise his > editorial independence, and, did they, upon his refusal to be compromised, > drop all advertising?
I've checked the details, and it was actually _two_ years ago. He began with the words, "I was recently invited to serve as a member of Microsoft's Visual C++ development team. I didn't take the job, but some of my colleagues did. In the months to come, you can look forward to reading their reviews of the product they helped create."
This was reported in the Sept '94 issue of Windows Tech Journal, and was followed up in the editorials for the '95 and '96 issue. The '96 editorial included a list of suggestions that any vendor could read and implement. I bet that a few of his ideas would be familiar to one or two Lisp hackers!
> not that I will ever buy or use a Microsoft product anyway, but I'd like to > have my prejudices and my beliefs in the Evil among us confirmed, once in a > rare while.
You can check the details with the man himself, by emailing him at 76701...@compuserve.com, or in section 9 of the Software Development forum (SDFORUM) on CompuServe. -- <URL:http://www.enrapture.com/cybes/> You can never browse enough Future generations are relying on us It's a world we've made - Incubus We're living on a knife edge, looking for the ground -- Hawkwind
cyber_sur...@wildcard.demon.co.uk wrote: > Same with me. I'm not that fussy - so long as I can afford it. > I may have to wait some time before anybody offers to buy me a > Lisp system.
Haha.
> Are you denying that you're an elitist?
Why? Because I'm using a Mac, Lisp, MCL, Computers?
> If you think that asking how we can make Lisp more popular > as a development tool isn't constructive enough, then fair > enough.
cyber_sur...@wildcard.demon.co.uk (Cyber Surfer) writes: > [I need] Full Win32 support. The C++ tools I have aren't even up to date. > It doens't look like the Windows support in DEC's compiler has > been updated for well over a year, and is Win16, not Win32.
DEC's Scheme->C supports win32 and win16, and has done for well over a year. Perhaps the win32 patch file (NT-15mar93.patches, dated Mar 14 1995) could have been better named, but Windoze 95 didn't actually exist back then. As far as I'm aware the win32 API hasn't changed (at the level required by the Scheme interpreter and library) in that time. There may have been changes to the GUI API to support the Windoze 95 look and feel, but the basic system runs as a console application. Anyway, that's what cdecl is for :-).
> I could in theory add Win32 support. In practice, who knows? > If somebody else did, then they might have done it already.
It has been done--I did it prior to the Windows NT 3.51 release.
> However, if I ever get the time, I'll see what I can do with DEC's > compiler. You never know, do you?
Well, since you asked so nicely... You can build the interpreter and the shared dll on win32 using Visual C++ version 2.2. (I see no reason why 4.0 shouldn't work, I just haven't tried.) You can also build and use the compiler although a trivial amount of work remains to allow the command line arguments to be supplied if you need them (they currently still try to special case on win16).
Wrap that MFC API with cdecl and a SOS framework, then write a meta-circular GUI development environment to prove how easy-to-use it is and the world will beat a path to your ftp server. Or not. Have fun.
In article <l3k9stoe1g....@OASIS007.msc.ie> ritch...@msc.ie "Russell Ritchie" writes:
> DEC's Scheme->C supports win32 and win16, and has done for well over a year. > Perhaps the win32 patch file (NT-15mar93.patches, dated Mar 14 1995) could > have been better named, but Windoze 95 didn't actually exist back then. As > far as I'm aware the win32 API hasn't changed (at the level required by the > Scheme interpreter and library) in that time. There may have been changes to > the GUI API to support the Windoze 95 look and feel, but the basic system runs > as a console application. Anyway, that's what cdecl is for :-).
I'm aware of this. I have the NT patch file, but I'm currently unable to decode it. It's on my ToDo list, right after upgrading the UU software I'm using.
As I've said before, this is just one of a number of options that I'm looking at. Some look more promising than others, depending on factors like the amount of work (i.e. time) required to get the thing working. As I'm not looking specifically for a Scheme to C compiler, but _any_ tool that'll help me.
Tools that have a simple install, work immediately, and have direct support for the APIs I need, may well get my attention sooner than, let's say, DEC's Scheme to C compiler. This is not a comment on the quality of that tool, but a reflection of the demands made by the need to meet deadlines etc.
> > I could in theory add Win32 support. In practice, who knows? > > If somebody else did, then they might have done it already.
> It has been done--I did it prior to the Windows NT 3.51 release.
No doubt. Do you mean that it has support for the latest Win32 APIs? It might be more than a little unfair to compare this Lisp compiler with VC++ 4.2, with its IDE and various wizards, but that's what a lot of Windows developers _will do_. Even if I had the time to get DEC Scheme to C compiler working, which I hope to do RSN, I've no idea if it can create a DLL. If it can't do this, then I'll have to add it, which will take more time.
> > However, if I ever get the time, I'll see what I can do with DEC's > > compiler. You never know, do you?
> Well, since you asked so nicely... You can build the interpreter and the > shared dll on win32 using Visual C++ version 2.2. (I see no reason why 4.0 > shouldn't work, I just haven't tried.) You can also build and use the > compiler although a trivial amount of work remains to allow the command line > arguments to be supplied if you need them (they currently still try to special > case on win16).
I don't have a copy of VC++ 2.2 - I don't even have VC++ 4.2. What I have is 4.0, which is...missing a lot of features that I need, and apparently full of bugs. I can confirm that VC++ 4.0 has trouble compiling the interpreter, but I'm hoping that the problem is a trivial one that'll not take long to find and fix. If I get it working, I'll let you know.
> Wrap that MFC API with cdecl and a SOS framework, then write a meta-circular > GUI development environment to prove how easy-to-use it is and the world will > beat a path to your ftp server. Or not. Have fun.
Sure, if and when I get the time. I really doubt it, as I have more than enough things to do already, and I get paid for them, giving them a significantly higher priority. Compilers like DEC's will always lose under these conditions. There may be a number of ways in which to change the conditions, like quiting my job, or convincing my boss that a Lisp to C compiler is more vital to our success as a company than meeting the demands of clients. Wish me luck...
I can hardly complain about a free lunch, even if I'm prepared to spend (my own) money on the tools that (I believe) I need, which I am. I'm trying hard not to sound bitter, but I'm not sure it's working. I just hate using C++ instead of Lisp. As others have pointed out, I _do_ have a choice. I can insist on using Lisp (but _who_ pays for it?), or quit my job. It's not a great choice, but I'm saving my money anyway, as I'm sure I'll need it.
My current favourite (I'll know more when I get more info, which should be any day) is Ilog Talk. It looks like it'll work _now_, without needing much, if any, work. Since time is critical, and it takes almost no time at all to spend 22K francs, this may well be the one for me. When I have the money, that is. Meanwhile, I can use my time profitably, meeting deadlines etc.
Anyway, thanks. I'm at least considering Lisp as an option for work, rather than just using it in my own time, or ignoring it completely, as many seem to be doing. So there's hope. ;) -- <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
