In article <··········@goanna.cs.rmit.EDU.AU>
··@goanna.cs.rmit.EDU.AU "Richard A. O'Keefe" writes:
> Ok, how big _is_ the perl runtime?
> ls -lL `which perl` => 650 000 bytes (rounded). SPARC
>
> Now, how big are some Schemes?
> scm 236k SPARC
> elk ~400k [*1] SPARC
> stalin 1736k Highly optimising compiler SPARC
> nawk 188k [*2] SPARC
> tclsh 192k [*6] SPARC
>
> MacScheme 84k Mac
SPARC? Are you kidding me? I can't use a SPARC, nor can the people
I work with, nor do any of their users. They use machines with Intel
(compatible) CPUs in them.
How many of those Lisp systems can deliver code that can be linked
with C/C++ for Windows? This isn't a hypothetical question, it's
about the demands made by real clients.
> In comparison with an optimising compiler whose end product is native code,
> yes, Perl is small.
I wouldn't use Perl to write code and then deliver it to a client,
but it does get used on web servers. You'd only need one copy of the
interpreter, of course. MS want you to use VC++.
> (3) Don't admit to your real competition in the size stakes.
Err, but what about the client? ;-)
> >I agree. It's not just useful for Unix users, either. I'm using it for
> >NT, and I'm told that there's a web server for Netware that includes a
> >Perl interpreter.
>
> There are web servers including all sorts of things, including ML.
Does it run under NT? After reading about ISAPI, I suddenly have
visions of someone lashing up ML with IIS.
> >> There's nothing in Perl that Lisp couldn't have if we wanted it to.
> >> The 'scsh' people have been adding that kind of stuff to their Scheme.
> >
> >Err, scsh requires 20 MB of RAM.
>
> So what? That's irrelevant to my point.
It's not irrelevant to _my_ point, which is that I can't justify
something that uses more memory than C++, simply coz I'd have to
show why using, let's say, Lisp is better for the _client_, not
why it's better for me.
> There is nothing in Perl that Lisp couldn't have IF WE WANTED IT TO.
I agree. Let's add it!
> Interlisp-D, a much richer language than Perl, with a compiler
> included, plus a ton of networking software, two Lisp editors,
> a drawing editor, and a programmable WYSIWIG editor not altogether
> unlike Alpha, ran *happily* on a machine with 32Mb _max_ virtual
> memory, and 4Mb _max_ of physical memory. You were able to do
> Perlish stuff in that without a lot of paging.
Would that be a system that you'd have to boot, or could it be run
under an OS like NT? That's vital to me, as I _must_ use either NT
or some other form of Windows. I don't have that choice.
> >Nobody who doesn't use Unix is going to accept overheads like that.
>
> Blame the Scheme48 implementation technology, where memory footprint
> has not been a priority. The point is that the _language_ can absorb
> this stuff easily.
Sure, but not for NT. Not yet, anyway. While I'm waiting, I'll just
have to use C++ instead. I'd also need to seperate the runtime from
the development time support, so that the user doesn't get burdened
with any unnecessary overheads. I don't know if Scheme 48 can do that,
but if it can, and it can be done for NT, produce native code, fully
support the Win32 API (perhaps via a FFI), then I _might_ be able to
convince my boss. I doubt that most other Windows developers have
find it so easy, as my boss is also one of my best friends.
> Interlisp-D could do _awesome_ things in 32Mb of *virtual* memory,
> 4Mb of *real* memory. I have yet to see a windowing system approach
> it for power, ease of use, or performance.
Too bad, then, that my boss and none of his clients know about it.
Who marketed it?
> >If you're really suggesting that Lisp can
> >be used to develop popular Windows apps, then please tell me which
> >Lisp you're talking about so I buy it.
>
> Naughty naughty. You snuck in that word "popular".
> If big memory footprints made programs unpopular, Microsoft Word
> would no longer exist, indeed Windows itself would be a rapidly
> fading memory. I'm using Macintosh "apps" written in Scheme, TCL,
> and Clean, with no memory footprint problems.
Word isn't so bad on a machine with 32MB of RAM, but I think that the
real reason why Word "succeeds" even when its so big is that it has MS
pushing it. You can buy it as part of a bundle called Office. Some
people need Word simply coz so many other things depend on it. Who can
afford to be without it? In spite of all the obvious failings, it
survives coz MS want it to.
> I am not writing "apps" for the mass market on _any_ machine.
> Next semester, I hope to join a project working on software worth
> millions. (Fingers crossed...) GUI interfaces will not be a
> priority; rock solid right answers will be.
Good luck to you, then. Few of us are so fortunate.
> >That might be a lot easier than convincing Windows developers, since
> >Bill Gates has very little interest in Unix, other than replacing it
> >with NT.
>
> If I understand you correctly, you seem to be saying that Windows
> developers only use tools blessed by Bill Gates, or possibly that
> Bill Gates is the only Windows developer, I can't figure out which.
The "blessing" of Bill Gates, yes. That's it exactly. One of the things
that a Windows developer can be sure of is that buying VB/VC++ won't hurt,
and anything else blessed by MS (like Word) might also help. I dunno
how true this is, but you can easily find people who behave as if they
believe it.
> What on earth has Bill Gates' interest in Unix (which Windows NT
> closely resembles AND CLAIMS TO IMPLEMENT) or fish or frogs or
> anything got to do with the utility of Lisp?
It has a great deal to do with the perception of things created by
the marketing people at MS.
> There is nothing about Windows NT (except the performance problems I
> keep hearing about) which makes it unsuitable for Lisp or anything
> else. If I can run CLISP on a small machine, and I can, I can run
> CLISP on a Windows NT machine.
I know. I've used Lisp on an NT machine (I have one right here),
so I know I can use a Lisp, like ACL/Win. I'm not sure about CLISP,
but only coz the when I tried it, I got an error message. It looked
like there was a memory problem, so perhaps I'll have to tweak the
setup a bit, when I have the time.
Sadly, I'm unlikely to be paid to use CLISP to develop apps. I'm not
even sure it _could_ be used to write these apps, unless there's now
a Win32 version of CLISP, producing native code?
> The only real problem with Lisp size that has been mentioned so far
> is that
> - Lisp systems tend to include a lot of stuff instead of autoloading
> - some of this stuff is optimising compiler
> - some of this stuff is development system
> - stripping it out requires a really good treeshaker.
> This is admittedly a flaw, but there is no law that says Lisp systems
> _have_ to be built that way, and Stalin for one isn't. Programs compiled
> using Stalin (a compiler for Scheme) do not include compiler or development
> system. Stalin is a one-man show, and it is intended to produce speedy
> object code, not fast compilation time.
I agree about these things being possible. It's the fact that they
appear not to have yet been done that worries me. I can't use something
that's not available for a platform that I use, like NT. However, I'm
actually developing for Win16, so I I'd need Win32s support, which
would increase the size of the delivered code (Win32s itself would
have to be included).
Is Stalin available for NT?
> Application memory footprint is something Dylan was supposed to address.
> Shame on you, Apple!
Yep, shame on Apple. Still, I'm lucky that I'm not a Mac developer!
Thanks for cheering me up. ;-)
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
Cyber Surfer <············@wildcard.demon.co.uk> writes:
>In article <··········@goanna.cs.rmit.EDU.AU>
> ··@goanna.cs.rmit.EDU.AU "Richard A. O'Keefe" writes:
>> Ok, how big _is_ the perl runtime?
>> ls -lL `which perl` => 650 000 bytes (rounded). SPARC
>>
>> Now, how big are some Schemes?
>> scm 236k SPARC
>> elk ~400k [*1] SPARC
>> stalin 1736k Highly optimising compiler SPARC
>> nawk 188k [*2] SPARC
>> tclsh 192k [*6] SPARC
>>
>> MacScheme 84k Mac
>SPARC? Are you kidding me? I can't use a SPARC, nor can the people
>I work with, nor do any of their users. They use machines with Intel
>(compatible) CPUs in them.
I have access to a SPARC, so that's what I measured things on.
Are _you_ kidding me that you see that as a problem?
Do you know of any reason why the size ratio for scm/perl should be
more in Perl's favour on a 386 than on a SPARC?
>How many of those Lisp systems can deliver code that can be linked
>with C/C++ for Windows? This isn't a hypothetical question, it's
>about the demands made by real clients.
Of the Scheme systems I listed, the answer is "all of them".
>> In comparison with an optimising compiler whose end product is native code,
>> yes, Perl is small.
>I wouldn't use Perl to write code and then deliver it to a client,
>but it does get used on web servers.
So does ML. So what?
>You'd only need one copy of the
>interpreter, of course. MS want you to use VC++.
And Sun want you to use Java.
>> (3) Don't admit to your real competition in the size stakes.
>Err, but what about the client? ;-)
I don't understand what point you are making here, if any.
I did not write "don't admit XXX to your competition",
I wrote "don't admit to [the existence of] your competition".
"What about the client?" Well, it's precisely the potential
client who is being deceived by this failure to admit to the
existence of the _real_ competition.
>> There are web servers including all sorts of things, including ML.
>Does it run under NT?
No idea. Since NT is supposed to have a "POSIX personality",
why wouldn't it?
>After reading about ISAPI, I suddenly have
>visions of someone lashing up ML with IIS.
I can't keep up with the acronyms in the Wintel world.
Please tell me what IIS and ISAPI are.
>It's not irrelevant to _my_ point, which is that I can't justify
>something that uses more memory than C++, simply coz I'd have to
>show why using, let's say, Lisp is better for the _client_, not
>why it's better for me.
Yes, but "scsh" and "Lisp" are no coextensive.
I just went to the trouble of pointing out that there are _other_ Schemes,
with the exception of a separate compiler delivering small extremely fast
standalone executables, they were all smaller than Perl.
>> Interlisp-D, a much richer language than Perl, with a compiler
>> included, plus a ton of networking software, two Lisp editors,
>> a drawing editor, and a programmable WYSIWIG editor not altogether
>> unlike Alpha, ran *happily* on a machine with 32Mb _max_ virtual
>> memory, and 4Mb _max_ of physical memory. You were able to do
>> Perlish stuff in that without a lot of paging.
>Would that be a system that you'd have to boot, or could it be run
>under an OS like NT?
It's the same "Medley" that has recently been mentioned in this newsgroup.
I know that Medley runs as an ordinary process on UNIX boxes.
I don't know what the PC version does, but apparently there is one.
>> Interlisp-D could do _awesome_ things in 32Mb of *virtual* memory,
>> 4Mb of *real* memory. I have yet to see a windowing system approach
>> it for power, ease of use, or performance.
>Too bad, then, that my boss and none of his clients know about it.
>Who marketed it?
"not sure if we want to be in the computer business" Xerox, that's who.
The inventors of the WIMP paradigm epitomised by Mac and Windows today.
The inventors of Smalltalk.
Xerox technical work was *brilliant*.
Xerox marketing was *abysmal*.
>Word isn't so bad on a machine with 32MB of RAM,
I haven't _got_ a machine with 32Mb of RAM.
>but I think that the
>real reason why Word "succeeds" even when its so big is that it has MS
>pushing it.
Exactly.
The success of Wintel and Perl, and the lack of Lisp growth,
can be attributed to the same three factors:
Marketing,
Marketing, and
Marketing.
>> I am not writing "apps" for the mass market on _any_ machine.
>> Next semester, I hope to join a project working on software worth
>> millions. (Fingers crossed...) GUI interfaces will not be a
>> priority; rock solid right answers will be.
>Good luck to you, then. Few of us are so fortunate.
How many *popular* "apps" have you written, and what tools were used
to write them?
>The "blessing" of Bill Gates, yes. That's it exactly. One of the things
>that a Windows developer can be sure of is that buying VB/VC++ won't hurt,
>and anything else blessed by MS (like Word) might also help. I dunno
>how true this is, but you can easily find people who behave as if they
>believe it.
Once upon a time there was a slogan "nobody was ever sacked for buying IBM."
>Is Stalin available for NT?
Stalin itself is compiled by the free "Scheme to C" compiler.
As I said, it's a one man project. I don't know any reason why it
_couldn't_ be made to run on NT. If I had an NT box, I'd try it.
>> Application memory footprint is something Dylan was supposed to address.
>> Shame on you, Apple!
>Yep, shame on Apple. Still, I'm lucky that I'm not a Mac developer!
>Thanks for cheering me up. ;-)
--
Fifty years of programming language research, and we end up with C++ ???
Richard A. O'Keefe; http://www.cs.rmit.edu.au/~ok; RMIT Comp.Sci.
In article <··········@goanna.cs.rmit.EDU.AU>
··@goanna.cs.rmit.EDU.AU "Richard A. O'Keefe" writes:
> I have access to a SPARC, so that's what I measured things on.
> Are _you_ kidding me that you see that as a problem?
No, I'm simply pointing out that not everyone has a SPARC, or even
has access to one. I thought we were discussing why so many people
see Lisp as a dead language?
> Do you know of any reason why the size ratio for scm/perl should be
> more in Perl's favour on a 386 than on a SPARC?
Perl is an interpreter, so comparing it with VB might make more sense
than with native code generated from a Lisp compiler. I'm thinking of
the size of the object code delivered with an app, since that's what
so many people (like clients, users, etc) seem to be concerned with.
> >How many of those Lisp systems can deliver code that can be linked
> >with C/C++ for Windows? This isn't a hypothetical question, it's
> >about the demands made by real clients.
>
> Of the Scheme systems I listed, the answer is "all of them"
Excellent. How many of them can produce stand-alone apps and provide
even a tenth of the Windows support that you can find in VB?
I'm actually agreeing with you, but if I want to use these tools to
develop with, then I have to be able to prove that these tools can
do the same job as C++ or VB. Lisp itself suffers from a credibility
problem, so even if it were technically possible, we still have to
prove it. While I'd _prefer_ to use Lisp to write Windows apps, not
everyone has the time available to me for experiementing, and a fair
number of developers won't have the willingness, either.
> >I wouldn't use Perl to write code and then deliver it to a client,
> >but it does get used on web servers.
>
> So does ML. So what?
So, Perl has been very heavily promoted by Larry Wall and friends.
Would Lisp have that kind of popularity, if it had been promoted
as much? I dunno.
Part of the problem is that it's much easier to know what Perl is,
while Lisp comes in many different flavours, sizes, etc. I've lost
count of the number of times that I've seen someone on UseNet, even
when they're a Lisp programmer, claiming that Lisp requires 20 MB
of RAM! The first Lisp that I remember reading about only needed
16K, but that was something like than 15 years ago.
> >You'd only need one copy of the
> >interpreter, of course. MS want you to use VC++.
>
> And Sun want you to use Java.
I know. Java is getting a _lot_ of promotion. Is that all a language
needs, for it to succeed?
> >> (3) Don't admit to your real competition in the size stakes.
>
> >Err, but what about the client? ;-)
>
> I don't understand what point you are making here, if any.
> I did not write "don't admit XXX to your competition",
> I wrote "don't admit to [the existence of] your competition".
> "What about the client?" Well, it's precisely the potential
> client who is being deceived by this failure to admit to the
> existence of the _real_ competition.
What I mean is that the client will see the size of the code.
That's pretty hard to hide, when the code is delivered to them.
Some people are still counting bytes - even if tends to be
floppy disks, these days.
> >> There are web servers including all sorts of things, including ML.
>
> >Does it run under NT?
>
> No idea. Since NT is supposed to have a "POSIX personality",
> why wouldn't it?
I dunno. I'm mainly developing for Win16, but when it's possible,
then I try to write an app for Win32 - which, BTW, is being heavily
promoted by MS and a number of other big software companies. I've
no idea whether POSIX will be enough, coz the demand that I'm aware
of is for Win32.
> >After reading about ISAPI, I suddenly have
> >visions of someone lashing up ML with IIS.
>
> I can't keep up with the acronyms in the Wintel world.
> Please tell me what IIS and ISAPI are.
IIS is the MS web server, while ISAPI is the interface for "CGI"
code. It's not actually CGI, of course, coz it used dynamic linking
instead of starting a new process.
> I just went to the trouble of pointing out that there are _other_ Schemes,
> with the exception of a separate compiler delivering small extremely fast
> standalone executables, they were all smaller than Perl.
I'm trying to point out that neither Lisp nor Perl are competing
with VB, which is interpreted, or VC++, which is native code. Both
VB and C++ are seen as _the_ Windows development tools, leaving
very little room for any other languages, altho there are some.
In such a competitive market, I'm impressed that Smalltalk is still
there, at the high end of the market, but not everyone may feel
that way. A Windows developer might find it very much harder to
justify using ST, never mind Lisp, when VB or C++ is available.
I'm certainly _not_ saying that I like this situation, but I am
wondering what might be done to improve it.
> >Would that be a system that you'd have to boot, or could it be run
> >under an OS like NT?
>
> It's the same "Medley" that has recently been mentioned in this newsgroup.
> I know that Medley runs as an ordinary process on UNIX boxes.
> I don't know what the PC version does, but apparently there is one.
Well, that doesn't answer my question. Never mind. If you don't
know, then I'd not be suprised if very few Windows developers
know about it, either. I've never seen an advert for it, but I
wouldn't expect to - there are ST systems that I don't recall
ever seeing an advert for, either, so it may mean very little.
> >Too bad, then, that my boss and none of his clients know about it.
> >Who marketed it?
>
> "not sure if we want to be in the computer business" Xerox, that's who.
> The inventors of the WIMP paradigm epitomised by Mac and Windows today.
> The inventors of Smalltalk.
> Xerox technical work was *brilliant*.
> Xerox marketing was *abysmal*.
I totally agree! I watched them lose it all in the early 80s, and
a recently 3-part TV series, here the UK, dedicated an entire show
to the sad story. That's why I asked, "Who marketed it?" I knew
the answer, and my point was that successful marketing is vital
these days, when the market is so competitive. Having a good idea
is not enough to succeed.
> >Word isn't so bad on a machine with 32MB of RAM,
>
> I haven't _got_ a machine with 32Mb of RAM.
Neither did I, until 5 months ago. ;-) I don't do word processing,
if I can avoid it, and I usually can. Actually, my dad uses Word
on a 16 MB machine, and seems happy, but he's using Win95, while
I'm using NT and VC++.
> >but I think that the
> >real reason why Word "succeeds" even when its so big is that it has MS
> >pushing it.
>
> Exactly.
We probably don't have anything to argue about. ;-)
> The success of Wintel and Perl, and the lack of Lisp growth,
> can be attributed to the same three factors:
> Marketing,
> Marketing, and
> Marketing.
That's just what I've been saying.
> How many *popular* "apps" have you written, and what tools were used
> to write them?
Last year, I wrote a multimedia app that was, I'm told,
distributed with about 1/4 million magazines. I've wondered
how that app might have been written in Lisp, but if I find
a way of doing it, then I'll have to use it to write the
Win32 version, as I'm no longer working on the Win16 version.
What I could really use is a Lisp system with the Windows
support that VB has, with OCX support, very low runtime
overhead, and some decent marketing behind it. I'm not even
sure if DylanWorks will have that!
> Once upon a time there was a slogan "nobody was ever sacked for buying IBM."
True. So what? I'm not buying C++. I've asked for ACL/Win,
but I dunno if or when I'll get it. I'm just a programmer.
> >Is Stalin available for NT?
>
> Stalin itself is compiled by the free "Scheme to C" compiler.
> As I said, it's a one man project. I don't know any reason why it
> _couldn't_ be made to run on NT. If I had an NT box, I'd try it.
So it's unlikely that it'll have any of the Win32 support that
I need. Thanks.
--
<URL:http://www.enrapture.com/cybes/> "You can never browse enough."
Cyber Surfer:
> And Sun want you to use Java.
I know. Java is getting a _lot_ of promotion. Is that all a language
needs, for it to succeed?
no. they also need large (and long-lasting) government research grants
for artifical person construction, nuclear submarine guidence software
and www-expert systems.
:-\
oz