Thoughts on Franz Inc., ACL pricing, etc.
C. H. Graham
Here's my $ .02 on ACL for Windows, Franz Inc. pricing, etc.
I'm an independent consultant. I bought the Professional version of ACL
Windows,
because I am doing some product development and, based on wide experience,
I believe Lisp is quite simply the best programming language in existence.
As a "Common Lisp - The Language" implementation, ACL is an excellent
product.
In the little contact I have had with Franz Inc. employees, I have found
them to be
helpful and fair.
ACL does lag the evolution of Windows itself (lacking as it does
higher-level
Lispian/CLOS interfaces to the various Win32 system services, OLE/ActiveX,
multi-threading, etc.). This is of course a real problem for the Win32
developer,
and I, for one, am paying close attention to how (and how quickly) Franz
improves the ACL for Windows product.
Given economy of scale, and expertise required to produce a commercial Lisp
implementation, I'm not surprised that ACL for Windows cost more than VC++,
however I would MUCH rather pay a royalty on the product I sell than pay
such
a large premium up front. I'm sure it turns a lot of developers away from
Lisp.
Also, I feel that having to, in effect, pay extra for WinSock in Lisp, is
weird
and plays to a self-defeating aspect of Franz's situation in the
marketplace.
Ditto for the real editor.
By way of comparison, consider Visual Cafe (Java + RAD) from Symantec...
dirt cheap, very, very good, and you certainly don't pay any more for
sockets.
I could buy Visual Cafe about 25 times over for what ACL Professional cost
me.
Basically, it all boils down to a "for the love of Lisp" situation, and
that is
unfortunate...
Chris
Dave Tenny
With respect "C. H. Graham" <cgr...@cgo.wave.ca>'s comments
on Franz's Allegro/PC product:
I second most of what you mentioned. Good product, good support.
Lagging in Windows application development and deployment support.
However there's a point below on runtime systems where we have different points
of view.
[...]
>Given economy of scale, and expertise required to produce a commercial Lisp
>implementation, I'm not surprised that ACL for Windows cost more than VC++,
>however I would MUCH rather pay a royalty on the product I sell than pay
>such
>a large premium up front. I'm sure it turns a lot of developers away from
>Lisp.
On this point I completely disagree. I'm trying to use ACL for two things
1) Server side development in which some royalty cost might be acceptable.
2) Client side applications (which interface with the server), where
royalties would absolutely kill my product viability. I need to distribute the
client for nearly free. I need to be able to generate an executable and
distribute it free of royalties.
I can do this with Franz' product, though the runtime system generator
is extremely painful to use. But adding royalties to it would render it
useless for me. As it is, I'm forced to consider recoding my client logic
in Java to increase my platform availability. But for now, Lisp is too
useful in helping me deliver quickly to consider alternatives.
>
>Also, I feel that having to, in effect, pay extra for WinSock in Lisp, is
>weird
>and plays to a self-defeating aspect of Franz's situation in the
>marketplace.
>Ditto for the real editor.
Yes, the standard edition is pretty useless without a real editor.
While you can get free Emacs for NT, they only ship the ACL<->Emacs
(editi) interface with the professional edition.
>Basically, it all boils down to a "for the love of Lisp" situation, and
>that is
>unfortunate...
Well, the love of Lisp, and the ROI for the decreased time required to deliver
applications. Give me DEFMACRO and DEFCLASS any day for productivity.
Dave Tenny
te...@games.ultranet.com
Cyber Surfer
With a mighty <333a786e...@news.ultranet.com>,
te...@games.ultranet.com uttered these wise words...
[good points about runtime royalties deleted]
> Yes, the standard edition is pretty useless without a real editor.
This is where I disagree. I love the editor you get with ACL/PC (I
can't comment on the Unix version), and wouldn't change it. I
prefer to have the very simple visual indication of matching
parentheses to any number of "smart" keyboard commands.
> While you can get free Emacs for NT, they only ship the ACL<->Emacs
> (editi) interface with the professional edition.
This isn't a problem for non-Emacs users, like me. ;) Obviously, not
everyone will feel this way, but not all Lisp programmers are also
Emacs users.
> >Basically, it all boils down to a "for the love of Lisp" situation, and
> >that is
> >unfortunate...
>
> Well, the love of Lisp, and the ROI for the decreased time required to deliver
> applications. Give me DEFMACRO and DEFCLASS any day for productivity.
I feel the same way. Unfortunately, it's hard to turn any arguments
for productivity into money to pay for a tool, esp when there's mass
marketing convincing most people that non-Lisp tools are the only way.
This is IMHO why it's a "for the love of Lisp" situation. You have to
convince people who've already bought C++, Java, VB, and all the memes
that go with these languages.
If you get paid to use Lisp, then I wish you luck. Most of us have to
struggle with lesser tools, but which can strangely deliver the apps
that we're asked to write, while Lisp cannot. In the case of ACL/PC,
the price alone is enough to ensure that it can't be used by most
programmers. (Please note that I didn't say "most Lisp programmers".)
The long list of features supported by C++ but not by ACL/PC should be
another big problem. You may be very productive with a tool, but if
that tool can't use the technology (like ActiveX), then some of us
won't be able to use it. Franz may get away with asking $3000 for a
product that offers a programmer less support for Windows than VC++,
but I don't call that a justification. It's just Franz telling us that
they don't consider most programmers to be potential customers.
You don't have to love C++ to use it. You may even hate it, but you
may still be forced to use it, or look for another job. That sounds
to me like a real "for the love of Lisp" situation.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please remove the "nospam" if you want to email me.
Erik Naggum
* Cyber Surfer
| You have to convince people who've already bought C++, Java, VB, and all
| the memes that go with these languages.
|
| If you get paid to use Lisp, then I wish you luck. Most of us have to
| struggle with lesser tools, but which can strangely deliver the apps that
| we're asked to write, while Lisp cannot.
well, it seems that this is your particular meme and that it isn't going to
die no matter how much evidence you get to the contrary. frankly, I find
this all very tiring. it also seems as if you argue mainly to support this
meme and that you would find any new argument to support it should your
previous arguments fail to do that.
| In the case of ACL/PC, the price alone is enough to ensure that it can't
| be used by most programmers.
another meme that won't die with you seems to be that the price of Allegro
for Windows is that of the Professional version, only. how many times must
you be told that the price of the standard version is less than USD 600?
frankly, I'm getting the impression that you're grasping for straws to
stave off something that looks suspiciously like fear of actually getting a
Lisp environment and having to _prove_ your alleged love of Lisp. this has
all been going on for too long, now. it's time to realize that you can't
program in Lisp or that you actually can and take full responsibility of
the consequences of either choice. you shouldn't just keep going about how
you can't make a decision. if you do, it certainly isn't Lisp's fault.
| The long list of features supported by C++ but not by ACL/PC should be
| another big problem.
hm. I can still program in assembly and the amount of extra work to get
the object-oriented features of C++ is not prohibitive. the way C++ is
designed, it is in fact quite easy to get it. the main feature of C++ is
that the compiler catches a number of minor problems in the code. the way
it does a lot of mumbo-jumbo (like calling constructors and destructors as
if the compiler had a free will) is in fact a serious _barrier_ to quality
code. as for as the syntax goes, the language is mainly automating naming.
the language just isn't smart enough to really warrant the cost of the
complex syntax and its complex semantics; the underlying features are
actually _very_ simple. in contrast, I would have to work a _lot_ to get
even a semblance of Lispness, and when I need that, I need it _bad_.
C++ really doesn't give much over assembly languages (especially not if you
have a good macro system). Lisp provides easy access to a lot of highly
complex features that are fundamentally _hard_ to do in assembly. my
experience is that it's a _lot_ easier to get C++ functionality in Lisp
than to get Lisp functionality in C++. it seems that some would like
everything to be equally easily accessible in Lisp, despite the obvious
differences of approach, and that doing things natural to a Lisp programmer
would be as prohibitive to a C++ programmer as doing it in assembly.
exempli gratia: implement `apply' in C++.
| You may be very productive with a tool, but if that tool can't use the
| technology (like ActiveX), then some of us won't be able to use it.
this is getting silly. if you can do it in C++, you can do it in Lisp.
there are many levels of effort needed to get things done. if it's easier
to talk to ActiveX in C, do it in C, then build a sufficiently advanced
interface to it that you don't need to mess with the minutiae. Franz'
Foreign Function Interface in Allegro for Windows is very good. if you
need to write a hundred lines of glue code to get it to work, what's that
compared to the pain of writing all of it in C++?
| Franz may get away with asking $3000 for a product that offers a
| programmer less support for Windows than VC++, but I don't call that a
| justification. It's just Franz telling us that they don't consider most
| programmers to be potential customers.
Franz is giving away a Lisp environment for free, then charge $600 for the
standard version, and you can buy the individual pieces that go into the
Professional version piecemeal, or buy the whole thing for USD 2500 (new
prices after 1997-04-01). if you can't absorb a cost of USD 2500 if you
are a professional programmer, the programming language isn't your biggest
problem.
| You don't have to love C++ to use it. You may even hate it, but you may
| still be forced to use it, or look for another job. That sounds to me
| like a real "for the love of Lisp" situation.
I wrote a lot of C++ code with Emacs. the repetitiveness of the C++ code,
with stupid declarations all over the place that the system should have
figured out on its own, the irritating requirement that all methods must be
declared in the class itself, etc, can all be solved mechanically, and
writing a small language that takes care of all this is really simple. I
later graduated to Common Lisp when I discovered that I was fast removing
myself from C++ semantics, not just syntax. it was then that I discovered
how assembly-language-like C++ is and how assembly-language-unlike Lisp is,
and consequently why I thought in Lisp in Lisp and in assembly in C++.
#\Erik
--
I'm no longer young enough to know everything.
Erik Naggum
* Cyber Surfer
| Does ACL/PC support deliver in DLLs? No, it does not. Franz admit that,
| even if you do not.
should I "admit" something? who are you kidding? you know, I think "DLL"
is just your current excuse. if Franz comes around and provides us with a
DLL for Common Lisp and a DLL builder that can exploit it, I'm 99% certain
that you will _still_ bring "bad news" and find some other show-stopper for
your needs.
| The Standard Version doesn't deliver stand alone programs. Ask Franz.
look, I had a Professional version of Allegro for Windows installed at
client's site. I know reasonably well what both can and cannot do.
| As I said, it can't do something that a C++ system can do, and in this
| case, at half the price. Like or not, but some people care about such
| things.
my computer can't make hot water for my coffee in the morning, yet it costs
about 300 times as much as the water heater. bum deal, huh?
| In other words, I'll be wasting a lot of money on a fabulous tool that I
| can't use professionally, because I'm asked to write code that it can't
| produce, i.e. DLLs.
this is quite odd. Emacs cannot make stand-alone binaries, yet anybody who
watches me work would see that I work only in Emacs and yet I produce a
stand-alone binary every now again. what does it take to build a DLL?
could you fruitfully have used Lisp as part of the process?
| I'm expected to [use] C/C++ or Java, because these are the tools that my
| colleagues use. Now, if this unusual, then I might dismiss it as a case
| of bad luck, and perhaps look for another job.
I don't claim to know The Market According to Gates, but there are others.
I went out of my way to locate other markets, and they're there allright.
I discovered that it isn't all that difficult to have people fork over the
money for the Unix version of Allegro. if I save only a day's of work if a
client buys the Standard version of Allegro for Windows, we'd break even.
if I save a week of time, we'd break even with the Professional version.
should I save more than this, it's net earnings.
my current Lisp project uses Allegro for Windows and it has proved so hard
that it would be impossible to do it in C++ and my client would have
scrapped the project and hired more people to do the work manually. we'll
be installing a working version on April 3. in the process, I've been
through more research (= failed experiments, to be honest) than I would
have managed in as many years as I have used months should I have used C++.
| Alas, it isn't at all unusual. Your meme appears to be that it is
| unusual.
NO! dammit! pay attention, will you? all I'm saying is that the market
you consistently deny that exists, does in fact exist and that it is not
hard to enter it, nor is it very hard to convince people to let you use
Lisp if you know what you're doing.
| Remember, I didn't say that this was the case for _Lisp_. I'm saying
| that's the case for the vast majority of Windows developers.
I know this is a family newsgroup, but fuck the majority! you aren't the
majority, Martin, and neither is any other individual. each of us is the
ultimate minority. as long as we are a healthy community in which we can
get work done and enlighten each other, who the hell cares how many there
are of the others? the majority of people on this planet do not speak
English. help! help! what are we gonna _do_? drop English now!
| Don't tell me, I _want_ Lisp. It's the people who don't want it that are
| the problem. I'm not your enemy, Erik, just the guy with the bad news.
| Please don't shoot the messenger.
if you can't shoot him, what good is a messenger? (I have worked with a
few newspapers and a good number of journalists over the years, and I
believe the saying "don't shoot the messenger" was invented by a journalist
union leader to save his own miserable hide.)
seriously, we have received your message. there's no need to resend it.
| I know. I agree. It doesn't help me, or anyone else. Tell _MS_. Tell
| Borland. Tell Symantec. Stop their marketing people from selling us C++
| memes. We choose Lisp, while the majority of programmers still choose
| C++, Java, and VB.
seems that marketing people could take lessons from you. you actually
believe only what you are served from the marketing sources, don't you?
didn't your mom tell you to wear meme-resistant gear when it rains lies and
deception?
seriously, the majority is always fundamentally irrelevant for anybody who
is not going into politics or marketing. if you are, please say so, but
you give the impression sometimes of being a programmer. what the majority
does or does not do should not concern you. you don't have a responsiblity
to make the lies of the marketing staffs and the politicians come true.
| > exempli gratia: implement `apply' in C++.
|
| Why? I don't have time to do that, I have work to do that I'm paid to
| do.
I'm stunned. you can't implement `apply' in C++. that should have been
pretty darn obvious by now.
| Please give me credit for knowing my job.
why? I don't know anything about your work other than you seem to be hired
to program in C++ and hate your job, yet won't do diddly to change it.
| Anyway, if this problem was unique to me, we wouldn't be discussing this,
| as the majority of programmes would be using Lisp, and as I've chosen
| Lisp, that's what I'd be using.
why this obsession with the majority, Martin? does it make your whining
any less irrational if you can point to a lot of other people as an excuse
for not going your own way? if you can be in at least one minority, what's
the point of being alive? why, join the majority of dead people!
| You don't have to convince me, I'm not your enemy.
yes, you are. you bring nothing but bad news, and I don't need that.
| He's sympathetic, and yet he still can't change the world.
I change the world every day. you don't notice it, of course, but neither
does a buddhist monk in Tibet notice the decisions made by Bill Gates.
the only world you _can_ change is your own.
if _you_ won't start with yourself, who will?
| People need to deliver software, and at a "reasonable" price. We may not
| like the way that they do it, but some of us will have to work with it.
if you deliver end-user applications, the language has no bearing on what
you do. if you don't deliver end-user applications, you don't have to
deliver applications at a reasonable price. in what way is this wrong?
| I'm simply being pragmatic.
of all the things you are, "pragmatic" is the least likely option. if you
were pragmatic, you would have acquired a Lisp system and used it to show
your boss or anyone else that you could be more productive with it than
without and then you would be able to write more and more Lisp code.
| I wish I could afford to be dogmatic, and insist on using Lisp.
but you _are_ dogmatic and insist upon _not_ using Lisp!
| If you have a random sample of Windows developers who use Lisp instead of
| C++, Delphi, VB, etc, then I'd like to know where such a random sample
| may be found, and why nobody else knows about them. If there's a
| conspiracy, then we should expose it. Please help me, as I'd love to do
| this, if it's possible.
I'm going to work on a project for the European Union starting in May. we
will write it in Common Lisp, using CLOS for a lot of the hairy stuff that
C++ can't do. it will require SGML and Hytime expertise and will involve a
lot of people and a _lot_ of time. I'm not going to let you near it, nor
tell you about it in detail, because I don't want a person as negative as
you are on the team.
if there is a conspiracy, I'd say it's one that aims to keep people who
only bring bad news about Lisp out of the lab and out of sight.
there, back in the score file! no more bad news for a while. whew!
Cyber Surfer
With a mighty <30685506...@naggum.no>,
er...@naggum.no uttered these wise words...
> well, it seems that this is your particular meme and that it isn't going to
> die no matter how much evidence you get to the contrary. frankly, I find
> this all very tiring. it also seems as if you argue mainly to support this
> meme and that you would find any new argument to support it should your
> previous arguments fail to do that.
Does ACL/PC support deliver in DLLs? No, it does not. Franz admit
that, even if you do not. The same is true for LispWorks for Windows.
If you have evidence that you've not yet shared, please do so.
> | In the case of ACL/PC, the price alone is enough to ensure that it can't
> | be used by most programmers.
>
> another meme that won't die with you seems to be that the price of Allegro
> for Windows is that of the Professional version, only. how many times must
> you be told that the price of the standard version is less than USD 600?
The Standard Version doesn't deliver stand alone programs. Ask Franz.
As I said, it can't do something that a C++ system can do, and in this
case, at half the price. Like or not, but some people care about such
things.
I'm not claiming that everyone does, or that all Lisp programmers will
suffer because of this, but I am saying that a great many people do,
and that will be a problem for many of us.
> frankly, I'm getting the impression that you're grasping for straws to
> stave off something that looks suspiciously like fear of actually getting a
> Lisp environment and having to _prove_ your alleged love of Lisp. this has
> all been going on for too long, now. it's time to realize that you can't
> program in Lisp or that you actually can and take full responsibility of
> the consequences of either choice. you shouldn't just keep going about how
> you can't make a decision. if you do, it certainly isn't Lisp's fault.
<sigh> I could use ACL/PC, sure, but I won't get paid to use it. In
other words, I'll be wasting a lot of money on a fabulous tool that I
can't use professionally, because I'm asked to write code that it
can't produce, i.e. DLLs. In fact, it's far worse than that. I'm
expected to C/C++ or Java, because these are the tools that my
colleagues use. Now, if this unusual, then I might dismiss it as a
case of bad luck, and perhaps look for another job.
Alas, it isn't at all unusual. Your meme appears to be that it is
unusual. Remember, I didn't say that this was the case for _Lisp_. I'm
saying that's the case for the vast majority of Windows developers.
It's probably also true for a fair number of Unix and Mac developers,
too, but can't say. Perhaps the Mac and Unix developers that I know
are unrepresentative.
> | The long list of features supported by C++ but not by ACL/PC should be
> | another big problem.
>
> hm. I can still program in assembly and the amount of extra work to get
> the object-oriented features of C++ is not prohibitive. the way C++ is
> designed, it is in fact quite easy to get it. the main feature of C++ is
> that the compiler catches a number of minor problems in the code. the way
> it does a lot of mumbo-jumbo (like calling constructors and destructors as
> if the compiler had a free will) is in fact a serious _barrier_ to quality
> code. as for as the syntax goes, the language is mainly automating naming.
> the language just isn't smart enough to really warrant the cost of the
> complex syntax and its complex semantics; the underlying features are
> actually _very_ simple. in contrast, I would have to work a _lot_ to get
> even a semblance of Lispness, and when I need that, I need it _bad_.
Don't tell me, I _want_ Lisp. It's the people who don't want it that
are the problem. I'm not your enemy, Erik, just the guy with the bad
news. Please don't shoot the messenger.
> C++ really doesn't give much over assembly languages (especially not if you
> have a good macro system). Lisp provides easy access to a lot of highly
> complex features that are fundamentally _hard_ to do in assembly. my
> experience is that it's a _lot_ easier to get C++ functionality in Lisp
> than to get Lisp functionality in C++. it seems that some would like
> everything to be equally easily accessible in Lisp, despite the obvious
> differences of approach, and that doing things natural to a Lisp programmer
> would be as prohibitive to a C++ programmer as doing it in assembly.
I know. I agree. It doesn't help me, or anyone else. Tell _MS_. Tell
Borland. Tell Symantec. Stop their marketing people from selling us
C++ memes. We choose Lisp, while the majority of programmers still
choose C++, Java, and VB.
> exempli gratia: implement `apply' in C++.
Why? I don't have time to do that, I have work to do that I'm paid to
do. Please give me credit for knowing my job. Anyway, if this problem
was unique to me, we wouldn't be discussing this, as the majority of
programmes would be using Lisp, and as I've chosen Lisp, that's what
I'd be using.
[more misunderstandings deleted]
You don't have to convince me, I'm not your enemy. I've put all these
arguments to my boss. (He described the experience as "stressful".)
He's sympathetic, and yet he still can't change the world. It's tough
business.
The problem is not that anyone wants to stop us from using Lisp. Such
people may exist, but they're not the problem. No, I think that the
problem is a rather more basic one. People need to deliver software,
and at a "reasonable" price. We may not like the way that they do it,
but some of us will have to work with it.
I'm simply being pragmatic. I wish I could afford to be dogmatic, and
insist on using Lisp. It's not all bad news, tho. Perhaps DylanWorks
will be what I and some other Windows developers are looking for. Have
you seen the list of Windows features that Harlequin say DylanWorks
will support, and have you noticed how few of them are supported by
ACL/PC? These things are more important to Windows developers than the
APPLY function, or anything like it.
If you have a random sample of Windows developers who use Lisp instead
of C++, Delphi, VB, etc, then I'd like to know where such a random
sample may be found, and why nobody else knows about them. If there's
a conspiracy, then we should expose it. Please help me, as I'd love to
do this, if it's possible.
Thanks.
Brian Rogoff
On Fri, 28 Mar 1997, Cyber Surfer wrote:
> I feel the same way. Unfortunately, it's hard to turn any arguments
> for productivity into money to pay for a tool, esp when there's mass
> marketing convincing most people that non-Lisp tools are the only way.
> that go with these languages.
I haven't seen any marketing aimed at convincing people that
"non-Lisp" tools are the only way. Certainly, tool vendors hawk their
tools, and if those tools aren't Lisp, Lisp isn't hawked.
> If you get paid to use Lisp, then I wish you luck. Most of us have to
> struggle with lesser tools, but which can strangely deliver the apps
> that we're asked to write, while Lisp cannot. In the case of ACL/PC,
> the price alone is enough to ensure that it can't be used by most
> programmers. (Please note that I didn't say "most Lisp programmers".)
If you don't like the ACL/PC price, there is Harlequin. Or you
could port CMUCL to Windows. (BTW, anyone out there tried this yet?)
> The long list of features supported by C++ but not by ACL/PC should be
> another big problem. You may be very productive with a tool, but if
> that tool can't use the technology (like ActiveX), then some of us
> won't be able to use it. Franz may get away with asking $3000 for a
> product that offers a programmer less support for Windows than VC++,
> but I don't call that a justification. It's just Franz telling us that
> they don't consider most programmers to be potential customers.
Hmmm, I'm pretty sure that Harlequin Lisp comes with ODBC drivers,
DDE support, a foreign language interface. I imagine ACL/PC does too.
Specifically, what do you want? Are you so sure that the current commercial
offerings can't help you?
> You don't have to love C++ to use it. You may even hate it, but you
> may still be forced to use it, or look for another job. That sounds
> to me like a real "for the love of Lisp" situation.
Sometimes you use C or C++ to access the API of some piece of
software. Why get upset about it? Yeah, it might be nice if CL had a
standardized minimal FFI, like the Interfaces.C package in Ada, but the
current situation is not horrible. For ~ $700 you can buy Harlequin CL with
CLIM. Thats definitely an acceptable price for a Windows development
environment. You should be overjoyed.
-- Brian
Bao Chau Ha
Dave Tenny (te...@games.ultranet.com) wrote:
: >Ditto for the real editor.
: Yes, the standard edition is pretty useless without a real editor.
: While you can get free Emacs for NT, they only ship the ACL<->Emacs
: (editi) interface with the professional edition.
I got ACL/Windows professional version 1.0 and 2.0. There were no real
editor in them. Guess what happened. :-(
Bao
Cyber Surfer
With a mighty <30685727...@naggum.no>,
er...@naggum.no uttered these wise words...
> | Does ACL/PC support deliver in DLLs? No, it does not. Franz admit that,
> | even if you do not.
>
> should I "admit" something? who are you kidding? you know, I think "DLL"
> is just your current excuse. if Franz comes around and provides us with a
> DLL for Common Lisp and a DLL builder that can exploit it, I'm 99% certain
> that you will _still_ bring "bad news" and find some other show-stopper for
> your needs.
In my case, yes, there's another problem. I didn't mention it because
it might not apply in larger companies, where there could be more than
one Lisp programmer. Alas, where I work, I'm the only one. That's why
I've been asked to use Java. Still, other programmers may be more
fortunate, so I can't say for sure that this will be a big problem.
I'll be amoung the first to congratulate Franz for adding such a
feature to their Lisp. However, if you think that's all I'm talking
about, then you'd be mistaken. The point is that there are things that
people are doing with C++, and any Lisp for Windows will have to
compete _on the same terms_. Your experience may be different, but I'm
willing to bet that you'r enot a typical Windows developer.
> | The Standard Version doesn't deliver stand alone programs. Ask Franz.
>
> look, I had a Professional version of Allegro for Windows installed at
> client's site. I know reasonably well what both can and cannot do.
Hold on, Erik. Weren't we discussing the Standard Version just now? I
too know what the Professional Version can and cannot do - I've
checked with Franz. I'm also aware of the limitations of the Standard
Version, which is what the $595 will get you.
> | As I said, it can't do something that a C++ system can do, and in this
> | case, at half the price. Like or not, but some people care about such
> | things.
>
> my computer can't make hot water for my coffee in the morning, yet it costs
> about 300 times as much as the water heater. bum deal, huh?
We're discussing Windows development tools, are we not?
> | In other words, I'll be wasting a lot of money on a fabulous tool that I
> | can't use professionally, because I'm asked to write code that it can't
> | produce, i.e. DLLs.
>
> this is quite odd. Emacs cannot make stand-alone binaries, yet anybody who
> watches me work would see that I work only in Emacs and yet I produce a
> stand-alone binary every now again. what does it take to build a DLL?
> could you fruitfully have used Lisp as part of the process?
Are you suggesting that Windows programmers use Emacs to develop and
deliver their apps? It may be possible to write _some_ apps that way,
but I can't imagine too many users appreciating it. I'm not knocking
Emacs in any way, as I consider it to be a fine programmer's editor.
However, most computer users are not programmers.
Can Emacs use OCX controls?
> | I'm expected to [use] C/C++ or Java, because these are the tools that my
> | colleagues use. Now, if this unusual, then I might dismiss it as a case
> | of bad luck, and perhaps look for another job.
>
> I don't claim to know The Market According to Gates, but there are others.
> I went out of my way to locate other markets, and they're there allright.
I know. I've said this myself, right here in this newsgroup. Remember
me mentioning Smalltalk MT? It uses OCX controls, can deliver in a
DLL, and supports multi-threading. It also costs less than the
Standard Version of ACL/PC.
> I discovered that it isn't all that difficult to have people fork over the
> money for the Unix version of Allegro. if I save only a day's of work if a
> client buys the Standard version of Allegro for Windows, we'd break even.
> if I save a week of time, we'd break even with the Professional version.
> should I save more than this, it's net earnings.
I agree. Still, ACL/PC can't do what I need. As I've said, if my
demands were atypical of Windows developers, I'd dismiss this problem
as something unique to myself.
[more stuff deleted]
> > You don't have to convince me, I'm not your enemy.
> yes, you are. you bring nothing but bad news, and I don't need that.
<sigh> You may not like it, Erik, but you'll find a lot of people
agreeing with me. I'd love to deny it, just as you do, but most of us
can either be pragmatic, or unemployed. Your attitude won't change
that, and i'm not even sure if mine will, but I may find the answer
when I get my hands on a copy DylanWorks. _That_ system sounds like it
can do all the things I need to convince people that I should use it
(check the Harlequin announcement, esp the OLE server part).
Did you miss the hostile C++ programmers who used to hassle this
newsgroup? If so, then that may help explain your faith in Lisp's
ability to convince people who neither know nor care about Lisp.
I'm fortunate enough to work for someone who trusts my judgement, and
who isn't a complete C++ fanatic. However, even he has to give his
clients what they demand. DylanWorks should be able to do that, while
at present, ACL/PC cannot. That doesn't make it a poor Lisp, just a
poor system for developing the apps that _most_ people want.
IMHO, denying this doesn't help Lisp. It only makes it worse. I know
that you "don't need that", and I don't need it, either. I _do_ have
to live - and work - with it, even if you don't.
Good luck, Erik. I envy you. You've either convinced your boss, or
your clients, or you're your own boss, in which case you have no right
to tell me how to do _my_ job, nor anyone else in a similar position.
Like a large number of programmers, I get paid to write _Windows_
software. Not Lisp software. I get paid to write it with the tools
that I've told to use, and for some bloody good business reasons, i.e.
giving clients the software they ask for, and thus keeping the
business running. If you can do this in Lisp, that's wonderful, but
either you're not writing the same kind of code, or you get to make
the choice of tools yourself. Most of us do not.
If you prefer to ignore bad news, then just forget all of the above.
Cyber Surfer
With a mighty <Pine.SGI.3.95.970328172856.27613B-
100...@shellx.best.com>,
b...@best.com uttered these wise words...
> If you don't like the ACL/PC price, there is Harlequin. Or you
> could port CMUCL to Windows. (BTW, anyone out there tried this yet?)
Does CMUCL deliver stand alone code? How about in a DLLs? Can it use
ActiveX? As I understand it, the CMUCL port isn't complete yet. I'd
love to use it, if it was, esp if the FFI works with DLLs.
However, I doubt that many Windows people will see it as a good
substitute for tools like VC++. I'll be happy to use it, and I expect
that I will, but I doubt that it'll help me with the code that I'm
asked to write.
Naturally, I could just use it and then justify it later, by saying
that it helped me deliver the code so quickly. I doubt that I'd get
away with this, but I could try it anyway. That's one of the reasons
why I'm eager to see a Win32 port of CMUCL - so I can use it. On the
other hand, I know that I'm expected to produce stand-alone programs,
so this might not be very wise. I've been told _not_ to do this.
If any Windows developers are reading this, and have tried this tactic
and made it work, then I'd appreciate any advise you can give me.
Erik's advise seems to be just to do it, as he's said nothing about
how to deal with the consequences. In fact, he seems to be denying
that there _are_ any consequences. Perhaps I've misunderstood him? I
don't think so, but if I have, then I'd appreciate knowing what it is
that I've missed.
> Hmmm, I'm pretty sure that Harlequin Lisp comes with ODBC drivers,
> DDE support, a foreign language interface. I imagine ACL/PC does too.
> Specifically, what do you want? Are you so sure that the current commercial
> offerings can't help you?
In fact, I've been seriously considering LispWorks for Windows ever
since it was announced. I've only hesitated because of the features
that it doesn't (yet) support, but which would be _very_ useful to me
right now. (I've mentioned the editor in another article.)
How about support for OCX (or ActiveX, depending on what you wish to
call it - MS appear to have renamed OCX/OLE)? A lot of Windows people
consider this to be important. Looking at the mass of OCX controls
available now, it's easy to see why they'd want this.
So, I'm tempted to buy LispWorks simply for my own use, possibly
without CLIM. (Portable code is no value to me at present, but others
will _certainly_ find it useful.) It will be harder to satisfy the
demands of professional Windows developers, either because they're an
awkward lot, many of them may insist on using something else anyway,
they'll think that "Lisp is dead", or some other nonsense. I'm sure
you know what I mean, as we've seen enough of it in comp.lang.lisp
over the years. Developers with even less contact with Lisp may be
less inclined to consider it.
While most of us here are unlikely to be any of those people, some of
us will certainly know - or worse - work with such people. While Erik
may be speaking for the Lisp programmers free of the limited demands
of most Windows people, is it not possible that I might be speaking
for those programmers who are less fortunate? Is it possible that such
developers may exist, may wish to use Lisp, but may be forced to use
something else?
> Sometimes you use C or C++ to access the API of some piece of
> software. Why get upset about it? Yeah, it might be nice if CL had a
> standardized minimal FFI, like the Interfaces.C package in Ada, but the
> current situation is not horrible. For ~ $700 you can buy Harlequin CL with
> CLIM. Thats definitely an acceptable price for a Windows development
> environment. You should be overjoyed.
I've mentioned DylanWorks. If that has a price similar to LispWorks
and MLWorks, i.e. $700 - $800, then it should be very attractive to a
fair number of Windows developes. Curiously, my boss feels far more
positive about DylanWorks than ACL/PC. Perhaps he's thinking that I
won't be the only programmer in the company that could use it. This
could be the reason why Apple changed the syntax. It's a cosmetic
detail, but it's amazing how important this can be to most people.
Considering how important some Lisp people feel the differences
between CL and Scheme are, perhaps this shouldn't be suprising.
So, I _am_ overjoyed. I think I made that clear some time ago. All I'm
saying is that the demands of Windows developers are rather different
to the demands of Lisp developers. This should be obvious from the
success of tools like VC++ and VB, and the emphesis on technologies
like OLE, OCX (now ActiveX), DLLs, etc. It's vital to offer people
tools that they want to use, rather than simply the tools that we, as
Lisp programmers, are happy with.
The price is an important issue, but it's certainly not the only one.
Developers like myself can now afford to buy a commercial Lisp that
can produce complete stand alone programs. If we're free to just write
code without being told which tools to use, then there will be no
problem.
The point I'm making is that we're not all that free. When we're told
to use an OCX control, or deliver code in a DLL, what do we use? Right
now, I suspect that the answer will be DylanWorks, but I could be
wrong. The price may be too high, or some of us may not be able to
wait. Apparently, ILOG Talk can deliver code in a DLL, but it costs
too much for many of us, thus making it less competitive with C++ etc.
If we didn't have to convince non-programmers, this would be so much
simpler. Programmers, on the other hand, may have their own biases,
but it may still be possible to convince them. I'm optimistic about
that, but I don't claim it's easy to do. The demands of clients have
to be met, in order to stay in business. If your clients are different
from mine, that doesn't make my clients any easier to please.
Erik Naggum
* Cyber Surfer
| If any Windows developers are reading this, and have tried this tactic
| and made it work, then I'd appreciate any advise you can give me. Erik's
| advise seems to be just to do it, as he's said nothing about how to deal
| with the consequences. In fact, he seems to be denying that there _are_
| any consequences. Perhaps I've misunderstood him? I don't think so, but
| if I have, then I'd appreciate knowing what it is that I've missed.
fuck you, Martin Rodgers. your incessant use of the word "deny" to try to
make your opponents appear to say something very different from what they
do in fact say is so foul play, so dishonest, so disgustingly manipulative
that it pales in comparison to the extremely negative marketing campaigns
against Lisp and Lisp vendors that you seem to enjoy perpetrating. that
you're too damn stupid to understand what you're doing, doesn't help.
cut the crap, will you, and go back to work. with your campaigns against
Lisp, I would really be surprised if anybody ever let you near a Lisp job.
considering the campaigns where you lie about what others "deny", I would
very much doubt that anybody who have read your crap will let you out of
your C++/Windows hell. if anybody deserve programming for Windows, you do.
| While Erik may be speaking for the Lisp programmers free of the limited
| demands of most Windows people, is it not possible that I might be
| speaking for those programmers who are less fortunate?
"less fortunate"? may whatever god you believe in destroy you! you're a
lazy, whining bum, and that's all. your situation has nothing whatsoever
to do with being "fortunate" -- you don't do shit to improve your own
condition, you only want others to provide you with "features" you "need"
without making the slightest effort to get there yourself. while some of
us have worked hard for years to use Lisp in a commercial setting, you have
the _gall_ to call yourself "less fortunate"!
get the hell out of the way.
Erik Naggum
* Cyber Surfer
| Your experience may be different, but I'm willing to bet that you'r enot
| a typical Windows developer.
that should be an exceptionally easy bet. I've told you several times
already that I don't develop for or in The World According to Gates. I'm
deploying a Lisp solution on an NT box, but it's nowhere near being a
Windows application. it will talk to a Delphi application via sockets,
which will handle the user interface and the Windows specific operations.
the Lisp could even run on a uninfested computer.
| Are you suggesting that Windows programmers use Emacs to develop and
| deliver their apps?
why, yes, of course! but I think you missed the point. what you develop
in and what you deliver need not be the same. I use Lisp to write a lot of
C code for me from a reasonable input language of my own creation. then I
run GCC (under Emacs) to build the binaries. for all intents and purposes,
the source is in a domain-specific language. for all intents and purposes,
I did deliver a C application. these do not conflict. you think they do.
I don't want to write in C, anymore, so I don't. it's as simple as that.
| You may not like it, Erik, but you'll find a lot of people agreeing with
| me.
so what? you could find a lot of people agreeing there's a comet behind
Hale-Bopp and that it's a good idea to commit mass suicide to be picked up.
whoever agrees with you are not important. those who manage to use Lisp
fruitfully even on Windows platforms _are_ important, because they further
the cause, they improve the products, they build applications that others
will hear about. you, on the other hand, keep giving people who don't want
to use Lisp the best arguments in the world, and yet you have nothing to
show for your "bad news" other than your own unwillingness even to _try_.
| I'd love to deny it, just as you do, but most of us can either be
| pragmatic, or unemployed.
get a grip, OK? I'm not denying anything! you have been saying this for
months, yet it remains as untrue as it was the first time you said it.
all I'm telling you is that your "bad news" does not reflect the whole
truth, and that you are consistently bad-mouthing a vendor and a product
that works exceedingly well for a (relevant) lot of people. I get the
impression that _you_ deny these people the right to exist because they
don't match your notion of "most of us" or "the majority".
you are no pragmatist, Martin. if you were, you would find ways to use
Lisp. you don't. you consistently and extremely annoyingly keep ranting
about how you can't use Lisp. you're a negative dogmatist, Martin.
| Did you miss the hostile C++ programmers who used to hassle this
| newsgroup? If so, then that may help explain your faith in Lisp's
| ability to convince people who neither know nor care about Lisp.
I thought it should be obvious by now, and I do get the feeling I'm
repeating myself, but I DO NOT CARE about anybody who "neither know nor
care about Lisp". can't you at least understand _that_?
however, I _do_ care about those who know and care about Lisp, even those
who have problems for which I think Lisp would come to their aid, but I'm
in no hurry to see more of them just for the sheer sake of numbers and I
don't think marketing campaigns to convert people to either a programming
language or a religious faith are morally defensible.
| I'm fortunate enough to work for someone who trusts my judgement, and who
| isn't a complete C++ fanatic.
really? so the judgment that is trusted is that you should not use Lisp?
| IMHO, denying this doesn't help Lisp.
can you get a grip on yourself and stop lying about what other people say?
dammit! I thought I would get rid of the annoyance by scoring you well
below zero, but I can't even leave your articles alone because you're lying
about me in them.
NOBODY IS DENYING ANYTHING OF YOUR FACTS, YOU DIMWIT!
but the fact also remains that it is well below half the truth, and that
you _never_ seem to grasp that there is more to this than your incessant
whining about this feature and that feature that you don't get.
you're like some of the student groups on some campuses -- you only keep
demanding and there's no point in giving you anything you ask for since it
is obvious that you will keep demanding regardless of what you get, indeed
that meeting your demands will only prove to you that your whining "works".
| Good luck, Erik. I envy you. You've either convinced your boss, or your
| clients, or you're your own boss, in which case you have no right to tell
| me how to do _my_ job, nor anyone else in a similar position.
amazing. yes, I'm my own boss, but being one's own boss does not exactly
_lighten_ the requirement to give people what they would like to pay for.
yes, I convince my clients of several things to get a project. (1) that I
can do it. (2) that I can do it within their budget. (3) that I can do it
in a reasonable time. (4) that I can do it better than anybody else for
the same price. (5) that I am an expert at everything I do for pay. (6)
that I need the right tools to get the job done. (7) that they need to
have installed a computer on which I can deploy the result. some or all of
these arguments may involve Lisp. or none.
why should my clients care which programming language I use? if they want
somebody to write in C++ or for the Windows API, they don't have a problem
I would want to solve. if they want something that can be used from C++ or
with the Windows API, that's OK, because no matter how shitty they are, I
can find a way to interface with them, if need be by hiring a programmer
who knows them well, as I have done in the past. I have written so much
glue code in my life that interfacing X to Y is ipso facto possible for all
values of X and Y as long as bits can traverse an interface or a hundred.
believing otherwise, which seems to be your particular angle on life, is
proof positive of gross incompetence.
| Like a large number of programmers, I get paid to write _Windows_
| software. Not Lisp software.
nobody has ever hired me to write Lisp software. people hire me to solve
problems that others think are impossible or that they don't know how to
solve. most of the time, I don't, either, but I usually find a way. most
of the time in the past, that entailed a _lot_ of manual labor. these
days, it still entails manual labor, but I learn more in the process, I
enjoy it more, and I solve much more challenging problems. this difference
is directly attributable to the programming languages used.
| If you can do this in Lisp, that's wonderful, but either you're not
| writing the same kind of code, or you get to make the choice of tools
| yourself. Most of us do not.
I care what "the rest of us" do. I do not care what some unknown majority
does. I am frankly amazed that you care so much about what those you
cannot possibly affect to, and so little about those you can.
| If you prefer to ignore bad news, then just forget all of the above.
don't be such an insufferable idiot! your news is not only bad, it is
stale. it has been reported (mostly by you) literally hundreds of times.
I'm not ignoring or denying the _facts_ you report (such as they are), I'm
denying the _importance_ you to give them, and I'm _this_ close to ignoring
anything _you_ say because you have not brought any fresh information or
data to this forum for a _very_ long time.
perhaps the best part of your "contributions" is how easy you make it for
others to point to "some jackass C++ Windows fool like that Cyber Surfer",
laugh, and go back to making real software, again.
(that other shit piece of his arrived while I was composing this message,
but this is too good to waste.)
Cyber Surfer
With a mighty <30686792...@naggum.no>,
er...@naggum.no uttered these wise words...
> fuck you, Martin Rodgers. your incessant use of the word "deny" to try to
> make your opponents appear to say something very different from what they
> do in fact say is so foul play, so dishonest, so disgustingly manipulative
> that it pales in comparison to the extremely negative marketing campaigns
> against Lisp and Lisp vendors that you seem to enjoy perpetrating. that
> you're too damn stupid to understand what you're doing, doesn't help.
In what way have I misrepresented you? Please note that I didn't say
that I was sure I understood you, and in fact asked for you to clarify
anything that I'd missed. If you're _not_ denying that the demands of
Windows developers include features like delivery in DLLs, OCX, etc,
then you only have to address this issue.
> cut the crap, will you, and go back to work. with your campaigns against
> Lisp, I would really be surprised if anybody ever let you near a Lisp job.
> considering the campaigns where you lie about what others "deny", I would
> very much doubt that anybody who have read your crap will let you out of
> your C++/Windows hell. if anybody deserve programming for Windows, you do.
Campaigns against Lisp? No, if I wanted to attack Lisp then I'd be
promoting Java, instead of asking for Lisps with support for the same
Windows features already supported by compilers for C++, APL, Basic,
Smalltalk, Pascal, and others. The prices and OS support of these
compilers may vary, of course.
Have you noticed that there are C++ programmers who argue against VB
and Delphi? If you think that I'm being negative, then you've no idea
what we, as Lisp programmers, are fighting against. I'm campaigning
_for_ Lisp, but my style is a little different from yours. I'm sorry
that you see that as an attack on Lisp.
I wonder what you think Harlequin are doing, with DylanWorks. Is that
also an "attack"?
> "less fortunate"? may whatever god you believe in destroy you! you're a
I'm an agnostic. ;)
> lazy, whining bum, and that's all. your situation has nothing whatsoever
> to do with being "fortunate" -- you don't do shit to improve your own
> condition, you only want others to provide you with "features" you "need"
> without making the slightest effort to get there yourself. while some of
> us have worked hard for years to use Lisp in a commercial setting, you have
> the _gall_ to call yourself "less fortunate"!
_I_ don't need these features. I thought I'd made that clear. I'm
simply being pragmatic. If I insisted on using Lisp for all my code,
I'd be unemployed. I'm more than happy to use Lisp for _everything_,
but I'm (currently) not allowed to. As I've pointed out, my boss is
very positive about tools like Lisp. He's used Actor and Smalltalk
himself, and appreciated the advantages.
The problem is that the world is not run by programmers, and sometimes
choices like which language to use will be made by people who listen
more to marketing people than better informed voices, like ours.
> get the hell out of the way.
Erik, I've never been _in_ your way. It's the bastards who insist on
apps written in C++ that get in the way. I'm on your side!
Cyber Surfer
With a mighty <30686800...@naggum.no>,
er...@naggum.no uttered these wise words...
> * Cyber Surfer
> | Your experience may be different, but I'm willing to bet that you'r enot
> | a typical Windows developer.
>
> that should be an exceptionally easy bet. I've told you several times
> already that I don't develop for or in The World According to Gates. I'm
> deploying a Lisp solution on an NT box, but it's nowhere near being a
> Windows application. it will talk to a Delphi application via sockets,
> which will handle the user interface and the Windows specific operations.
> the Lisp could even run on a uninfested computer.
I'd say that we have a lot in common. Perhaps the only difference is
that I can't choose the tools I'm paid to develop code with. In this
respect, I'm closer to being a typical Windows developer.
Now, you may have noticed that from time to time in comp.lang.lisp,
people ask why Lisp isn't more successful. One answer might be that
there's a conspiracy to stop Lisp from being used more often than it
is. I'm not a conspiracy theorist, so I'm inclined to look for other
explanations. Perhaps this is a mistake. There are certainly people
who will refuse to allow Lisp to be used on a project, tho I can only
guess at what their _true_ reasons may be. They may, as some do, claim
that there are sound business reasons for choosing something else,
like C++, or Java.
There are programmers who refuse to believe that anything but C++ may
be used for a project, and you may even find one or two who will lie
about the capailities of alternative tools. Many programmers will
simply be ignorant of any alternatives, and their only mistake may be
to assume that the limits of their knowledge are also the limits of
what is possible. This is a serious mistake, but it's easy to make it.
Whether or not that makes it forgivable is a good question. A lot of
people won't have the time to find an answer.
We all do what we can, because we can. I'm pointing out that you may
be able to do some things that others cannot. That may be because you
have an employer who gives you more freedom than others, or it may be
that you're more pursuasive than most of us. I don't know. Please
don't think that just because some of us are not so good at handling
the politics that surrounds and effects programming that we're any
less enthusiastic about a particular tools, like Lisp, that you happen
to use.
> | Are you suggesting that Windows programmers use Emacs to develop and
> | deliver their apps?
>
> why, yes, of course! but I think you missed the point. what you develop
> in and what you deliver need not be the same. I use Lisp to write a lot of
> C code for me from a reasonable input language of my own creation. then I
> run GCC (under Emacs) to build the binaries. for all intents and purposes,
> the source is in a domain-specific language. for all intents and purposes,
> I did deliver a C application. these do not conflict. you think they do.
This is one of my favourite ways of using Lisp. I'm still trying to
educate my colleagues about this, but I suspect that my words are
falling on deaf ears, perhaps because I have a reputation for being a
bit "weird". I strive to be professional, but when I'm told that's not
what's needed, I begin to understand some of the anti-MS anti-Windows
ranting, on UseNet. (Ranting doesn't imply that someone is wrong, of
course.) So, I'm weird. I don't think that's a bad thing.
> I don't want to write in C, anymore, so I don't. it's as simple as that.
I don't choose to use C, but I do choose to work. If the only work
that's available to me is using C++ or Java, I have a simple choice,
either quit or put up with tools I dislike. I've made it clear to my
colleagues that I may quit, rather than continue using these tools.
For now, tho, I choose to be progmatic, rather than dogmatic, as I may
be able to use DylanWorks instead. That may depend on when Harlequin
release it, and the price. I find it strange, tho, that someone
should find Dylan is easier to accept than Lisp, after I've spent an
hour explaining why Lisp is the best tool for my to use. Still...
A few years ago, the prospect of employment looked very attractive,
esp since I'd be working with friends. Now I'm not so sure. I partly
blame you for this, Erik ;-), because you've reminded me so much of
how I used to feel about Lisp, 10 years ago. I feel the same passion
for Lisp, but over the years it became tainted by pragmatism.
Rant on, Erik, and you may give me a good reason for quiting my job,
and searching for one that allows me to use tools that I can respect,
and to write software that I can be proud of. Right now, I'm more
likely to feel ashamed - tho not because of the quality of the code is
necessarily low, but because I set such a _high_ standard.
A year from now, I may be thanking you! In fact, why wait? Well,
perhaps your lack of support doesn't help much, but I won't hold that
against you. In your position, I might feel the same way. I'm not sure
I'd express it in the same way, but that's another matter.
If you have a use for a Lisp programmer teleworking from England,
please let me know. ;-) However, that still leaves those programmers
who've discovered Lisp, who'd love to use it, but who have trouble
convincing their empoyers & colleagues. Adding support for a few key
Windows features wouldn't hurt you, and it would help sell a few more
copies of Lisp, which could help Franz, Harlequin, etc.
I don't know why you're arguing so strongely against something that
would help all of us, either directly or indirectly, and which at
least one Lisp vendor is interested in doing anyway. In the case of
DylanWorks, it looks like it's already being done, and in a way
that'll impress the hell out of a lot of Windows people. Since I doubt
that Harlequin would put so much effort into a product for no good
reason, it could be that I'm not the only programmer with an interest
in this issue. You don't have to like "The World According to Gates"
to appreciate the advantages of such features.
Brian Rogoff
On Sat, 29 Mar 1997, Cyber Surfer wrote:
> With a mighty <Pine.SGI.3.95.970328172856.27613B-
> 100...@shellx.best.com>,
> b...@best.com uttered these wise words...
>
> > If you don't like the ACL/PC price, there is Harlequin. Or you
> > could port CMUCL to Windows. (BTW, anyone out there tried this yet?)
>
> Does CMUCL deliver stand alone code? How about in a DLLs? Can it use
> ActiveX? As I understand it, the CMUCL port isn't complete yet. I'd
> love to use it, if it was, esp if the FFI works with DLLs.
Obviously, if there is no existing Windows port, asking if CMUCL
supports ActiveX is premature. If you are interested in a Lisp for work,
then you would have to value your time very lightly, since even the
"expensive" US $2500 Franz product is going to save you the several month
porting effort. I was being facetious, talking about the port.
> If any Windows developers are reading this, and have tried this tactic
> and made it work, then I'd appreciate any advise you can give me.
> Erik's advise seems to be just to do it, as he's said nothing about
> how to deal with the consequences. In fact, he seems to be denying
> that there _are_ any consequences. Perhaps I've misunderstood him? I
> don't think so, but if I have, then I'd appreciate knowing what it is
> that I've missed.
I believe that the point that you are missing is that the current
crop of Lisp development environments are quite suitable for a large range
of work on the Windows platform. Given an FFI, you can certainly wrap any
piece of C code (which can talk to whatever you want, OLE controls, etc)
in a chunk of Lisp. So you can use Lisp. You may want to have VC++ around
too if you do serious Windows development, but I assume you know that.
Consider that Java, Perl, and VB are widely used in the Windows
world now, and they also have to "talk to" C++. This is not a problem.
> > Hmmm, I'm pretty sure that Harlequin Lisp comes with ODBC drivers,
> > DDE support, a foreign language interface. I imagine ACL/PC does too.
> > Specifically, what do you want? Are you so sure that the current commercial
> > offerings can't help you?
>
> In fact, I've been seriously considering LispWorks for Windows ever
> since it was announced. I've only hesitated because of the features
> that it doesn't (yet) support, but which would be _very_ useful to me
> right now. (I've mentioned the editor in another article.)
It sounds like you will never shell out the dollars to buy a
commercial Lisp, that there will always be something you want. An editor?
Get emacs, or buy one that you prefer.
> How about support for OCX (or ActiveX, depending on what you wish to
> call it - MS appear to have renamed OCX/OLE)? A lot of Windows people
> consider this to be important. Looking at the mass of OCX controls
> available now, it's easy to see why they'd want this.
If you have an FFI, and VC++ (or whatever), you can write the
glue code. Besides, no vendor will (or should) care about your whining
until you are a *paying* customer. It is easy to complain on the net about
what you want, but they are trying to make money. Shit or get off the pot
or "loo" to you).
> So, I'm tempted to buy LispWorks simply for my own use, possibly
> without CLIM. (Portable code is no value to me at present, but others
> will _certainly_ find it useful.) It will be harder to satisfy the
> demands of professional Windows developers, either because they're an
> awkward lot, many of them may insist on using something else anyway,
> they'll think that "Lisp is dead", or some other nonsense. I'm sure
> you know what I mean, as we've seen enough of it in comp.lang.lisp
> over the years. Developers with even less contact with Lisp may be
> less inclined to consider it.
I am a professional programmer, Windows NT is my OS, and I shelled
out the $$$ for Lisp. I see it as an investment in the future. Lots of
VB and Perl programs would be better served by Common Lisp. CL isn't
perfect, and there is a lot I don't like about it, but if I take your
attitude then all programming languages suck, I can't do anything, and I
may as well just quit. Problems are there to be solved.
> While most of us here are unlikely to be any of those people, some of
> us will certainly know - or worse - work with such people. While Erik
> may be speaking for the Lisp programmers free of the limited demands
> of most Windows people, is it not possible that I might be speaking
> for those programmers who are less fortunate? Is it possible that such
> developers may exist, may wish to use Lisp, but may be forced to use
> something else?
No one forces you to do anything. In particular, no one forces
you, or anyone else, to code in C++.
> I've mentioned DylanWorks. If that has a price similar to LispWorks
> and MLWorks, i.e. $700 - $800, then it should be very attractive to a
> fair number of Windows developes.
Its very easy to assume that some future thing will come along to
help you out with todays problem. When that comes and is found wanting,
you'll have to wait for something else. I'm looking forward to commercial
Dylan environments too, but Common Lisp is here now, and the environments
are mature. All of the difficulties you have described can be surmounted
with a little work.
> The point I'm making is that we're not all that free.
By this one statement, you have convinced me that the philosophical
gap between us is so great that conversation is problematic.
-- Brian
Cyber Surfer
With a mighty <Pine.SGI.3.95.970330123243.4054A-
> Obviously, if there is no existing Windows port, asking if CMUCL
> supports ActiveX is premature. If you are interested in a Lisp for work,
> then you would have to value your time very lightly, since even the
> "expensive" US $2500 Franz product is going to save you the several month
> porting effort.
Exactly. My interest in CMUCL is purely for personal use. It's hard
enough to convince Windows people that _any_ Lisp could be used, never
mind one that is still being ported from Unix. CMUCL has a reputation
as an excellent Lisp, and I'm eager to discover for myself how good it
is.
> I was being facetious, talking about the port.
I suspected that. ;)
> I believe that the point that you are missing is that the current
> crop of Lisp development environments are quite suitable for a large range
> of work on the Windows platform. Given an FFI, you can certainly wrap any
> piece of C code (which can talk to whatever you want, OLE controls, etc)
> in a chunk of Lisp. So you can use Lisp. You may want to have VC++ around
> too if you do serious Windows development, but I assume you know that.
Indeed, I agree that Lisp "is quite suitable for a large range of work
on the Windows platform". It's just that not everyone can see it as
easily as we do. Plus, some people will demand features provided by
OCX and OLE products. This is _not_ uncommon for Windows, as any
magazine for Windows developers can confirm. Even a more general mag,
like Byte, will tell you this.
If this is a myth created Microsoft's marketing people, then it's
working. All the Windows developers that I know appear to believe it.
When a client demands a feature provided by an OCX control, how many
of us can ignore it? If it saves time, and the component doesn't cost
too much, then it'll soon pay for itself, even on just a single
project.
> Consider that Java, Perl, and VB are widely used in the Windows
> world now, and they also have to "talk to" C++. This is not a problem.
Note how much effort is being put into making Java support features
that are specific to Windows. There's a big demand. I bet that this is
why Lisp vendors are interested, too.
> It sounds like you will never shell out the dollars to buy a
> commercial Lisp, that there will always be something you want. An editor?
> Get emacs, or buy one that you prefer.
Actually, I'd like to be able to use Lisp professionally, rather than
just for my own personal projects. I've said this many times, now.
Still, it's just possible that I may be able to impress someone enough
to overcome their doubts. That's one reason why I'm considering it,
but the real reason is that there are day to day tasks that could be
made easier by using Lisp.
If I have an editor problem, it's not a lack of Emacs. I'd rather have
a non-Emacs editor. In fact, the editor in the Standard Version of
ACL/PC is perfect for me. Not _all_ Lisp programmers are Emacs fans.
> If you have an FFI, and VC++ (or whatever), you can write the
> glue code. Besides, no vendor will (or should) care about your whining
> until you are a *paying* customer. It is easy to complain on the net about
> what you want, but they are trying to make money. Shit or get off the pot
> or "loo" to you).
That's another reason for buying either ACL/PC or LispWorks for
Windows. Right now, I'd probably choose DylanWorks, if it were
available yet. It appears to have all the Win32 support that I'm
looking for, which would leave me time to actually write the code
that's expected from me.
If you expect Windows people to write code for features that VC++, VB,
etc _already_ support, then don't blame them for choosing those tools,
instead of Lisp. All I'm doing is explaining the point of view of
Windows developers. You may be right, and everyone should be happy to
pay $3000 for a product, and then spent time adding support that's
available in C++ for a tenth of the cost. This is certainly a short
sighted way of looking at it, but that's how most people will see it.
I'll be more than happy to beta test DylanWorks. It'll increase my
chances of using it professionally, and there's already a _very_ good
chance of that.
> I am a professional programmer, Windows NT is my OS, and I shelled
> out the $$$ for Lisp. I see it as an investment in the future. Lots of
> VB and Perl programs would be better served by Common Lisp. CL isn't
> perfect, and there is a lot I don't like about it, but if I take your
> attitude then all programming languages suck, I can't do anything, and I
> may as well just quit. Problems are there to be solved.
It ain't _my_ attitude. How many times do I have to spell it out? I
love Lisp, and I'm doing everything I can to convince people that I
should be using it! Please don't blame me if these people fail to be
convinced. Not everyone has $3000 to spend on a development tool,
unless perhaps it's the latest "gotta have it" fad (e.g. Java).
Even then, $3000 may still be a lot of money to spend on a _single_
product. We know it's worth it, but the people who hold the money
_don't_, coz they're...not...programmers. Is that clear enough?
If you like, I can give you the email address of the guy who decides
this for me, so you can convince him. I, on the other, was convinced
well over 10 years ago!
Meanwhile, there are a lot of other people left to convince, and we
can't do it overnight. I'll be happy to do it one company at a time.
So, here I am working at a place where they know sweet FA about Lisp,
and they happy to leave it like that. _I'm_ trying to change that.
It should be easy, as everyone there is a friend. Alas, it isn't easy.
However, it's a hell of lot harder to convince strangers.
> No one forces you to do anything. In particular, no one forces
> you, or anyone else, to code in C++.
True, but I prefer not to be unemployed. If that's whining, then I'm
not ashamed of it. Offer me a job coding in Lisp, where I can telework
from home, and who knows? So far, nobody has been interested.
Anyway, this isn't about me. _I_ don't need convincing, and it may
make no difference to anyone else whether I code in Lisp or C++. Franz
and Harlequin don't need my money, but who are they selling their
Windows products to? _They're_ the ones that need convincing. I think
that the people at Franz and Harlequin know this better than I do.
> Its very easy to assume that some future thing will come along to
> help you out with todays problem. When that comes and is found wanting,
> you'll have to wait for something else. I'm looking forward to commercial
> Dylan environments too, but Common Lisp is here now, and the environments
> are mature. All of the difficulties you have described can be surmounted
> with a little work.
It ain't _that_ far away. Neither is VC++, which is why I'm using it.
And then there's J++, which is at least closer to what I'm looking
for, even if it doesn't quite get there. A fair number of people seem
to be satisfied with it, so why not me? Well, coz I'd prefer Lisp.
It's unlikely that I'm the only programmer in this situation. I recall
a thread in this newsgroup, back in 1992, discussing how to convince
managers that using Lisp was worthwhile, even if the code was
sometimes rewritten in C++. Isn't it amazing how there can be managers
who don't understand the simple idea of prototyping?
> > The point I'm making is that we're not all that free.
>
> By this one statement, you have convinced me that the philosophical
> gap between us is so great that conversation is problematic.
This should be no suprise. It's a big world, full of ignorant people.
A lot of them are guillible, and a few of them are short of money.
Others are merely reluctant to spend it. This should not be news to
anyone here! If you dare to tell people how to run their business,
they may well tell you where to go. The same is true for individuals,
and programmers are no different.
Are you _really_ unaware that not all programmers choose their tools?
In case you didn't notice, some businesses are run by people who don't
use Lisp, don't know it, and don't even know what they're missing! If
it's a small enough business, you may find that a great deal of
interest is taken in the tools that get used.
Perhaps these companies don't count, in which case you needn't worry.
(Yes, I did noticed that you don't worry about it.) Fair enough, but I
don't understand how a vendor supporting a few Win32 features can hurt
you. If it can help sell a few more copies of Lisp, wouldn't it have
the _opposite_ effect?
David H. Thornley
In article <Pine.SGI.3.95.97033...@shellx.best.com>,
Brian Rogoff <b...@best.com> wrote:
>On Sat, 29 Mar 1997, Cyber Surfer wrote:
>> With a mighty <Pine.SGI.3.95.970328172856.27613B-
>> 100...@shellx.best.com>,
>> b...@best.com uttered these wise words...
>>
(with-delurking-on
>> > If you don't like the ACL/PC price, there is Harlequin. Or you
>> > could port CMUCL to Windows. (BTW, anyone out there tried this yet?)
>>
>> Does CMUCL deliver stand alone code? How about in a DLLs? Can it use
>> ActiveX? As I understand it, the CMUCL port isn't complete yet. I'd
>> love to use it, if it was, esp if the FFI works with DLLs.
>
> Obviously, if there is no existing Windows port, asking if CMUCL
>supports ActiveX is premature. If you are interested in a Lisp for work,
>then you would have to value your time very lightly, since even the
>"expensive" US $2500 Franz product is going to save you the several month
>porting effort. I was being facetious, talking about the port.
>
Look, guys, most of us are interested in making our lives easier.
Everybody in this discussion is convinced that developing in Lisp
is easier than, say, C++, all other things being equal. The problem
is that not all other things are equal.
Most of the time, programming languages are not chosen by how good
they are, but for other reasons. This is the nature of business.
Some of the other reasons would be availability of certain kinds of
supporting libraries, conformance with existing standards, availability
of people to support the code in the future, and so forth. All of
this biases businesses towards C++ rather than Lisp. Anybody who
wants to be something other than a lone self-employed developer has
to deal with this.
Even a self-employed developer has to consider how to implement features.
If a lot of features have to be implemented in C++ and accessed from
Lisp that way, then Lisp is not making life as easy as it should.
At some point, it may become easier simply to write the whole application
in C++.
I have no religious attachment to Lisp; I merely want to work as effectively
as possible. C++ is not a bad language, and it comes with all sorts of
good libraries available, since it's what people assume development is
done in. Most C++ systems already have the same sort of integrated
development environments that Lisp pioneered. I can find lots of people
who know it, and lots of people who have C++ compilers at home.
In other words, it is easier for me to program in C++ in all respects
except writing the code. It is far easier for me to find a C++ job
rather than a Lisp job. I would like that to change, and so I'd like
to see changes made in the marketplace.
I'm very happy, therefore, about Harlequin's release of a complete
development system for under a thousand dollars. This is, in my opinion,
progress. Nobody is going to spend thousands of dollars on a development
system unless they know it's going to pay off, and nobody's going to
spend thousands simply to ditz around on their home box.
One thing I think critical is the ability to deliver stand-alone
applications. This is done by every C and C++ personal computer system
I know about, on every platform. On most Lisp implementations, it's
an optional, and potentially expensive, extra. I'd like to see more
vendors supply it as part of the standard product.
In other words, I fully agree with Cyber Surfer. I feel his pain,
because I am in much the same situation. I am not an independent
consultant, accepting only the best jobs with the most freedom.
Most of the programming world is in much the same situation. There
simply isn't enough money among the elite few to support massive
efforts to keep up with the C++ world. Franz, Digitool, and Harlequin
have to keep some sort of presence in the low end of the market, or
they will simply become irrelevant.
)
--
David H. Thornley, known to the Wise as thor...@cs.umn.edu O-
Disclaimer: These are not the opinions of the University of Minnesota,
its Regents, faculty, staff, students, or squirrels.
Datclaimer: Well, maybe the squirrels. They're pretty smart.
Will Hartung
(Why do I drag myself into these things...however...)
cyber_...@wildcard.demon.co.uk (Cyber Surfer) writes:
>It ain't _my_ attitude. How many times do I have to spell it out? I
>love Lisp, and I'm doing everything I can to convince people that I
>should be using it! Please don't blame me if these people fail to be
>convinced. Not everyone has $3000 to spend on a development tool,
>unless perhaps it's the latest "gotta have it" fad (e.g. Java).
This paragraph is, I believe, the key between the points of view that
Erik and Martin differ on.
It is not a Lisp issue at all, but a use of tools issue.
Martin is trying to change the "world" so that they will accept his
choice of tools, while Erik has changed himself. From what I
understand, Erik jumps through whatever hoops are necessary so that a
majority of his work is done in the environment that he feels most
comfortable, and is most productive.
Erik doesn't want to make the world safe for Lisp, or anything else.
He wants to make the world safe for Erik (I think we can all relate
with him on this point)! Erik presents himself to his
clients/employers as a black box generator, and on completion of his
projects delivers black boxes that perform to the clients
satisfaction. The tools used to fashion and paint the box are not
relevant to the function of the box, as long as it is within spec.
Martin, it seems, does the same thing. His result is a Windows .DLL
file. A .DLL is about as black as a box can get, designed properly.
But it appears that the primary difference between the two techniques
is that Martin does not feel that he can use enough of the Lisp Tool to
justify the time spent in jumping through hoops to create the
standalone .DLL file. Whereas Erik can leverage his experience of hoop
jumping to make the net time trade off end up ...umm... in the black,
so to speak.
Granted, Eriks primary task does not seem to be producing
.DLLs, and he would choose not to do such a project in the first
place, however I do not believe that fact invalidates the issue that,
perhaps, Lisp could be leveraged to improve the .DLL creation process.
But, as a corallary, Erik did his early hoop jumping at a price paid
that is now paying off for him, but Martin does not seem to have started
yet. I believe that Eriks position is for Martin to start jumping and
stop shouting. Perhaps Martins position is that he shouldn't have to
see the hoops, much less jump through them.
I can relate to Eriks position. Just about any significant work of
data that comes through my hands spends some portion of its life on a
UNIX system, even if it didn't start or end up there. UNIX is a far
more productive environment for me that any pain in converting and
copying data is a net gain in the long term for what I need to get
done.
One can compare the two philosophies to two salesmen: One who is out
driving around and knocking on doors, while the other says "Sales are
down, the phone isn't ringing."
And, that's the whole point I think. It is not a tools issues, much
less a Lisp issue. It's a philisophical "approach to life" issue.
Which is one reason why this has got so heated, as no technical issues
are really involved.
So, in summary:
Martin: "I can't use Lisp because it won't make .DLL's."
Erik : "Yeah. So?"
This is just my take on this whole ..err.. discussion. No intent to
offend anyone.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Bruce Tobin
Brian Rogoff wrote:
>
> Hmmm, I'm pretty sure that Harlequin Lisp comes with ODBC drivers,
> DDE support, a foreign language interface. I imagine ACL/PC does too.
> Specifically, what do you want? Are you so sure that the current commercial
> offerings can't help you?
He wants:
1. The ability to create a DLL. This is basic. If you can make DLL's,
you
have a solid justification for using Lisp in any project where Lisp-like
capabilities
are needed, regardless of what the primary tool chosen for the project
happens to be.
If you can't, you don't.
2. The ability to create and use OLE automation servers. OLE
automation has become
the lingua franca of Windows, and if you don't speak it, you're not in
the game.
3. The ability to create and use ActiveX controls. This is the first
question my
management-- or any IS management I know-- will ask about a proposed
Windows development tool.
Note that 3 is really a special case of 2, and 2 of 1. Given 1, you
could build the rest.
Cyber Surfer
With a mighty <vfr750E7...@netcom.com>,
vfr...@netcom.com uttered these wise words...
[excellent stuff that needs no comment]
> Martin, it seems, does the same thing. His result is a Windows .DLL
> file. A .DLL is about as black as a box can get, designed properly.
This is the theory. It's certainly how I see it. Apparently, it's not
the way that everyone else sees it. For example, suppose I left the
company and somebody else had to maintain my code? I suspect that they
might struggle to understand my C++ code, and but that's just a guess.
Also, I'm naturally inclined to believe that - and to certainly
suggest it - as it supports my goal of using Lisp instead of C++,
Java, etc. If I can write code faster and better in Lisp, and then why
not just use Lisp? (Or Prolog, as I have a Prolog that can deliver
code in a DLL, via a "logic server" DLL.)
However, if I code in a language that few other programemrs use, then
I'm making it far less likely that anyone else will be able to
maintain my code. In theory, they could learn Lisp, or find someone
else who knows Lisp. In practice, this isn't as easy as finding
someone who knows C++ or Java.
Hence the problem. It's _possible_, but people choose not to do it. If
you question their choice, then you're telling them how to run their
business. I'm a programmer, and know very little about running a
business, so what should I do? Quit?
> But it appears that the primary difference between the two techniques
> is that Martin does not feel that he can use enough of the Lisp Tool to
> justify the time spent in jumping through hoops to create the
> standalone .DLL file. Whereas Erik can leverage his experience of hoop
> jumping to make the net time trade off end up ...umm... in the black,
> so to speak.
No, I don't feel that at all. My choice is _Lisp_. Various Lisp
vendors have told me that their Lisps can't (yet) produce DLLs. The
only vendor that has a Lisp that can do this (ILOG Talk) has a rather
high price. I'd be inclined to buy it myself, and use it, if I could
use it on my projects, but I'm told to use C++.
Now, most Windows programmers seem happy to use C++. Perhaps the ones
who use Lisp keep quiet, discreetly writing their black boxes, and
never telling their clients that they use Lisp. This implies that they
work as consultants, free to choose any tools they like.
My situation is a little different, so perhaps I should change it. I'm
certainly considering it, i.e. quiting. On the other hand, I might
only need to wait for DylanWorks, or (less likely) some other tool
which I'll be allowed to use. This raises an interesting question:
just why are people so negative about Lisp, but positive about Dylan?
Could it be that DylanWorks has some bloody impressive Windows
support, by _anybody's_ standards, or is it just the name? I'm not
sure, and these are my _friends_. I should at least be able to know
what they're prejudices are! If the justification for not using Lisp
is the lack of Lisp expertise elsewhere in the company, then why
should this argument not also apply to Dylan?
> Granted, Eriks primary task does not seem to be producing
> .DLLs, and he would choose not to do such a project in the first
> place, however I do not believe that fact invalidates the issue that,
> perhaps, Lisp could be leveraged to improve the .DLL creation process.
Indeed, and I've asked various Lisp vendors about it. I've even
pointed out to my boss the possiblity of using Lisp to create an EXE,
while using a DLL to interface it to the code that uses it. (This
could be easily done with a named pipe. Messy, but it should work.) No
deal. Perhaps some people just refuse to allow Lisp to be used?
> But, as a corallary, Erik did his early hoop jumping at a price paid
> that is now paying off for him, but Martin does not seem to have started
> yet. I believe that Eriks position is for Martin to start jumping and
> stop shouting. Perhaps Martins position is that he shouldn't have to
> see the hoops, much less jump through them.
The argument is often that the hoops are unnessary if you use C++.
It's not _my_ argument, of course. I'd do things the same way that
Erik does, if anyone would pay me to do so. So far, that's yet to
happen. Just the opposite, in fact.
> I can relate to Eriks position. Just about any significant work of
> data that comes through my hands spends some portion of its life on a
> UNIX system, even if it didn't start or end up there. UNIX is a far
> more productive environment for me that any pain in converting and
> copying data is a net gain in the long term for what I need to get
> done.
I can also relate to Eriks position. I understand his point of view,
and I share it. Alas, the people who pay me do not. These people are
not at all rare, either, so just looking for another job is unlikely
to solve this problem. It would also leave the problem for anyone else
wishing to use Lisp in similar environments. I'm not sure that Unix
has anything to do with this, as I've found just as many anti-Lisp
people who use Unix as anti-Lisp people who use anything else.
This is why I like the idea of doing everything possible to increase
the number of Lisp programmers. That would create a healthier world,
and make it easier for all of use who wish to use Lisp, not just the
programmers (consultants?) who don't have anyone looking over their
shoulder, telling them how to do their job.
> One can compare the two philosophies to two salesmen: One who is out
> driving around and knocking on doors, while the other says "Sales are
> down, the phone isn't ringing."
Using this analogy, I advocate going out, beating on doors, and
selling Lisp. ;) It's developers creating black boxes who are sitting
by the phone. The problem, as I see it, as one of memes, not software.
The software works. There's no doubt about that! The Lisp memes, on
the other hand, are heavily outnumbers, resulting in people believing
that Lisp is dead, so if you even mention Lisp, they look at you like
you just said you use COBOL, or worse.
> And, that's the whole point I think. It is not a tools issues, much
> less a Lisp issue. It's a philisophical "approach to life" issue.
> Which is one reason why this has got so heated, as no technical issues
> are really involved.
Eactly. I'm told not to use Lisp. There's nothing technical about it,
as it's all justified by hard business sense. Erik says, "fuck you",
and this is the same message that I get from my friends, only worded a
hell of a lot more tactfully. However, that's how it sounds to me.
This message shouldn't be strange to anyone who read comp.lang.lisp
before 1995. Remember the waves of anti-Lisp attacks? Where are they
now? Probably diverted to the Java newsgroups, which I rarely read.
Still, I can remember the intense negativity in those attacks, and I
find the beliefs elsewhere, with an odd twist: the same people who
refuse to use Lisp will happily embrace Java.
This problem may well have more to do with politics and marketing than
technical issues. I can't argue politics and marketing - well, I can,
but I risk being dismissed as a crackpot. This won't change my belief
that Lisp is the best tool for me, but I may have to compromise a
little - just as we all do. Erik's compromise is to reject the work
that requires features not provide by Lisp, or to spend time adding
support for those features. He may not see it as a compromise, but
many others will. Lost time is lost time, esp when you have a
deadline. This is why some people will always compromise by choosing
the tools that are "safe", in the sense that they won't lose their job
by choosing, let's say, C++. With so much marketing behind C++, the
non-programmes are less likely to C++ for failed projects.
What we do is choose how to deal with this situation. I'm not inclined
to give to the best job I could have, but if it prevents me from using
Lisp, then I'll be very tempted. It's a very high price to pay.
Perhaps it might be better to simply making a "standing protest",
every time I'm given a new project. I say, "This would be better in
Lisp", and give a justification, and then see what the reaction is.
Someday, the answer may be "yes". In this way, I may sell the Lisp
meme. If I just run away from the problem, then nothing will have
changed. The technical problems are easy be comparison.
Even when Lisp is the first choice, and there are no doubts, and
everyone working a project knows and uses Lisp, you may still find a
use for features not currently supported by any available Lisp. It
doesn't hurt us if a vendor provides this support _as standard_.
Marc Wachowitz
Cyber Surfer (cyber_...@nospam.wildcard.demon.co.uk) wrote:
> However, if I code in a language that few other programemrs use, then
> I'm making it far less likely that anyone else will be able to
> maintain my code.
As far as I can see, there are only two _realistic_ choices about that:
Either you somehow happen to convince your boss/customer/whoever that
this problem could be solved, or you just forget using anything beyond
the mainstream at work. I doubt many readers around here would deny that
it would be incredibly naive to expect Lisp becoming mainstream in the
near future, or will be surprised by such news; so what's the point of
repeating it over and over? A Lisp vendor pushing significant money
into yet another feature of an extended GUI will hardly change the mind
set which prevents most people from looking beyond this surface (and
then understanding what they would see).
> If you question their choice, then you're telling them how to run their
> business. I'm a programmer, and know very little about running a
> business, so what should I do? Quit?
You're constantly switching between several very different problems,
and the one which you agree to be the biggest is non-technical and way
beyond the power of anyone around here to change in a general way.
What should we do? Blackmail your boss? Create yet another newsgroup,
maybe alt.support.lisp-lover or alt.sex.bondage.c++-and-windows? ;-)
> I should at least be able to know
> what they're prejudices are! If the justification for not using Lisp
> is the lack of Lisp expertise elsewhere in the company, then why
> should this argument not also apply to Dylan?
So decide whether you want to do advertising, including all the silliness
which comes with marketing, or try to educate, and remove their prejudices
this way. If you need serious information about the latter, e.g. books on
the usefulness of Lisp or technical help with something which would solve
a real problem, this is certainly the right place to ask (just in case you
wouldn't know the answers yourself already).
> Perhaps some people just refuse to allow Lisp to be used?
Perhaps the parantheses invoke some uncomfortable childhood memories
about their parents?
> I'm not sure that Unix
> has anything to do with this, as I've found just as many anti-Lisp
> people who use Unix as anti-Lisp people who use anything else.
Sure, ignorance grows everywhere, but at least Unix has been designed
and implemented as a toolbox, and it tends to be simple (technically)
to connect pieces whatever pieces one wants - mayby it won't be the
most beautiful component software you've seen anywhere, but it will
usually be robust and doable with a reasonable effort. Hence no points
to be made about this or that not working like Bill's new toys and such
silliness. It's developed as a system by programmers for programmers,
leaving the user interface stuff where it belongs - at the application
level. (The fact that some applications on Unix are primitive and a
nightmare for their users doesn't change the principle.)
-- Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de>
Russell Senior
>>>>> "Cipher Surfer" == <cyber_...@wildcard.demon.co.uk> writes:
Cipher Surfer> [...] I can, but I risk being dismissed as a crackpot.
Risk? Where _have_ you been?
--
Russell Senior
sen...@teleport.com
Cyber Surfer
With a mighty <5hrgrk$m...@trumpet.uni-mannheim.de>,
m...@ipx2.rz.uni-mannheim.de uttered these wise words...
> As far as I can see, there are only two _realistic_ choices about that:
> Either you somehow happen to convince your boss/customer/whoever that
> this problem could be solved, or you just forget using anything beyond
> the mainstream at work. I doubt many readers around here would deny that
> it would be incredibly naive to expect Lisp becoming mainstream in the
> near future, or will be surprised by such news; so what's the point of
> repeating it over and over? A Lisp vendor pushing significant money
> into yet another feature of an extended GUI will hardly change the mind
> set which prevents most people from looking beyond this surface (and
> then understanding what they would see).
If Lisp vendors go after small markets, IMHO nothing will change. My
impression is that Dylan was designed to address the needs of the more
mainstream programmers, while retaining many of the strengths of Lisp.
Perhaps Lisp vendors like Harlequin are unable to provide anything
between the two extremes, LispWorks and DylanWorks, but we'll see.
> You're constantly switching between several very different problems,
> and the one which you agree to be the biggest is non-technical and way
> beyond the power of anyone around here to change in a general way.
A significant part of the non-technical problem is the belief that
Lisp is unable to compete with C++. Lisp's low profile doesn't help
much, but there are certainly mainstream apps that use Lisp. It's
unfortunate that two good examples (AutoCAD and Hot Metal Pro) both
use proprietry Lisps, either embedded in an app, or not available to
other developers.
Still, strong native OS support in commercial Lisps would be very
helpful for convincing people that Lisp is a viable alternative to
C++/VB/etc. I think that Lisp vendors know this (have I said this
before? It seems like it).
> > I'm not sure that Unix
> > has anything to do with this, as I've found just as many anti-Lisp
> > people who use Unix as anti-Lisp people who use anything else.
>
> Sure, ignorance grows everywhere, but at least Unix has been designed
> and implemented as a toolbox, and it tends to be simple (technically)
> to connect pieces whatever pieces one wants - mayby it won't be the
> most beautiful component software you've seen anywhere, but it will
> usually be robust and doable with a reasonable effort. Hence no points
This is exactly how MS describe Windows. ;) If you wish to use this
argument, then your voice may need to be loud than theirs. However,
this is a purely marketing issues, not one that's worth discussing
here. I don't believe it's an OS issue, as I don't see C++ being any
less dominant on Unix than anywhere else.
> to be made about this or that not working like Bill's new toys and such
> silliness. It's developed as a system by programmers for programmers,
> leaving the user interface stuff where it belongs - at the application
> level. (The fact that some applications on Unix are primitive and a
> nightmare for their users doesn't change the principle.)
What has this got to do with the C++ vs Lisp issue? It's a great
argument for using Unix instead of Windows, if you're already
convinced that "Unix is The Answer", but it won't convince anyone who
belives that "Windows is The Answer" - but as I said, this isn't the
issue. If there are more jobs using Lisp for Unix than for Windows,
then the OS would be relevant, and I'd agree (with a qualifier) that
for a Lisp programmer, Unix would be superior.
It may get even better if you limit yourself to jobs using a Lisp
Machine. Lisp Machines should beat Unix boxes every time, just as
easily as Unix beating Windows.
I've been seeing the question "Why isn't Lisp more popular?" for
years, but threads like this suggest that most of us understand the
reasons very well.
Cyber Surfer
With a mighty <86hghq5...@coulee.tdb.com>,
sen...@teleport.com uttered these wise words...
> Cipher Surfer> [...] I can, but I risk being dismissed as a crackpot.
>
> Risk? Where _have_ you been?
Yeah, the in early 80s I was a crackpot for talking about OOP. ;)
Perhaps I should never have looked beyond Basic, as that language
seems to be enjoying a _great deal_ of success at the moment. Good
grief, some people will even admit that you can get native code
compilers for Basic! The world is moving forward...slowly.
I could use a time machine, so I can skip the next 15 years.