From: ········@bayou.uh.edu
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <5m2h2t$gib$1@Masala.CC.UH.EDU>
todd alden marshall (·············@ctw.org) wrote:
[Snip]
: Assembly on the endangered species list? only because Assembly
: programmers are more of an elite, not because they are less useful.
If the number of assembly language programmers has declined it means
one thing and one thing only -- the demand for them has declined. They
may think of themselves as "elite" the way the White Rhino thinks of
itself as "elite" -- by virtue of the fact that there aren't many of
them.
Now moving on with this train of logic, is this drop in numbers
consistent with the rest of the programming industry? No.
Conclusion: Assembly programmers are experiencing a decline in their
numbers which is not consistent with what the rest of the industry
is experiencing.
Conclusion: Given that other languages are higher level than assembly,
the drop in assembly and relative climb in other languages means that
higher level programming is being embraced at the expense of low level
programming.
Conclusion: What they were saying 10 years ago was correct.
--
Cya,
Ahmed
Big women -- I like the size
Big women -- flappy thighs
Big women, Big women, Big women fill my eyes!
"Big Women" by G.B.H.
From: James Logajan
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <jameslEALvwp.G5@netcom.com>
········@bayou.uh.edu (········@Bayou.UH.EDU) wrote:
: If the number of assembly language programmers has declined
[remaining "logic," unsupported assertions, and conclusion elided]
No one has in fact established that the amount of assembly language
programming has declined, or by what metric the decline would be
measured in. Number of lines of code? Amount of machine code generated?
Number of programmers? Percentage of programmers? Amount of time spent
programming in assembly? Percentage of programming time spent using assembly?
From: ········@bayou.uh.edu
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <5m4q0v$qga$1@Masala.CC.UH.EDU>
James Logajan (······@netcom.com) wrote:
: ········@bayou.uh.edu (········@Bayou.UH.EDU) wrote:
: : If the number of assembly language programmers has declined
: [remaining "logic," unsupported assertions, and conclusion elided]
Translation: I snipped everything that could disprove what I am about
to say.
: No one has in fact established that the amount of assembly language
: programming has declined, or by what metric the decline would be
: measured in. Number of lines of code? Amount of machine code generated?
: Number of programmers? Percentage of programmers? Amount of time spent
: programming in assembly? Percentage of programming time spent using assembly?
First off, just so I know from where to discuss this, do you agree
at least that the number of assembly language programmers has
declined? I would like an explicit agreement or disagreement on this
point before taking time to proceed.
--
Cya,
Ahmed
From: James Logajan
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <jameslEAp86x.252@netcom.com>
········@bayou.uh.edu (········@Bayou.UH.EDU) wrote:
: James Logajan (······@netcom.com) wrote:
: : ········@bayou.uh.edu (········@Bayou.UH.EDU) wrote:
: : : If the number of assembly language programmers has declined
: : [remaining "logic," unsupported assertions, and conclusion elided]
: Translation: I snipped everything that could disprove what I am about
: to say.
IMHO, one should quote only enough of a Usenet news posting to establish
context. Futhermore, thanks to automated news archivers such as Dejanews,
your original posting is retrievable for just about forever, so any
evil plot on my part to elide everything that could "disprove" what I say
would be futile.
I will admit that my eliding remark constitutes more opinion than
logical argument, but surely you, of all people, would grant me the
right to post my opinion to the net?
: First off, just so I know from where to discuss this, do you agree
: at least that the number of assembly language programmers has
: declined?
I don't know if the number of assembly language programmers has declined or
increased. I thought that it was up to you to establish the truth of your
premises before you proceed to draw conclusions. Never mind what I believe;
I have no "facts" to disprove your premises, but neither have you supplied
any "facts" to support your premise. I don't see the point of checking the
validity of any of the rest of your argument until you have at least
established the validity of your premises.
(But if you really really want my guess: I would GUESS that more
programmers know assembly languages today than ever before in the short
history of computers. I would GUESS that in absolute numbers, the amount
of assembly language programming has increased. But I would GUESS that
assembly language programming constitutes a smaller fraction of all
programming being done than ever before. I would GUESS that there is just a
hell of a lot more programming in many different programming languages
being done today than ever before.)
: I would like an explicit agreement or disagreement on this
: point before taking time to proceed.
Since I disagree with your leading premise, perhaps you should
first proceed to validate it.
From: Peter da Silva
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <5mes2a$pj1@web.nmti.com>
In article <············@masala.cc.uh.edu>,
········@bayou.uh.edu <········@Bayou.UH.EDU> wrote:
> First off, just so I know from where to discuss this, do you agree
> at least that the number of assembly language programmers has
> declined?
Has it?
Given the increase in the number of programmers, as computers are applied to
new feilds of endeavour, a moderate increase in the number of programmers
involved in the sort of project that assembly is suited for (which is about
the same thing it was suited for 10 years ago) would look like a decrease
by comparison.
--
The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
Har du kramat din varg, idag? `-_-' Kulanu Kibo.
Hail Eris! All Hail Discordia! Vi er alle Kibo.
HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
From: Paul Campbell
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <3385A047.1CFBAE39@lucent.com>
········@bayou.uh.edu wrote:
>
> Conclusion: What they were saying 10 years ago was correct.
>
To qualify my orignal reply: 10 years ago the the phrase
"in 10 years time we won't have to worry about efficency" was very
popular
among prolog avocates and it was a commonly held view in academic
circles that
the availibility of cheap computing power would soon herald the end of
3gls such as
C in favor of the likes of prolog and lisp.
So please forgive me my skepticism when I hear the same phrase bandied
about today,
particularly as the proportion of software developed by essentialy
imperitive
3gls (I'm including C++ here) vs prolog and list et-al has probably
increased -
even in the face of computing power escalating way beyond anything
envisaged at
the time.
People know that computers are getting ever faster so they expect them
to either
do more, or do the same job proportionately faster - I know I do !.
Ok so there has been a bit of a move away from assembler but even that
may be
just because there are more, as a proportion, user-level application v.s
embedded systems.
Paul C.
UK.
From: David Hanley
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <3385BC90.FC4@nospan.netright.com>
Paul Campbell wrote:
>
> ········@bayou.uh.edu wrote:
>
> >
> > Conclusion: What they were saying 10 years ago was correct.
> >
>
> To qualify my orignal reply: 10 years ago the the phrase
> "in 10 years time we won't have to worry about efficency" was very
> popular
> among prolog avocates and it was a commonly held view in academic
> circles that
> the availibility of cheap computing power would soon herald the end of
> 3gls such as
> C in favor of the likes of prolog and lisp.
>
> So please forgive me my skepticism when I hear the same phrase bandied
> about today,
> particularly as the proportion of software developed by essentialy
> imperitive
> 3gls (I'm including C++ here) vs prolog and list et-al has probably
> increased -
> even in the face of computing power escalating way beyond anything
> envisaged at
> the time.
>
> People know that computers are getting ever faster so they expect them
> to either
> do more, or do the same job proportionately faster - I know I do !.
>
> Ok so there has been a bit of a move away from assembler but even that
> may be
> just because there are more, as a proportion, user-level application v.s
> embedded systems.
Ok, but that's not what I said. I never said that effeciency would not
be
important, but that it would be less important in some situations, where
legitimate eingineering tradeoffs could be made.
Additionally, what is efficent and innefficent has changed
substantially.
C/C++ is great for small programs and tight loops. But people *are*
moving slowly
to simpler languages ( Java, Perl, 4gl's ) over C/C++.
Ten years ago, if you wanted a fast program on a home computer, you
pretty
much wrote it in assembley. Now, C or even C++ is the norm. I think in
10 years we
can expect progress away from C/C++ to 'better' languages. I hope that
functional
languages will be among these.
Part of this is because we can expect compiler technology to improve to
the point where there won't be advantages to using C/C++ over, say, ML,
Haskell,
or LISP. Remember, ten years ago, C was *much* slower than assebler on
many platforms.
Optimizers got better, though.
So, I feel that progress has happened in the past ten yeas, and will
continue
to take place. And I doubt any language currently existing is the
pinnacle of SE..
dave
>
> Paul C.
> UK.
In article <············@nospan.netright.com>, ·····@nospam.netright.com wrote:
(much snipped)
> Ten years ago, if you wanted a fast program on a home computer, you
>pretty
>much wrote it in assembley. Now, C or even C++ is the norm. I think in
>10 years we
>can expect progress away from C/C++ to 'better' languages. I hope that
>functional
>languages will be among these.
>
> Part of this is because we can expect compiler technology to improve to
>the point where there won't be advantages to using C/C++ over, say, ML,
>Haskell,
>or LISP. Remember, ten years ago, C was *much* slower than assebler on
>many platforms.
>Optimizers got better, though.
That first assertion there is amazing. Ten years ago, and for a long time
before that, home computers came WITHOUT any assembler and WITH
a Basic interpreter in their usual packaged forms. So the language of
first choice for programming them was BASIC. It was slow because it
was interpreted, so for fast programmes something else was needed.
There were perfectly adequate C and Pascal compilers available from
several software vendors, and a lot of software was written in these
languages. Assembler was used for some things (mostly for writing
games programs, I guess) but it is just not true that you were forced
to use it to get fast programmes. I don't think much has changed in
ten years, people still use C, people still resort to assembler for some
of the more esoteric bits (assembler embedded in C, of course), - C++
has come in and Pascal is going out, but that's is anything a change
to a lower level!
Like you. I would like to see much wider use of funtional languages,
languages with decent types systems, logic languages, and so on.
But unlike you I don't think the reason for the very slow take-up of
these languages is to do with raw performance (although the very large
footprint of applications produced by most CLOS development systems
has tended to restrict the pplicability of LISP). It's more the result of
quite different factors: some of them are commercial (if you want a
development system for PCs for commercial use you buy from someone
who is going to be around to provide upgrades as the platform develops -
freeware out of a research group is not going to get much of a look in);
some are to do with usability (most functional languages are pretty
awful in this respect, although things are getting better); another is
(perceived) lack of stability - are there any ANSI or ISO or ECMA
standards for the language; another is difficulty of understanding -
or maybe inadequate tutorial documentation - and lack of available
training courses; another is lack of portability / platform independence;
another is lack of adequate libraries/standard functions/interfaces to
other tools (could I write Active-X conformant stuff in Haskell? does
Gopher have an ODBC interface?); and finally of course we have the
lack of standard binary interfaces which would allow these languages
to be used where appropriate instead of for the whole of a project.
Tom Thomson
With a mighty <··········@rocannon.cam.harlequin.co.uk>,
····@harlequin.co.uk uttered these wise words...
> a Basic interpreter in their usual packaged forms. So the language of
> first choice for programming them was BASIC. It was slow because it
> was interpreted, so for fast programmes something else was needed.
Basic _implementations_ have generally been slow. Basic itself is
something else. I still find it ironic that a popular Basic for the
Atari ST was (and for all I know still is) a token based interpreted
implementation called "Fast Basic". It could easily be faster than ST
Basic, which I think came with the machine, but as ST Basic fell over
a weak breeze, this says more about flacky software than anything
else.
Just like Lisp, Basic's image suffers because of poor software. If you
want a batch compiler for Basic, these have been available for
decades. Don't blame Basic if so few people know or use them. Even MS,
who seem to love batch compilers (as an alternative to interactive
compilers), have only recently released a version of VB with support
for native code. Note that VB 5 still allows an incremental style of
development in which you barely see the compiler working.
This gives me an excellent opportunity to plug my favourite book about
compilers:
Writing Interactive Compilers and Interpreters
P.J. Brown
John Wiley & Sons Ltd
ISBN 0 471 27609 X hbk
ISBN 0471 100722 pbk
> Like you. I would like to see much wider use of funtional languages,
> languages with decent types systems, logic languages, and so on.
I feel the same way. However, I wouldn't want to rush something, by
promoting - or hyping - it too early. I'd also like to see strong
support for things like COM, ActiveX, etc, and a good IDE. Perhaps an
environment like Delphi, but using SML instead of Pascal. A bias
towards delivery (at for a platform like Windows) in the form of an
EXE or DLL/OLE/ActiveX component would also be very tasty.
However, I don't expect this to happen, because the existing
developers using language like ML appear not to be interested in such
things. At least, this is what people tell me. I just think about what
Harlequin claim DylanWorks will offer, and wonder what makes Dylan
programmers so different from programmers using Lisp, Prolog, and more
functional languages.
Right now, it appears that the technolgies that you intend to use may
determine the language(s) that you use. Choose ActiveX, and you're
choosing VB, C++, and perhaps even Java. Choose the more traditional
"AI" technologies, and you may find yourself using Lisp or Prolog.
Of course, you _can_ use ODBC is Lisp or Prolog, and it wouldn't be
too hard to define an ODBC module to Haskell and then implement it.
I just doubt that many people currently using Basic or C++ will be
attracted by the prospect. This is fair enough, as not many Lisp or
Prolog programmers appear to be too enamoured by the capabilities of
VC++ and VB.
Politics and marketing may have something do with it, but all I know
is that I can find few people who will admit that some tool that
differs greatly from what they currently use could possibly be of
value to them. In some cases, they even doubt it could be of value to
_anyone_. This often takes of the form long threads in which people
slag off each others' chosen programming tools.
Which species is superior: humans or dolphin? I'm human, so I may be
biased...OTOH, if I'd been born a dolphin, I might enjoy doing nothing
but playing and eating fish. This is why I sometimes find myself in
the water, trying to see the other point of view.
> But unlike you I don't think the reason for the very slow take-up of
> these languages is to do with raw performance (although the very large
> footprint of applications produced by most CLOS development systems
> has tended to restrict the pplicability of LISP).
> another is lack of adequate libraries/standard functions/interfaces to
> other tools (could I write Active-X conformant stuff in Haskell? does
> Gopher have an ODBC interface?); and finally of course we have the
> lack of standard binary interfaces which would allow these languages
> to be used where appropriate instead of for the whole of a project.
First find a commercial implementation of Haskell or Gopher. It's more
than a little unfair to compare, say, Haskell with C++ or Java, as
some languages have more resources thrown at them, by several orders
of magnitude, I bet. Haskell is still changing, but then, so is Java.
At least, I hope it is!
Some people are doing interesting things with such languages, like
Conal Elliot at MSR (the MS Ivory Tower). Remember ActiveVRML?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In article <·························@news.demon.co.uk>,
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) wrote:
> Just like Lisp, Basic's image suffers because of poor software.
I beg to disagree violently! Basic's image suffers because of brain-damaged
conceptions. The original Basic was:
* statement oriented
* no recursion
* no arguments/parameters to subroutines (info passed globally)
* very short identifiers
* slow as sh*t (even compared with interpreted Lisp)
I.e., original Basic was complete crap. Lisp had the full power of the lambda
calculus from day 1.
'Visual' Basic isn't 'Basic' at all, it is an interpreted form of
Ada/Modula/Eiffel. It is still slow as sh*t.
From: Mike Haertel
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <slrn5p264t.508.mike@ducky.net>
In article <·······················@10.0.2.1>, Henry Baker wrote:
>I.e., original Basic was complete crap. Lisp had the full power of the lambda
>calculus from day 1.
No argument about Basic.
But I would like to point out that it took Lisp more than a decade
to get lexical scope and closures (in Scheme). Essential for implementing
the lambda calculus.
I don't see why your Lisp advocacy has to be so rabid as to descend
to hyperbole. You don't do either yourself or the language any favor.
With a mighty <·······················@10.0.2.1>,
······@netcom.com uttered these wise words...
> In article <·························@news.demon.co.uk>,
> ············@gubbish.wildcard.demon.co.uk (Cyber Surfer) wrote:
>
> > Just like Lisp, Basic's image suffers because of poor software.
>
> I beg to disagree violently! Basic's image suffers because of brain-damaged
> conceptions. The original Basic was:
> * statement oriented
> * no recursion
> * no arguments/parameters to subroutines (info passed globally)
> * very short identifiers
> * slow as sh*t (even compared with interpreted Lisp)
Well, I dunno about you, Henry, but I grew up in a generation that was
perfectly happy with most of the limitations that you've mentioned. I
soon discovered the joys of other languages, which eventually lead me
to Lisp and even more functional languages.
> I.e., original Basic was complete crap. Lisp had the full power of the lambda
> calculus from day 1.
Agreed. What has this to do with Lisp's image vs Basic's image? As
I've pointed out before, the general perception of a language may
differ greatly from the perception of it by those who use it.
Beware of the eggs!
> 'Visual' Basic isn't 'Basic' at all, it is an interpreted form of
> Ada/Modula/Eiffel. It is still slow as sh*t.
Even some VB people will admit this. It's still incredibly successful.
Even if this is only due to the fondness that Bill Gates has for
Basic, and the huge resources of MS, VB has a very high profile.
There are entire magazines devoted to it, regular columns for it in
less specialised mags. While we may complain that this interest is not
founded on any technical merit (highly debated tho that claim may be),
can we really deny that VB has a positive image?
Many anti-VB criticisms apply to pre-VB 5. Some of the same criticisms
may also apply to...Lisp. When I want fast I/O performance, I still
have to resort to C. This not the fault of Lisp itself, but the Lisp
implementations that vendors make available. At least one vendor has
told me that the demand of more efficient I/O is not great enough.
It could be that many programmers with a demand for high performance
I/O can't wait for a Lisp vendor to improve their code, and so switch
to another language. The "lack of demand" would then become a self
fullfilling prophecy!
I'm not saying that Basic is "better" than Lisp. I will suggest that
the marketing of Basic may have been better than Lisp, over the years.
Today, you can find C++ programmers slagging off Basic in the same way
that they slag off Lisp, Java, etc. While Lisp and Basic differ in
many _technical_ ways, in this sense they have a lot in common. There
are C++ programmers who, I guess, feel threatened by them.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Hrvoje Niksic
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <kig206mpj8h.fsf@jagor.srce.hr>
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
> > > Just like Lisp, Basic's image suffers because of poor software.
> >
> > I beg to disagree violently! Basic's image suffers because of brain-damaged
> > conceptions. The original Basic was:
> > * statement oriented
> > * no recursion
> > * no arguments/parameters to subroutines (info passed globally)
> > * very short identifiers
> > * slow as sh*t (even compared with interpreted Lisp)
>
> Well, I dunno about you, Henry, but I grew up in a generation that was
> perfectly happy with most of the limitations that you've mentioned.
Which generation is that, exactly? I've never met a person happy with
them before.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm a Lisp variable -- bind me!
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> Which generation is that, exactly? I've never met a person happy with
> them before.
Ask in a VB newsgroup, and you should get plenty of replies. ;-)
Perhaps you've just never met one before, but I can assure you that
they do exist.
Followups set to comp.lang.misc,comp.lang.basic.visual.misc.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Hrvoje Niksic
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <kigyb8txcq4.fsf@jagor.srce.hr>
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
> > Which generation is that, exactly? I've never met a person happy with
> > them before.
>
> Ask in a VB newsgroup, and you should get plenty of replies.
Henry wasn't talking about VB (whatever that stands for), but for
BASIC.
> Perhaps you've just never met one before, but I can assure you that
> they do exist.
All sorts of people exist. The people who have never seen a decent
programming language, the people who supported Hitler, the people
who are plain stupid, whatever. Meeting one of them proves /nothing/.
You were talking about a whole generation "happy" about the most basic
limitations (pun not intended) one can name.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Then... his face does a complete change of expression. It goes from
a "Vengeance is mine" expression, to a "What the fuck" blank look.
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> ············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
>
> > > Which generation is that, exactly? I've never met a person happy with
> > > them before.
> >
> > Ask in a VB newsgroup, and you should get plenty of replies.
>
> Henry wasn't talking about VB (whatever that stands for), but for
> BASIC.
So? Whether it's VB or Basic from 20 years (or more) ago, there are
still people happy with it. VB is a good example of a modern Basic. If
you doubt that people are happy with it and using it, follow my
suugestion and see the VB newsgroups.
Please note that I have no interest in "defending" Basic. I'm simply
noting that Basic has its supporters. If some of them are as rabid as
the supports for C++, Lisp, Tcl, whatever, then this could be the
start of a stupid language war. I hope this will not be the case!
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Hrvoje Niksic
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <kig4tbgqdn8.fsf@jagor.srce.hr>
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
> VB is a good example of a modern Basic.
Henry wasn't talking about modern BASICs. The image BASIC has
certainly predates its modern incarnations.
Am I clear now?
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
I'm a Lisp variable -- bind me!
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> Henry wasn't talking about modern BASICs. The image BASIC has
> certainly predates its modern incarnations.
I certainly am. We could talk endlessly about the past, and it would
have no relevance. One of the classic techniques of trashing a
programming language (or other any software) is to compare an old
example with a modern rival. Like comparing and old Basic system with
a modern Lisp system.
> Am I clear now?
Yes, perfectly. I'm just saying that it's an exmaple of the very
problem that I was refering to. Lisp isn't diminished by comparing
modern Lisp systems with modern Basic systems. I'm comparing them by
saying that they have something significant in common: there are who
people spread disinformation about them.
Paraphrasing yourself: The images Lisp and Basic have certainly
predate their modern incarnations.
Am I clear now?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Hrvoje Niksic
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <kig3eqyl3yg.fsf@jagor.srce.hr>
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
> > Henry wasn't talking about modern BASICs. The image BASIC has
> > certainly predates its modern incarnations.
>
> I certainly am.
Then you are changing the subject.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!"
"They are my innards! I will not have them misread by a poseur!"
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> Then you are changing the subject.
Only by putting a comment about Basic 10 years ago into some
perspective. Native code Basic compilers were available at least 15
years ago, so we should take care about say that Basic _interpreters_
may be "slow". That's very different from saying that _Basic_ was
slow, 10 years ago.
Let's play fair. 10 years ago, it was easy to find a "slow" Lisp.
That doesn't make Lisp slow, does it? We should take care in how we
measure performance. I could claim that O'caml is 5 times faster than
LWW, but I'd be measuring their relative I/O performance.
I learned long ago that no matter how good the native code produced by
a compiler may be, the I/O performance may depend on the runtime code,
and that may suck farts from dead cats. It's only a language issue if
people using that language are less concerned about the performance of
that area of the implementation than the users of another language and
the implementation of similar area. In this case, it's I/O.
One reason I picked I/O performance is that some examples are so bad
that it doesn't matter whether the code is compiled or interpreted.
This is perhaps a good argument for profiling language runtime systems
to see where the _real_ time is spent.
The other reason is much simpler; much of the code I write heavily
depend on I/O. Perhaps this is why some people say that VB is "slow"?
Profile the code, indentify the bottlenecks, and rewrite them in C,
and you might get a very different result. Just blaming the language
is dumb. Blaming the implementation would be better, but not as
constructive as addressing the real performance issue.
Check the subject of this thread before you accuse me of "changing the
subject". Perhaps I'm more on-topic than you think. Didn't I say in an
earlier post that Lisp and Basic have a few things in common? Being
the victims of misinformation that only serves C/C++ programmers may
be one of them.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
>With a mighty <···············@jagor.srce.hr>,
>·······@srce.hr uttered these wise words...
>> ············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
>>
>> > > Which generation is that, exactly? I've never met a person happy with
>> > > them before.
>> >
>> > Ask in a VB newsgroup, and you should get plenty of replies.
>>
>> Henry wasn't talking about VB (whatever that stands for), but for
>> BASIC.
>So? Whether it's VB or Basic from 20 years (or more) ago, there are
>still people happy with it. VB is a good example of a modern Basic. If
>you doubt that people are happy with it and using it, follow my
>suugestion and see the VB newsgroups.
But that is completely *not* the point! You've changed the subject.
Henry listed 5 specific limitations of original Basic. You said you
"grew up in a generation that was perfectly happy with most of the
limitations that [he] mentioned." Not "happy with VBasic today", but
happy with *those* limitations. Not "used Basic because it was
available in *spite* of those limitations", but happy with those
limitations.
Now, you might not have meant exactly that, which is fine --- for
example you might just have been defending Basic. But Hrvoje Niksic's
response was simply expressing surprise that there was an entire
generation perfectly happy with most of the _limitations_:
e.g. statement oriented, no recursion, no arguments/parameters to
subroutines (info passed globally), very short identifiers, slow (even
compared with interpreted Lisp).
Does Visual Basic share these limitations? Were you just
misinterpreted? Or do you really think there was a generation
specifically "that was perfectly happy with most of the limitations
that [he] mentioned." If so, which generation was that?
············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
>If you wish to compare Basic in (picking a year not quite at random)
>1981 with Lisp in 1981, what do you get?
I'm not trying to compare Basic or Lisp with anything, least alone
with each other. You made a statement about people (an entire
generation, in fact) being happy with specific limitations, namely
those listed below. That's a language independent statement. Now,
what most people are arguing is that the people who were happy with
Basic, were *not* happy with those limitations. Either they were
happy with Basic for *other* reasons (availability, for one thing), or
in *spite* of those limitations, or they were unaware of those
limitations.
>The significance of this may have been overstimated by some people,
>and understimated by others. For example, if the first machine you
>used was a Lisp Machine, then you may well have more experience with
>Lisp, and a more favourable impression of Lisp than Basic.
Actually, (and this is *completely* beside the point), I *used* Basic.
The 2nd Lisp I used was a pseudo-lisp interpreter I wrote myself for
my TRS-80 that had almost none of the positive features of modern
lisp. That's not the point, except as a counter-example to some of
your later statements. There was certainly a couple of years where I
was much more familiar with Basic than with Lisp, but I don't think it
scarred me for life.
>> Now, you might not have meant exactly that, which is fine --- for
>> example you might just have been defending Basic. But Hrvoje Niksic's
>> response was simply expressing surprise that there was an entire
>> generation perfectly happy with most of the _limitations_:
>> e.g. statement oriented, no recursion, no arguments/parameters to
>> subroutines (info passed globally), very short identifiers, slow (even
>> compared with interpreted Lisp).
From reading the rest of your post, I assume that your answer is "I
simply meant that people were/are happy with Basic". I have no
arguments with that, had no arguments with that, and will have no
arguments with that.
With a mighty <··················@CS.Stanford.EDU>,
········@Radon.Stanford.EDU uttered these wise words...
> I'm not trying to compare Basic or Lisp with anything, least alone
> with each other. You made a statement about people (an entire
> generation, in fact) being happy with specific limitations, namely
> those listed below. That's a language independent statement. Now,
> what most people are arguing is that the people who were happy with
> Basic, were *not* happy with those limitations. Either they were
> happy with Basic for *other* reasons (availability, for one thing), or
> in *spite* of those limitations, or they were unaware of those
> limitations.
Exactly. Being unaware of a limitation, some people will just accept
it. Worse, people can even rationalise limitations! I don't blame
anyone for doing this, esp when they don't know that there's an
alternative. If an alternative is known but unavailable (for whatever
reason), rationalising the lack of choice may seem like a sensible
thing to do.
Of course, I'm guessing about this, as I can only imagine why someone
else decides to do something or to believe something. For years, I
just accepted using a terminal over a 9600 serial line. I didn't have
to use it, but I liked the machine at the other end of the cable
enough so that it didn't bother me.
The primitive user interfaces that I used during that time were fine
with me, coz what I really wanted was a fully graphical modeless user
interface system, and that was beyond my reach at that time. It's only
relatively recently that tools for building thin clients have become
high profile (perhaps thanks to Java?), so at last I can write the
kind of software that I was lusting after in the early 80s.
I still wonder, tho, how I could be so content with a line editor. I
know I wrote a very basic screen editor, but I wrote it in C, and in
those days I had the bad habit of optimising my code before I wrote
it, leading to serious bugs in the buffer handling code. For some
reason, I never returned to that code to fix the bug(s), even after my
C skills had improved. By that time, I was more into assembly language
and Forth, so a line editor wasn't much of a problem.
Still, I didn't rationalise the use of a line editor. I don't recall
giving it that much thought! Perhaps that was worse, but I dunno. As I
said, it didn't seem like a problem at the time. My Forth had it's own
editor, which was "screen" based (Forth "screens" are a little
different from VDU screens - it's a unit of source code).
> Actually, (and this is *completely* beside the point), I *used* Basic.
> The 2nd Lisp I used was a pseudo-lisp interpreter I wrote myself for
> my TRS-80 that had almost none of the positive features of modern
> lisp. That's not the point, except as a counter-example to some of
> your later statements. There was certainly a couple of years where I
> was much more familiar with Basic than with Lisp, but I don't think it
> scarred me for life.
I wouldn't say that Basic will necessarily scar you for life. Of
course, I may be saying that because _I_ started with Basic. It may
still be true. My first Lisp was written in assembly language, but I
don't think that scared me, either. I learned a lot from that
experience - so my second Lisp interpreter was written in C.
Curiously, writing 3000 lines of assembly language (just for Lisp)
helped give me a better understanding of C. Pointer casting and unions
held no terror for me after that!
It sounds like you and I have done some similar things.
> >> Now, you might not have meant exactly that, which is fine --- for
> >> example you might just have been defending Basic. But Hrvoje Niksic's
> >> response was simply expressing surprise that there was an entire
> >> generation perfectly happy with most of the _limitations_:
> >> e.g. statement oriented, no recursion, no arguments/parameters to
> >> subroutines (info passed globally), very short identifiers, slow (even
> >> compared with interpreted Lisp).
[the above was not written by me - tho I may certainly have quoted it]
[the above line is purely for quotation pedants! ;-)]
> From reading the rest of your post, I assume that your answer is "I
> simply meant that people were/are happy with Basic". I have no
> arguments with that, had no arguments with that, and will have no
> arguments with that.
That's correct. I might still refer to "an entire generation of Basic
programmers", as I don't recall anyone that I knew at the time
complaining about the limitations (or otherwise) of Basic. We were
more concerned about the relative merits of the 6502 vs the Z-80!
Languages weren't an issue - there was only Basic and machine code.
Perhaps this says more about the limitations of the software available
to us at that time - I was unusual amoungst the people that I knew coz
I bought a C compiler (LC, I think it was called - based on the Small
C compiler). It was pretty expensive software for the TRS-80, as ISTR
that it cost about 100 pounds (or $100?). I was also unusual for
buying LDOS, which was I think just as expensive. I don't regret
either purchase, as I learned a lot from them.
In fact, I still miss some LDOS features. Well, now I can use bash...
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
············@gubbishwildcard.demon.co.uk (Cyber Surfer) writes:
>With a mighty <··················@CS.Stanford.EDU>,
>········@Radon.Stanford.EDU uttered these wise words...
>> I'm not trying to compare Basic or Lisp with anything, least alone
>> with each other. You made a statement about people (an entire
>> generation, in fact) being happy with specific limitations, namely
>> those listed below. That's a language independent statement. Now,
>> what most people are arguing is that the people who were happy with
>> Basic, were *not* happy with those limitations. Either they were
>> happy with Basic for *other* reasons (availability, for one thing), or
>> in *spite* of those limitations, or they were unaware of those
>> limitations.
>Exactly. Being unaware of a limitation, some people will just accept
>it.
So, I guess we can now kill the old thread since there is no
disagreement: there was no generation *happy* with those limitations,
just a generation who used Basic *unaware* of any such limitations.
>
>> ... There was certainly a couple of years where I
>> was much more familiar with Basic than with Lisp, but I don't think it
>> scarred me for life.
>I wouldn't say that Basic will necessarily scar you for life.
Forget "scar" then; I thought you explicitly conjectured that certain
behavior could be traced to whether you learnt Basic first or learnt
Lisp first. I was submitting myself as a counter-example.
>> >> Now, you might not have meant exactly that, which is fine --- for
>> >> example you might just have been defending Basic. But Hrvoje Niksic's
>> >> response was simply expressing surprise that there was an entire
>> >> generation perfectly happy with most of the _limitations_:
>> >> e.g. statement oriented, no recursion, no arguments/parameters to
>> >> subroutines (info passed globally), very short identifiers, slow (even
>> >> compared with interpreted Lisp).
>[the above was not written by me - tho I may certainly have quoted it]
I wrote it. You quoted it. I didn't mean to misattribute it.
>> From reading the rest of your post, I assume that your answer is "I
>> simply meant that people were/are happy with Basic". I have no
>> arguments with that, had no arguments with that, and will have no
>> arguments with that.
>That's correct. I might still refer to "an entire generation of Basic
>programmers", as I don't recall anyone that I knew at the time
>complaining about the limitations (or otherwise) of Basic.
Not even the lack of local variables and no parameters to subroutines?
And the short identifiers? I remember these as complaints (that I
*and* others had) when I first learned Basic. (Of course, I
personally complained about the speed and reliability of CSAVE and
CLOAD more than anything else). Or you'd say this was because Basic
was not my first language: I guess I knew Fortran, PL/1, PDP11
assembler, and Algol before I learnt Basic.
So the proper quote from you would be "I meant that there was a
generation of people for whom Basic was the only (or best) language
they knew, and they were happy with it."
With a mighty <··················@Xenon.Stanford.EDU>,
········@Xenon.Stanford.EDU uttered these wise words...
> >So? Whether it's VB or Basic from 20 years (or more) ago, there are
> >still people happy with it. VB is a good example of a modern Basic. If
> >you doubt that people are happy with it and using it, follow my
> >suugestion and see the VB newsgroups.
>
> But that is completely *not* the point! You've changed the subject.
> Henry listed 5 specific limitations of original Basic. You said you
> "grew up in a generation that was perfectly happy with most of the
> limitations that [he] mentioned." Not "happy with VBasic today", but
> happy with *those* limitations. Not "used Basic because it was
> available in *spite* of those limitations", but happy with those
> limitations.
If you wish to compare Basic in (picking a year not quite at random)
1981 with Lisp in 1981, what do you get? The generation that I'm
refering to could easily get hold of Basic implementations. In fact,
it was hard to avoid them, as Basic was included in ROM on micros at
that time. (With a few exceptions, like S100 machines, the Jupiter
Ace, and other "uncommon" machines.)
I'm not disputing the technical superiority - others might, but not
me. However, comparing Lisp with Basic on a micro in the early 80s
isn't particularly fair to Lisp, due to the ROM advantages which gave
Basic more exposure and more memory. Of course, this gave Basic an
"edge" over many other languages, too.
The significance of this may have been overstimated by some people,
and understimated by others. For example, if the first machine you
used was a Lisp Machine, then you may well have more experience with
Lisp, and a more favourable impression of Lisp than Basic. This is
what I mean by "egg orientation". The reality may have nothing to do
with our perceptions of Lisp or Basic if our perceptions depend so
heavily on our initial experiences with computers.
> Now, you might not have meant exactly that, which is fine --- for
> example you might just have been defending Basic. But Hrvoje Niksic's
> response was simply expressing surprise that there was an entire
> generation perfectly happy with most of the _limitations_:
> e.g. statement oriented, no recursion, no arguments/parameters to
> subroutines (info passed globally), very short identifiers, slow (even
> compared with interpreted Lisp).
Many of those Basic programmers "progressed" to assembly language,
which is hardly a more sophisticated language. It may certainly be
more _efficient_, but that would depend on the quality of your Basic
implementation. The same applies to Lisp. As you said, Basic in those
days tended to be interpreted and perceived as "slow", as was Lisp.
That didn't mean that every implementation of these languages were
interpreted and slow.
You're assuming that everyone who uses Basic will appreciate the
differences between Lisp and Basic. Well, a programmer would first
have to understand Lisp before they can appreciate it. As I've pointed
out, Basic has - for micros, at least - been given rather more
exposure than Lisp.
Companies like MS have given Basic much more support than Lisp. Do MS
still sell Mu-Lisp? Did they promote Mu-Lisp as hard as Basic? Could
the bias of Bill Gates towards Basic have anything to do with this?
Could any of this just be due to a historical accident, like Gates
being exposed to Basic before Lisp, before writing a language system
for a certain Altair machine? Who knows.
> Does Visual Basic share these limitations? Were you just
> misinterpreted? Or do you really think there was a generation
> specifically "that was perfectly happy with most of the limitations
> that [he] mentioned." If so, which generation was that?
A generation heavily exposed to Basic before Lisp. There may even be
many Basic programmers with _no_ exposure to Lisp at all. It may be
incredible to some Lisp people, but it does sometimes happen. Perhaps
these are the people who give me blank looks when I mention Lisp?
All I know is that they've generally used Basic, perhaps a little C
and/or assembly language, plus a few domain specific languages (SQL,
simple scripting languages, xBase, etc).
Whatever you may think of Basic, you should accept that there are
programmers who're perfectly happy with it. If you only tell them that
"Lisp is better", then you'll risk creating a hostile reaction. One
major problem with the above claim is the lack of "evidence". Modern
Basic systems, like VB, have technical advantages that have great
value, even if not many Lisp people appreciate them. These advantages
may have more to do with the _environment_ than the language, hence
the success of Deplhi, which applies similar IDE ideas to Pascal
instead Basic.
So, the "ROM advantage" has been replaced by the "IDE advantage".
However, since Basic lacks features like reflection, and not many Lisp
people seem to appreciate the fact that many programmers _don't want_
reflection, the misunderstandings continue. (Note that using
reflection in Basic isn't completely alien. I have a book called
Implemention Basics, by Payne & Payne, that described how something
like this may be done. Sadly, the idea of a reflective Basic never
became popular enough to become survive.)
As the subject of this thread refers to C++'s success, we should look
at how C/C++ compilers tend to heavily exploit the "IDE advantage", at
least on some machines (Mac, Windows). Lisp environments tend to be
built using reflection, and so operate in a very different manner.
while this makes them much more powerful and flexible, such
environments tend to have weak support for what many Basic and C++
programmers now call "component based development".
In other words, there's a deep idealogical rift. I doubt that it'll be
easy to bridge it, but a few people are trying. See Smalltalk MT for
an example, using Smalltalk. ST environments traditionally exploit
reflection rather heavily, perhaps too heavily for many people.
I guess that, in the past, Lisp and Basic programmers wanted something
different, and they got it. What interests me is not so much what they
wanted, but why they wanted it. I'm also curious about how these
desires may have changed, or not changed, and _why_. I'm satisfied
with the all too convenience answer that "those other people got it
wrong". They certainly made different choices, and I don't think that
anyone here is disputing that. The question is _why_?
The only answer that I have is that not all programmers want the same
things. We could ask why different programmers want different things,
and I'm sure that some people will say (as they have in the past) that
some people are just stupid. IMHO that's grossly unfair, as way too
convenient. We can always call people who disagree with us "stupid".
"Ignorant" might be better, but that's still far too simplistic to
really answer the question. It's also just a little insulting, and so
it could lead to more hostile reactions.
In the end, the only diplomatic answer is to say that we see things
differently. We might not even be looking at the same things! I've
seen Lisp and C++ people often misunderstanding each other. No doubt
the same thing can happen with Lisp and Basic people. For example, how
many Basic programmers know what "reflection" refer to? How many Lisp
programmers know what "component based development" refers to? How
many programmers can understand _both_ points of view?
Damn few, I bet. Hence the problem. "Ignorance" works both ways.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In article <·························@news.demon.co.uk>, Cyber Surfer wrote:
>The generation that I'm
>refering to could easily get hold of Basic implementations. In fact,
>it was hard to avoid them, as Basic was included in ROM on micros at
>that time. (With a few exceptions, like S100 machines, the Jupiter
>Ace, and other "uncommon" machines.)
Actually, it's very easy to avoid them; just avoid micros! There's
this implication that micros were the only computers. Lisp didn't
even run on Micros until really late in the game (ie, post-ibm-pc is
late in the game).
--
Darin Johnson
·····@usa.net.delete_me
From: Will Hartung
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <vfr750EB9utA.KI8@netcom.com>
·····@usa.net.delete_me (Darin Johnson) writes:
>In article <·························@news.demon.co.uk>, Cyber Surfer wrote:
>>The generation that I'm
>>refering to could easily get hold of Basic implementations. In fact,
>>it was hard to avoid them, as Basic was included in ROM on micros at
>>that time. (With a few exceptions, like S100 machines, the Jupiter
>>Ace, and other "uncommon" machines.)
>Actually, it's very easy to avoid them; just avoid micros! There's
>this implication that micros were the only computers. Lisp didn't
>even run on Micros until really late in the game (ie, post-ibm-pc is
>late in the game).
Wow! What a concept. I lived in a world that was structured a bit
differently. Our towers were of a different color.
True, technically micros weren't the only computes available. But,
realistically, it is a whole different story.
The year before I went to my High School, there was a three week
"Computer Programming" camp held. During that time, 15ish students
purchased TI-59's to learn programming, and then assembled an
IMSAI-8080 computer, with 16K of RAM, big-o-toggle switches on the
front panel, a cassette interface, and a 9 inch B/W monitor that was
probably a life-threatening electrical shock hazard as it was an open
chassis. The BASIC tape required a 150 byte 8080 programmed to be keyed
in through the monitor to bootstrap the tape. BASIC used 9K of the 16.
The families of the kids in the program, funded the entire thing. The
calc alone were a couple $100 each. I would guess that the price/kid
was $4-500, including the calcs.
I specfically remember ditching Drivers Ed to play on that machine in
the chemistry lab where it rested. Trying to decode the wonders of
INPUT.
Those were exciting days for everyone. 1978.
At the end of the year, someone donated 3 Commadore PET computers. 8K
RAM, built in cassette, BASIC in ROM. I specifically remember the
science teacher being literally ON HIS KNEES, and his eyes wide with
excitement when I told him about the gift to the school, and while he
was talking to the donor. The gift probably totalled about $3000.
An large amount of free time was spent banging on those machines.
Those were exciting days for everyone. 1979.
Dad had a big 'ol TRS-80 with 48K RAM, and 2 Disk Drives, and a wierd
electrostatic printer that happened to make great photocopies at his
office. He had MACRO-80, FORTRAN, and Scripsit (WP prog). System
probably cost the company $4-$5000.
For a gift, he gave me a KIM-1 single board computer. 6 Digit Hex
display, 1K RAM, cassette interface, 6502 CPU. What fun making lights
blink, and watching the TV lose its signal whenever I fired the thing
up. How I longed for a teletype to bolt on to that little computer.
The computer cost $300ish, tape recorder was $30.
Those were exciting days for everyone. 1980.
I was in college, encountered the wonder of the CDC Cyber 730, 1200
Baud terminals (the fast ones), the magic of FORTRAN. The enormous
machine filling the room. I doubt I could fathom the cost of this
machine and its supported infrastructure and staff. The students
shared this machine with Administration. We always cursed
Registration, because the system would drag.
A Summer Job resulted in the money for an Atari 800. Probably spent
$1500 on that thing. Extremely cool graphics hardware, 48K RAM, 80K
Disk Drive, BASIC in cartridge. Discovered more assembly, Forth, etc
on the Atari. The Apple was all the rage, because it had Wizardry on
it. The C64 was on its way to start the price wars that help destroy
the micros. The PC was starting to make a little noise.
Those were exciting days for everyone. 1982.
In the world where I came from, micros were the only real option. What
else was available for human beings? For kids in high school? Some
folks I knew went to local colleges to play in their labs. That wasn't
the norm where I came from.
Micros were available, but still expensive. "Well we could get junior
a computer, or we could get him a car." I didn't own a car. My money
fed this silicon based habit I seemed to have developed.
College opened my eyes to a whole different world: APL, SNOBOL, LISP,
Pascal, C...But that's what college was for. That's why they're here.
High Schools get whatever they can get their hands on. This is 1997,
and STILL we here the cry "We need computers in the schools" (though
more for elementary nowadays).
The micros of old are now consider stone knives and bearskins of the
computing world. More famous for the nostalgia of they they invite
than anything compared to what we are running today. Heck, most of
these old machines are now software programs running on PCs. Emulators
that run all of that old software.
So, perhaps micros were not the only computers available to some, but
they were the ones available to most. My friend didn't buy his first
workstation (A Sun 50) until 1988, and I remember him forking over
$2250 for a 750MB drive -- just the drive. I was pretty stunned. This
was after 10 years of Moores Law. 3 years earlier our company paid
$25000 for a 400MB drive for our PUNY VAX 11/730. That drive
quintupled our storage.
A few years later, I had bought a NeXTStation for $3000. Micros were
gone, PCs ruled the day.
Today, computing power no longer dictates what we develop in as
strongly as it did. Computing power is cheap. We can sit back in our
arm chairs and point fingers at the past; decry "They shoulda...".
I don't thing anyone with the aptitude, who had been bitten by the bug,
was put off of Computer Programing because of the limitations of the
old BASICs. It was interactive, it was simple, it did the job and
produced immediate, mostly correctable results. Much like a Painter
giving up on watercolors and moving to oils, those old BASICs were
enough to light the spark inside of a lot of people. The BASICs
satisfied some, and acted as a step up to others.
So, others may have been able to pick and choose from high powered
computng resources when I was down in the gutters, flailing away with
2 character variable names and line numbers, but I don't think most
people did...not from the magazines I was reading.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
With a mighty <················@netcom.com>,
······@netcom.com uttered these wise words...
> Wow! What a concept. I lived in a world that was structured a bit
> differently. Our towers were of a different color.
Hehehe.
> True, technically micros weren't the only computes available. But,
> realistically, it is a whole different story.
A friend of mine got to play on Prime machines, thanks to his dad, but
most of us kids had to get by with micros. From your account, your
experiences were very much like ours. Small machines, lots of effort,
blood, sweat, perhaps even a few tears.
> College opened my eyes to a whole different world: APL, SNOBOL, LISP,
> Pascal, C...But that's what college was for. That's why they're here.
> High Schools get whatever they can get their hands on. This is 1997,
> and STILL we here the cry "We need computers in the schools" (though
> more for elementary nowadays).
Now my mother is using computers, and talking about CD-ROMs and
multimedia! She works in a school, BTW. How things have changed!
> The micros of old are now consider stone knives and bearskins of the
> computing world. More famous for the nostalgia of they they invite
> than anything compared to what we are running today. Heck, most of
> these old machines are now software programs running on PCs. Emulators
> that run all of that old software.
Is there a TRS-80 emulator? I wouldn't be at all suprised.
> Today, computing power no longer dictates what we develop in as
> strongly as it did. Computing power is cheap. We can sit back in our
> arm chairs and point fingers at the past; decry "They shoulda...".
Yeah. "How different things could've been, if only..." Reading UseNet,
you can find an older generation (or two), saying much the same. Try
reading comp.arch for more than a week.
> I don't thing anyone with the aptitude, who had been bitten by the bug,
> was put off of Computer Programing because of the limitations of the
> old BASICs. It was interactive, it was simple, it did the job and
> produced immediate, mostly correctable results. Much like a Painter
> giving up on watercolors and moving to oils, those old BASICs were
> enough to light the spark inside of a lot of people. The BASICs
> satisfied some, and acted as a step up to others.
Very well put. Basic is still doing this, I think. The problem may be
that altho there are more languagea available now for more machines
than ever before, marketing helps obscure this fact. Browse the
comp.lang.* hierarchy to find loads of languages that _don't_ get
massive amounts of promotion.
> So, others may have been able to pick and choose from high powered
> computng resources when I was down in the gutters, flailing away with
> 2 character variable names and line numbers, but I don't think most
> people did...not from the magazines I was reading.
I don't remember ever being limited to 2 character variable names, but
I certainly suffered with line numbers, even if I didn't appreciate
that it was a problem. As you said, we weren't alone. Micros dominated
the scene that _we_ were a part of, and that was generally what the
magazines wrote about. They'd sometimes mention Unix in vague terms,
making it sound like some mystical haven for "grown up" computing, but
that may have turned some of us off. After all, how could we ever
imagine using such machines, or such software on _micros_?
Eventually we saw micros running Unix, but they were way too expensive
for most of us. And then the really cheap micros began to appear, at a
fraction of the cost of a Unix-based micros. It's easy to forget this
in the era of Linux. Some of us got to play with Xenix on 286 machines
(but not me, I hasten to add). A few remember the scars.
The rest is history.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
With a mighty <····················@connectnet1.connectnet.com>,
·····@usa.net.delete_me uttered these wise words...
> Actually, it's very easy to avoid them; just avoid micros! There's
> this implication that micros were the only computers. Lisp didn't
> even run on Micros until really late in the game (ie, post-ibm-pc is
> late in the game).
Avoid micros? Hmm. ;)
I remember reading about a Lisp that ran in 16K, on the TRS-80. I may
still have a review of mu-lisp, for CP/M - from 1979, I believe. As
you go back further in time, you'll find increasingly smaller numbers
of people using micros. (That's obvious.) You were pretty unusual if
you had a micro in the 70s, at least in the UK. Yep, that mu-lisp
review was published in a UK magazine!
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
[Note: newsgroups trimmed to the one I read...]
Darin Johnson wrote:
>Actually, it's very easy to avoid them; just avoid micros! There's
>this implication that micros were the only computers. Lisp didn't
>even run on Micros until really late in the game (ie, post-ibm-pc is
>late in the game).
I don't know if it's fair to bring this up, but there WAS a lisp put
out by Software Toolworks that I ran on my H8 computer. The H8 was
8080-based (though mine had been upgraded to a Z80). I remember that
I invoked this lisp program several times. :-)
At the time lisp was a complete mystery to me and I didn't get very
far with it, so I can't say how far one could have gotten with it, but
they did call it lisp, and it did use parentheses and car and cdr, and
I'm pretty sure it garbage collected---though never having used a
memory allocator in my life at the time I didn't even know what a
garbage collector was.
I DID get much further with Xlisp on the amiga, and that is post-IBM-PC.
There was also Logo, which ran on many 8-bit micros.
--
-Fred Gilham ······@csl.sri.com
``The road to tyranny is paved with human rights....Once the state
sets out to guarantee a right, it will destroy every obstacle that
stands in the way of liberating the oppressed.'' --Thomas Fleming
Fred Gilham <······@japonica.csl.sri.com> writes:
>[Note: newsgroups trimmed to the one I read...]
>Darin Johnson wrote:
>>Actually, it's very easy to avoid them; just avoid micros! There's
>>this implication that micros were the only computers. Lisp didn't
>>even run on Micros until really late in the game (ie, post-ibm-pc is
>>late in the game).
>I don't know if it's fair to bring this up, but there WAS a lisp put
>out by Software Toolworks that I ran on my H8 computer. ...
> ... but
>they did call it lisp, and it did use parentheses and car and cdr, and
>I'm pretty sure it garbage collected..
And there were certainly also non-commercial Lisps. The first "big"
program I wrote on my TRS80 was a Lisp interpreter (not for
distribution, just for me to learn Lisp). It only had fixnums,
symbols, and conses (no bignums, floats, or strings). No closures,
and all symbols were global. No macros. No separate function and
value cells. The Z80 version had a GC that (mostly) worked, but the
Basic version did not (I had separate heaps for symbols, ints, and
conses with hard limits). It had no pretty-printer. In most cases,
stack-overflow killed the lisp (I think I only checked during function
invocation, otherwise I happily trashed memory).
The only input-editing I had was delete and super-paren (i.e. add
enough close-parens to match all open-parens in the input.)
Out of curiosity, I wish I had listings (I doubt the cassette tape
would do me any good!) -- I never did, because I didn't own a
printer. I can't even remember how big the code was.
I was a pretty inexperienced programmer; I'm sure other people did
better jobs. I certainly didn't understand Lisp when I wrote mine!
(unfortunately I can't remember, but I know I had some "non-standard"
(and decidedly bogus) evaluation rules).
Sigh. Enough nostalgia. I think the point was that there were
Basic's on mainframes, and Lisp was accessible on micros (in most
cases it did *not* mean writing your own.)
Hrvoje Niksic <·······@srce.hr> writes:
> You were talking about a whole generation "happy" about the most basic
> limitations (pun not intended) one can name.
Well, as a member of this generation "Micro-Computer BASIC", I can
assure you, that most of the people using home/micro computers in the
late 70s to early 80s were perfectly happy with the two "languages"
they usually got, i.e. Assembler and a crippled ROM-based BASIC
interpreter.
The reasons are quite simple: Most of these enthusiast started
computing with these beasts and were autodidactic, i.e. they had
usually never seen anything else, so they were not likely to miss
something (there were of course always exceptions to this rule...)
And BASIC is most certainly simpler and more powerfull than
programming a programmable calculator, or soldering together your own
ALU...
The other factor people forget when looking at the past, is how much
times have changed since then: In those (glorious?!) days of yore, a
simple, half-capable micro (e.g. an Apple II+, with 2 disk drives,
etc.) cost you around 5-6000.- DM (and that was in the days where the
DM/$ exch. rate was at around 3DM/$, and due to inflation those
6000.-DM would probably be around 8-9000 DM in todays money, i.e. that
was _a lot_ of money!!!!). Add to this that the few (semi-capable)
languages that _were_ available usually cost a neat sum of money...
(Consider what you had to spend in 1985 to get a decent Lisp system,
and you needed workstation, nowadays you get this for <1500$)
Compare this with todays prices (i.e. <2000DM for a decent computer),
with very capable OSs and most languages on the moon for free, and you
get a very different picture!
Yes, you encountered restraints in BASIC, but you worked around them,
as you can in any Touring-complete language. Those were the days of
sheer hacking fun, not of professional software development with
deadlines and multi-billion-dollar deals! In those days, most
software "producers" for micros were small start-ups (even Microsoft
;).
That there was something beyond BASIC dawned on us, when we got in
touch with better/different languages, either on the micro (consider
UCSD-Pascal, Logo, several Forth dialects, or even Modula-2), or
through contact with "real" computers at university/work...
Try to get hold of some of the earlier magazines/user group
newsletters (i.e. AUGE (Apple User Group Europe), etc.), and you will
see the "spirit" of those days. Very unprofessional, but therefore
much more exciting and fun...
BTW: That generation of BASIC users is totally different from those
that use Visual Basic nowadays.
Regs, Pierre.
PS: Some/Most of the restrictions blamed on BASIC as a whole are only
restrictions of the brain-dead minimalistic BASICs encountered on
micros or early PCs. Even in 1977 there existed Standard BASIC, which
was on the whole much more capable (i.e. sub-routines, parameter
passing, etc.), and certain dialects were even used for Real-Time
Process Control in some incarnations...
See ECMA/TC21/76/44 and ANSI X3J2/76-35...
With a mighty <··············@torus.cs.tu-berlin.de>,
····@cs.tu-berlin.de uttered these wise words...
> Well, as a member of this generation "Micro-Computer BASIC", I can
> assure you, that most of the people using home/micro computers in the
> late 70s to early 80s were perfectly happy with the two "languages"
> they usually got, i.e. Assembler and a crippled ROM-based BASIC
> interpreter.
ROM-based meant that bug fixes were a pain, if available at all. I
still recall the day I got the lowercase ROM fix. Yep, the entire
system software was in ROM, text was in two shades of green, and the
keyboard had a wonderful spungy feel to it. I used keyboards and
screens like that for most of the 80s. Perhaps you did, too.
> The reasons are quite simple: Most of these enthusiast started
> computing with these beasts and were autodidactic, i.e. they had
> usually never seen anything else, so they were not likely to miss
> something (there were of course always exceptions to this rule...)
This is the point I was trying to make, tho not as well as you've just
done. When you get a machine with a language system in ROM and a
manual that doesn't mention the possiblity of anything else, it should
be no suprise that many people using such machines don't consider
using anything else.
For months I believed that the machine directly executed my Basic
code, until one day I read about assembly language and machine code.
It wasn't long after that that I began hand assemblying code, typing
the hex codes into a program called TBUG, and eventually using POKE to
insert the code into REM statements, strings, or used parts of the
memory map. This was typical for anyone using machine code on a micro
at that time. What was far more typical was only using Basic.
> And BASIC is most certainly simpler and more powerfull than
> programming a programmable calculator, or soldering together your own
> ALU...
Oh yes. I first (and only) programmable calculater fell apart, after a
few days. Still, I had some fun with it, playing Nim. Hey, that was
before I got my first micro! That means I was using a very simple form
of machine code even before Basic. It took me years to realise and
then appreciate that point.
> The other factor people forget when looking at the past, is how much
> times have changed since then: In those (glorious?!) days of yore, a
> simple, half-capable micro (e.g. an Apple II+, with 2 disk drives,
> etc.) cost you around 5-6000.- DM (and that was in the days where the
> DM/$ exch. rate was at around 3DM/$, and due to inflation those
> 6000.-DM would probably be around 8-9000 DM in todays money, i.e. that
> was _a lot_ of money!!!!). Add to this that the few (semi-capable)
> languages that _were_ available usually cost a neat sum of money...
> (Consider what you had to spend in 1985 to get a decent Lisp system,
> and you needed workstation, nowadays you get this for <1500$)
Does anyone here remember Microsoft's first macro assembler? Leon
Heller, are you out there? I still think that program beats the heck
out MASM - not that that means much. I just loved, and still love, the
features of MACRO-80.
Of the various alternatives to Basic that I remember being available
for the TRS-80, I got the most from Forth. Perhaps today we could call
a typical Forth a reflective system. My first compiler efforts were
Forth systems. 15 years ago, I also had access to Fortran (MS) and
Pascal (p-system), but on a TRS-80 they could't compete with Forth in
terms of speed of development and runtime performance. It took a
staggering 30 seconds to go from command mode to filer mode in the p-
system, on that machine. On a Sage II, the same operation was barely
noticable - the terminal speed (9600) became the bottleneck.
> Compare this with todays prices (i.e. <2000DM for a decent computer),
> with very capable OSs and most languages on the moon for free, and you
> get a very different picture!
Yeah, I've got loads of languages on my machine that you can all get
for free, from the Internet, and there are many more that I've yet to
find the time to fetch and play with. Just browse thru the comp.lang.*
heirarchy for examples. Not many Basic implementations, but I think
I've seen at least one. And no, I'm not talking about Linux software,
this stuff that's also available for Windows and Mac machines.
Is it only the Internet that has brought about this change?
> Yes, you encountered restraints in BASIC, but you worked around them,
> as you can in any Touring-complete language. Those were the days of
> sheer hacking fun, not of professional software development with
> deadlines and multi-billion-dollar deals! In those days, most
> software "producers" for micros were small start-ups (even Microsoft
> ;).
The first micro software I used was MS Basic. People work around the
limitations of software - and hardware, too. If there's any truth to
the conspiracy theory about IBM trying to sabatage micros with loads
of kludges, I could've told them that it wouldn't work. Most micros
were already filled with kludges, and yet they still sold.
As an ex-Sage user, I can sympathise with people who've used well
designed machines who then encounter machines load with kludges.
For example, Lisp Machine users who're forced to suffer with Unix
workstations (see the prefact to the Unix haters manual). I'm not
anti-Unix, nor am I anti-Windows, but perhaps it takes a LispM user to
remind us how wonderful things _could be_.
> That there was something beyond BASIC dawned on us, when we got in
> touch with better/different languages, either on the micro (consider
> UCSD-Pascal, Logo, several Forth dialects, or even Modula-2), or
> through contact with "real" computers at university/work...
My first encounter with the WHILE control structure was using Forth,
not Basic or Pascal. I think that MS Basic for CP/M had WHILE/WEND at
that time, but this was uncommon for Basic. I could be wrong about
this, but I recall that BBC Basic had REPEAT/UNTIL but no WHILE.
There was certainly one such curiousity, even if it wasn't Basic on
the BBC micro (a machine spondered by a national TV network). You
could also get Forth and some other languages for the BBC micro,
all in 32K ROMs. That was luxury compared to the 4K, 8K, or 12K on
earlier machines.
> Try to get hold of some of the earlier magazines/user group
> newsletters (i.e. AUGE (Apple User Group Europe), etc.), and you will
> see the "spirit" of those days. Very unprofessional, but therefore
> much more exciting and fun...
ISTR one mag foolishly publishing a short Basic program I wrote,
earning me 5 pounds. I got the impression that they'd publish anything
that was sent in! My contribution was never worth 5 quid.
> BTW: That generation of BASIC users is totally different from those
> that use Visual Basic nowadays.
Most certainly. The language and the programmers have changed, even
when the names haven't.
> PS: Some/Most of the restrictions blamed on BASIC as a whole are only
> restrictions of the brain-dead minimalistic BASICs encountered on
> micros or early PCs. Even in 1977 there existed Standard BASIC, which
> was on the whole much more capable (i.e. sub-routines, parameter
> passing, etc.), and certain dialects were even used for Real-Time
> Process Control in some incarnations...
>
> See ECMA/TC21/76/44 and ANSI X3J2/76-35...
I mentioned Implementing Basics in an earlier post, and this book
really opened up my mind to what Basic could do, if only people were
prepared to think big enough. Today, we have such Basics and much
more. However, I gave up using Basic in the early 80s, after
discovering Forth, C, Lisp, and then a multitude of languages.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
Hrvoje Niksic <·······@srce.hr> wrote in article
<···············@jagor.srce.hr>...
>
> Henry wasn't talking about VB (whatever that stands for), but for
> BASIC.
>
FYI, VB stands for Visual Basic.
Bill House
--
http://www.dazsi.com
Note: my e-mail address has been altered to
confuse the enemy. The views I express are
mine alone (unless you agree with me).
With a mighty <··························@wjh_dell_133.dazsi.com>,
······@dazsi.nospam.com uttered these wise words...
> Hrvoje Niksic <·······@srce.hr> wrote in article
> <···············@jagor.srce.hr>...
> >
> > Henry wasn't talking about VB (whatever that stands for), but for
> > BASIC.
> >
>
> FYI, VB stands for Visual Basic.
Ah, yes. I made the mistake of ASSuming that everyone knew this.
Sorry. Well, I guess this supports my point about reading the VB
newsgroups for a bit. Just as I'd recommend that anyone with doubts
about the practicality of Lisp should check out comp.lang.lisp.
In other words, Know Thy Enemy. ;) Basing your attack on out of date
info is very unwise. Readers of comp.lang.lisp will have seen, or had
the opportunity to see, many C++ programmers commit that folly. Base
your attack on Lisp by refering exclusively to XLISP (or SCM, or
newLisp) and you'll soon by made to look rather silly. Pick a system
for proffesional software development (like ACL, LispWorks), get to
know it and its limitations (as you see them), and you could have a
much stronger argument.
Sometimes the facts are ugly, but they're still worth knowing.
Hrvoje Niksic has perfectly demonstrated my point about Basic and Lisp
having something in common, that they both suffer from attacks based
on ignorance. A Lisp programmer may be just as ignorant of Basic as a
Basic programmer may be ignorant of Lisp.
This is why I refered to Jonathon Swift's "egg orientation" episode,
in Gulliver's Travels. Beware of the Eggs! In other word, the limits
of your own experience and how they shape your perception of things.
It's even possible that you might not be aware of this. The only way
to know (hoho) is to investigate a subject. Explore the boundaries of
your knowledge, the places where it's weakest. Alternately, you could
do what one or two people on UseNet seem to do, and just go ahead and
blindly attack. I don't recommend that option, tho!
ISTR the late Bill Hicks saying something very similar. Of course, his
wording may have been a little stronger than mine! What the heck.
It's just a ride.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Will Hartung
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <vfr750EB5r27.E57@netcom.com>
Hrvoje Niksic <·······@srce.hr> writes:
>············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
>> > > Just like Lisp, Basic's image suffers because of poor software.
>> >
>> > I beg to disagree violently! Basic's image suffers because of brain-damaged
>> > conceptions. The original Basic was:
>> > * statement oriented
>> > * no recursion
>> > * no arguments/parameters to subroutines (info passed globally)
>> > * very short identifiers
>> > * slow as sh*t (even compared with interpreted Lisp)
>>
>> Well, I dunno about you, Henry, but I grew up in a generation that was
>> perfectly happy with most of the limitations that you've mentioned.
>Which generation is that, exactly? I've never met a person happy with
>them before.
Hmmm...I guess I'm one of those from Generation B. I basically (heh!)
cut my keyboard teeth on IMSAI-8080's, TRS-80's, Apple ]['s, PETs, and
Atari 800s. I can't recall having as exciting of a time as during the
Early Days (you can't go back).
Whatever complaints one may have about the built-in basics, they had
the most enormous advantage of all: Availability!
Frankly, I really didn't know better. I had access to assembly
language (usually hand assembling the code), but no real access to the
machine architecture beyond the most simple. AL was extermely hard to
use over BASIC, and for most of the stuff I was playing with, it
wasn't worth the effort.
I can't even count the thousands of hours I spent in front of one of
these micros pounding out BASIC. It was there, it was easy to use, and
it enabled my imagination do all sorts of things. Of course there were
limitations, but I typically bounced off of those and routed around
them, there was so much to learn and explore, I didn't really care
about each nit I ran into.
I ended up buying other languages for my Atari: Forth, Action!, Basic
XL, assemblers...Basic XL was an accelerated Atari Basic. It was
quite fast. The only language I've ever seen with a "Fast" command.
Atari Basic (and perhaps others) has the problem that when you did any
kind of GOTO (GOSUB, NEXT, etc), it would scan for the proper line
number from the top of the program...every time. People started to put
popular utility routine at the top of the code to speed it up. Basic
XLs FAST command ran through the code and cached all of those scans.
Action! was an evil little C-esque high-level assembly language...but
it was VERY fast. A friend actually turned in a CS assignment written
in it -- quite a coup considering it was supposed to be done on the
schools Cyber 730 :-).
So, yup! BASIC is horrible. Evil. Terrible. But the built-ins of the
late 70's-early 80's gave an open door to a whole bunch of explorers
who otherwise may have been cut off at the beginning.
Frankly, I can't say where I'd be today without having exposure to those
horrible wonders in high school. Most of the bad BASIC habits are way
buried, but that "damn the side effects - full globals away"
philosophy still comes in handy when a REAL quick script/program is
needed.
I thought that QBASIC that used to come with MS-DOS was nice, for the
price.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
From: David Thornley
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <5n43uv$ndt$1@darla.visi.com>
In article <················@netcom.com>,
Will Hartung <······@netcom.com> wrote:
>Hrvoje Niksic <·······@srce.hr> writes:
>
>>············@gubbish.wildcard.demon.co.uk (Cyber Surfer) writes:
>
>>> > > Just like Lisp, Basic's image suffers because of poor software.
>>> >
>>> > I beg to disagree violently! Basic's image suffers because of brain-damaged
>>> > conceptions. The original Basic was:
>>> > * statement oriented
>>> > * no recursion
>>> > * no arguments/parameters to subroutines (info passed globally)
>>> > * very short identifiers
>>> > * slow as sh*t (even compared with interpreted Lisp)
>>>
>>> Well, I dunno about you, Henry, but I grew up in a generation that was
>>> perfectly happy with most of the limitations that you've mentioned.
>
People who didn't know better? When I first programmed in BASIC, I
didn't understand that those were limitations. I suspect that a
typical computer nerd development path was (a) learn BASIC, (b)
learn something better, (c) abandon BASIC, (d) never touch it again,
and therefore never learn of possible improvements.
>>Which generation is that, exactly? I've never met a person happy with
>>them before.
>
>Hmmm...I guess I'm one of those from Generation B. I basically (heh!)
>cut my keyboard teeth on IMSAI-8080's, TRS-80's, Apple ]['s, PETs, and
>Atari 800s. I can't recall having as exciting of a time as during the
>Early Days (you can't go back).
>
I'd been programming, off and on, for fifteen years or so when I got
my first TRS-80, Even so, it was exciting.
>Whatever complaints one may have about the built-in basics, they had
>the most enormous advantage of all: Availability!
>
I'm going to disagree about the "most enormous advantage". I think
it was the lack of a compiler. If you wrote an application in BASIC,
you shipped source code. You had to; there was no compiled form.
Presumably you could ship with shrouded source, but as a matter of
practice almost nobody did.
The result was that you could read the source to see how people did
things. You could tweak the code. It was a lot of fun, and in fact
how my wife learned to program. (She's gone on to much better things.)
Nowadays, most microcomputer stuff is written in C or Pascal or some
other high-level language, and source code is not provided, or even
available. A commercial program does what it is intended to, and
you can't change it or learn from it.
(Parenthetically, that's one of the things I like about the Gnu
General Public License. The source of copylefted code *has* to be
available.)
I'm in a similar situation now, as I don't have a redistribution
license for the lisp (Macintosh Common Lisp) I'm using, so I'd have
to distribute in source code. Of course, the distributee had better
have MCL on his or her machine. This is actually feasible if the
whole program will run in under fifteen minutes, as then they can use
the MCL demo. Hmmmm, this has possibilities.... This is the
"availability" deal mentioned earlier; all TRS-80 Model 1s came
with BASIC in ROM.
>
>Frankly, I can't say where I'd be today without having exposure to those
>horrible wonders in high school. Most of the bad BASIC habits are way
>buried, but that "damn the side effects - full globals away"
>philosophy still comes in handy when a REAL quick script/program is
>needed.
>
For a long time, I thought BASIC was the best thing around for a
program of ten lines or less. Since then, I've changed my mind,
but it's still pretty good for short quick-and-dirties.
David Thornley
From: Bruce Tobin
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <339DE1F8.54E2@infinet.com>
Henry Baker wrote:
> 'Visual' Basic isn't 'Basic' at all, it is an interpreted form of
> Ada/Modula/Eiffel. It is still slow as sh*t.
Actually the latest version of VB is (partially-- code in a form is
still interpreted) compiled. On the simple integer benchmarks I run to
test different C/S tools, VB5 is faster than any of the Lisps I've
tested (Allegro/Win, Allegro/Linux, CMUCL/Solaris).
From: Bernhard Pfahringer
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <5nkpeq$5kr@borg.cs.waikato.ac.nz>
In article <·············@infinet.com>,
Bruce Tobin <······@infinet.com> wrote:
>still interpreted) compiled. On the simple integer benchmarks I run to
>test different C/S tools, VB5 is faster than any of the Lisps I've
>tested (Allegro/Win, Allegro/Linux, CMUCL/Solaris).
Mind to share these benchmarks?
Bernhard
--
Bernhard Pfahringer
···············@cs.waikato.ac.nz http://www.ai.univie.ac.at/~bernhard
From: Bruce Tobin
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <33A07864.61A0@infinet.com>
Well, the only version I still have is the ACL/Win version. As I
mentioned, it's a very simple benchmark:
(defun is-prime (num)
(let ((i 2))
(until (or (i= (imod num i) 0) (i> (i* i i) num) )
(iincf i))
(i> (i* i i) num)))
(defun primes ()
(let ((k 0)
(j 1))
(until (i> j 30000)
(if (is-prime j)
(iincf k))
(iincf j))
k))
Yes, I tried a tail-recursive version; this is faster. The VB 5 version
of this code ran about 50% faster than ACL/Win. The ACL/Linux version,
which looked rather different (used real declares instead of those
i-functions), ran about the same. The CMUCL version ran much more
slowly, enough so that I suspect some kind of configuration problem.
I don't get access to that machine much, so I can't say for sure.
With a mighty <·············@infinet.com>,
······@infinet.com uttered these wise words...
> Actually the latest version of VB is (partially-- code in a form is
> still interpreted) compiled. On the simple integer benchmarks I run to
> test different C/S tools, VB5 is faster than any of the Lisps I've
> tested (Allegro/Win, Allegro/Linux, CMUCL/Solaris).
How does the VB 5.0 I/O performance compare with ACL & CMUCL? I've not
yet been able to test this. I currently compare I/O performance with
code compiled by VC++ 4.0 (it could be a long time before I get 5.0),
using a simple line count (similar to wc) run on a 24 MB archive for
comp.infosystems.www.announce.
GNU C and O'caml give performances with barely measurable differences.
ACL/PC, LWW, and Gambit C all appear to crawl, by comparison.
Yes, you've guessed it. I'd like to write a program to feed megabytes
of UseNet announcememnts into a database. I could do it in Lisp and
say, "to hell with speed", but this is hardly an argument for using
Lisp instead of C. I know Lisp has many other advantages, but when
you're trying to convince people with a massive interest in databases,
text processing, and not much else...
The obvious answer is: write a compiler that takes a spec for a
database app, using sexprs, and turns it into C source code, then
compile that to native code. However, this is effectively what _VB_
does, but without the need for a C compiler. It also takes no time to
write, and has the advantage of being usable by VB programmers.
On the positive side, for purely database apps most of the work could
be done by ODBC, making the language irrelevant to the performance
issue. So, the choice of language might be determined solely by the
availability of programmers and their (existing) skills. Hence the
succeess of VB? Hmm.
Here's the Scheme code I used:
(define (count n)
(let ((c (read-char)))
(cond
((eof-object? c) n)
((char=? c #\newline)
(count (+ n 1)))
(else
(count n)))))
(display (count 0))
(newline)
Here's the C code:
void main(int argc, char *argv[])
{
int c, nl = 0;
while ((c = getc(stdin)) != EOF)
if (c == '\n')
nl++;
printf("%d\n", nl);
}
With the above code, VC++ was 40 times faster than Gambit C. Perhaps
the problem here is that Gambit C compiles to C, giving a C compiler
an advantage? LispWorks for Windows does better, being only 11 times
slower than the C version:
(defun lc (&optional (filename *filename2*))
(let ((line-no 0))
(with-open-file (f filename :direction :input)
(loop
(let ((line (read-line f nil :eof)))
(if (eq line :eof)
(return line-no))
(incf line-no))))))
BTW, I remembered to compile the above function before timing it.
Profiling it determined where the bottleneck was: read-char. Using
read-char instead of read-line confirmed this, as it made no real
difference to the performance:
(defun lc2 (&optional (filename *filename2*))
(let ((line-no 0)
(char-no 0))
(with-open-file (f filename :direction :input)
(loop
(let ((c (read-char f nil :eof)))
(if (eq c :eof)
(return (values char-no line-no)))
(incf char-no)
(if (eql c #\newline)
(incf line-no)))))))
Do these Lisps not use I/O buffering, I wonder? That could explain the
poor I/O performance. I certainly can't believe that it can be a Lisp
problem, so it must be the implementations. Alas.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Mukesh Prasad
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <339E9E43.4B0F@polaroid.com>
Cyber Surfer wrote:
[snip]
> Do these Lisps not use I/O buffering, I wonder? That could explain the
> poor I/O performance. I certainly can't believe that it can be a Lisp
> problem, so it must be the implementations. Alas.
Most probably marketing's or users' fault.
If all else fails, turns out you can also blame Fortran.
If you don't believe me, take a look at:
http://cbl.leeds.ac.uk/nikos/tex2html/examples/good-bad-win/node13.html
where Fortran is successfully blamed by accusing it of an idiom
it does not have. (Actually, the one thing Fortran does do well,
is to make it easy to transcribe mathematical/algebraic expressions.)
For more inspiring techniques, visit
http://cbl.leeds.ac.uk/nikos/tex2html/examples/good-bad-win/node12.html
and
http://cbl.leeds.ac.uk/nikos/tex2html/examples/good-bad-win/node11.html
for excellent examples of how to suggest the programmer
is at fault for not being on totally intimate terms with the
particular Lisp implementation, or for trying to make use of
convenient language features which are not efficient. (Actually
at node 12, the programmer's manager gets successfully blamed, since
a good case for the programmer's fault is not too tenable, and
perhaps may even be counter-productive.)
When working from these inspirational models,
remember to make a case that all your arguments
are examples of "The Right Thing". This last
part is very important since it differentiates
you from the marketing people.
Cyber Surfer wrote:
> Here's the Scheme code I used:
>
> (define (count n)
> (let ((c (read-char)))
> (cond
> ((eof-object? c) n)
> ((char=? c #\newline)
> (count (+ n 1)))
> (else
> (count n)))))
>
> (display (count 0))
> (newline)
Gambit-C's I/O routines are rather slow when the port is not specified,
as is the case in your Scheme code. It's mainly because they must fetch
the current I/O port from the dynamic environment, which is implemented
as an alist. Try the following:
(declare
(standard-bindings) ; enable inlining of primitives
(block) ; non-mutated functions can be inlined
(fixnum) ; fixnum arithmetic
(inlining-limit 500))
(define (count n port)
(let ((c (read-char port)))
(cond
((eof-object? c) n)
((char=? c #\newline) (count (+ n 1) port))
(else (count n port)))))
(display (count 0 (current-input-port)))
(newline)
This code will still be slower than its C/C++ equivalent since I/O
operations are not especially fast in Gambit-C, but it should be much
faster than the code you wrote.
I think the main difficulty of writing efficient programs in Scheme/Lisp
(and to some extent C++) comes from the fact that the programmer must
have a pretty good understanding of the runtime system and the
compilation strategies implemented by the compiler (which are often
quite different for each such system). Since C is much closer to
assembly language than Scheme/Lisp, the code generated is (almost)
always much more predictable.
--Dominique
+------------------------------------------+-------------------+
| Dominique Boucher, M.Sc. | //\\ |
+------------------------------------------+ \\ |
| L a m b d a S o f t | /\\ |
| Software Consultant | S/O F\T |
| Functional Programming Systems and Tools | // \\// |
+------------------------------------------+-------------------+
With a mighty <·················@iro.umontreal.ca>,
········@iro.umontreal.ca uttered these wise words...
> This code will still be slower than its C/C++ equivalent since I/O
> operations are not especially fast in Gambit-C, but it should be much
> faster than the code you wrote.
Yep, it's now only 24 times slower, instead of 40.
> I think the main difficulty of writing efficient programs in Scheme/Lisp
> (and to some extent C++) comes from the fact that the programmer must
> have a pretty good understanding of the runtime system and the
> compilation strategies implemented by the compiler (which are often
> quite different for each such system). Since C is much closer to
> assembly language than Scheme/Lisp, the code generated is (almost)
> always much more predictable.
I don't see how this can be. Perhaps Lisp I/O systems are much more
complicated than the C I/O system, but it doesn't look like it to me.
Instead, it looks like they're not using buffered I/O, as this would
be more than enough to explain the poor performance.
Here's the C code to test unbuffered performance, for Win32:
LONG crapio(LPSTR szFileName)
{
HANDLE hFile;
BOOL bResult;
char c;
DWORD nBytesToRead = 1, nBytesRead;
LONG i = 0;
if ((hFile = CreateFile(szFileName,
GENERIC_READ,
0, NULL,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
NULL)) == INVALID_HANDLE_VALUE) {
error("can't open file: [%s]\n", szFileName);
}
do {
bResult = ReadFile(hFile,
&c,
nBytesToRead,
&nBytesRead, NULL);
if (c == '\n')
i++;
} while (bResult && nBytesRead > 0);
CloseHandle(hFile);
return i;
}
The above code, using the same test data, is 25 times slower than the
C code using buffered I/O. I could've used the standard C library I/O
functions, but I feel this code makes the point rather well. It's not
the language that's the issue, but how the I/O code is written. When
you use the library I/O functions, instead of calling the OS directly,
you rely the buffer size for the performance.
This code is easily out-performed by the version using buffered I/O,
even tho that version may well use more function calls per character.
Unless the Lisp function call overhead is outrageously hideous in
LispWorks and Gambit C, how can we account for the poor performance?
The unbuffered I/O explanation fits the bill nicely. Can anyone
convince me that this is not the case? Is there a flaw in my code that
conceals the truth? I'm not interested in slagging off otherwise fine
development software, so if there's a way of making the I/O functions
provided as standard perform as well - or just closer - to C, please
let me know. I'd very much appreciate it.
Alternately, you could just dismiss me as an I/O speed freak. ;) If I
were the only person doing I/O on multi-megabyte files, that would be
easy and no problem to anyone. Alas, I fear this is not the case, and
that many people consider this issue to be of great significant. If
this is so, then it _may_ help explain some of the success of C/C++.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
I was recently telling someone that stdio is much faster, due to buffering,
than direct calls to ReadFile and WriteFile (those calls buffer too, but
there must be more overhead in the calls and/or they only buffer a block at
a time or something.), but I realized afterward that a memory mapped file
would beat both. Is there much portability to memory mapped files and/or do
many/any Lisps/Schemes give access to memory mapped files on Win32?
- Jay
Cyber Surfer <············@gubbishwildcard.demon.co.uk> wrote in article
<·························@news.demon.co.uk>...
> With a mighty <·················@iro.umontreal.ca>,
> ········@iro.umontreal.ca uttered these wise words...
>
> > This code will still be slower than its C/C++ equivalent since I/O
> > operations are not especially fast in Gambit-C, but it should be much
> > faster than the code you wrote.
>
> Yep, it's now only 24 times slower, instead of 40.
>
> > I think the main difficulty of writing efficient programs in
Scheme/Lisp
> > (and to some extent C++) comes from the fact that the programmer must
> > have a pretty good understanding of the runtime system and the
> > compilation strategies implemented by the compiler (which are often
> > quite different for each such system). Since C is much closer to
> > assembly language than Scheme/Lisp, the code generated is (almost)
> > always much more predictable.
>
> I don't see how this can be. Perhaps Lisp I/O systems are much more
> complicated than the C I/O system, but it doesn't look like it to me.
> Instead, it looks like they're not using buffered I/O, as this would
> be more than enough to explain the poor performance.
>
> Here's the C code to test unbuffered performance, for Win32:
>
> LONG crapio(LPSTR szFileName)
> {
> HANDLE hFile;
> BOOL bResult;
> char c;
> DWORD nBytesToRead = 1, nBytesRead;
> LONG i = 0;
>
> if ((hFile = CreateFile(szFileName,
> GENERIC_READ,
> 0, NULL,
> OPEN_EXISTING,
> FILE_ATTRIBUTE_NORMAL,
> NULL)) == INVALID_HANDLE_VALUE) {
> error("can't open file: [%s]\n", szFileName);
> }
>
> do {
> bResult = ReadFile(hFile,
> &c,
> nBytesToRead,
> &nBytesRead, NULL);
> if (c == '\n')
> i++;
> } while (bResult && nBytesRead > 0);
>
> CloseHandle(hFile);
>
> return i;
> }
>
> The above code, using the same test data, is 25 times slower than the
> C code using buffered I/O. I could've used the standard C library I/O
> functions, but I feel this code makes the point rather well. It's not
> the language that's the issue, but how the I/O code is written. When
> you use the library I/O functions, instead of calling the OS directly,
> you rely the buffer size for the performance.
>
> This code is easily out-performed by the version using buffered I/O,
> even tho that version may well use more function calls per character.
> Unless the Lisp function call overhead is outrageously hideous in
> LispWorks and Gambit C, how can we account for the poor performance?
>
> The unbuffered I/O explanation fits the bill nicely. Can anyone
> convince me that this is not the case? Is there a flaw in my code that
> conceals the truth? I'm not interested in slagging off otherwise fine
> development software, so if there's a way of making the I/O functions
> provided as standard perform as well - or just closer - to C, please
> let me know. I'd very much appreciate it.
>
> Alternately, you could just dismiss me as an I/O speed freak. ;) If I
> were the only person doing I/O on multi-megabyte files, that would be
> easy and no problem to anyone. Alas, I fear this is not the case, and
> that many people consider this issue to be of great significant. If
> this is so, then it _may_ help explain some of the success of C/C++.
>
> Thanks.
> --
> <URL:http://www.wildcard.demon.co.uk/> You can never browse enough
> Martin Rodgers | Programmer and Information Broker | London, UK
> Please note: my email address is gubbish.
>
With a mighty <··························@drugs>,
·········@cornell.edu.nospam uttered these wise words...
> I was recently telling someone that stdio is much faster, due to buffering,
> than direct calls to ReadFile and WriteFile (those calls buffer too, but
> there must be more overhead in the calls and/or they only buffer a block at
> a time or something.), but I realized afterward that a memory mapped file
> would beat both. Is there much portability to memory mapped files and/or do
> many/any Lisps/Schemes give access to memory mapped files on Win32?
As far as I know, this is beyond the scope of the language. You'd need
either support in the implementation, or add that support yourself, by
writing some functions that use the file mapping API. I don't know
about other platforms, but that's how Lisp on Win32 looks to me.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
Cyber Surfer wrote:
> > This code will still be slower than its C/C++ equivalent since I/O
> > operations are not especially fast in Gambit-C, but it should be
> > much faster than the code you wrote.
>
> Yep, it's now only 24 times slower, instead of 40.
Try again using these declarations. I think the slowdown should be
close to 9 now.
(declare
(standard-bindings)
(block)
(fixnum)
(not safe) ;; <- add this
(inlining-limit 300))
> > I think the main difficulty of writing efficient programs in
> > Scheme/Lisp (and to some extent C++) comes from the fact that the
> > programmer must
> > have a pretty good understanding of the runtime system and the
> > compilation strategies implemented by the compiler (which are often
> > quite different for each such system). Since C is much closer to
> > assembly language than Scheme/Lisp, the code generated is (almost)
> > always much more predictable.
>
> I don't see how this can be. Perhaps Lisp I/O systems are much more
> complicated than the C I/O system, but it doesn't look like it to me.
> Instead, it looks like they're not using buffered I/O, as this would
> be more than enough to explain the poor performance.
Gambit-C uses buffered I/O (almost straight calls to the standard
library functions). But see below.
> Here's the C code to test unbuffered performance, for Win32:
> [C code elided]
>
> This code is easily out-performed by the version using buffered I/O,
> even tho that version may well use more function calls per character.
> Unless the Lisp function call overhead is outrageously hideous in
> LispWorks and Gambit C, how can we account for the poor performance?
I don't know of LispWorks, but I know that cross-module calls in
Gambit-C are very expensive since Gambit-C is properly tail-recursive.
[This cost would be greatly reduced if machine code was to be generated
instead of C code.] Also, the Scheme<->C interface is costly.
Here are the steps involved in a call like (read-char port) in module
foo.scm:
1. jump (C goto) to the dispatcher (trampoline) of module foo.scm;
2. module foo.scm is exited (a C return);
3. the global dispatcher calls module library;
4. the dispatcher of module library switches to the body of read-char;
5. The arguments to read-char are converted from Scheme values to C
values;
6. The C function fgetc is called;
7. The result value is converted to a Scheme value;
8. jump to the dispatcher of module library;
9. module library is exited;
10. the global dispatcher calls module foo.scm
11. the dispatcher of module foo.scm switches to the continuation of
(read-char port).
So in order to get better perfomances, try avoiding the cross-module
calls:
(declare
(standard-bindings)
(block)
(fixnum)
(not safe)
(inlining-limit 300))
(c-declare "#include <stdio.h>")
(c-define-type FILE* (pointer "FILE"))
(define fopen
(c-lambda (char-string) FILE* "___result = fopen(___arg1, \"r\");"))
(define fclose (c-lambda (FILE*) int "fclose"))
(define (fgetc f)
(let* ((get (c-lambda (FILE*) int "___result = getc(___arg1);"))
; since getc is often a macro
(c (get f)))
(if (< c 0)
#!eof
(integer->char c))))
(define (count3 n f)
(let ((c (fgetc f)))
(cond
((eof-object? c) n)
((char=? c #\newline) (count3 (+ n 1) f))
(else (count3 n f)))))
(define (test file)
(let* ((f (fopen file))
(r (count3 0 f)))
(fclose f)
r))
On my Linux box (a 133Mhz Pentium w/ 64M of RAM), this code runs only
about 4 times slower than the equivalent C code, and its mainly due to
the type conversions between C and Scheme (even C pointers are boxed in
Scheme). So I DO think that a good understanding of the Scheme/Lisp
system you use can be valuable when it comes to writing efficient code.
But I agree that these things are not really well documented.
> The unbuffered I/O explanation fits the bill nicely. Can anyone
> convince me that this is not the case? Is there a flaw in my code that
> conceals the truth? I'm not interested in slagging off otherwise fine
> development software, so if there's a way of making the I/O functions
> provided as standard perform as well - or just closer - to C, please
> let me know. I'd very much appreciate it.
So you'll never get I/O performances close to C with Gambit-C.
> Alternately, you could just dismiss me as an I/O speed freak. ;) If I
> were the only person doing I/O on multi-megabyte files, that would be
> easy and no problem to anyone. Alas, I fear this is not the case, and
> that many people consider this issue to be of great significant. If
> this is so, then it _may_ help explain some of the success of C/C++.
Maybe a factor 4 or 5 is prohibitive for your own needs, I don't know.
If I/O speed is the bottleneck of your application, use C or C++.
--Dominique
+------------------------------------------+-------------------+
| Dominique Boucher, M.Sc. | //\\ |
+------------------------------------------+ \\ |
| L a m b d a S o f t | /\\ |
| Software Consultant | S/O F\T |
| Functional Programming Systems and Tools | // \\// |
+------------------------------------------+-------------------+
I wrote:
> On my Linux box (a 133Mhz Pentium w/ 64M of RAM), this code runs only
> about 4 times slower than the equivalent C code, and its mainly due to
> the type conversions between C and Scheme (even C pointers are boxed in
> Scheme). So I DO think that a good understanding of the Scheme/Lisp
> system you use can be valuable when it comes to writing efficient code.
> But I agree that these things are not really well documented.
Oups! It's not true that the code I gave is only 4 times slower than the
equivalent C code. I extrapolated those numbers from Cyber Surfer's
numbers.
It is in fact 11 times slower (using Gambit-C 2.6, the latest release)
and the unannotated/unoptimized Scheme version is ... 116 times slower!
A speedup of 10 is nice, but the program is still very slow compared to
C.
I took a look at the C code generated by Gambit-C and it seems that
setjmp is called before each call to a C function. I think it's because
Gambit-C is now reentrant [i.e. Scheme can call C, which in turn can
call Scheme, and so on].
Cheers,
--Dominique
+------------------------------------------+-------------------+
| Dominique Boucher, M.Sc. | //\\ |
+------------------------------------------+ \\ |
| L a m b d a S o f t | /\\ |
| Software Consultant | S/O F\T |
| Functional Programming Systems and Tools | // \\// |
+------------------------------------------+-------------------+
With a mighty <·················@iro.umontreal.ca>,
········@iro.umontreal.ca uttered these wise words...
> I took a look at the C code generated by Gambit-C and it seems that
> setjmp is called before each call to a C function. I think it's because
> Gambit-C is now reentrant [i.e. Scheme can call C, which in turn can
> call Scheme, and so on].
As I suspected. This a feature that's needed when using callback
functions, as Windows does.
Am I right in thinking that this wouldn't be a problem if Scheme
didn't use continuations? Perhaps if Gambit C had a no-continuations
option, performance could improve? I'll suggest this to Mark Freeley.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
Cyber Surfer wrote:
> As I suspected. This a feature that's needed when using callback
> functions, as Windows does.
Exactly.
> Am I right in thinking that this wouldn't be a problem if Scheme
> didn't use continuations? Perhaps if Gambit C had a no-continuations
> option, performance could improve? I'll suggest this to Mark Freeley.
It would improve, but not that much. As I stated in a previous message,
the main cost comes from the trampoline technique used to implement
proper tail-recursion and from the interface to C.
--Dominique
+------------------------------------------+-------------------+
| Dominique Boucher, M.Sc. | //\\ |
+------------------------------------------+ \\ |
| L a m b d a S o f t | /\\ |
| Software Consultant | S/O F\T |
| Functional Programming Systems and Tools | // \\// |
+------------------------------------------+-------------------+
From: Fergus Henderson
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <5o7iv2$1ls@mulga.cs.mu.OZ.AU>
Dominique Boucher <········@iro.umontreal.ca> writes:
>Cyber Surfer wrote:
>> Am I right in thinking that this wouldn't be a problem if Scheme
>> didn't use continuations? Perhaps if Gambit C had a no-continuations
>> option, performance could improve? I'll suggest this to Mark Freeley.
>
>It would improve, but not that much. As I stated in a previous message,
>the main cost comes from the trampoline technique used to implement
>proper tail-recursion and from the interface to C.
FWIW, Mercury compiles to GNU C, has what Scheme/Lisp people would call
proper tail-recursion, and its C interface is fully reentrant.
With the Mercury implementation, the cost of calling C functions
is very small -- there is no need to call setjmp(), for example.
setjmp() is called only when calling Mercury from C, which tends to be
a lot rarer.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
With a mighty <·················@iro.umontreal.ca>,
········@iro.umontreal.ca uttered these wise words...
> Try again using these declarations. I think the slowdown should be
> close to 9 now.
I get 13, but I can reduce that to 12 by enabling optimisation for
speed in VC++.
> (declare
> (standard-bindings)
> (block)
> (fixnum)
> (not safe) ;; <- add this
> (inlining-limit 300))
Note that my C code didn't require _any_ optimisations. (I find this
12 to 1 performance ratio puzzling.) The C compiler I used didn't need
any optimisations.
That's an important part of the point I'm making. C has always had an
advantage in this respect. It "optimises" the code before you even
write it, but at a cost. It makes the code harder to write.
> Gambit-C uses buffered I/O (almost straight calls to the standard
> library functions). But see below.
This is even more puzzling!
> I don't know of LispWorks, but I know that cross-module calls in
> Gambit-C are very expensive since Gambit-C is properly tail-recursive.
> [This cost would be greatly reduced if machine code was to be generated
> instead of C code.] Also, the Scheme<->C interface is costly.
This is why I have reservations about continuations. I like speed more
than like the freedoms that continuations provide.
> So in order to get better perfomances, try avoiding the cross-module
> calls:
Hmm. This could be called cheating - bypassing the Scheme I/O
functions by calling the C I/O functions directly. Still, this is a
trick used by some C programmers, calling the _OS_ directly. Perhaps
this is a fair way to do it, and in Gambit C, it's still as portable
as C.
> On my Linux box (a 133Mhz Pentium w/ 64M of RAM), this code runs only
> about 4 times slower than the equivalent C code, and its mainly due to
> the type conversions between C and Scheme (even C pointers are boxed in
> Scheme). So I DO think that a good understanding of the Scheme/Lisp
> system you use can be valuable when it comes to writing efficient code.
It certainly can be. I just regret how "messy" it is, and that the
performance is still several times slower than just using C. On the
other hand, this ia a very simple example. A more realistic example
might perform even better.
> But I agree that these things are not really well documented.
That's a big part of the problem. See below.
> So you'll never get I/O performances close to C with Gambit-C.
Assuming that Gambit C used unbuffered I/O. But is it? I'm not yet
familiar enough with the internals to know. Nor can I (yet) fairly
judge the behaviour - and costs - of the code produced by Gambit C.
This is another part of the problem. Should detailed knowledge of the
internals of the compiler be necessary before we can write efficient
code with it? I deliberately avoided calling the C functions directly,
as I thought I was using _Scheme_, not C.
> Maybe a factor 4 or 5 is prohibitive for your own needs, I don't know.
> If I/O speed is the bottleneck of your application, use C or C++.
That's my fear. ;-) I prefer Scheme! As I said above, more complex
code should depend less heavily on I/O than this example.
Anyway, thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
Cyber Surfer wrote:
> Note that my C code didn't require _any_ optimisations. (I find this
> 12 to 1 performance ratio puzzling.) The C compiler I used didn't need
> any optimisations.
That's true, but C does not automatically insert array bound checks,
runtime type checks, heap/stack overflow checks, etc.
> That's an important part of the point I'm making. C has always had an
> advantage in this respect. It "optimises" the code before you even
> write it, but at a cost. It makes the code harder to write.
True again, but you cannot tell the C compiler to insert array bound
checks when you want to debug your code. You have to instrument the code
yourself.
> > I don't know of LispWorks, but I know that cross-module calls in
> > Gambit-C are very expensive since Gambit-C is properly tail-recursive.
> > [This cost would be greatly reduced if machine code was to be generated
> > instead of C code.] Also, the Scheme<->C interface is costly.
>
> This is why I have reservations about continuations. I like speed more
> than like the freedoms that continuations provide.
This has nothing to do with continuations. For example, Bigloo, Manuel
Serrano's nice Scheme -> C compiler, does not fully support proper
tail-recursion. Each Scheme function is translated into an equivalent C
function. But it also supports first-class continuations (call/cc is
provided as a library function).
> Hmm. This could be called cheating - bypassing the Scheme I/O
> functions by calling the C I/O functions directly. Still, this is a
> trick used by some C programmers, calling the _OS_ directly. Perhaps
> this is a fair way to do it, and in Gambit C, it's still as portable
> as C.
I agree.
> Assuming that Gambit C used unbuffered I/O. But is it? I'm not yet
> familiar enough with the internals to know. Nor can I (yet) fairly
> judge the behaviour - and costs - of the code produced by Gambit C.
Gambit-C uses buffered I/O. The I/O code resides in lib/os.c (of the
Gambit-C distribution).
> This is another part of the problem. Should detailed knowledge of the
> internals of the compiler be necessary before we can write efficient
> code with it? I deliberately avoided calling the C functions directly,
> as I thought I was using _Scheme_, not C.
Unless the compiler always produces code as fast as C, I think you'll
have to understand some of the internals of the runtime system. And I
think it's also true of C/C++ compilers. Knowing some of their
compilation strategies would help writing more efficient code. But we
often think that since we're writing C code, it's efficient. VC++ 4.2,
for instance, produces horrible code when compiling Gambit-C. It is not
able to use registers adequately. That's a shame.
> That's my fear. ;-) I prefer Scheme! As I said above, more complex
> code should depend less heavily on I/O than this example.
I prefer Scheme too. But I'm aware of its limitations. But don't forget
that Marc Feeley (the author of Gambit-C) is also fully aware of this
tradeoff - portability vs efficiency. Note also that Gambit-C does not
make use of sophisticated dataflow/control-flow analyses, which would
reduce the need for program annotations.
--Dominique
+------------------------------------------+-------------------+
| Dominique Boucher, M.Sc. | //\\ |
+------------------------------------------+ \\ |
| L a m b d a S o f t | /\\ |
| Software Consultant | S/O F\T |
| Functional Programming Systems and Tools | // \\// |
+------------------------------------------+-------------------+
With a mighty <·················@iro.umontreal.ca>,
········@iro.umontreal.ca uttered these wise words...
> Cyber Surfer wrote:
> > Note that my C code didn't require _any_ optimisations. (I find this
> > 12 to 1 performance ratio puzzling.) The C compiler I used didn't need
> > any optimisations.
>
> That's true, but C does not automatically insert array bound checks,
> runtime type checks, heap/stack overflow checks, etc.
That's what I mean about C optimising the code before you even write
it. Compilers for some languages give you an "unsafe" option, but C
doesn't need it.
> > That's an important part of the point I'm making. C has always had an
> > advantage in this respect. It "optimises" the code before you even
> > write it, but at a cost. It makes the code harder to write.
>
> True again, but you cannot tell the C compiler to insert array bound
> checks when you want to debug your code. You have to instrument the code
> yourself.
That may be a different issue. I know that some C programmers use
tools for bounds checking. I regret that this isn't a standard option
for C compilers. Perhaps it soon will be, as these tools are becoming
more and more popular.
> This has nothing to do with continuations. For example, Bigloo, Manuel
> Serrano's nice Scheme -> C compiler, does not fully support proper
> tail-recursion. Each Scheme function is translated into an equivalent C
> function. But it also supports first-class continuations (call/cc is
> provided as a library function).
I'm not familiar with that compiler, tho I've read that Stalin
supports continuations but can avoid using them when they're not
needed.
> Unless the compiler always produces code as fast as C, I think you'll
> have to understand some of the internals of the runtime system. And I
> think it's also true of C/C++ compilers. Knowing some of their
> compilation strategies would help writing more efficient code. But we
> often think that since we're writing C code, it's efficient. VC++ 4.2,
> for instance, produces horrible code when compiling Gambit-C. It is not
> able to use registers adequately. That's a shame.
I'm still using VC++ 4.0. Is that any better in this respect?
> > That's my fear. ;-) I prefer Scheme! As I said above, more complex
> > code should depend less heavily on I/O than this example.
>
> I prefer Scheme too. But I'm aware of its limitations. But don't forget
> that Marc Feeley (the author of Gambit-C) is also fully aware of this
> tradeoff - portability vs efficiency. Note also that Gambit-C does not
> make use of sophisticated dataflow/control-flow analyses, which would
> reduce the need for program annotations.
Yes, I'm aware of this. I recall from email with him that he's
interested in improving Gambit C in this area, and I wish him luck.
BTW, I've recompiled all of the code I'm using for these tests, and
enabling as many optmisations as possible. In O'caml this means only
telling the compiler to compile "unsafe", while in C it means telling
the compiler to optimise for speed. In LWW, the code now uses the
system::read-binary-bytes function to read from the file (thanks to
Greg Mann at Harlequin for his tips and code).
So, I'm getter much better times for all these tests:
O'caml 10.16
Gambit C 36.42
VC++ 7.68
LispWorks 24.9
The test data is still a 30 MB file of posts to
comp.infosystems.www.announce.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
Cyber Surfer wrote:
> I'm not familiar with that compiler, tho I've read that Stalin
> supports continuations but can avoid using them when they're not
> needed.
Bigloo (http://cuiwww.unige.ch/~serrano) is a nice Scheme compiler that
produces efficient C code. It is not fully properly tail-recursive
(which means that it does not need a trampoline like Gambit-C), has a
fairly complete C interface, and a lot more. It has builtin support for
lexical analyzers and LALR(1) syntax analyzers (a la yacc). Also,
call/cc is supported as a library function. If you don't use
continuations, you won't pay for them. It is not fully R4RS nor IEEE
compliant, though.
Unfortunately (for you), it has not yet been ported to NT, but Manuel
Serrano is actively working on this port, as far as I know.
> I'm still using VC++ 4.0. Is that any better in this respect?
No, it's worse than VC++ 4.2. If I remember correctly, Gambit-C is at
least 30%-40% faster when compiled with Watcom C instead of VC++ 4.0!
> Yes, I'm aware of this. I recall from email with him that he's
> interested in improving Gambit C in this area, and I wish him luck.
My PhD project consists of developing a global analyzer and optimizer
across module boundaries for Gambit-C (Marc Feeley is my thesis
advisor). My goal is to perform cross-module inlining and to
automatically annotate programs based on the result of the analysis.
> So, I'm getter much better times for all these tests:
>
> O'caml 10.16
> Gambit C 36.42
> VC++ 7.68
> LispWorks 24.9
The implementation of count as you first wrote it [without annotations
and using (read-char) instead of (read-char port)], when compiled with
Bigloo with the -unsafe -O6 compilation options, is 4.5 times faster
than the Gambit-C version bypassing the standard I/O procedures. I will
compare these results with OCaml today.
Cheers,
--Dominique
+------------------------------------------+-------------------+
| Dominique Boucher, M.Sc. | //\\ |
+------------------------------------------+ \\ |
| L a m b d a S o f t | /\\ |
| Software Consultant | S/O F\T |
| Functional Programming Systems and Tools | // \\// |
+------------------------------------------+-------------------+
With a mighty <·················@iro.umontreal.ca>,
········@iro.umontreal.ca uttered these wise words...
> Bigloo (http://cuiwww.unige.ch/~serrano) is a nice Scheme compiler that
> produces efficient C code. It is not fully properly tail-recursive
> (which means that it does not need a trampoline like Gambit-C), has a
> fairly complete C interface, and a lot more. It has builtin support for
> lexical analyzers and LALR(1) syntax analyzers (a la yacc). Also,
> call/cc is supported as a library function. If you don't use
> continuations, you won't pay for them. It is not fully R4RS nor IEEE
> compliant, though.
It sounds wonderful, thanks.
> Unfortunately (for you), it has not yet been ported to NT, but Manuel
> Serrano is actively working on this port, as far as I know.
Excellent. I look forward to playing with it, when it's done.
> > I'm still using VC++ 4.0. Is that any better in this respect?
>
> No, it's worse than VC++ 4.2. If I remember correctly, Gambit-C is at
> least 30%-40% faster when compiled with Watcom C instead of VC++ 4.0!
<sigh> Yet another reason for an upgrade. It'll be 5.0 now, of course.
> My PhD project consists of developing a global analyzer and optimizer
> across module boundaries for Gambit-C (Marc Feeley is my thesis
> advisor). My goal is to perform cross-module inlining and to
> automatically annotate programs based on the result of the analysis.
I wish you success! Go for it.
> The implementation of count as you first wrote it [without annotations
> and using (read-char) instead of (read-char port)], when compiled with
> Bigloo with the -unsafe -O6 compilation options, is 4.5 times faster
> than the Gambit-C version bypassing the standard I/O procedures. I will
> compare these results with OCaml today.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
Cyber Surfer wrote:
> I'm not familiar with that compiler, tho I've read that Stalin
> supports continuations but can avoid using them when they're not
> needed.
Bigloo (http://cuiwww.unige.ch/~serrano) is a nice Scheme compiler that
produces efficient C code. It is not fully properly tail-recursive
(which means that it does not need a trampoline like Gambit-C), has a
fairly complete C interface, and a lot more. It has builtin support for
lexical analyzers and LALR(1) syntax analyzers (a la yacc). Also,
call/cc is supported as a library function. If you don't use
continuations, you won't pay for them. It is not fully R4RS nor IEEE
compliant, though.
Unfortunately (for you), it has not yet been ported to NT, but Manuel
Serrano is actively working on this port, as far as I know.
> I'm still using VC++ 4.0. Is that any better in this respect?
No, it's worse than VC++ 4.2. If I remember correctly, Gambit-C is at
least 30%-40% faster when compiled with Watcom C instead of VC++ 4.0!
> Yes, I'm aware of this. I recall from email with him that he's
> interested in improving Gambit C in this area, and I wish him luck.
My PhD project consists of developing a global analyzer and optimizer
across module boundaries for Gambit-C (Marc Feeley is my thesis
advisor). My goal is to perform cross-module inlining and to
automatically annotate programs based on the result of the analysis.
> So, I'm getter much better times for all these tests:
>
> O'caml 10.16
> Gambit C 36.42
> VC++ 7.68
> LispWorks 24.9
The implementation of count as you first wrote it [without annotations
and using (read-char) instead of (read-char port)], when compiled with
Bigloo with the -unsafe -O6 compilation options, is 4.5 times faster
than the Gambit-C version bypassing the standard I/O procedures. I will
compare these results with OCaml today.
Cheers,
--Dominique
+------------------------------------------+-------------------+
| Dominique Boucher, M.Sc. | //\\ |
+------------------------------------------+ \\ |
| L a m b d a S o f t | /\\ |
| Software Consultant | S/O F\T |
| Functional Programming Systems and Tools | // \\// |
+------------------------------------------+-------------------+
With a mighty <·································@news.lavielle.com>,
······@lavielle.com uttered these wise words...
> You sure would not want to use READ-LINE!
I thought that read-line was a standard function? Is there an
alternative ANSI CL function that I could use?
> in MCL (using READER-FUNCTION) i'd write something like:
>
> (defun lc4 (&optional (filename *the-file*))
> (with-open-file (stream filename)
> (multiple-value-bind (reader-function value) (stream-reader stream)
> (locally (declare (optimize (speed 3)))
> (loop for char = (funcall reader-function value)
> while char
> count (eql (the character char) #\newline) integer)))))
Hmm. Not very portable, tho. Unless reader-function is ANSI CL? I
don't _think_ that it is.
I'm disappointed that it's (apparently) so easy for ANSI C to beat
ANSI CL. It may be unrealistic to expect standard, and therefore
_portable_, code to perform well.
> or if I wanted to count lines and chars:
>
> (defun lc5 (&optional (filename *the-file*))
> (with-open-file (stream filename)
> (multiple-value-bind (reader-function value) (stream-reader stream)
> (locally (declare (optimize (speed 3)))
> (loop for char = (funcall reader-function value)
> while char
> count char into chars integer
> count (eql (the character char) #\newline) into lines integer
> finally return (values lines chars))))))
Of course, there may well be a similar trick that can make LWW perform
better. I don't yet have complete docs for LWW, so I may be missing
something important.
How does your MCL code compare against the C code I posted a few days
ago? I'd expect I/O in MCL to be just as fast as in C.
Of course, another optimisation would be to call the OS directly, or
to call some buffered I/O functions written in C. I've avoided doing
that, so far, as I was trying to programming in CL. For a trivial
example like counting lines, I might as well use C, but for more
realistic code it might be worth the effort - and the ugliness.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
> (defun lc (&optional (filename *filename2*))
> (let ((line-no 0))
> (with-open-file (f filename :direction :input)
> (loop
> (let ((line (read-line f nil :eof)))
> (if (eq line :eof)
> (return line-no))
> (incf line-no))))))
Read-line creates a string that is just overhead.
The fastest way to do this is likely to use read-sequence
to get a buffer-full and then count the lines
in each buffer full:
(defun lc (filename)
(let ((nlines 0)
(buffer (make-string 8192))) ;; 8k buffer
(declare (optimize (speed 3) (safety 0))
(fixnum nlines)
(simple-string buffer))
(with-open-file (f filename :direction :input)
(loop
for nfilled = (read-sequence buffer f)
while (> nfilled 0)
do
(incf nlines (count #\newline buffer :end nfilled))
))
nlines
))
-Kelly Murray ···@franz.com http://www.franz.com
With a mighty <············@sparky.franz.com>,
···@math.ufl.edu uttered these wise words...
> Read-line creates a string that is just overhead.
> The fastest way to do this is likely to use read-sequence
> to get a buffer-full and then count the lines
> in each buffer full:
Alas, LWW seems not to know of read-sequence. ACL/PC doesn't seem to
know it, either! At least, the Lite version doesn't. I can't check the
Standard or Pro versions of ACL, as I don't have access to them.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In article <·························@news.demon.co.uk>,
············@gubbishwildcard.demon.co.uk (Cyber Surfer) wrote:
> With a mighty <············@sparky.franz.com>,
> ···@math.ufl.edu uttered these wise words...
>
> > Read-line creates a string that is just overhead.
> > The fastest way to do this is likely to use read-sequence
> > to get a buffer-full and then count the lines
> > in each buffer full:
>
> Alas, LWW seems not to know of read-sequence. ACL/PC doesn't seem to
> know it, either! At least, the Lite version doesn't. I can't check the
> Standard or Pro versions of ACL, as I don't have access to them.
MCL hasn't it either. It is a recent addition of ANSI CL.
Sigh.
--
http://www.lavielle.com/~joswig/
With a mighty <·································@news.lavielle.com>,
······@lavielle.com uttered these wise words...
> MCL hasn't it either. It is a recent addition of ANSI CL.
> Sigh.
Well, it's good to see such useful functions being added to CL, even
if the cost is that we must sometimes wait for them to appear in the
implementations. So it goes.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In article <·························@news.demon.co.uk>,
············@gubbishwildcard.demon.co.uk (Cyber Surfer) wrote:
> With a mighty <·································@news.lavielle.com>,
> ······@lavielle.com uttered these wise words...
>
> > You sure would not want to use READ-LINE!
>
> I thought that read-line was a standard function? Is there an
> alternative ANSI CL function that I could use?
If you want to scan through a file to count the lines, READ-LINE
may be overkill - don't you think? How about the useless
allocated memory?
> > (defun lc4 (&optional (filename *the-file*))
> > (with-open-file (stream filename)
> > (multiple-value-bind (reader-function value) (stream-reader stream)
> > (locally (declare (optimize (speed 3)))
> > (loop for char = (funcall reader-function value)
> > while char
> > count (eql (the character char) #\newline) integer)))))
>
> Hmm. Not very portable, tho. Unless reader-function is ANSI CL? I
> don't _think_ that it is.
>
> I'm disappointed that it's (apparently) so easy for ANSI C to beat
> ANSI CL. It may be unrealistic to expect standard, and therefore
> _portable_, code to perform well.
You are right - this is not one of CL's strengths.
There is a problem. CL has its own ideas of I/0.
On most Common Lisp systems I/O is implemented on atleast
four (!!!) levels.
1) Native I/O of the operating system (with all its baggage, #_PBReadSync, ...).
2) Low level CL interface to 1) (%ftyi, ...)
3) CLOS-based streams (stream-tyi, ...)
4) ANSI CL (read-char, ...)
MCL's STREAM-READER gives you access to level 2 without
unnecessary indirections or CLOS dispatch.
Imagine how fast you can get with a directly in CL implemented
OS and its I/O, getting rid of the intermediate layers.
> How does your MCL code compare against the C code I posted a few days
> ago? I'd expect I/O in MCL to be just as fast as in C.
Fortunately I don't have a C compiler on my Mac.
Rainer Joswig
--
http://www.lavielle.com/~joswig/
With a mighty <·································@news.lavielle.com>,
······@lavielle.com uttered these wise words...
> If you want to scan through a file to count the lines, READ-LINE
> may be overkill - don't you think? How about the useless
> allocated memory?
The line counting example, as I have said, is used here only to
isolate the I/O code from the code that would process the lines. In a
more realistic program, I/O might still dominate the run time, but it
could bias the timing enough to be a problem.
For example, parsing the text to extract fields then and feeding them
into a database would also use a certain amount of I/O. What then
would we be measuring in our tests?
As for the allocated memory, I've not noticed that this is a problem
in LWW. Comparing the test with read-line with the test with read-
char, I get very similar timing. The allocated memory is very
different, of course, but that doesn't significantly affect the run
time. In fact, it's barely measurable!
Profilig the code reveals why. LWW spends most of the time in read-
char, regardles of whether you use read-line or not. My guess is that
read-line simply calls read-char, collects the characters into a
string, and then returns it.
Now, if there was a low level version of read-char, I could call that
instead. Instead, it appears that I must fill a buffer and then read
from that. Still, it means that I could write my own fast-read-char
function, using this explicit buffering. Alternately, perhaps I should
just call some C code in a DLL? See below.
> There is a problem. CL has its own ideas of I/0.
> On most Common Lisp systems I/O is implemented on atleast
> four (!!!) levels.
Ouch. I can understand why this would be done, of course. I'm just
concerned about the result, esp when my own file I/O demands rarely
(if ever) require anything that sophisticated.
> 1) Native I/O of the operating system (with all its baggage, #_PBReadSync, ...).
> 2) Low level CL interface to 1) (%ftyi, ...)
> 3) CLOS-based streams (stream-tyi, ...)
> 4) ANSI CL (read-char, ...)
It looks to me like 1) and 2) would be implementation dependant. I
guess that would be no problem if you don't need portable code (I
prefer it, but I don't need as much as decent performance) and if the
documentation covers these functions.
> MCL's STREAM-READER gives you access to level 2 without
> unnecessary indirections or CLOS dispatch.
Excellent. I'm not fond of using CLOS for such low level functions as
I/O, esp not for character I/O. For large files, that's very painful.
LWW also provides such efficient low level I/O functions, but I don't
yet appear to have the docs for them.
> Imagine how fast you can get with a directly in CL implemented
> OS and its I/O, getting rid of the intermediate layers.
I've even considered writing a DLL for doing the low level character
based I/O. This technique, of using C code for I/O, works very well
for Gambit C.
For something more demanding, like parsing HTML, the performance
advantages should even greater. Considering how (relatively) ugly the
low level I/O handling in Lisp looks, I'd call this a serious option.
It really depends on how happy you are writing some code in C. As I
already have most of an HTML parser written in C++, I could probably
do this without too much effort.
However, I'd prefer to write the parser in Lisp first, before using
the C code. Both solutions look like ugly hacks to me, but the Lisp
hack would be preferable, while the C hack may well deliver better
performance. <sigh>
> Fortunately I don't have a C compiler on my Mac.
Fortunately? I guess you never need to write any code that requires C.
I have to do that from time to time, but luckily someone else provides
me with a C/C++ compiler. I wouldn't buy one now, and GNU C is more
than adequate for maintaining my old C/C++ code.
Give me a Lisp compiler that can produce a DLL with low overhead, with
bindings for the _entire_ Win32 API (no, I'm _not_ kidding!), support
for multi-threading, and perhaps I won't need a C/C++ so much. So far,
no CL or Scheme compiler fits the bill. I dunno about DylanWorks yet.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In article <·························@news.demon.co.uk>,
············@gubbishwildcard.demon.co.uk (Cyber Surfer) wrote:
> > Fortunately I don't have a C compiler on my Mac.
>
> Fortunately? I guess you never need to write any code that requires C.
MCL 4.1 is enough for me on PowerMacs and on my Symbolics
MacIvory there is no need for C at all.
My current MCL folder has 1132987+12 (see below) lines of Lisp code and
some more on backup volumes. Most of that I even haven't looked at.
This should keep me busy. :-) No need for C at all.
(let ((files (directory "ccl:**;*.lisp")))
(flet ((count-lines (filename)
(with-open-file (stream filename)
(multiple-value-bind (reader-function value) (stream-reader stream)
(locally (declare (optimize (speed 3)))
(loop for char = (funcall reader-function value)
while char
count (eql (the character char) #\newline) integer))))))
(ccl::with-shown-progress (task "Count Lines..." :denominator (length
files))
(loop for file in files
do (ccl::show-progress task :note (princ-to-string file))
summing (count-lines file)))))
--
http://www.lavielle.com/~joswig/
With a mighty <·································@news.lavielle.com>,
······@lavielle.com uttered these wise words...
> In article <·························@news.demon.co.uk>,
> ············@gubbishwildcard.demon.co.uk (Cyber Surfer) wrote:
>
>
> > > Fortunately I don't have a C compiler on my Mac.
> >
> > Fortunately? I guess you never need to write any code that requires C.
>
> MCL 4.1 is enough for me on PowerMacs and on my Symbolics
> MacIvory there is no need for C at all.
> My current MCL folder has 1132987+12 (see below) lines of Lisp code and
> some more on backup volumes. Most of that I even haven't looked at.
> This should keep me busy. :-) No need for C at all.
You've proved my point, then. You don't use Windows. ;-)
Honestly, Rainer. Try writing an OLE server or a shell extension in
Common Lisp. A lot of features like this depend on DLLs. The only CL
systems I've found all produce EXEs, not DLLs.
Damn few of us get to use a MacIvory. Perhaps that's irrelevant, tho.
In an ideal world, we'd _all_ have a machine that runs nothing but
Lisp. Meanwhile, it's easier to just _choose_ to use just Lisp, and
claim that's the sme thing.
Alas, it isn't. Some of don't even have Macs! Never mind a MacIvory.
You've told me many times that MCL doesn't have any problems, and I've
reminded you that I - and many others - don't use a Mac. We don't all
choose these things, so your advise isn't particularly helpful.
As I said earlier, I guess you never need to write any code that
requires C. If that were enough to change the world, there'd be no
problem. The world is still dominated by people who don't use Lisp,
and don't wish to. Never mind use Lisp exclusively. You and I would be
happy to use Lisp exclusively, and it seems that you can do it.
Back in the real world...Yuk. A world hostile to Lisp. Bizarre. Even
worse, a load of Lisp people who either don't understand that world,
or who undestand it but just reject it anyway. The result is the same,
in both cases, an increase in the perception of Lisp as a language
unable to meet the demands of the "real world", whatever that is.
Whatever you say, Rainer, I doubt that you'll convince many people
that a MacIvory is worth much. They'll first have to understand what
is it, then why they'd want one, and finally that they can actually
get one. If you try to convince people who've already chosen Lisp,
then it'll be much easier, but that's a minority.
You'll have more success with MCL, talking to people who've already
chosen to use a Mac. Still, I guess the numbers don't count. In the
end what counts is that _you_ can use Lisp without touching a C
compiler. The number of other programmers who don't have that choice
has no relevance, does it? _You_ never need to write any code that
requires C, regardless of the hordes who _do_, for whatever reasons.
I'm trying to convince people that I should use Lisp, that I'm not
alone, that Lisp is a great tool for writing _Windows_ software, that
loads of Windows developers could be using it. Can you help, or can
you only tell me about Macs and Lisp machines? Try to imagine a world
dominated by C++ and Basic programmers - yuk - and an OS with demands
for a form of delivery not supported by any CL system.
No wonder that C++ and Basic dominate! Lisp can't compete on those
terms, but those are the terms that exist. Deny them if you can, but
some of us have to deal with this. If Lisp vendors reject it, is it
suprising that so many people reject Lisp? Is it suprising that a few
of us who _choose_ Lisp for developing Windows software sometimes also
need a C compiler?
Someone from a well known Lisp vendor recently advised me to write a
user interface in C, because their own Common Lisp didn't support
certain popular Windows features. Go figure.
Flame away, if you like Rainer, but all I'm asking for is support for
the basic features of the OS that I use. Truly _basic_ features. Do
you have anything more constructive to offer than "use a mac"?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
············@gubbishwildcard.demon.co.uk (Cyber Surfer) wrote:
| You've proved my point, then. You don't use Windows. ;-)
|
| Honestly, Rainer. Try writing an OLE server or a shell extension in
| Common Lisp. A lot of features like this depend on DLLs. The only CL
| systems I've found all produce EXEs, not DLLs.
Let's ask a simple question that will separate the programmers from the hackers:
Why the HELL would anyone EVER want to allocate memory?
Oh yes, there are cases where you have no choice, because your code has to
fit in with another piece of code, and that code can't be fixed so as to
remove this vile abomination of a requirement.
But if you answer, "speed" or "because it's just automatically better,"
you're a hacker, not a programmer, and you should ignore Lisp, because
that isn't what Lisp is about.[1]
| Back in the real world...Yuk. A world hostile to Lisp. Bizarre. Even
| worse, a load of Lisp people who either don't understand that world,
| or who undestand it but just reject it anyway. The result is the same,
| in both cases, an increase in the perception of Lisp as a language
| unable to meet the demands of the "real world", whatever that is.
What does the "real world" REALLY want? Applications "must" do what they
are advertised to do. Second, they "have to" play nice with the rest of
the apps and the OS, and third, they "should" not suck.
What the "real world" THINKS it wants is C++ and Windows NT. Say what you
want, but neither of these are terribly advanced systems. They are just
now reinventing concepts that Lisp had in the Seventies. Heck, they're
reinventing concepts that mainframes had in the Sixties.
One uses Lisp because one doesn't want to have to deal with what the real
world THINKS it wants. One uses Lisp because one wants to use really good
programming tools to get an idea into code quickly, without regard for C
and Windows and junk like that. Luckily, this lines up well with what the
real world really wants, you just have to convince the real world of this
fact.
{DIGRESSION:
If you read "The Elements of Programming Style" by Kernighan and Plaugher
(NOTE: Yes, that Kernighan, the father of C and Unix and all that is Great
and Holy, AMEN), you will see that their ideas on how to speed up programs
are basically:
1) Buy a faster computer, or add stuff to make it faster
2) Change the algorithm or compiler optimizations
...and THEN and ONLY then...
3) Profile and optimize your program's code.
They give copious, really entertaining anecdotes to support this wisdom,
and you should buy this book and read it.
The point of this digression is to make it clear that even the so-called
inventors of the modern computing system Unix/C think precisely in the
same way that the average Lisp programmer would -- ie. start general and
get specific later, and only IF you have to.
I can back this idea up by pointing out that Unix hackers think that
cobbling together a bunch of small programs via pipes is a better way to
do things than to write one mondo program to do everything. (Of course,
the traditional rejoinder "Fixed in <release>" applies here. How many
arguments does "ls" have these days!) The hackers know that using pipes is
slower and more cumbersome than having a single program, but it's also
faster to develop, and less prone to code errors.
Which to me means that you should not judge a programming system by how
it, for example, allocates memory until you KNOW FOR A FACT that you have
an actual requirement forcing you to care. And no, "because my friends
will laugh at me for using Lisp" isn't a very strong requirement.
I do realize that the argument, "my code needs to frob the xyzzy manager,
and I can't do that in Lisp" is perfectly valid, to the extent that I
think someone should add that ability to Lisp, as they did in MCL, as a
service to protect the programmer from having to touch that yucky memory
stuff.
END OF DIGRESSION}
The difference between what the real world wants and what it thinks it
wants is non-trivial. In the past, for example, I wrote a piece of code
which was to have become a tiny part of DEC's VMS operating system. I
wrote it in BASIC, because it took me 5 minutes to write the code, and I
knew that I wouldn't have a problem with memory allocation or anything
like that, and because there really wasn't much of a speed requirement or
memory requirement. It did have to allocate memory, and communicate with
the rest of VMS, which is not written in BASIC, but I was able to do those
things easily because the authors of that BASIC had thoughtfully included
appropriate routines to do it.
Naturally, it worked like a champ, and never ever had a bug. But about
three years later, someone dropped into DEC's source-level debugger in my
code (because they were fixing a driver that my code was part of) and saw
"BASIC" in the window, and called me, asking me why I didn't use a real
programming language. I told him that I had saved DEC many thousands of
dollars by doing so, and if he had a problem with that. Of course not. He
was just amazed that anyone had the gumption to ship BASIC as part of VMS,
and I said, "I simply didn't tell them it was BASIC." (In UNIX, I could
have done the same thing by writing it in Perl or TCL or sed, and I would
have been lauded for my ingenuity.)
I'll encourage Lisp programmers to apply the same argument to the
so-called real world. If you can write a program that does the functions
necessary, without bugs and crashes, people will care and will pay for it,
no matter what language.
If you can do it in Lisp, chances are it will take you less time to
develop and test it, which means more profit for you.
If someone were to approach me, and ask for a text formatter program
(which a whole LOT of programs really are, at the base), I'd tell them to
use a language like sed or Perl or Lisp to do it. If they complained that
it wasn't fast enough, I'd be very tempted to ask why they thought so. I
mean, how much speed is needed?
I once wrote one of these, my code was probably 10x as slow as "optimized
C" -- but it meant that the program ran in 1 day instead of the previous
"by hand" effort: 1 month. When the Mac IIci came out, the program ran in
1 hour. These days, with processors 500x as fast as the MacPlus I
originally used, I'm pretty sure it would still take the whole hour,
because humans can't click any faster than they used to!
People routinely say that code is bigger and slower because "programmers
are lazy." But they seem to forget that programs also have many more
features and much shorter time-to-market these days. Sure, you can write a
text editor with 90% of the features of Microsoft Word 6, in assembly, and
it will be 10x as small, and run 10x as fast, but it will take 10x as long
to develop a new version. This actually happened -- the program is called
WriteNow 4. (And last I checked, Word 6 is written in C.)
At the same time, I will say that C programs often are smaller and faster
precisely because the programmer is lazy. I mean, how much error-checking
code did YOU add to your app to deal with the fact that the file you are
writing into might be on a file server which might disconnect in
mid-write? Obviously, a general-purpose library, such as the ones that
typically come with Lisp or C, must have code to deal with this. And code
takes up space, and perhaps slows things down, even though the chances of
this error occurring are relatively rare.
What it gets down to is a preference: do you want to spend your time
dealing with crashes because you allocated memory wrong, or do you want to
spend your time writing cool new features, at the expense of a
surprisingly small amount of overhead?
I'd rather force the question of size and speed, than just bury Lisp
because I *thought* it was slower and bigger than C.
I recognize that you don't always get that choice. But this really means
that you need to add stuff to Lisp to make it manage the interface to
hostile OS routines, so that you can write Lisp without dealing with
memory allocation and similar crud.
And maybe you "can't" write this code in Lisp. So what's your point? You
pay somebody to write the C code to add the missing stuff to Lisp, and
then you use it. This is exactly what happens with C.
People are finally adding some stuff to C++ to insulate programmers from
some of the low-level crud they've needed to deal with, to this point.
Well bully for them! I encourage C++ to add as many new features to make
it "just as good as Lisp" or "better than Lisp," or whatever it is that
their gloating about this week. Why not?
And if they fix their obscene syntax crocks that are held-over to allow
ancient, ugly programs to continue to run and only OCCASIONALLY happen to
cause mysterious errors that new programmers seem to fall into -- why that
would be even better.
Use whatever programming you want. But if you think using a malnourished
language is superior because it makes the code smaller and faster, at the
expense of taking longer to write and debug, well, you aren't living in
the real, real world.
bc
[1] Of course, there are people who WANT to hack this way. They think it's
cool to make an algorithm that fits in 11 bytes, or whatever. That's
great! They should write compilers, and we can all be very happy. I'd
personally pay someone money to implement very clever compiler
optimizations (of course, they'd be bug free, right?). I frequently do
just that.
But I have come to realize that my challenge as an application programmer
is to write a dingus, not write it in under 32k, or only using one hand,
or without using the letter "e," or whatever. Those requirements are not
as important to me as getting things done, on time, within budget, and
without bugs.
I equate "allocating memory" with "optimizing code" -- it's fun, but not
what I want to do all day long.
With a mighty <···················@17.127.18.248>,
··@wetware.com uttered these wise words...
> But if you answer, "speed" or "because it's just automatically better,"
> you're a hacker, not a programmer, and you should ignore Lisp, because
> that isn't what Lisp is about.[1]
The point I was making was about support for certain OS-specific
features, rather significant features, if fact.
Speed can also be significant, esp if that's what people expect. I
don't see it as an end in itself. Normally, I wouldn't be concerned
about the time taken to run some code, but when I write code for
people who _are_ concerned about such things, then I must consider it.
Sometimes I too must consider it, if only for my own convenience. why
wait several minutes for a program to complete, when it can be done in
just a few second if you pay a little attention to performance.
However, the point to which you were responding was about another
matter. I said:
> Honestly, Rainer. Try writing an OLE server or a shell extension in
> Common Lisp. A lot of features like this depend on DLLs. The only CL
> systems I've found all produce EXEs, not DLLs.
You've not denied that CL systems have this limitation.
> What does the "real world" REALLY want? Applications "must" do what they
> are advertised to do. Second, they "have to" play nice with the rest of
> the apps and the OS, and third, they "should" not suck.
Hence my interest in delivering code in a DLL. If you, like Rainer,
are suggesting that I should not be writing code for Windows, then
that's a totally different issue. Some Lisp programmers evidently do
code for Windows, as a number of Lisp vendors will tell you.
> What the "real world" THINKS it wants is C++ and Windows NT. Say what you
> want, but neither of these are terribly advanced systems. They are just
> now reinventing concepts that Lisp had in the Seventies. Heck, they're
> reinventing concepts that mainframes had in the Sixties.
I'm not disputing that point. Please note that I'm not a fan of C++! I
only use NT because: 1) I get it for free 2) I'm paid to use it. I'm
not going to waste time defending a position that I don't support.
Anyone who wished to pay me to develop code for the Mac should email
me. ;) Meanwhile, I'll continue to use the platform that I'm asked to
use. OS advocacy belongs in an .advocacy newsgroup.
> One uses Lisp because one doesn't want to have to deal with what the real
> world THINKS it wants. One uses Lisp because one wants to use really good
> programming tools to get an idea into code quickly, without regard for C
> and Windows and junk like that. Luckily, this lines up well with what the
> real world really wants, you just have to convince the real world of this
> fact.
This is why I mentioned the "real world". It's ugly because that's
where you find people who don't know Lisp, and don't wish to. If I
could compete with the mass of marketing bullshit telling people that
non-Lisp stuff is "what the real world really wants", I wouldn't be
here making the point that it's going to hard to convince Windows
people that Lisp can solve their problems when they believe - perhaps
rightly - that there are OCX/OLE components that solve their problems,
and yet Lisp systems don't support OCX/OLE.
The task that you're refering to is one that would show that the mass
of OCX/OLE/DLL tools available for Windows developers _don't_ solve
any useful problems. If you're saying that Lisp developers don't need
these tools, that's a little different, but you still need to show how
Lisp can do all these things better. That's a mighty big task!
> They give copious, really entertaining anecdotes to support this wisdom,
> and you should buy this book and read it.
I read it years ago, and I recommened it to other programmers. What
they say about software tools directly applies to Windows technologies
like OCX/OLE. _Directly_. You can't use K&P to dismiss this stuff, as
it's the same thing! All you're doing is claiming that a 70s style of
tool building is superior to 90s style style, and you'd lose that
argument very quickly. Whether you believe that Windows has anything
to offer or will always suck farts from dead cats is irrelevant. The
evidence is in the application of the tools themselves.
> The point of this digression is to make it clear that even the so-called
> inventors of the modern computing system Unix/C think precisely in the
> same way that the average Lisp programmer would -- ie. start general and
> get specific later, and only IF you have to.
All you're doing is making a Unix vs Windows argument. You don't see
that Windows developers also do this, that Windows does exactly the
same things, but the details are a little different.
In other words, you're saying, "Not invented here". If this is not
what you're saying, then please show how the tool building ideas in
OLE/OCX (what MS now call ActiveX) are fundamentally different. If all
you have is a pro-Unix argument, don't be too suprised if Windows
people ignore you - and Lisp.
[(anti-Windows?) rant deleted]
You may see this as a Unix vs Windows issue, but most Windows
developers will simply see it as a Lisp vs VB/VC++ issue. It doesn't
matter which language is superior when you're more interested in
developing the apps that your clients ask for. That's why I suggest
that the way make Lisp more popular with Windows developers is to add
support for the features they demand.
On the other hand, if you're happy with the rather different demands
made by Unix software, don't write Windows software and expect it to
be Unix software. Nor should you expect Windows people to be too
impressed with it. The demands are _different_. Fortunately, these
differences may just be surface details. Unfortunately, a great many
people consider them to be of vital significance. Hence the problem.
My answer to this problem is "culturally assimilate". This is what
Python for Windows has done, and I like the result. I'd still prefer
Lisp, tho, but that's because I like the Lisp language, and CL in
particular. I don't like C++, but it can do a few things that no CL
system can. As Python can also do some of these things, perhaps I
should consider using it, but I'm waiting for DylanWorks.
It isn't a technical issue, but a cultural one. Stop playing "not
invented here", assimilate a little bit of the native culture, and
Lisp people might learn a few things from the C++/VB/Delphi people,
and they might learn a few things from Lisp. Both groups have a lot to
learn, I think. For example, tool building is more important than
language ideology. I can't blame anyone for picking a tool that most
strongly supports what they intend to do. Nor can I blame them for
ignoring a tool that _doesn't_ support what they want.
Lisp is about tool building. So is Windows. The problem is that the
two systems - as they currently exist - are incompatible. What I find
curious is the way in which Lisp ideas can be found lurking inside
Windows, in some many places. These ideas are getting stronger now,
with the addition of things like ActiveX Scripting.
I look forward to seeing a Lisp that exploits these features, instead
of working _against_ them. Take a good look at ActiveX, and the bits
that it is composed of (OLE, OCX, etc). Apart from being designed for
C++ programmers, is it really so different? Also take a look at Python
for Windows, and ask yourself how easy would it be to do the same
thing with Lisp? A Common Lisp system with that kind of integration
with the native API would be a killer.
If you're one of those people who insist that Windows sucks, no matter
what, then we have nothing to say to each other. There are people
who've used Unix and say the same thing about it. This is why I'm not
interested in such "arguments". I'm far more interested in building
and applying tools. In other words, something constructive. If that's
a flame, then too bad. I like being constructive.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In article <·························@news.demon.co.uk>,
············@gubbishwildcard.demon.co.uk (Cyber Surfer) wrote:
> I look forward to seeing a Lisp that exploits these features, instead
> of working _against_ them. Take a good look at ActiveX, and the bits
> that it is composed of (OLE, OCX, etc). Apart from being designed for
> C++ programmers, is it really so different? Also take a look at Python
> for Windows, and ask yourself how easy would it be to do the same
> thing with Lisp? A Common Lisp system with that kind of integration
> with the native API would be a killer.
For whom?
A decent Windows (when?) and a decent Lisp on such a Windows (when?)
could be moderate success. A killer? Not really. Still it
is true that some Lisp vendors are a bit unwilling to
move to Windows. I mean, where would you move else? Windows
is the biggest market.
My copy of LispWorks for Windows does not
support TCP/IP (isn't this the decade of the Internet?)
and the event/process handling simply sucks
(example: no drawing updates for a Listener while there is running
a computation). Inspecting a long list costs you a day
of your life. I haven't used ACL/PC, but requiring
to use Emacs on Windows for serious ;-) development (> 32k files)
sounds not very promising. Gold Hill? Don't know.
If users want a decent Lisp implementation for the PC
better they stop whining, instead they should collect a wish list,
send it to their vendors and post the response here.
--
http://www.lavielle.com/~joswig/
With a mighty <·································@news.lavielle.com>,
······@lavielle.com uttered these wise words...
> > I look forward to seeing a Lisp that exploits these features, instead
> > of working _against_ them. Take a good look at ActiveX, and the bits
> > that it is composed of (OLE, OCX, etc). Apart from being designed for
> > C++ programmers, is it really so different? Also take a look at Python
> > for Windows, and ask yourself how easy would it be to do the same
> > thing with Lisp? A Common Lisp system with that kind of integration
> > with the native API would be a killer.
>
> For whom?
That's an easy one. Windows developers using Lisp. Of course, I'm
using the definition of "Windows developers" that you can find in
magazines like Windows Tech Journal, Microsoft Systems Journal, and
now Visual Systems Journal. The last two mags could perhaps be accused
of having a strong "MS marketing" flavour, but they certainly have a
strong bias towards COM/ActiveX.
> A decent Windows (when?) and a decent Lisp on such a Windows (when?)
> could be moderate success. A killer? Not really. Still it
> is true that some Lisp vendors are a bit unwilling to
> move to Windows. I mean, where would you move else? Windows
> is the biggest market.
I know of at least two commercial Lisps for Windows (I have evaluation
versions of them both), but neither of them suppport ActiveX - yet.
I'm sure that, like some Smalltalk vendors, they're working on it.
Meanwhile, I've found at least one APL that can save the workspace as
an OLE object. That was a year or two ago. I doubt that it would be
relatively hard to for a Lisp vendor add such a feature to their Lisp.
> My copy of LispWorks for Windows does not
> support TCP/IP (isn't this the decade of the Internet?)
> and the event/process handling simply sucks
> (example: no drawing updates for a Listener while there is running
> a computation). Inspecting a long list costs you a day
> of your life. I haven't used ACL/PC, but requiring
> to use Emacs on Windows for serious ;-) development (> 32k files)
> sounds not very promising. Gold Hill? Don't know.
This is what multi-tasking is for. LWW supports it, and that's one of
the reasons why I'm choosing LWW. As for TCP/IP, I can call the
WININET functions, which is how I'm doing it in C/C++. However, I can
only get away with that because I'm happy using FTP and HTTP only. If
I needed something else, like SMTP, I might prefer to use an OCX.
> If users want a decent Lisp implementation for the PC
> better they stop whining, instead they should collect a wish list,
> send it to their vendors and post the response here.
I've done that. ;-) I'm still doing it, whenever I get email from a
Lisp vendor asking me what I think of their Lisp. Meanwhile, I'm
working on my Lisp to C compiler again. I don't expect that I'll get
it doing anything useful before DylanWorks becomes available, but it's
a way of staying sane. It's also a lot of fun, which makes a change
after a day of coding in Java or C++!
BTW, I don't consider constructive criticism to be "whining". Vendors
need feedback, and _we_ can benefit from the free exchange of ideas.
Healthy debate never hurt anyone.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In comp.lang.lisp Fred Haineux <··@wetware.com> wrote:
[snip]
: Let's ask a simple question that will separate the programmers from the hackers:
: Why the HELL would anyone EVER want to allocate memory?
[snip]
: But if you answer, "speed" or "because it's just automatically better,"
: you're a hacker, not a programmer, and you should ignore Lisp, because
: that isn't what Lisp is about.[1]
[snip]
I know I shouldn't really get into this flame war, being this is prolly
the first of my posts here, but I got something to say about this.
I learned C as a first language, and got quite good at it. I did all of
the requisite checking of return values, learned all about how to make
it fast, even went into assembly for speed. But then again, I'm a
graphics programmer. I had to. Even so. I began to explore the true
nature of algorithms and I realized that C can do nearly everything.
In the end, I ended up inplementing part of LISP(the mapcar and list cell
part) in C without really *understanding* what LISP was all about. LISP
allows certain expressions of algorithms that are, in all honesty, a
true pain to implement in C. I don't like typing... :) Now that I've
learned enough of LISP to learn the rest happily, I am overjoyed with
the expression the language allows. I still use C a lot, but then again
I program under UNIX. There are a *lot* of C libs that do everything
you could prolly ever want from a system perspective. Those are hard
to get in LISP. What I would like to see is a way to be able to access
the functionality of C libs under UNIX inside of LISP. I know there
are ways of doing it, but the docs suck and they are different among
dialects of LISP. LISP allows a concise way of doing algorithms, I am
eternally grateful for that. C is closer to the system and the assembly
and gives you fine control over where the speed goes and what happens
in the algo. Can there be a middle ground? A language where you get
the expression of LISP and the control of C if you want it?
Speed is only needed if you write speed intensive apps like games
or what not. Use the language that provides the faculties for what you
desire to get done. Also, I try to learn as many of them as I can for
one day I hope to take the best features of all those languages and write
a language that has very powerful features, and you don't have to type
much in it. :)
My definition of a hacker is one who tries to push the boundaries of
the language far beyond normal usage. A programmer is just someone
who makes a living writing code. They can overlap, but when deadlines
come, you write what you know.
-pete
············@gubbishwildcard.demon.co.uk (Cyber Surfer) writes:
>Back in the real world...Yuk. A world hostile to Lisp. Bizarre. Even
>worse, a load of Lisp people who either don't understand that world,
>or who undestand it but just reject it anyway. The result is the same,
>in both cases, an increase in the perception of Lisp as a language
>unable to meet the demands of the "real world", whatever that is.
Let me tell you all about a programming language.
It supports the following data types:
- nil
- logical (true/false)
- number
- string
- sequence (no static limit on length; sequences can be dynamically
resized, heterogeneous elements including sequences and functions)
- functions, including anonymous lambda-like forms
- Storage management is entirely automatic
- variables can take on values of different types at run time
- it is taking steps towards OOP
- functions can have optional parameters with defaults
It sounds a lot like Lisp, no?
As for development,
- historically the language was interpreted, but
- now there is a compiler
- with tolerably good source-oriented debugging.
It still sounds like Lisp.
It has a comp.lang.* newsgroup dedicated to it,
which is very active (550 recent messages here).
This language has been used to develop a _lot_ of very successful DOS
applications. There are Windows upgrade paths.
This doesn't sound much like Lisp, though.
What _is_ this language with the Lisp guts and the DOS appeal?
It's Clipper, a member of the XBASE family.
There's a fair bit of historical baggage inherited from dBASE III,
but there's a very Lisp-like system underneath.
The DOS/Windows world may be hostile to Lisp *looks*, but when it
*looks* like dBASE, they've embraced Lisp *guts*.
--
Four policemen playing jazz on an up escalator in the railway station.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.
With a mighty <············@goanna.cs.rmit.edu.au>,
··@goanna.cs.rmit.edu.au uttered these wise words...
> What _is_ this language with the Lisp guts and the DOS appeal?
>
> It's Clipper, a member of the XBASE family.
> There's a fair bit of historical baggage inherited from dBASE III,
> but there's a very Lisp-like system underneath.
>
> The DOS/Windows world may be hostile to Lisp *looks*, but when it
> *looks* like dBASE, they've embraced Lisp *guts*.
I know. My boss reacted very positively to _DylanWorks_, because of
the OLE server support. He's an ex-Clipper programmer, BTW, and was
very fond of Actor. So I just compare languages like Lisp and Dylan to
Actor when I want to present them positively.
Support for hot Windows features, like OLE, just makes something look
even better. Even marketing people with no programming experience will
appreciate that. Here's another curious thought: can reflection be
added to software that exploits OLE? Any language may be used as an
ActiveX script engine, and OLE objects are part data, part code, and a
recent issue of MSJ describes how to use OLE to create "plug-ins".
It's easy to knock Windows without understanding how it works. The
fact that much of this potential is rarely exploited tells us more
about the level of ignorance of ideas like reflection. So much of
these Windows features are built on the humble DLL, which is why
people feel it's important for a compiler to be able to create DLLs.
Now even VB can do it.
The fact that Lisp can do the same kind of things, in a Lisp way, will
be irrelevant to most Windows people, as they'll want software that
works the _Windows way_. Not some alternative way, however good it may
be. As many people reading this will be aware, Lisp is not very well
understood by non-Lisp people. (Almost stating the obvious, there!)
It's easier to understand Fortran without actually using it, perhaps
because it's a "traditional" batch language, while Lisp is generally
interactive, incremental, reflective, etc.
Go into any large bookstore and count the number of books on Windows
programming, and then count the number of books about Lisp. Does this
explain the general ignorance of Lisp? Is it simply a matter of books
and magazines? I'm not suggesting a radical change to Lisp, as that
already been done, with Dylan. Implementations like DylanWorks will
show us what these changes can do for Lisp, in the market. The point
I'm making here is about attitudes. I hope that it isn't just a matter
of Lisp vs Windows, but even if it is, let's try to understand what
we're talking about.
You mentioned Clipper as an example of the DOS world embracing (at
least _some_) Lisp ideas. The Windows world is doing much more than
that, IMHO, and moving towards reflection. In fact, Windows has been
moving in this direction for a great many years, thanks to the DLL.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
Hi!
RO> There's a fair bit of historical baggage inherited from dBASE III,
RO> but there's a very Lisp-like system underneath.
But it's more on the level of the old-time dynamic scope lisps. Yuck.
bye, Georg
* Cyber Surfer -> Rainier Joswig
| You've proved my point, then. You don't use Windows. ;-)
is that your point? that anybody who doesn't use Windows is not a part of
the "real world"? I would say the exact opposite is true.
I would say that those who depend on Microsoft software are like those who
invested in the Albanian pyramids. they are being defrauded and have been
since they acquired their first PC with some Microshit pre-installed. they
will find out, just like the Albanians that had already lost their savings
by the time they found out.
on the other hand, if you're such a willing servant of Bill Gates, why
aren't you able to write wrappers around the functions you need?
you know, the more time you spend not writing what you claim to need, the
harder it will look for everybody else to do, and they don't even need it.
it took me six months to write a system for machine-aided conversion of
unbelievably shitty RTF generated by some randomly losing Microshit Word
application into a structured, consistent SGML form. I didn't know RTF
when I started, I didn't know diddly about the complexity of the problem
(it took six months instead of the three I had hoped for), and the SGML
form it needed to be forced into was itself barely more intelligent than
Word. and it had to run under that Microshit Non-Technology fo(u)r naught.
if it weren't for Microsoft's systemic braindamage and the amazingly
resistant beliefs of some managers that only Microshit would "work" despite
all evidence to the contrary, chances are it would have taken the three
projected months because the sheer pain of working with the incomplete,
underspecified, buggy and flat out dysfunctional environment known as
"Windows" wouldn't have slowed me down so much.
if you can't wrap a decent programming environment around your DLL nonsense
in all the time you have claimed you wanted and needed it so badly, I for
one will believe that it is because Microshit is so insanely braindamaged
that anyone who has the intelligence and good taste to know what to do
won't be able to stomach it, or won't consider the pain worth his while.
and I guess that's why there's not much support for Microshit from people
who would rather buy a real computer with a half-decent operating system
instead of falling pray to Bill Gates' fraudulent business practices and
amazingly successful _hype_ that replaces reasonably informative marketing
as put out by all of his still self-respecting competitors.
| Flame away, if you like Rainer, but all I'm asking for is support for the
| basic features of the OS that I use.
"all you're asking for" is for people to file off their fingers with a
rusty nail file, stick chopsticks in the bloody sockets, and write "I will
succumb to Bill Gates" a million times on an old Teletype. if this is so
hard even you can't do it, asking others to do it for you is unbelievably
arrogant, especially when you repeat, again and again, that you won't pay
for it, and won't help those who do it for you in any possible way, that
is, not in any commercially rewarding way. now, _why_ should they do what
you ask for? there's a million reasons people should _not_ do what you ask
for. if they can make a reasonable living without suffering the pain of
working with Microshit, who the hell are you to demand they _do_ suffer?
| Truly _basic_ features. Do you have anything more constructive to offer
| than "use a mac"?
learn to dig for truffles with your nose. you'll need it in your next life.
#\Erik
With a mighty <················@naggum.no>,
····@naggum.no uttered these wise words...
> * Cyber Surfer -> Rainier Joswig
> | You've proved my point, then. You don't use Windows. ;-)
>
> is that your point? that anybody who doesn't use Windows is not a part of
> the "real world"? I would say the exact opposite is true.
>
> I would say that those who depend on Microsoft software are like those who
> invested in the Albanian pyramids. they are being defrauded and have been
> since they acquired their first PC with some Microshit pre-installed. they
> will find out, just like the Albanians that had already lost their savings
> by the time they found out.
>
> on the other hand, if you're such a willing servant of Bill Gates, why
> aren't you able to write wrappers around the functions you need?
>
> you know, the more time you spend not writing what you claim to need, the
> harder it will look for everybody else to do, and they don't even need it.
>
> it took me six months to write a system for machine-aided conversion of
> unbelievably shitty RTF generated by some randomly losing Microshit Word
> application into a structured, consistent SGML form. I didn't know RTF
> when I started, I didn't know diddly about the complexity of the problem
> (it took six months instead of the three I had hoped for), and the SGML
> form it needed to be forced into was itself barely more intelligent than
> Word. and it had to run under that Microshit Non-Technology fo(u)r naught.
> if it weren't for Microsoft's systemic braindamage and the amazingly
> resistant beliefs of some managers that only Microshit would "work" despite
> all evidence to the contrary, chances are it would have taken the three
> projected months because the sheer pain of working with the incomplete,
> underspecified, buggy and flat out dysfunctional environment known as
> "Windows" wouldn't have slowed me down so much.
>
> if you can't wrap a decent programming environment around your DLL nonsense
> in all the time you have claimed you wanted and needed it so badly, I for
> one will believe that it is because Microshit is so insanely braindamaged
> that anyone who has the intelligence and good taste to know what to do
> won't be able to stomach it, or won't consider the pain worth his while.
>
> and I guess that's why there's not much support for Microshit from people
> who would rather buy a real computer with a half-decent operating system
> instead of falling pray to Bill Gates' fraudulent business practices and
> amazingly successful _hype_ that replaces reasonably informative marketing
> as put out by all of his still self-respecting competitors.
>
> | Flame away, if you like Rainer, but all I'm asking for is support for the
> | basic features of the OS that I use.
>
> "all you're asking for" is for people to file off their fingers with a
> rusty nail file, stick chopsticks in the bloody sockets, and write "I will
> succumb to Bill Gates" a million times on an old Teletype. if this is so
> hard even you can't do it, asking others to do it for you is unbelievably
> arrogant, especially when you repeat, again and again, that you won't pay
> for it, and won't help those who do it for you in any possible way, that
> is, not in any commercially rewarding way. now, _why_ should they do what
> you ask for? there's a million reasons people should _not_ do what you ask
> for. if they can make a reasonable living without suffering the pain of
> working with Microshit, who the hell are you to demand they _do_ suffer?
>
> | Truly _basic_ features. Do you have anything more constructive to offer
> | than "use a mac"?
>
> learn to dig for truffles with your nose. you'll need it in your next life.
>
> #\Erik
>
Try that in comp.os.ms-windows.nt.advocacy, where it belongs. I'm
making a serious point about putting Lisp into the hands of people who
want to use it. If we happen to use Windows, so what? Does that make
us a second class citizen? I hope not.
Careful, Erik. the message that you're giving is anti-Windows. Some
Lisp vendors believe that supporting Windows is a good idea. Are you
disagreeing with me or them? Or are you simply flaming me because you
don't like the idea that "Lisp is less than perfect"?
It is possible to make _constructive_ criticism, which is what I hope
I'm doing. I don't know about you. I have a great deal of respect for
you, but sometimes it seems that you go a little too far. It won't
hurt Lisp to admit that some implementations could be better. If you
feel that this is not so, could it not be said without resorting to
abuse? If you dislike Windows, take it to an advocacy newsgroup.
Pay me to use whatever tools you use, otherwise please don't lecture
me on what tools I should be using. Note that I don't tell _you_ what
software to use. If you're unable to engage in a debate, and entertain
a few new ideas, without flaming...
I'm forwarding your message to my boss, as he find your rantings very
entertaining. I wish I did. The message you're giving is that Lisp and
Windows don't mix, while I'm asking what may be done to make them a
_better_ mix. Which of us is being more constructive?
Followups adjusted.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
Wow! Not "Cyber Surfer"? Or, is it "Cyberpunker" this week?
> Careful, Erik. the message that you're giving is anti-Windows.
Ha! Now you got him.
> I'm forwarding your message to my boss, as he find your rantings very
> entertaining. I wish I did. The message you're giving is that Lisp and
> Windows don't mix, while I'm asking what may be done to make them a
> _better_ mix. Which of us is being more constructive?
Erik, of course.
Not that I will attampt to defend his tactlessness (to put it mildly),
but he has been very clear in what you should do to make Lisp support
DLL-s (or whatever fancy thing you want to have) -- write wrapper
functions. If you are uncapable of doing it, pay others to do it.
But don't expect others to do it *for free* because you don't feel
like doing it.
That is the point of Erik's article. Feel free to forward this
message to your boss, too.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Idle RAM is the Devil's playground.
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
Wow! Not "Cyber Surfer"? Or, is it "Cyberpunker" this week?
> Careful, Erik. the message that you're giving is anti-Windows.
Ha! Now you got him.
> I'm forwarding your message to my boss, as he find your rantings very
> entertaining. I wish I did. The message you're giving is that Lisp and
> Windows don't mix, while I'm asking what may be done to make them a
> _better_ mix. Which of us is being more constructive?
Erik, of course.
Not that I would attempt to defend his tactlessness (to put it mildly),
but he has been very clear in what you should do to make Lisp support
DLL-s (or whatever fancy thing you want to have) -- write wrapper
functions. If you are uncapable of doing it, pay others to do it.
But don't expect others to do it *for free* because you don't feel
like doing it.
That is the point of Erik's article. Feel free to forward this
message to your boss, too.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Idle RAM is the Devil's playground.
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> Not that I would attempt to defend his tactlessness (to put it mildly),
> but he has been very clear in what you should do to make Lisp support
> DLL-s (or whatever fancy thing you want to have) -- write wrapper
> functions. If you are uncapable of doing it, pay others to do it.
> But don't expect others to do it *for free* because you don't feel
> like doing it.
Wrapper functions? Do you know what a DLL is? One EXE cannot link to
another EXE. IPC techniques like pipes and sockets can pass data
between an EXE and a DLL that acts as its "front end", for other EXEs
to link to.
I think you can see why this would not be acceptable. It would _work_,
sure, but it's very ugly and there's a high performance cost.
> That is the point of Erik's article. Feel free to forward this
> message to your boss, too.
With respect, Erik didn't make that very clear. It looked more like a
direct attack on Windows. Consider this bit of Erik's post:
> I would say that those who depend on Microsoft software are like those who
> invested in the Albanian pyramids. they are being defrauded and have been
> since they acquired their first PC with some Microshit pre-installed. they
> will find out, just like the Albanians that had already lost their savings
> by the time they found out.
I repeat: this belongs in comp.os.ms-indows.nt.advocacy. It has
nothing to do with the issue of how well implementations of a
particular programming language supports a particular OS.
Perhaps Erik could clarify his position. Is he against Windows,
against Lisp implementations for Windows, or only against stronger
support in any Lisp implementations for Windows? It's hard to tell
when he's ranting about how terrible Windows is, as that isn't the
issue. People will develop software for Windows regardless of what
Erik thinks of it, and some are doing it in Lisp. There are others who
would like to use Lisp, but find that the Lisps currently available
for don't do what they need, like create DLLs.
If you were simply to say that Windows features like DLLs shouldn't
matter to Lisp programmers, that would be different. I'm simply
suggesting that some Lisp programmers will appreciate such support,
and that DylanWorks is evidence of that. (I'm agreeing with Kent
Pitman about the value of DLLs and Dylan being a Lisp.) Feel free to
disagree, as we can then have a debate, but abuse gets us nowhere.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
> With a mighty <···············@jagor.srce.hr>,
> ·······@srce.hr uttered these wise words...
>
> > Not that I would attempt to defend his tactlessness (to put it mildly),
> > but he has been very clear in what you should do to make Lisp support
> > DLL-s (or whatever fancy thing you want to have) -- write wrapper
> > functions. If you are uncapable of doing it, pay others to do it.
> > But don't expect others to do it *for free* because you don't feel
> > like doing it.
>
> Wrapper functions? Do you know what a DLL is?
Wrapper functions towards Lisp, written in C. Yes, I know what a DLL
is, but I don't want to know the defailts.
> > That is the point of Erik's article. Feel free to forward this
> > message to your boss, too.
>
> With respect, Erik didn't make that very clear.
Yes, he did. You chose to disregard his point, like you are choosing
to disregard mine.
> I repeat: this belongs in comp.os.ms-indows.nt.advocacy.
I don't really care where you think it belongs.
> If you were simply to say that Windows features like DLLs shouldn't
> matter to Lisp programmers, that would be different.
I didn't say that.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Oh lord won't you buy me a color TV...
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
> With a mighty <···············@jagor.srce.hr>,
> ·······@srce.hr uttered these wise words...
>
> > Not that I would attempt to defend his tactlessness (to put it mildly),
> > but he has been very clear in what you should do to make Lisp support
> > DLL-s (or whatever fancy thing you want to have) -- write wrapper
> > functions. If you are uncapable of doing it, pay others to do it.
> > But don't expect others to do it *for free* because you don't feel
> > like doing it.
>
> Wrapper functions? Do you know what a DLL is?
Wrapper functions towards Lisp, written in C. Yes, I know what a DLL
is.
> > That is the point of Erik's article. Feel free to forward this
> > message to your boss, too.
>
> With respect, Erik didn't make that very clear.
Yes, he did. You chose to disregard his point, like you are choosing
to disregard mine.
> I repeat: this belongs in comp.os.ms-indows.nt.advocacy.
I don't really care where you think it belongs.
> If you were simply to say that Windows features like DLLs shouldn't
> matter to Lisp programmers, that would be different.
I didn't say that.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Oh lord won't you buy me a color TV...
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> Wrapper functions towards Lisp, written in C. Yes, I know what a DLL
> is.
That still doesn't explain how you disguise an EXE as a DLL. Perhaps
this is a very poorly documented technique, as I don't recall ever
seeing an example of it, or even a reference to it.
> Yes, he did. You chose to disregard his point, like you are choosing
> to disregard mine.
No, I'm asking for an explanation. A reference to a book that
describes how an EXE may be disguised as a DLL will be enough.
I'v never heard of such a thing being done, altho I can't say that it
_can't_ be done. So I'd appreciate a book reference.
As for using such a technique to create an OLE server, for example...
Are you seriously suggesting that Windows programmers should do this?
No, I think I'll just wait for DylanWorks. I'd recommend the same
action to other Windows programmers wishing to use Lisp.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
> No, I'm asking for an explanation.
That's the same thing over again. You are not going to get those
explanations. Go read the books and write the code, if you need it.
Or pay someone else to do it.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Silence!" cries Freydag. "I did not call thee in for a consultation!"
"They are my innards! I will not have them misread by a poseur!"
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> That's the same thing over again. You are not going to get those
> explanations. Go read the books and write the code, if you need it.
Are you saying that it can be done, then? Have you done it? Why have
Harlequin or Franz not done it, if it's so simple?
> Or pay someone else to do it.
Very helpful. Is that how you answer questions about Lisp? For all I
know, you're just dismissing this as a "Windows problem", and you
can't be bothered to deal with it. If this is not the case, could you
please give a reply that suggests otherwise? A book ref will do, as I
can then go and read it.
I'll make it clear for you. Windows people make a big distinction
between an EXE and a DLL. Perhaps this distinction is a forced one,
but it exists. There are development tools that make the distinction,
and which complain if you give them the wrong type of module. Also,
when you load a module, it knows what type of module it is, and a DLL
does very different things to an EXE. The distinction may be forced,
but when you can't control where the event loop goes, or the way in
which the module is initialised, the way in which you can use that
module become somewhat limited.
Now, if a development tool like a Lisp compiler can only produce one
type of module, can you not see why that will be a problem? Convince
me that this thing can be done, and I'll accept what you say, but so
far you've done nothing but say "I don't care - it's your problem."
Do you know how most Windows people will "fix" this problem? They'll
avoid using Lisp. On the other hand, you too could be "fixing" this
problem by avoiding it. I.e. avoiding the issue of putting Lisp code
into a DLL, and anything else that you can't currently make Lisp do.
BTW, I _am_ paying someone else to fix this. I've paid for a Lisp, and
I've asked the vendor if they can address this issue. I also have
Amzi! Prolog, which uses a DLL to run Prolog code, and I have access
to VB, which can create DLLs.
When DylanWorks becomes available, I'll pay for that, too. Harlequin
use the phrase "DLL interoperability and library generation" on this
page: <URL:http://www.harlequin.com/full/products/sp/dylan.html>.
Meanwhile, could you please tell me how I turn a WinMain function in
somebody else's code into a LibMain function? Do you have any idea
what I'm talking about?
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
> > That's the same thing over again. You are not going to get those
> > explanations. Go read the books and write the code, if you need it.
>
> Are you saying that it can be done, then?
I am saying that you are unwilling to make sure it is done. I do not
need those features -- you do.
> > Or pay someone else to do it.
>
> Very helpful. Is that how you answer questions about Lisp?
No. That is how I answer this particular question of yours, for the
reasons clearly stated before.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
You'll notice that perl is not itself written in Perl.
-- The Perl FAQ
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> > Are you saying that it can be done, then?
>
> I am saying that you are unwilling to make sure it is done. I do not
> need those features -- you do.
>
> > > Or pay someone else to do it.
> >
> > Very helpful. Is that how you answer questions about Lisp?
>
> No. That is how I answer this particular question of yours, for the
> reasons clearly stated before.
Thanks for ignoring all the technical issues. You're not even trying
to be helpful. You're just avoiding the issue, which you seem unable
to discuss.
How do I get the source code for a Lisp? I don't expect a vendor to
just hand it over, and you'd be very naive to do so.
So, in case you missed it the first time (apparently you did), here it
is again:
I'll make it clear for you. Windows people make a big distinction
between an EXE and a DLL. Perhaps this distinction is a forced one,
but it exists. There are development tools that make the distinction,
and which complain if you give them the wrong type of module. Also,
when you load a module, it knows what type of module it is, and a DLL
does very different things to an EXE. The distinction may be forced,
but when you can't control where the event loop goes, or the way in
which the module is initialised, the way in which you can use that
module become somewhat limited.
Now, if a development tool like a Lisp compiler can only produce one
type of module, can you not see why that will be a problem? Convince
me that this thing can be done, and I'll accept what you say, but so
far you've done nothing but say "I don't care - it's your problem."
Do you know how most Windows people will "fix" this problem? They'll
avoid using Lisp. On the other hand, you too could be "fixing" this
problem by avoiding it. I.e. avoiding the issue of putting Lisp code
into a DLL, and anything else that you can't currently make Lisp do.
BTW, I _am_ paying someone else to fix this. I've paid for a Lisp, and
I've asked the vendor if they can address this issue. I also have
Amzi! Prolog, which uses a DLL to run Prolog code, and I have access
to VB, which can create DLLs.
When DylanWorks becomes available, I'll pay for that, too. Harlequin
use the phrase "DLL interoperability and library generation" on this
page: <URL:http://www.harlequin.com/full/products/sp/dylan.html>.
Meanwhile, could you please tell me how I turn a WinMain function in
somebody else's code into a LibMain function? Do you have any idea
what I'm talking about?
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
> Thanks for ignoring all the technical issues. You're not even trying
> to be helpful. You're just avoiding the issue, which you seem unable
> to discuss.
No. The technical issues you are trying to push are totally
irrelevant in this discussion. See my other posts for an explanation
why. Unlike you, I will not repeat them here.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
* Q: What is an experienced Emacs user?
* A: A person who wishes that the terminal had pedals.
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
> Thanks for ignoring all the technical issues. You're not even trying
> to be helpful. You're just avoiding the issue, which you seem unable
> to discuss.
No. The technical issues you are trying to push are totally
irrelevant in this discussion. See my other posts for an explanation
why. Unlike you, I will not repeat it here.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
* Q: What is an experienced Emacs user?
* A: A person who wishes that the terminal had pedals.
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> No. The technical issues you are trying to push are totally
> irrelevant in this discussion. See my other posts for an explanation
> why. Unlike you, I will not repeat it here.
OLE is irrelevant? Try telling that to Franz and Harlequin.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
Will write Lisp code for food
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
> > No. The technical issues you are trying to push are totally
> > irrelevant in this discussion. See my other posts for an explanation
> > why. Unlike you, I will not repeat it here.
>
> OLE is irrelevant?
That's not what I said, and you know it.
Why don't you just add me to your "bozo" filter, to spare us comments
like the one quoted above? Maybe I should lend some briskness from
Erik in order to earn that distinction.
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Oh lord won't you buy me a color TV...
With a mighty <···············@jagor.srce.hr>,
·······@srce.hr uttered these wise words...
> ···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
>
> > > No. The technical issues you are trying to push are totally
> > > irrelevant in this discussion. See my other posts for an explanation
> > > why. Unlike you, I will not repeat it here.
> >
> > OLE is irrelevant?
>
> That's not what I said, and you know it.
Which technical issues do you think that I'm refering to, if not OLE?
Perhaps I should say COM?
I hope that the discussion could be a little broader than OLE/COM/DLL
support, but it's a good place to begin. If you think that there are
some other technical issues being disussed here, please let me know,
as I haven't noticed.
There are, however, one or two _political_ issues which some people
appear unable to avoid.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
Will write Lisp code for food
In article <·························@news.demon.co.uk>,
···@gubbishwildcard.demon.co.uk (Martin Rodgers) wrote:
| With a mighty <···············@jagor.srce.hr>,
| ·······@srce.hr uttered these wise words...
|
| > That's the same thing over again. You are not going to get those
| > explanations. Go read the books and write the code, if you need it.
|
| Are you saying that it can be done, then? Have you done it? Why have
| Harlequin or Franz not done it, if it's so simple?
There's this problem here that Martin is stuck trying to do something
SPECIFIC, and that Hrvoje (am I getting this right?) is pointing out that
IN GENERAL, these problems are "small matters of programming."
Now, I don't know Windows from a hole in the ground, so I can't help. This
is why I, personally, hope that some Lisp company gets their act together
enough to generate DLLs instead of EXEs or whatever.
Good luck, Martin. It's good that someone is trying to be a pioneer. Don't
mind the arrows in your back -- they're high in fiber.
bc
With a mighty <···················@17.127.19.193>,
··@wetware.com uttered these wise words...
> Now, I don't know Windows from a hole in the ground, so I can't help. This
> is why I, personally, hope that some Lisp company gets their act together
> enough to generate DLLs instead of EXEs or whatever.
I'm sure they will, even if it's only DylanWorks. Apparently, ILOG
Talk could do it, but the ILOG website seems no longer to have a page
for it.
> Good luck, Martin. It's good that someone is trying to be a pioneer. Don't
> mind the arrows in your back -- they're high in fiber.
Pioneer? Only in the sense that I'm looking for a Lisp that can
support a very basic feature of Windows. It appears that some Lisp
people are rather hostile to this platform, and are unwilling to
discuss the _technical_ issues. The political issues should be
irrelevant. The Lisp vendors I've asked about this have replied to me
in a much more civilised manner, and I appreciate that.
I believe that I'm just being realistic. Perhaps if I were being
truely realistic, I might listen to the people who tell me to use
something other than Lisp, instead of looking for ways to convince
them that Lisp can solve their problems.
Thanks for your support. It's appreciated.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
* Martin Rodgers
| It appears that some Lisp people are rather hostile to this platform, and
| are unwilling to discuss the _technical_ issues.
I see. you actually think you discuss technical issues. that's pretty
amazing, considering that you don't include anything constructively
technical in any of your messages at all.
tell you what, Martin, if you had discussed technical issues, this thread
would have run to its completion in February 1996, and you would have the
ability to create DLLs in a Lisp you could afford to buy. the fact is,
however, that _you_ don't know enough about creating DLLs to help anybody
who could have done it. (IF you had known, you would have shared of this
knowledge to help fulfill your actual wishes, instead of whining for month
upon month that you don't get what you want. if you actually DO know how
to create DLLs, but keep going with your whining, you're more destructive
than I thought possible, so in the interest of being generous, I disregard
that possibility.)
| The political issues should be irrelevant. The Lisp vendors I've asked
| about this have replied to me in a much more civilised manner, and I
| appreciate that.
hm. you know what? if you call a company with a really stupid question or
being incredibly annoying, whoever answers can reply to you in a civilized
manner because they can share the experience with their colleagues as soon
as they hang up. this is one of the great benefits of having large rooms
of support people answering phones. this is why going out to lunch was
invented. it's very important to relieve stress, and having to deal with
people like you sure is stressful. if I were to answer a phone call from
you, I would be civilized to your face, too. if I worked for a Lisp
vendor, I would, however, insist that you help me solve the problem in a
constructive way, I would probably request a purchase order for the product
whenever it was finished, and I would probably also ask for funding to get
the job done in a timely fashion if you were in a hurry. _then_ it would
be a professional relationship between me and you, and you would be paying
me to be civilized to you on the phone, too. also, it doesn't take much to
be civilized to somebody on the phone if no commitments are made, no plans
are altered, no costs incurred (except the wasted time of the one person
answering the phone and those he tells afterwards). what _does_ take real
effort and goodwill is to be generous and civilized to people who make
destructive noises about Lisp vs the "real world" in a crowd of thousands.
your goodwill account is seriously overdrawn, Martin, and that's why I get
seriously hostile to you when you don't quit being annoying. you could
rectify your goodwill account by publishing _technical_ details necessary
for somebody to, like, change a WinMain to a LibMain function instead of
being an annoying asshole by asking others to "prove" to you they know some
idiotic arcana of Windows. consider this: if you asked somebody on the
phone to prove the same to you the way you do it here, they would hang up
and refuse to take more calls from you, IF they were civilized. if they
were not civilized, or the civilized veneer cracked, I sure wouldn't want
to be you.
| I believe that I'm just being realistic. Perhaps if I were being truely
| realistic, I might listen to the people who tell me to use something
| other than Lisp, instead of looking for ways to convince them that Lisp
| can solve their problems.
let's see. you would like us to infer that you are using Lisp, not
something other than Lisp, but Lisp cannot be used in your world, because
the DLL is the sine qua non of software development and no Lisp can build
DLLs. this contradiction must mean that you are _in_fact_ using something
other than Lisp, and it is obviously impossible successfully to convince
anybody that Lisp can solve their problems when Lisp can't solve their
problems because Lisp lacks the sine qua non. this means that all the
evidence presented can only suggest that Martin Rodgers would _like_ people
to believe he uses Lisp and has a real problem that he desperately needs
solved, but what people who read his rants carefully _actually_ believe is
that Martin Rodgers does not know Lisp, does not use Lisp, does not intend
to use Lisp, and even if he wanted to and tried, his boss (who must have
_some_ brains even though he hired Martin, because he finds my articles
entertaining) would turn down his desire to buy a professional version of a
commercial Lisp that could create DLLs.
who do you think you're kidding?
why do you insist upon wasting other people's time so much?
more importantly, who do I waste my time with you? (the answer is obvious,
actually. when I got back to reading comp.lang.lisp after a few weeks of
absence, as much as 90% of the articles contained whining about Windows or
followups to whining about Windows. if this is what Windows does to
people, I have one more reason to avoid it. when I'm faced with a serious
irritant, I try to remove it -- be that Windows or Windows fanatics. I
don't know whether I have actually succeeded in removing Martin Rodgers'
incessant whining, but I _have_ removed the irritant as far as _I'm_
concerned. and I doubt that anybody else is reading this, anyway, so the
danger of having annoyed any third party in the process is slim.)
#\Erik
--
if DUI is "Driving Under the Influence"
then GUI must be "Graphics Under the Influence"
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
> With a mighty <···················@17.127.19.193>,
> ··@wetware.com uttered these wise words...
>
> > Now, I don't know Windows from a hole in the ground, so I can't help. This
> > is why I, personally, hope that some Lisp company gets their act together
> > enough to generate DLLs instead of EXEs or whatever.
>
> I'm sure they will, even if it's only DylanWorks. Apparently, ILOG
> Talk could do it, but the ILOG website seems no longer to have a page
> for it.
Correct, Ilog Talk generates both DLLs and EXEs, as well as
integrating automatically with C and C++ DLLs. It's not very hard to
generate DLLs once the proper language infrastructure is in place.
(Automatically generating FFI interfaces to C/C++ is hard, though.)
However, the fact is that the market for such a Lisp is not that big,
certainly not worth the investment that would be necessary to fully
support it, and Ilog is trying to be a big company (pretty
successfully), so we stopped selling it. The good news is that we are
likely to give it away instead, although with much reduced support.
-- Harley
-------------------------------------------------------------------
Harley Davis net: ·····@ilog.com
Ilog, Inc. tel: (415) 944-7130
1901 Landings Dr. fax: (415) 390-0946
Mountain View, CA, 94043 url: http://www.ilog.com/
With a mighty <··············@iloginc.ilog.com>,
·····@iloginc.ilog.com uttered these wise words...
> > I'm sure they will, even if it's only DylanWorks. Apparently, ILOG
> > Talk could do it, but the ILOG website seems no longer to have a page
> > for it.
>
> Correct, Ilog Talk generates both DLLs and EXEs, as well as
> integrating automatically with C and C++ DLLs. It's not very hard to
> generate DLLs once the proper language infrastructure is in place.
> (Automatically generating FFI interfaces to C/C++ is hard, though.)
Agreed. Could you please remind me of the price for ILOG Talk? It's
been a while since I last checked, and perhaps the price has changed.
Could you please tell me why the ILOG website seems no longer to have
a page for it ILOG Talk?
> However, the fact is that the market for such a Lisp is not that big,
> certainly not worth the investment that would be necessary to fully
> support it, and Ilog is trying to be a big company (pretty
> successfully), so we stopped selling it. The good news is that we are
> likely to give it away instead, although with much reduced support.
I'm please to hear that the price is dropping, altho I didn't expect
ILOG to give it away. Still, a free Lisp with reduced support (does
that mean a finite amount of support, or none at all?) may encourage a
few more people to try Lisp. I know I'll try ILOG Talk, if you're
giving it away, and I'll no doubt recommend it to others.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
Will write Lisp code for food
* Martin Rodgers -> Hrvoje Niksic
| Are you saying that it can be done, then? Have you done it? Why have
| Harlequin or Franz not done it, if it's so simple?
if it were that simple, even you could have done it, and no Lisp vendor
would need to waste time on it.
however, it is obviously non-trivial, but doable. this means it costs time
and money to do it. if nobody offers a vendor to buy the product (or
otherwise cover the costs), it could be a week's worth of coding to get it
done, and _still_ it would never happen. it's as simple as that.
| For all I know, you're just dismissing this as a "Windows problem", and
| you can't be bothered to deal with it.
look, Martin, it's obvious that you have some sort of inferiority complex
on behalf of Windows, but Windows in whatever incarnation or version or
build or whatever Microsoft ships it is _completely_irrelevant_ to this
discussion. this is _not_ a discussion about Windows, pro or con, it's an
attempt to make you understand that Windows is not by itself an argument
for anybody to do anything. (yeah, I know, the Windows world tends to
think that market share is the be-all-end-all argument, but people who
aren't into selling good old products in new wrappings just because some
fresh-out-of-school MBA aced the "retargeting the market" class will see
the _problems_ of addressing the Windows world, namely that you have to be
a big player to overcome the marketing threshold of the Windows market, you
have to prepare an organization to ship thousands of copies a day once you
hit the right marketing channels, and you have to have a gargantuan support
system to handle all the dimwits who buy the product and lack every
conceivable clue yet expect to get free help on the most trivial of issues.
sure, anybody can sell a small volume to the Windows market, but if you
don't ship at least a hundred thousand copies, at the ridiculously low
prices they are willing to buy, you're not going to be able to _afford_ to
stay in business. the real reason I don't want Lisp vendors to go into the
Windows market is that I want them to stay alive. substantial companies
have crashed and burned trying to sell niche products to the Windows
market. the Lisp world doesn't have the luxury of any expendable vendors.)
get your head out of Bill Gates' rear and start to realize the demons that
you invoke with your misguided propaganda against Lisp in the guise of
being in favor of Lisp-on-Windows are so mind-bogglingly costly for vendors
and developers that you are a direct threat to the very existence of Lisp
if anybody is stupid enough to listen to you. to be successful in the
Windows market, you _have_ to get very, very comfortable with Microsoft,
and Microsoft is a company that is known far and wide to eat it partners
alive and kill those who offend them. there are many documented cases of
Microsoft changing systems internals to screw their past partners, IBM in
particular. Microsoft is a _predator_, and Bill Gates doubly so.
Lisp has survived in the underbrush (niche markets) for many decades, and
will in all likelihood continue to survive for many more decades, but those
who venture into the open field _will_ fall prey to Microsoft's fraudulent
business practices until Microsoft itself rots and dies, which I predict
happens between the years 2005 and 2010.
unlike the Windows world of predators and prey ruled not by ethics but by
whoever runs faster, the _real_ world is not in their hurry. substantial
projects still need to be completed, vast amounts of information still need
to be computerized and made accessible to software that will need to run
for decades to come. the kinds of fools who are upset with EXE or DLL or
whatever this week's hottest TLA is, are of no consequence, because they
are willing to sacrifice their _information_ at the slightest hint from
Redmond that something new and improved is coming out. people who invest
in _information_, with a touch of longevity, simply don't use Microsoft
products, because Microsoft stands to earn billions of dollars every time
the idiots who used Microsoft for their important files need to upgrade to
stay abreast with all the others, and Microsoft can't allow they to use
their old files and their old software, because there would be no money in
that for Microsoft. if you get married to Microsoft, the life expectancy
of your information and your software investments drops precipitously.
for a programming language that has survived the coming and going of lots
of inferior languages, multiple dialects and standardization of itself, and
still has an active community of programmers, the short-term flirts with
the here-today-gone-tomorrow community of Microsoft is _not_ a value, and,
I maintain, _will_ kill it.
that's why Martin Rodgers (and, god forbid, more people like him) should
pay for the development of Windows-friendly Lisps, not sit back and demand
that Lisp vendors commit suicide so that they can produce one stinking DLL
and decide "nah, Lisp isn't for me, anyway". you yourself have claimed
that you're waiting for Dylan to meet your needs, Martin, so it is hardly
unfair or overly harsh to ask you to shut the fuck up about your Windows
shit and let people earn their living as best they can, _without_ the
enormous costs that sleeping with Microsoft will entail.
Microsoft _will_ die, and I give them a decade, but Lisp must _not_ go down
the drain with them or be sacrificed to keep Microsoft alive a few more
months. C++ is already slated to die with Microsoft's defeat, and Java
will take over for a while, until people discover that it would be neat
with some actual performance, after all. something new will come along to
kill Java, too, in a few years' time, when Microsoft has invalidated all
investment with a broken, incompatible, our-way-only JVM implementation
that changes faster than Microsoft stock changes hands.
puerile impatience is deadly unless you have parents that do the long-range
planning for you. the Microsoft market is parented solely by Bill Gates,
and he does _not_ plan for _your_ best interests. if he could kill Lisp,
he would, and _that's_ the reason Lisp vendors should not flirt with him.
he's made it abundantly clear already that he has _no_ soft spot for good
ideas or elegant design. it's time people understand that he is no good.
and like all predators that run out of prey, he'll starve to death, soon.
#\Erik
--
if DUI is "Driving Under the Influence"
then GUI must be "Graphics Under the Influence"
With a mighty <················@naggum.no>,
····@naggum.no uttered these wise words...
> puerile impatience is deadly unless you have parents that do the long-range
> planning for you. the Microsoft market is parented solely by Bill Gates,
> and he does _not_ plan for _your_ best interests. if he could kill Lisp,
> he would, and _that's_ the reason Lisp vendors should not flirt with him.
> he's made it abundantly clear already that he has _no_ soft spot for good
> ideas or elegant design. it's time people understand that he is no good.
> and like all predators that run out of prey, he'll starve to death, soon.
Ooh, lovely. Another flame.
So you're saying that I'm using the wrong OS? What should I be using,
then? Will you pay me to use it and write code for it?
I'll make it clear for you. Windows people make a big distinction
between an EXE and a DLL. Perhaps this distinction is a forced one,
but it exists. There are development tools that make the distinction,
and which complain if you give them the wrong type of module. Also,
when you load a module, it knows what type of module it is, and a DLL
does very different things to an EXE. The distinction may be forced,
but when you can't control where the event loop goes, or the way in
which the module is initialised, the way in which you can use that
module become somewhat limited.
So, could you please tell me how I turn a WinMain function in
somebody else's code into a LibMain function? Do you have any idea
what I'm talking about? Can you do more than attempt to divert this
thread into another subject? It's obviously one that you're good at
discussing, as you've done little here but rant about Bill Gates.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
* Martin Rodgers
| So you're saying that I'm using the wrong OS?
no, Martin, that is not what I'm saying. please try to understand your
native language for a change.
I'm actually saying that whatever OS Martin Rodgers is using (be it Windows
or some Unix or whatever) is utterly irrelevant for any public discussion
of anything whatsoever that has any bearing at all on anything outside of
his cubicle and his relationship with his colleagues. Martin Rodgers'
choice (or lack thereof) of OS is as insignificant to the future of Lisp as
the fact that my second 19" Sun M monitor burned the other day, and that
the spare I received from a friend also burned. yes, I used to run a
dedicated Emacs with Allegro Common Lisp on that display. of course, I'm
very sad about this loss, and I have to find a way to either use virtual
displays or crowd the Emacs I run Allegro in into the first display which
is full of status-displaying windows, ZenIRC, Gnus, etc, if I can't locate
another monitor that's still in good shape. should I quit using Lisp, now
that I have had a small setback? should I sit down and cry that the world
is harsh and uninhabitable? and are _you_ getting bored yet?
you see, Martin, the above irrelevant rant is the level on which you're
talking to us about Windows and DLLs, Martin. irrelevant technical details
from your immediate surroundings that have no trace of value to discuss
with anybody. who _cares_ what Martin Rodgers suffers through in his
working day? who _cares_ what other Windows victims suffer through in
their working day? who _cares_ how many gazillions of Windows victims
there are as long as there are enough of the _relevant_ people to keep the
Lisp vendors happy and growing?
now, of course it would be useful if one could program on a real computer
and deploy on the GAIDS-infected wastes, but hey, if somebody actually has
the money to put where their mouth is, it'll happen. as long as some
whining loser lost somewhere in Britain makes a lot of noise about it, but
refuses to buy it when it comes out (ooh, it's too expensive for my toy
budget!), refuses to pay for the development (oh, no, I didn't mean _I_
should help them), and effectively argues against people who do make a
living using Lisp in non-Windows environments and even against those who
make a living in the Windows world _without_ that magic DLL thingy (oh,
that's not the "real world"), _why_ should anyone do it?
and _if_ somebody does it, what will Martin Rodgers complain about next?
you see, Martin, you don't do anything constructive here at all, so I'm
loathe to have a vendor actually come up with a solution to your problem,
as you might accidentally stumble on some relevant issue to whine about if
you don't continue to whine that you can't use it, it's too expensive, it
has the wrong color, it has American spelling, or something like that.
| I'll make it clear for you. Windows people ...
I wonder how clear a message needs to be for you to get it, Martin. let's
try again with a single sentence:
"Windows people" DO NOT MATTER on the time scale where Lisp matters.
you seem to be utterly unable to handle anything but the most trivial of
technical details, unable to lift your gaze to anything having a time frame
of more than a slight elongation of the moment, and incapable of handling
the fact that Microsoft's reign will pass. you're just like the incredibly
annoying people who argue against building infrastructure because they
can't immediately use it themselves to go shopping groceries, and they need
a water melon that's soft, but not too soft, and ... you get the idea.
| So, could you please tell me how I turn a WinMain function in somebody
| else's code into a LibMain function?
(make-library-entry-point <function>)
| Do you have any idea what I'm talking about?
no. why the hell should I? you don't matter. Windows doesn't matter.
| Can you do more than attempt to divert this thread into another subject?
oh, like it's _you_ who understand the _real_ issue? I see. HAHAHAHA!!
| It's obviously one that you're good at discussing, as you've done little
| here but rant about Bill Gates.
you have already proved beyond any possible doubt that you don't get any
message but your own, but I regret that I have given you an opportunity to
think you have.
#\Erik
--
if DUI is "Driving Under the Influence"
then GUI must be "Graphics Under the Influence"
With a mighty <················@naggum.no>,
····@naggum.no uttered these wise words...
> * Martin Rodgers
> | So you're saying that I'm using the wrong OS?
>
> no, Martin, that is not what I'm saying. please try to understand your
> native language for a change.
Hehehe. That's a wonderfully cheap shot, Erik. English may be your
second language, and you might not understand it as well as Norwegian,
but I think you know exactly what this is about.
I think that you're trying to direct this thread away from the real
questions, like how come LWW and ACL/PC can't create a DLL?
Fortunately, Harlequin are fixing that with DylanWorks. They describe
of the features as "DLL interoperability and library generation"
See: <URL:http://www.harlequin.com/full/products/sp/dylan.html>.
> I'm actually saying that whatever OS Martin Rodgers is using (be it Windows
> or some Unix or whatever) is utterly irrelevant for any public discussion
> of anything whatsoever that has any bearing at all on anything outside of
> his cubicle and his relationship with his colleagues. Martin Rodgers'
> choice (or lack thereof) of OS is as insignificant to the future of Lisp as
> the fact that my second 19" Sun M monitor burned the other day, and that
> the spare I received from a friend also burned. yes, I used to run a
> dedicated Emacs with Allegro Common Lisp on that display. of course, I'm
> very sad about this loss, and I have to find a way to either use virtual
> displays or crowd the Emacs I run Allegro in into the first display which
> is full of status-displaying windows, ZenIRC, Gnus, etc, if I can't locate
> another monitor that's still in good shape. should I quit using Lisp, now
> that I have had a small setback? should I sit down and cry that the world
> is harsh and uninhabitable? and are _you_ getting bored yet?
Did I say that I was concerned about what _you_ think is important to
Lisp? You're welcome to question what _I_ think, but I'm merely
suggesting to you that DLLs are rather important to Windows
development. The strength of Lisp support for dynamic linking indeed
have little relevance to the future of Lisp, but I suggest that you
ask people like Kent Pitman and David Moon about that, not me.
Their opinions may be of more interest than either of ours.
> you see, Martin, the above irrelevant rant is the level on which you're
> talking to us about Windows and DLLs, Martin. irrelevant technical details
> from your immediate surroundings that have no trace of value to discuss
> with anybody. who _cares_ what Martin Rodgers suffers through in his
> working day? who _cares_ what other Windows victims suffer through in
> their working day? who _cares_ how many gazillions of Windows victims
> there are as long as there are enough of the _relevant_ people to keep the
> Lisp vendors happy and growing?
Who said that I'm suffering? I'm suggesting that _Lisp_ may be
suffering, due to the - perhaps justified, perhaps not - belief that
Lisp has poor support for Windows. You can dispite that, but you've
yet to do so.
Instead, you're trying to make this personal. Don't bother with the
insults, Erik, as I don't take any of this personally. I've seen you
flame to many people in the same way to believe that this could be
about me. I suspect that I'm saying some things that make you
uncomfortable, and that you're using these bully tactics simply to try
to make me shut up.
Why not simply address the issue directly? I'm not the only one asking
about the value of dynamic linking for Lisp. For example, in a recent
posting, Kent Pitman wrote:
> Because of the large amount of investment required to change Lisp
> in a way that compatibly runs old programs but still accomodates new
> programs, Lisp changes slowly. However, there does seem to be motion
> toward integrating Lisp through modern databases, object interfaces,
> and even DLLs. (Part of this depends on what you think counts as Lisp;
> I think Dylan is in the Lisp family, and represents a substantial step
> forward in terms of the incorporation of DLLs into Lisp.)
I find myself agreeing with this. Who are you questioning, Erik?
Perhaps if you weren't flaming anyone of lower rank than Kent Pitman
who dares to express what we could call "Lisp Revisionism", there
might be a few more of us discussing this, and in a more constructive
fashion.
As Kent himself said, part of this depends on what you think counts as
Lisp. If Lisp is only what you personally will use, and you insist on
flaming anyone who thinks that it should be just a tad different, then
you're nothing more than a bully. You've made disparaging comments
about Bill Gates, but I'll leave the question of whether or not he too
is a bully for an advocacy newsgroup.
This article is being crossposted to an appropriate newsgroup, BTW.
I'm sure you know this, as you keep removing it when you post. Are you
denying that your strong negative feelings toward Windows make this an
advocacy issue, or are you denying that you such feelings?
> "Windows people" DO NOT MATTER on the time scale where Lisp matters.
This is a highly contentious issue. Hence my assertion that your
making a point that belongs more in an advocacy newsgroup than in
comp.lang.lisp. Are you unable to discuss the use of Lisp and Windows
without making derogatory comments about Windows, and ignoring the
issues that also concern Lisp, however limited that may be in your
opinion? No doubt Lisp would suvive if nobody used it to write Windows
software, but isn't the case. Instead, we have a number of Lisp
vendors with Lisps for Windows. I suggest that you continue your
private watr against Lisp for Windows with Franz, Harlequin, Mark
Freeley and anyone else who has the audacity to grace Windows with a
Lisp implementation.
> you seem to be utterly unable to handle anything but the most trivial of
> technical details, unable to lift your gaze to anything having a time frame
> of more than a slight elongation of the moment, and incapable of handling
> the fact that Microsoft's reign will pass. you're just like the incredibly
> annoying people who argue against building infrastructure because they
> can't immediately use it themselves to go shopping groceries, and they need
> a water melon that's soft, but not too soft, and ... you get the idea.
On the contrary. I'm familiar with the way in which Windows modules
are initialised, tho I'm not sure that you are. Like it or not, but in
Windows, an EXE and a DLL work a little differently. I know this is
awkward, but perhaps that's historical baggage for you. It hangs
around for years, getting in the way. We still have to deal with it.
> | So, could you please tell me how I turn a WinMain function in somebody
> | else's code into a LibMain function?
>
> (make-library-entry-point <function>)
<ahem> I'm aware of that, and it doesn't address the issue. Are you
saying that the only option is and can only ever be an ugly kludge
involving a hand written DLL that runs and then dynamically links to
an EXE? I think that we can do much better than that, and it would be
of great help if a Lisp implementation could just create the DLL
itself.
Placing the runtime support code into a DLL instead of the image (or
the EXE, in the case of LWW) would also help, as the EXE or DLL could
then be much smaller. One of the reasons I like Gambit C so much is
that the support code is in a DLL. With some effort, it should also be
possible to get it to create a DLL. However, this is not "Lisp" as you
define it, as that could only be Common Lisp, and Gambit C is Scheme.
Still, you may see my point. It can be done, and a number of other
languages succeed in doing far more demanding things than this.
There's an APL that can save the workspace as an OLE object, and
Smalltalk/MT can create DLLs. So can VB!
Why not Lisp? Apart from your stock answer, which is to place the
entire burden on the Lisp programmer rather than the vendor. You may
not like Windows, but can you not see how Lisp may benefit from
gaining a few more programmers, by supporting the things that they
need from a language?
> no. why the hell should I? you don't matter. Windows doesn't matter.
<sigh> Don't tell me - tell Franz and Harlequin, and their customers.
Meanwhile, save your riligious anti-MS rantings for a newsgroup where
they may be relevant - like comp.os.ms-windows.advocacy.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
Martin Rodgers <···@gubbishwildcard.demon.co.uk> wrote:
] With a mighty <················@naggum.no>,
]
] So you're saying that I'm using the wrong OS? What should I be
Apparently.
] I'll make it clear for you. Windows people make a big distinction
] between an EXE and a DLL. [...]
That's sad. After all, what is a dynamically linked library if
not a library that is dynamically linked? And what is an
executable if not a library + loader?
] So, could you please tell me how I turn a WinMain function in
] somebody else's code into a LibMain function? Do you have any
] idea what I'm talking about? Can you do more than attempt to
] divert this thread into another subject? It's obviously one
] that you're good at discussing, as you've done little here but
] rant about Bill Gates.
What a goober! Ok, I'm jumping into this thread, but just
convert the lisp code into C with any number of high-quality
programs.
Lisp compilers and interpreters are some of the very best of
their kind, and many high-quality solutions exist. If the
appropriate tools do not exist for Microsoft Windows, instead of
reflecting poorly on Lisp it is a sad commentary on Windows.
(Personally, I prefer Scheme to Common Lisp .. who needs side
effects anyway?)
] <URL:http://www.wildcard.demon.co.uk/> You can never browse enough
--
thur Mail Address: ··········@vt.edu or ········@vt.edu
n r
a JAMax "When a true genius appears in the world, you may know him
h o w by this sign, that the dunces are all in confederacy
tan lle against him." --Jonathan Swift
From: Holger Schauer
Subject: Re: Lisp in the "real world"
Date:
Message-ID: <64pvt0bjn4.fsf@gmd.de>
>>"MR" == Martin Rodgers schrieb am Wed, 2 Jul 1997 08:00:53 +0100:
MR> With a mighty <················@naggum.no>, ····@naggum.no
MR> uttered these wise words...
MR> Ooh, lovely. Another flame.
The old Martin-Rodgers Windows-and-Lisp flame-war, huh ?
MR> So you're saying that I'm using the wrong OS? What should I be
MR> using, then? Will you pay me to use it and write code for it?
What he says is: if you need A and can't (or don't want) to write it
yourself, pay for it. If you don't want that either, try looking for
another possibility which might be to get a job that does not involve
that W-word. These are your three possibilities, whining in this
newsgroup to a lot of people (and thus wasting bandwith and people's
time) is of no help. If you want to convince someone (useful, I might
add), go and ask some vendor: we can't or don't want to write code for
free so that only you have some benefit from it (as you seem to be the
only one in this NG that is constantly longing for it). If you need it
(e.g. DLLs production from Lisp) so urgently, go and write it, go and
pay some professionals, etc. but please stop posting this stuff over
and over again.
This does not mean that I think DLLs for Lisps under Windows are
useless. In fact, I think that they are important. But discussing this
issue here instead of with <your favourite lisp-vendor here> does not
help anybody.
Holger
With a mighty <··············@gmd.de>,
··············@gmd.de uttered these wise words...
> This does not mean that I think DLLs for Lisps under Windows are
> useless. In fact, I think that they are important. But discussing this
> issue here instead of with <your favourite lisp-vendor here> does not
> help anybody.
I _have_ discussed it with a number of Lisp vendors. I was hoping to
also discuss it with a few Lisp programmers, but I guess that's not
possible. Apparently, no Lisp programmers should want to write code
for Windows. Well, there are probably a few Windows people who agree
(I know of a few of them).
Has the market decided? I don't know. Perhaps the Lisp vendors I've
queried have only been humouring me. Perhaps the Windows support that
Harlequin claim will be in DylanWorks is just vapourware or hype?
Their tether technology is something that neither VC++ nor VB have,
but if it works as Harlequin describe, then I can imagine hords or
Windows programmers _begging_ to use it.
Does the market even know what's possible? I don't know. Without any
public discussion, we only have the word of Lisp vendors. And perhaps
people like Erik Naggum? He may even be right (note that I've not
denied any of his anti-Windows anti-MS comments), in which case it may
be that most people have got it horribly wrong. Including a couple of
Lisp vendors! Good grief.
Life is too short. I've added Erik to my "bozo" filter. I'll miss his
more constructive posts, but I have no time for his negativity. Not
until somebody pays me to use something other than Windows, anyway.
I was hoping for a constructive discussion, but Erik is making that
impossible. In spite of enouraging email from people (thanks to all of
you, you know who you are), I have a Lisp compiler to write, so I'd
like to follow the advise of someone who disagrees with me, and spend
more time working on it.
Any offers of Lisp work will be gratefully received.
Followups adjusted.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
it's possible that some of the readers of comp.os.ms-windows.nt.advocay and
comp.lang.dylan might actually believe Martin Rodgers fraudulent summary of
this thread. this is a more accurate summary:
Martin Rodgers says he can't use Lisp. when questioned why, he conjures up
an amazing number of problems, which, when solved, one by one, are just
replaced by another from his list. Martin Rodgers has been going on like
this in comp.lang.lisp for at least a year (or maybe it only feels that
way), and his current complaint is that no Lisp vendor will _give_ him the
ability to create DLLs from Lisp, although all technical questions about
why this is a good idea, why it is needed, and what he would like to do
were it possible, go unanswered. Martin Rodgers has made it clear that he
would rather spend a year sitting on his sorry ass whining about how little
support he gets from Lisp vendors while he also whines how expensive Lisp
systems are, how his boss is never in a million years going to pay him to
write Lisp code, regardless of what the Lisp vendors do, and how we are all
so mean when we won't pat him on the back every day and sympathize with his
plight. you have to understand that he is paid to write C++ and Java, and
apparently hates it so much he has to share his frustrations on a daily
basis.
for some bizarre reason, Martin Rodgers thinks this is a topic worthy of
discussion in comp.os.ms-windows.nt.advocay, although he keeps posting to
comp.lang.lisp (for which I'm sure you guys are grateful), and that he's
actually trying to engage in technical discussion about Windows and Lisp.
however, technical discussions include facts, concrete problems, real code,
requests for ways to solve a problem, not a constant whining that some
unspecified problem can't be solved with some particular technique that he
would like to to believe he needs. in particular, technical discussions
have a specific goal, and when goal is reached, they end. Martin Rodgers
has (literally!) been repeating himself over and over again, not even
making any modifications to his assertion that DLL is a sine qua non for
Lisp to succeed on Windows, again without shred of evidence or ways to show
us poor Microsoft-deprived losers what he means. (oh, yeah, he also thinks
"Lisp in the `real world'" is an apt subject, clearly implying that the
millions of lines of Lisp in daily use are not worthy of being part of the
"real world".)
now, all of the people that he talks to have agreed with him that it would
be cool to have a full-fledged Lisp environment for Windows, it just is far
from clear (1) that there is a market -- in part because Martin Rodgers'
boss wouldn't let him use Lisp anyway, and he claims that's the rule, not
the exception, (2) that Lisp vendors should risk millions of dollars in
investments and maintenance costs to satisfy Martin Rodgers and _nobody_
else -- if there were any more who had his needs, one would think they
would have voiced their opinion by now, but no, _nothing_, (3) that Martin
Rodgers would ever stop complaining regardless of what toys he were given
to play with. in particular, it is obvious to anyone who has read his
laments that Martin Rodgers suffers not from lack of Lisp for Windows, but
for lack of a real shoulder to sob on when he gets home from the job he so
hates. he is so frustrated that he is completely unable to see that people
actually agree with him every now and then, he is utterly incapable of
appreciating that people would like to solve his problem, if they could
only get enough information from _him_ about what it is so they could at
least try to wrap their head around it. instead of being helpful to those
who could help him, Martin Rodgers goes on and on and on about he would
like others to prove to him that they can convert a WinMain function to a
LibMain function, flat out asserting that if we can't solve this puzzle, we
have no business discussing the business aspects of supporting a platform
that is known far and wide to be changing faster and more randomly than any
known tectonics could predict.
also, it might well be that there _are_ hard technical problems to solve
for a language that really likes to be master, and not slave, in its
relationship with "foreign functions". but we have never gotten to this
level of technical discussions, because Martin Rodgers _insists_ that
unless he gets his DLL solution Right Now!, we're not actually discussing
with him, we're mean and all that.
end summary.
* Martin Rodgers
| I _have_ discussed it with a number of Lisp vendors. I was hoping to
| also discuss it with a few Lisp programmers, but I guess that's not
| possible. Apparently, no Lisp programmers should want to write code
| for Windows. Well, there are probably a few Windows people who agree
| (I know of a few of them).
on last count, more than 20 Lisp programmers have agreed with Martin
Rodgers that it would be nice to use Lisp under Windows, but none of them
seem to be able to understand what Martin Rodgers would like to do in Lisp
that makes his soi disant technical problems so insurmountable. at least,
none of the seasoned Lisp programmers and real problem-solvers that inhabit
comp.lang.lisp, many of whom make a living out of programming in Lisp, or
at least solving problems with Lisp as a tool, have been able to argue with
Martin Rodgers on a technical level, or suggest what he could do to get
what he wants, which I take to mean that Martin Rodgers simply does not
communicate on a technical level to begin with.
| Has the market decided? I don't know. Perhaps the Lisp vendors I've
| queried have only been humouring me. Perhaps the Windows support that
| Harlequin claim will be in DylanWorks is just vapourware or hype? Their
| tether technology is something that neither VC++ nor VB have, but if it
| works as Harlequin describe, then I can imagine hords or Windows
| programmers _begging_ to use it.
this is typical of Martin Rodgers' whining. somehow, he thinks the market
(he also thinks "the market" is a physical entity with its own free will)
decides one thing when there is a staggering amount of evidence to the
contrary. _lots_ of people buy and use Lisp for Windows, _without_ the DLL
support he says is a sine qua non for Windows Development. _lots_ of
people are truly happy that they can do Graphical User Interfaces to their
heavy applications with, e.g., Allegro Common Lisp for Windows, yet they
don't have DLLs. I wrote an application myself that used sockets to
communicate with a Delphi process which in turn handles the user interface
and communication with MS Word via OLE, and as long as the performance
bottleneck on a 200MHz Pentium Pro with enough RAM is the user, I can't
imagine how one could say that this doesn't work unless I have DLLs.
the problem is that Martin Rodgers really is full of it, and that he spends
his time with negative hype against Lisp, against Lisp vendors (who don't
do what he wants), and against Lisp programmers who would rather discuss
Lisp than Martin Rodgers' inability to do what he wants.
| Does the market even know what's possible? I don't know. Without any
| public discussion, we only have the word of Lisp vendors. And perhaps
| people like Erik Naggum? He may even be right (note that I've not denied
| any of his anti-Windows anti-MS comments), in which case it may be that
| most people have got it horribly wrong. Including a couple of Lisp
| vendors! Good grief.
people like me solve problems, then go on to the next problem. people like
me grow progressively more intolerant of people who _don't_ want to solve
problems, but who want to _create_ problems, and who spend all their time
whining that people don't help them, especially if there is a _demand_ that
we help them for free, that we invest time and money so they can come up
with another reason why they aren't able to do their work.
| Life is too short. I've added Erik to my "bozo" filter.
oh, goody. then he won't see this and repeat himself for the umpteenth
time, and he won't notice that I have answered his infelicitous remarks
about me to a newsgroups wholly unrelated to the discussion just because he
wants to hurt my name. anybody that has seen Martin Rodgers in action for
a while knows that he's _lying_ all the time, that he _must_ lie to keep up
his "I can't use Lisp because of (pop circular-complaint-list)" -- _lots_
or people throughout the civilized world are able to use Lisp in just the
ways he _implies_ (but never actually tells) he would use it. if I'm added
to his "bozo" filter, I will also be relieved of more of his libelous
claims about me, because he no longer reads what I write. or so I hope,
although I expect Martin Rodgers to go on for months repeating that I'm so
mean to him when I don't give him a dime, like I don't give any other pushy
pan-handlers anything, either.
| I'll miss his more constructive posts, but I have no time for his
| negativity.
perhaps this means comp.lang.lisp will get rid of his? perhaps this means
that Martin Rodgers will now move on to comp.os.ms-windows.nt.advocay and
annoy you guys, instead?
| I was hoping for a constructive discussion, but Erik is making that
| impossible.
funny how everything bad in this world is never Martin Rodgers' fault.
always somebody else, always something to whine about. if a new Bible were
to be written in the next millennium, they'd think Job was too much of an
optimist and call in Martin Rodgers to fill the pages with sob stories.
| In spite of enouraging email from people (thanks to all of you, you know
| who you are), I have a Lisp compiler to write, so I'd like to follow the
| advise of someone who disagrees with me, and spend more time working on
| it.
this is probably news to the comp.os.ms-windows.nt.advocay crowd, but Lisp
is a language that is easy to learn, comparatively easy to master (compared
to other languages), but real hard to become a expert in, and incredibly
hard to implement correctly. it's common for people who don't really
understand Lisp to want to write their own Lisp implementation instead of
going on to become masters of the language and perhaps experts. no other
language inspires so many people to write compilers and interpreters than
Lisp, and for many it's actually a very fruitful learning experience.
| Any offers of Lisp work will be gratefully received.
I'd like to related how I started with Lisp. back in 1978 (I think, my
memory is hazy) I discovered The Little Lisper, which took my brain with
storm, and left permanent inspiration its wake. over the years, I have
seen Lisps on various computers I have worked on, but I could never find a
way to use Lisp for real. (this is a common problem, I later found out,
with beginners in Lisp, because Lisp brings with it a new mind-set compared
to the batch-compiled languages, and making an "application" is a different
kind of task with Lisp than with other languages.) in 1994, after I had
had a nasty brush with a monster called C++, I decided it was time to find
something better to do, and I spent three years studying Lisp in various
shapes and forms, I worked extensively on GNU Emacs, both Lisp code and the
C substrate, and I worked my way up to enlightenment. in the process, I
grew more cynical of the working environments we're told are so great, like
Unix and Windows (and NT really is no better, if you need this fuel to
flame me :), and would like to rediscover some of the old systems from
which Unix and Windows have drawn their overly simplistic design. this has
led me through a _lot_ of background material, a _lot_ of stuff that I
didn't know I needed to understand to appreciate where Lisp is today. I'm
not saying that this is necessary, it's just that if you come to Unix from
a Lisp Machine, you will need a fair amount of time to accomodate yourself,
and likewise from Unix to Windows. I tried to rediscover the Lisp Machine
under Unix, through the Emacs window, and it's clear that my 15 years with
Unix have actually evidenced quite slow progression. it has also humbled
me to the task of learning a new system _fully_, a task which I see from
friends and colleagues who try to do it for the Microsoft world is much,
much bigger there than Unix ever was. (in consequence, Microsoft experts
are much less expert in their field than Lisp or Unix experts are, but I
don't really need _you_ to hate me too, so I won't elaborate on that.)
it's the progress that I _don't_ see with Martin Rodgers that bothers me.
my own articles of a year ago were still a bit naive. I've done my first,
moderately large, incredibly complex, Lisp application since then, and
there's no substitute for a hard nut to crack to learn nut-cracking. (am I
sounding like Ross Perot, yet?) Martin Rodgers has stayed put, whining,
when I have seen not only myself, but a dozen other people, too, show
impressive progress in their appreciation and use of Lisp. I'd like more
people to know how fast good programmers get up to speed in Lisp, but it's
as if comp.lang.lisp is saturated with this whining loser that can't use
Lisp and has made no progress for a year. that's Martin Rodgers, and this
is why I don't treat him very nicely. he's the only one I have any reason
at all not to treat nicely in comp.lang.lisp, which has been a most
impressively technical and helpful newsgroup, apart from Martin Rodgers.
| Followups adjusted.
yeah. good idea. I removed the Lisp, Scheme, and Dylan groups.
you NT advocates deal with Martin Rodgers, please. he's one of your
babies, after all.
#\Erik
--
if DUI is "Driving Under the Influence"
then GUI must be "Graphics Under the Influence"
In article <·························@news.demon.co.uk>,
···@gubbishwildcard.demon.co.uk (Martin Rodgers) wrote:
> I _have_ discussed it with a number of Lisp vendors. I was hoping to
> also discuss it with a few Lisp programmers, but I guess that's not
> possible. Apparently, no Lisp programmers should want to write code
> for Windows. Well, there are probably a few Windows people who agree
> (I know of a few of them).
I think a Lisp with strong support for Windows would be welcome.
Most of the desktop systems are running Windows and often servers
are running Windows NT. The market for PC software is ***huge***.
A lot of current PCs have more
than enough memory and computing power. So what is
the problem? I don't know.
How much code is there available on the Net that is Lisp
and Windows specific? I haven't seen much - this
may be my selective view, but for Macs and even Symbolics
more platform specific code (graphics, TCP/IP, multimedia,
IPC, ...) seems to be available. And there
would be a lot of Windows 95/NT stuff to support.
I asked one support person from some vendor whether they
have a mailing list for their customers (not
a support mailing address from the vendor). Answer:
It could be that there is some newsgroup where I
would find other users. - Sigh. I knew that before.
It even seems currently not possible to find a multithreaded
Common Lisp able to run CL-HTTP on a PC under Windows!!!
What a bitter joke. CL-HTTP runs everywhere but not under
Windows.
Sometimes it seems Lisp on the PC is more of a *hobby* of some vendors. ;-)
Until this will change, Lisp on the PC is *not* a viable option
for me.
--
http://www.lavielle.com/~joswig/
Rainer Joswig <······@lavielle.com> wrote in article
<·································@news.lavielle.com>...
>
> I think a Lisp with strong support for Windows would be welcome.
> Most of the desktop systems are running Windows and often servers
> are running Windows NT. The market for PC software is ***huge***.
> A lot of current PCs have more
> than enough memory and computing power. So what is
> the problem? I don't know.
>
I have a pretty good notion of what the problem is-- this likely because the
Lisp vendors realize that to have a truly Windows-centric Lisp, rather than
just a Lisp that runs under Windows, they have to go through _major_ changes.
Also, to be truly Windows-centric, they would probably need to leverage the MS
C++ framework, the same way that Pythonwin does.
Another reason is probably cultural mismatch. Certainly, I've seen enough here
to convince me that non-Windows programmers' perspectives of Windows are no
more enlightened than non-UNIX programmers' perspectives of UNIX. It's hard to
see solutions in an environment you regard with a jaundiced eye.
Beyond that, perhaps the Lisp vendors are too influenced by the LispM heritage
to buy into the notion of making Lisp a good Windows denizen. <shrug>
FWIW, that's all OK in my book, because I think their tunnel vision will end up
being someone else's opportunity. <g>
Bill House
--
Note: my e-mail address has been altered to
confuse the enemy.
···@gubbishwildcard.demon.co.uk (Martin Rodgers) writes:
> I'll make it clear for you. Windows people make a big distinction
> (...)
Now, is it my imagination, or have I heard this somewhere before?
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Contrary to popular belief, Unix is user friendly.
It just happens to be selective about who it makes friends with.
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* Martin Rodgers -> Hrvoje Niksic
>| Are you saying that it can be done, then? Have you done it? Why have
>| Harlequin or Franz not done it, if it's so simple?
>
>if it were that simple, even you could have done it, and no Lisp vendor
>would need to waste time on it.
>
Look, Martin is a guy with a problem. He'd like to use Lisp, but
has great difficulties with it. Nor is he alone, except that he's
still struggling to use Lisp in a hostile environment.
>however, it is obviously non-trivial, but doable. this means it costs time
>and money to do it. if nobody offers a vendor to buy the product (or
>otherwise cover the costs), it could be a week's worth of coding to get it
>done, and _still_ it would never happen. it's as simple as that.
>
Yes, but why bother to put out a commercial Windows CL system without
it? Further, what does it imply about the future of Lisp?
>| For all I know, you're just dismissing this as a "Windows problem", and
>| you can't be bothered to deal with it.
>
>look, Martin, it's obvious that you have some sort of inferiority complex
>on behalf of Windows, but Windows in whatever incarnation or version or
>build or whatever Microsoft ships it is _completely_irrelevant_ to this
>discussion. this is _not_ a discussion about Windows, pro or con, it's an
>attempt to make you understand that Windows is not by itself an argument
>for anybody to do anything.
Erik, in the past you've let us know that you use Lisp, and that you
can make a living doing only Lisp. This is good. The fact is that
there are a whole lot of Microsoft Windows installations out there.
Now, you think this is a mistake. I think it's a mistake. I'm also
typing this in on a Windows machine because I work in a place that
uses it (they've made many other mistakes, as well).
In order to keep Lisp live, it behooves us to see that people use it.
It therefore behooves us to see that people *can* use it. If you care
only about yourself, Erik, that's your business. I'd like to see my
son grow up in a world where he can program in Lisp, or something better
if something better is invented.
>(yeah, I know, the Windows world tends to
>think that market share is the be-all-end-all argument, but people who
>aren't into selling good old products in new wrappings just because some
>fresh-out-of-school MBA aced the "retargeting the market" class will see
>the _problems_ of addressing the Windows world, namely that you have to be
>a big player to overcome the marketing threshold of the Windows market, you
>have to prepare an organization to ship thousands of copies a day once you
>hit the right marketing channels, and you have to have a gargantuan support
>system to handle all the dimwits who buy the product and lack every
>conceivable clue yet expect to get free help on the most trivial of issues.
>sure, anybody can sell a small volume to the Windows market, but if you
>don't ship at least a hundred thousand copies, at the ridiculously low
>prices they are willing to buy, you're not going to be able to _afford_ to
>stay in business. the real reason I don't want Lisp vendors to go into the
>Windows market is that I want them to stay alive. substantial companies
>have crashed and burned trying to sell niche products to the Windows
>market. the Lisp world doesn't have the luxury of any expendable vendors.)
>
The other side of this is that there's a tremendous amount of software
written for Windows, since that's where the big bucks are. There are
a tremendous amount of perfectly nice programmers who have to write
software for Windows. Have you no sympathy for them? Individually,
some of them could drop out of Windows programming, perhaps at a pay cut.
(Some have financial obligations that make pay cuts impractical.)
To keep your corner of the Universe comfortable, you'd tell them all to
keep on using Visual C++ and MFC?
>get your head out of Bill Gates' rear and start to realize the demons that
>you invoke with your misguided propaganda against Lisp in the guise of
>being in favor of Lisp-on-Windows are so mind-bogglingly costly for vendors
>and developers that you are a direct threat to the very existence of Lisp
>if anybody is stupid enough to listen to you. to be successful in the
>Windows market, you _have_ to get very, very comfortable with Microsoft,
>and Microsoft is a company that is known far and wide to eat it partners
>alive and kill those who offend them. there are many documented cases of
>Microsoft changing systems internals to screw their past partners, IBM in
>particular. Microsoft is a _predator_, and Bill Gates doubly so.
>
Yeah, Microsoft is dangerous. They gained their current market share
before the Justice Department realized what was going on, and they've
been capitalizing on that ever since, but that doesn't mean companies
can't deal in the Windows world.
Besides, both Harlequin and Franz are already selling Common Lisps for
Windows. Why should they keep their products substandard?
>Lisp has survived in the underbrush (niche markets) for many decades, and
>will in all likelihood continue to survive for many more decades, but those
>who venture into the open field _will_ fall prey to Microsoft's fraudulent
>business practices until Microsoft itself rots and dies, which I predict
>happens between the years 2005 and 2010.
>
Lisp is in the open field! For pretty much all major platform, you can
get a good implementation of Common Lisp (free for some platforms).
This is the sort of thing that supports Franz and Harlequin and Digitool.
Martin simply wants a CL system for Windows that will go along with
industry standards, the same as any other non-Microsoft language system
for windows. There are several of them, and they aren't showing signs
of going out of business soon.
>unlike the Windows world of predators and prey ruled not by ethics but by
>whoever runs faster, the _real_ world is not in their hurry. substantial
>projects still need to be completed, vast amounts of information still need
>to be computerized and made accessible to software that will need to run
>for decades to come. the kinds of fools who are upset with EXE or DLL or
>whatever this week's hottest TLA is, are of no consequence, because they
>are willing to sacrifice their _information_ at the slightest hint from
>Redmond that something new and improved is coming out. people who invest
>
The other technique is to wait until other, non-Microsoft, vendors
commit to something. DLLs are not something new, they're here and
are supported by several vendors other than Microsoft. It's time that
Franz and Harlequin joined in, if they want to continue to sell in
the Windows environment.
>for a programming language that has survived the coming and going of lots
>of inferior languages, multiple dialects and standardization of itself, and
>still has an active community of programmers, the short-term flirts with
>the here-today-gone-tomorrow community of Microsoft is _not_ a value, and,
>I maintain, _will_ kill it.
>
Well, yes. Never be the first to jump onto a Microsoft bandwagon.
Let somebody else do it, to see if there's traps. However, it is possible
to deal in Windows software with reasonable safety, and there's a good
deal of money in it.
>that's why Martin Rodgers (and, god forbid, more people like him) should
>pay for the development of Windows-friendly Lisps, not sit back and demand
>that Lisp vendors commit suicide so that they can produce one stinking DLL
>and decide "nah, Lisp isn't for me, anyway". you yourself have claimed
>that you're waiting for Dylan to meet your needs, Martin, so it is hardly
>unfair or overly harsh to ask you to shut the fuck up about your Windows
>shit and let people earn their living as best they can, _without_ the
>enormous costs that sleeping with Microsoft will entail.
>
Um, Martin has clearly said that he will pay for a Common Lisp on Windows
that satisfies his needs. This is how the free market works, Erik.
If there are a lot of people like Martin, who want to use quality
tools and have reasons that seem good to them to work in Windows
(like, maybe, it pays), then it will pay Franz or Harlequin or both
to add DLL creation to their existing Windows products.
Have you ever called or written or emailed to a Lisp vendor and said
"Gee, it would be really neat if..."? If you were working on a commercial
Lisp that didn't handle tail recursion, would you write and call
and politely ask when they might add it, or would you think, "Gee,
would I want to fund the necessary programming to do tail recursion?
Maybe I'll just use DO rather than complain, even when tail recursion
would be cheaper."
The intemperate language I've seen in this thread has *not* come from
Martin. He has been civilized and mostly courteous, even when
exasperated. Now, I don't have any problems with intemperate language
being used to refer to Microsoft or Microsoft products, and I haven't
seen Martin object to that either. I do have a problem with intemperate
language being used against Martin. He has a need, and there are
products that almost address it. I don't have a problem with Erik's
view that it would be best if no professional touched Microsoft Windows,
in the hopes of killing Microsoft sooner, although I don't think it's
practical. I do have problems with Erik impugning professionals that
do, and who hope that others will help, or possibly just sympathise,
with them.
>Microsoft _will_ die, and I give them a decade, but Lisp must _not_ go down
>the drain with them or be sacrificed to keep Microsoft alive a few more
>months.
I'm not so sure Microsoft will die. It isn't even necessary; before
monopolizing the desktop OS market they were mostly harmless. If
we were to, say, see PowerPC machines running Apple's Rhapsody
stuff taking over desktops, Microsoft could continue to make software
and nobody would be the worse. (I'd also like to see the Java Virtual
Machine enhanced to make it easier to compile Common Lisp into.)
Note that, at some time, Intel is going to be unable to keep up
the x86 architecture. It already takes much more complexity to
keep a Pentium running almost as fast as a 604e, and the only thing
saving Intel's butt is economies of scale.
In the meantime, how do we want to see Lisp in the marketplace?
The one thing that's likely to kill Lisp is preventing people from
using it. IMHO, Lisp vendors in the Windows market should provide
what's necessary for Windows developers. They don't have to pioneer.
(Nobody should pioneer in that market. In many markets, pioneers
get arrows in the back. In the Windows market, it's machine-gun
bullets.) They do have to follow, albeit at a safe distance.
David Thornley
With a mighty <············@darla.visi.com>,
········@visi.com bravely poked his head over the parapet and risked
being shot at...
> The other technique is to wait until other, non-Microsoft, vendors
> commit to something. DLLs are not something new, they're here and
> are supported by several vendors other than Microsoft. It's time that
> Franz and Harlequin joined in, if they want to continue to sell in
> the Windows environment.
They're also more than just, as Erik put it, "this week's hottest
TLA". That's exactly like describing forking as the latest Unix fad!
Not only have DLLs been part of Windows for most if not all of its
(compared to Unix) short existance, but an ever increasing number of
technologies are being built on them - and not just by MS.
Remove DLLs from Windows and nothing would be left. Somewhat like
removing forking from a Unix without any threading. Oops, your OS has
no bones to support the flesh. While Unix may not depend so heavily on
shared libraries, no Windows program can run without using a DLL. The
entire Windows API is in DLLs. While Win32 doesn't depend on forking
(coz of threading), and Win16 doesn't even have threading, where would
Unix be without multitasking?
I'm only comparing Windows with Unix to show how these two systems
both have features without which they couldn't function. I'm ignoring
the forking vs threading issue, as that isn't relevant here. While
there are still crtical Unix programs that depend on forking, that OS
feature will be seen as important by Unix programmers. For Windows
programmers, there are also vital features. DLLs, for example.
It's regretable that Erik fails to appreciate this and flame those who
_do_. Well, his lack of appreciation of Windows could be excused if
not for the manner (flaming) with which he expresses himself on this
subject. He might have something useful to contribute, as he so often
does. Alas, when the issue concerns Windows, it's hard to tell.
Most Windows people I know think that Lisp is dead. If Erik is typical
of Lisp programmers (I hope not), then perhaps they're right. At
least, as far as Windows is concerned. I'm more optimistic, tho. I
also have an interest in Lisp, while most people I know do not. If I
didn't feel that CL and Scheme were useful to me, I'd just quit Lisp
(as Erik seems to define it, i.e. no DLLs) and instead use Dylan.
Frankly, I could do without Erik's negativity. Until 1992, when I
discovered comp.lang.lisp, I was alone. I knew no other Lisp
programmers. UseNet has put me in contact with many like-minded
individuals, but now it seems to be isolating me again.
While I once felt that Lisp could do anything, I found on UseNet that
people have a much more limited view of how and where Lisp may be
used, while paradoxically claiming that "Lisp can do anything".
> In the meantime, how do we want to see Lisp in the marketplace?
> The one thing that's likely to kill Lisp is preventing people from
> using it. IMHO, Lisp vendors in the Windows market should provide
> what's necessary for Windows developers. They don't have to pioneer.
> (Nobody should pioneer in that market. In many markets, pioneers
> get arrows in the back. In the Windows market, it's machine-gun
> bullets.) They do have to follow, albeit at a safe distance.
Wise words, for which I'm grateful. Perhaps I'm not so alone!
Many thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
I agree with Martin. C++ is a horrible language to develop Windows
apps in, but there are few alternatives (Basic?!?!?). I would spend
money on a Lisp development system that could parse and
produce all the crap you need to interface to existing code (like
C and C++ header files, MIDL files, TLB files, etc.) and produced DLL
's
as output. It would be especially good if CLOS objects could be compiled
into
``ActiveX'' components. I'd like to be able to produce deliverables
for my clients without having the fact that the code was written in
Lisp be any concern whatsoever to them.
Actually, given the way that Microsoft's DCOM works (late binding,
explicitly tagged arguments, reference count GC, structured
exception handling, etc.) it looks like they'll reinvent Lisp at some
point. Of course I'd rather not wait that long, and I'm sure it wouldn't
be pretty.
In article <············@newsie.cent.net> "Emergent Technologies Inc." <········@eval-apply.com> writes:
From: "Emergent Technologies Inc." <········@eval-apply.com>
Newsgroups: comp.lang.lisp,comp.lang.scheme
Date: Wed, 2 Jul 1997 15:35:11 -0400
Organization: CENTnet, Inc.
Lines: 21
X-Newsreader: Microsoft Outlook Express 4.71.0544.0
X-MimeOLE: Produced By Microsoft MimeOLE Engine V4.71.0544.0
Xref: agate comp.lang.lisp:29048 comp.lang.scheme:22097
...
Actually, given the way that Microsoft's DCOM works (late binding,
explicitly tagged arguments, reference count GC, structured
exception handling, etc.) it looks like they'll reinvent Lisp at some
point.
Has not this being clear since 1984? Most "new" programming language
reinvent some Lisp feature sooner or later.
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
Martin Rodgers <···@gubbishwildcard.demon.co.uk> wrote in article
<·························@news.demon.co.uk>...
>
>[snip]
>
> Most Windows people I know think that Lisp is dead. If Erik is typical
> of Lisp programmers (I hope not), then perhaps they're right.
>
I just had the misfortune to get temporarily assigned to a Win32/MFC project,
due to a staffing problem. As I brush up on my somewhat-rusty MFC, I have to
tell you that, after a couple of years of Lisp development, it's like flint
knives and stone axes. Nevertheless, there is no Lisp I know of that would fit
for this project, which requires the creation of many Windows-centric objects
like OCXes, DLLs, and interfacing with 3rd-party components implemented as
same. <sigh>
Another shock I am having to endure is the C++ tunnel vision of the MFC jocks
we do have on the project. So far, I can see no reason to do the main GUI in
MFC -- VB or Java would have been preferable and far more effective IMO, but
suggestions in that direction have met with enormous pushback. Oh well, once
you buy into a religion, objectivity goes out the door. Lisp religion is no
different, I guess, but it's too bad -- a good Windows-centric Lisp would save
light-years of work on this beast!
Bill House
--
http://www.dazsi.com
Note: my e-mail address has been altered to
confuse the enemy. The views I express are
mine alone (unless you agree with me).
With a mighty <··························@wjh_dell_133.dazsi.com>,
······@dazsi.nospam.com uttered these wise words...
> I just had the misfortune to get temporarily assigned to a Win32/MFC project,
> due to a staffing problem. As I brush up on my somewhat-rusty MFC, I have to
> tell you that, after a couple of years of Lisp development, it's like flint
> knives and stone axes. Nevertheless, there is no Lisp I know of that would fit
> for this project, which requires the creation of many Windows-centric objects
> like OCXes, DLLs, and interfacing with 3rd-party components implemented as
> same. <sigh>
I have to agree with you about the flint knives and stone axes. The
availability of large numbers of "must have" OCXes, DLLs, and other
components, and the ease with which they can be added to a project
makes it hard to convince people that C++ is not such a great
development tool.
> Another shock I am having to endure is the C++ tunnel vision of the MFC jocks
> we do have on the project. So far, I can see no reason to do the main GUI in
> MFC -- VB or Java would have been preferable and far more effective IMO, but
> suggestions in that direction have met with enormous pushback. Oh well, once
> you buy into a religion, objectivity goes out the door. Lisp religion is no
> different, I guess, but it's too bad -- a good Windows-centric Lisp would save
> light-years of work on this beast!
I prefer building user interfaces in VB to _any_ other tool, but there
are also some good Java tools. I don't know about other C++ IDEs for
Windows, but VC++'s "Developer Studio" isn't as good at interface
building IMHO. Perhaps that's MFC complicating things, I dunno. VB
keeps simple things easy. Not that I use VB...
Now, a Lisp compiler with a VB-like IDE would be heaven. While the
platform independance of tools like CLIM, CAPI, Common Windows, etc
are great when you're writing portable code, this approach is totally
alien to the Windows style of building interfaces, where you want
complete control over things that CLIM hides from you. Anyone who's
not sure what I'm talking about should take a close look at VB and the
way in which menus and dialogs are designed, the way that code is
linked to events, and the setting of properties for components.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
...deleted
> business practices until Microsoft itself rots and dies, which I predict
> happens between the years 2005 and 2010.
That is a very long wait. Still, it is better than
not-in-the-forseeable-future (which is my own guesstimate). Would it be
possible to get the underlaying reasoning?
...deleted
> planning for you. the Microsoft market is parented solely by Bill Gates,
> and he does _not_ plan for _your_ best interests. if he could kill Lisp,
> he would, and _that's_ the reason Lisp vendors should not flirt with him.
> he's made it abundantly clear already that he has _no_ soft spot for good
> ideas or elegant design. it's time people understand that he is no good.
> and like all predators that run out of prey, he'll starve to death, soon.
Mr Gates probably would only kill LISP if there was a monetary gain in
doing so. Also, he is not altogether no good. He is, for instance, very
good at making money. But as for his influence on the computer/software
industry the analysis is ok.
--
Best Wishes, Bengt
Email: ······@damek.kth.se
······@damek.kth.se (Bengt Kleberg) writes:
> In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>
> ...deleted
> > business practices until Microsoft itself rots and dies, which I predict
> > happens between the years 2005 and 2010.
>
> That is a very long wait. Still, it is better than
> not-in-the-forseeable-future (which is my own guesstimate). Would it be
> possible to get the underlaying reasoning?
I'd like to hear it, too. Erik, what do you base your assumption on?
--
Hrvoje Niksic <·······@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"A Real Programmer's code can awe with its fiendish brilliance, even
as its crockishness appalls."
* Erik Naggum
| ... until Microsoft itself rots and dies, which I predict happens between
| the years 2005 and 2010.
* Bengt Kleberg
| That is a very long wait. Still, it is better than not-in-the-forseeable-
| future (which is my own guesstimate). Would it be possible to get the
| underlaying reasoning?
sure. I watched managers at all levels ignore the Year 2000 problem for a
whole decade after there started to be some murmurs among software
professionals about a possible problems in both software and data. then,
in 1995 or so, they suddenly got this Bright Idea that they should do
something about it, probably because somebody able to talk their language
could express the concern to them, and in typical manager-style, got all
panicky about it. the short-sightedness of today's average manager is much
worse than the short-sightedness of the average programmer. programmers
take some pride in writing code that doesn't break under forseeable stress,
but managers seem to take pride in "acting responsibly" and "taking charge"
_after_ an accident has happened, or when it is imminent, if they're good.
I guess no manager was ever promoted for wasting company resources to avoid
a costly problem that nobody ever saw because it was averted. however,
managers that act calm in a crises are awarded with promotion, provided
they can blame somebody else for the actual incident.
if this is how the manager guild actually works to promote their own, it
will dawn on some unusually bright manager that all the huge investments in
software and in information is all for naught when Microsoft changes their
data formats, API's, MFC internals, etc, all the time under their feet,
that they can't afford to re-key the documents, and can't afford to keep a
barn full of old computers with old software to make old documents
readable.
it probably doesn't take more than one large-scale lawsuit where some
_manager_ loses because he can't retrieve the necessary documents to defend
himself, documents which he entrusted to some version of Microsoft Word.
with some luck, there is already a manager somewhere who has grasped that
he has sold his soul to Bill Gates in exchange for some unproductive tool
with many colors and icons that only shortens the lifespan of his company's
information to about two releases, and he's very frustrated. he's trying
to alert other managers to this problem, and he can't do it, because what
he has discovered is not really a threat to managerdom, and he can't act
responsibly while blaming somebody else, because it's basically his own
idiocy that has come back to bite him. instead, he will find a consulting
company that can convert his old documents for him, but only after he has
created some crises that he can look good to senior management if he's on
top of and _he_ is in charge of fixing, and then he will become famous and
capitalize big time on this with nationwide seminars on "protecting company
assets in information" and all sorts of ways to lie about how he once was
an idiot who bought Microsoft Word for his secretary to type that one
letter that could have been the end of his career (never mind the company).
then it will take five years for Microsoft to die a horrible, flaming death
in humongous lawsuits from companies who have to spend billions upon
billions of dollars to fix what was a known problem in 1969.
incidentally, I fully expect the responsible authors of software that is
not Year 2000 Compliant to be hauled in front of a judge and made to pay.
I actually think this is the _only_ reason managers wised up to this
problem as early as they did. if it weren't for the lovely legal system,
managers wouldn't miss a night's sleep or worry a second until 1999-12-31,
when their personal calendars for "tomorrow" said "1900-01-01".
managerial incompetence giveth and taketh away. Microsoft is the best
proof ever that if you keep managers happy and careless, they will give you
oodles and oodles of money to help them stay that way. however, even the
average, incompetent manager will wake up, and the senior management will
notice that something is happening.
when this does transpire (a management word for "happens"), it's important
that somebody stand by to solve the problems they _really_ wanted to solve.
my guess is that free software will be in that position by the time
Microsoft goes down, and that programmers will no longer _want_ to waste
enormous amounts of time on stupid bugs only because incompetent managers
can't make the right choice.
the key to all this is to be prepared for Microsoft's fall. like the Year
2000 Problem, there will be _tens_of_thousands_ of incompetent managers who
want to capitalize on the problem -- after all, they know _exactly_ what
the problem is. like the Year 2000 Problem, it's very important not to be
in a position where you can be blamed for choosing Microsoft.
also note that this is different from any other company crash in history,
because no other company is so utterly oblivious to the information
(values) that their customers invest in with their tools. Microsoft will
fall because of lack of confidence, just like a failing bank crashes only
because people lose confidence, not because they have actually lost the
money, yet. this lack of confidence will be strictly isolated to Microsoft
because they have made such a big deal about inventing everything on their
own, too. the best part of this is that Microsoft's total lack of cultural
influence from the outside world will also mean that they can't just suck
up thousands of programmers to fix technical bugs. the whole of Microsoft
is built on marketing to incompetent managers, on a balloon of confidence
that _will_ burst, and on a belief in "the next version" which _will_ vane.
I have the highest hopes for the future. in the post-Microsoft era, I also
doubt that governments world-wide will allow a repetition of Bill Gates,
who should remember the wisdom in the saying "you have only one chance to
make a good last impression". I even envision the creation of American
Programmer's Association, possibly with bar exams or apprenticeships. it's
time the trade of programmers got as responsible as their position in the
society is. Microsoft will, through their phenomenal incompetence, prove
the need for certified programmers. of course this will be dirty, this
will require flirting with Washington, this will mean all kinds of permits
and government control, or at least overseeing by insurance companies and
legal advisors. the kinds of people who will be programmers in the future
are not the kind of people who become programmers today, just like witch
doctors are a different kind of person from today's MD's.
I believe programming will be a most important trade in the future, and the
company that will prove it to you -- Microsoft.
#\Erik
--
NT 4.0 -- an abbreviation of "new technology for naught"
On Sun, 29 Jun 1997 21:09:59 +0100, ···@gubbishwildcard.demon.co.uk
(Martin Rodgers) wrote:
: With a mighty <···············@jagor.srce.hr>,
: ·······@srce.hr uttered these wise words...
:
: > Not that I would attempt to defend his tactlessness (to put it mildly),
: > but he has been very clear in what you should do to make Lisp support
: > DLL-s (or whatever fancy thing you want to have) -- write wrapper
: > functions. If you are uncapable of doing it, pay others to do it.
: > But don't expect others to do it *for free* because you don't feel
: > like doing it.
:
: Wrapper functions? Do you know what a DLL is? One EXE cannot link to
: another EXE.
Not quite.
You can have one EXE link to another EXE. Using LoadLibrary routines,
you can map in modules exported by either a .dll or a .exe. And I
suspect, pretty much any .<suffix> you want.
: IPC techniques like pipes and sockets can pass data
: between an EXE and a DLL that acts as its "front end", for other EXEs
: to link to.
Linked libraries and IPC are not the same thing.
-- Sang.
With a mighty <·················@siesta>,
·······@inlink.com.remove.everything.after.dot.com uttered these wise
words...
> You can have one EXE link to another EXE. Using LoadLibrary routines,
> you can map in modules exported by either a .dll or a .exe. And I
> suspect, pretty much any .<suffix> you want.
You still need to check if the EXE is already running, run the EXE,
then link to it and use it, then remember to unlink it afterward. To
make this transparent, you'd need to write a "proxy" DLL to hide the
EXE. Would you do this for every OLE, OCX, or DLL that you wish to
write in Lisp?
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
cybes for 4.5 years, now plain old mcr
Please note: my email address is gubbish
On Thu, 3 Jul 1997 09:06:51 +0100, ···@gubbishwildcard.demon.co.uk
(Martin Rodgers) wrote:
: With a mighty <·················@siesta>,
: ·······@inlink.com.remove.everything.after.dot.com uttered these wise
: words...
:
: > You can have one EXE link to another EXE. Using LoadLibrary routines,
: > you can map in modules exported by either a .dll or a .exe. And I
: > suspect, pretty much any .<suffix> you want.
:
: You still need to check if the EXE is already running, run the EXE,
: then link to it and use it, then remember to unlink it afterward.
Huh?!?
LoadLibrary does not require you to have the exe running to link to
it. It treats the exe as if it was another dll which just happen to
include some program loading stuff which you don't care about.
I routinely link into both dlls and exes from my own code without any
concern regarding whether the exe is running or not. If it's running,
NT will simply map the exported routines into my process's space and
increment an internal counter. When I FreeLibrary or terminate my
process gracefully, NT will decrement the counter. The only
difference I would notice is that if the exe isn't already running
(and consequently already in memory), it will take just a tad longer
to initialize the entry points from my code. But programmatically, it
would be completely transparant.
: ...Would you do this for every OLE, OCX, or DLL that you wish to
: write in Lisp?
OLE/COM/OCX are treated differently. You wouldn't even bother with
LoadLibrary. You simply use the underlying COM mechanism to grab the
dispatch pointer to the routine you want to use. You can specifically
tell your code to either attempt to grab the active dispatch (ie.,
grab the instance of the object currently running if any), if it can
find one or create an instance of the object on the fly. Infact,
using COM, you can do some very late binding on your library routines.
Yes, do you have to worry about decrementing the ref count to the
object, but using OLE/COM libraries and/or your own classes, this can
be done automatically when your dispatch goes out of scope.
-- Sang.
With a mighty <··················@siesta>,
·······@inlink.com.remove.everything.after.dot.com uttered these wise
words...
> OLE/COM/OCX are treated differently. You wouldn't even bother with
> LoadLibrary. You simply use the underlying COM mechanism to grab the
> dispatch pointer to the routine you want to use. You can specifically
> tell your code to either attempt to grab the active dispatch (ie.,
> grab the instance of the object currently running if any), if it can
> find one or create an instance of the object on the fly. Infact,
> using COM, you can do some very late binding on your library routines.
> Yes, do you have to worry about decrementing the ref count to the
> object, but using OLE/COM libraries and/or your own classes, this can
> be done automatically when your dispatch goes out of scope.
Do you have any idea how to create an OLE server in ACL/PC or LWW,
or are you talking about write OLE/COM/OCX components in C++?
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
Will write Lisp code for food
On Fri, 4 Jul 1997 08:51:36 +0100, ···@gubbishwildcard.demon.co.uk
(Martin Rodgers) wrote:
: With a mighty <··················@siesta>,
: ·······@inlink.com.remove.everything.after.dot.com uttered these wise
: words...
:
: > OLE/COM/OCX are treated differently. You wouldn't even bother with
: > LoadLibrary. You simply use the underlying COM mechanism to grab the
: > dispatch pointer to the routine you want to use. You can specifically
: > tell your code to either attempt to grab the active dispatch (ie.,
: > grab the instance of the object currently running if any), if it can
: > find one or create an instance of the object on the fly. Infact,
: > using COM, you can do some very late binding on your library routines.
: > Yes, do you have to worry about decrementing the ref count to the
: > object, but using OLE/COM libraries and/or your own classes, this can
: > be done automatically when your dispatch goes out of scope.
:
: Do you have any idea how to create an OLE server in ACL/PC or LWW,
: or are you talking about write OLE/COM/OCX components in C++?
Should it matter? But to answer you, yes I'm talking about C/C++.
Infact, the whole point of this was that you can link to routines
exported by either .dll or .exe from your code--regardless of what
language you're code is written.
Similarly, I don't see how the language would make a difference in how
you instanciate an OLE server. Whether you explicitly grab a
IDispatch pointer to the COM object or whether that process is hidden
within the language construct, makes no difference as far as how your
code preceives the object (or I should say it shouldn't--you can
certainly write a language which makes that artificial distinction).
This is how C/C++ works, how VB works, how REXX works, how Delphi
(Object Pascal) works, et. al. Infact, some of these other languages
work somewhat better than C/C++ since a lot of the bookkeeping is done
for you in the back ground. But there is little distinction as far as
these languages are concerned regarding where the COM/OLE object sits.
(Other than the obvious in-proc and out-of-proc issue).
Furthermore, you have to be a bit more specific in your question when
you ask if I know how to create an OLE server. Do you mean, do I know
how to create an instance of the OLE server from the client code to
make use of? Or do you mean actually write an OLE automation server?
While in both cases, the answer is yes, I ask that you be specific so
I know what direction you're trying to lead this discussion.
For your information, I've spent the last couple of years working
strictly with COM/OLE. And the last 10 months writing automation
servers and clients for a very large project in both C++ and VB for a
company where I consult. So yes, I believe I have a fairly good idea
of how COM/OLE/OCX works under NT/Win95.
-- Sang.
With a mighty <·················@siesta>,
·······@inlink.com.remove.everything.after.dot.com uttered these wise
words...
> Furthermore, you have to be a bit more specific in your question when
> you ask if I know how to create an OLE server. Do you mean, do I know
> how to create an instance of the OLE server from the client code to
> make use of? Or do you mean actually write an OLE automation server?
> While in both cases, the answer is yes, I ask that you be specific so
> I know what direction you're trying to lead this discussion.
I'm curious about OLE in general. Both servers and clients, but
servers in particular. Automation server included.
My concern is for writing OLE servers in Lisp. This is a feature
supported in DylanWorks, but not yet in ACL/PC or LWW. I'm wondering
what could be so hard about adding such support to Lisp, when there
are Smalltalk and APL systems that can manage it.
Note that I'm not talking about writing an OLE server (of any kind) in
C++, but in a rather different language. This issue is part of a more
general question about support in Lisp systems for Windows features.
A more specific question might be: how is it that a single vendor can
do "OLE/ActiveX interoperability and component generation" in Dylan
but not Common Lisp? That can only be answered by the vendor...
Perhaps there isn't an entirely technical reason for this. Could you
tell me, please, if you know of development tools that can update the
code for an OLE server while it is still in use? My experience with
C++ is that when you write a DLL, and an app loads it, it isn't
possible to relink the DLL. In languages like Lisp and Smalltalk, it's
very natural to recompile a function or a method while the code is
still running. No linker for C/C++ that I've ever used could cope with
this. That doesn't mean that it isn't possible, of course.
So, here's my non-technical answer:
<URL:http://www.harlequin.com/full/products/sp/dylan.html>
Perhaps Lisp ain't so dead, after all.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
Will write Lisp code for food
On Fri, 4 Jul 1997 20:32:26 +0100, ···@gubbishwildcard.demon.co.uk
(Martin Rodgers) wrote:
: I'm curious about OLE in general. Both servers and clients, but
: servers in particular. Automation server included.
:
: My concern is for writing OLE servers in Lisp. This is a feature
: supported in DylanWorks, but not yet in ACL/PC or LWW. I'm wondering
: what could be so hard about adding such support to Lisp, when there
: are Smalltalk and APL systems that can manage it.
:
: Note that I'm not talking about writing an OLE server (of any kind) in
: C++, but in a rather different language. This issue is part of a more
: general question about support in Lisp systems for Windows features.
There is absolutely no technical reason why you couldn't write OLE/COM
servers/objects with Lisp. Infact, writing OLE/COM servers/objects is
pretty much language neutral. It's true that COM interface
specification maps directly to C++ v-tables, but that still doesn't
preclude other languages. You can already write OLE servers (which
are COM objects) in Object Pascal (Delphi) and Visual Basic. And I
believe you can also write objects using Java as well.
: ...My experience with
: C++ is that when you write a DLL, and an app loads it, it isn't
: possible to relink the DLL. In languages like Lisp and Smalltalk, it's
: very natural to recompile a function or a method while the code is
: still running. No linker for C/C++ that I've ever used could cope with
: this. That doesn't mean that it isn't possible, of course.
If you're referring to generic library mapping, you're right--you
can't recompile a running library. However, COM/OLE allows for very
late binding. Under C/C++ using LoadLibrary, the functions/routines
are mapped in at compile/build time. Using COM/OLE, you can
instantiate objects and server at run time. One of the "problems"
that COM/OLE does fix to a degree with C++ is the fragile base class.
While this isn't exactly the same as rebuilding an object at run time,
it's is "relinking" (or instantiating) new routines/functions at run
time--which I think is what you're after, no?
-- Sang.
With a mighty <·················@siesta>,
·······@inlink.com.remove.everything.after.dot.com uttered these wise
words...
> You can already write OLE servers (which
> are COM objects) in Object Pascal (Delphi) and Visual Basic. And I
> believe you can also write objects using Java as well.
So I've read. I don't have access to most recent tools (with the
except of VB 5.0, which I installed yesterday), so I generally don't
have first hand experience with them.
Thankfully, none of these tools seem to require the programmer to add
the OLE server support themselves.
> If you're referring to generic library mapping, you're right--you
> can't recompile a running library. However, COM/OLE allows for very
> late binding. Under C/C++ using LoadLibrary, the functions/routines
> are mapped in at compile/build time. Using COM/OLE, you can
> instantiate objects and server at run time. One of the "problems"
> that COM/OLE does fix to a degree with C++ is the fragile base class.
No, I'm not referring to generic library mapping. I'm refering to
updating the code _while it's running_. Load the code, begin running
it, modify it, continue running it (i.e. don't stop it), and
eventually unload the code (quit the program, quit a program that uses
the DLL or OLE server, etc).
> While this isn't exactly the same as rebuilding an object at run time,
> it's is "relinking" (or instantiating) new routines/functions at run
> time--which I think is what you're after, no?
As I understand it, that's right. If you mean unloading the code,
modifying it, then reloading it, then it's nothing like rebuilding an
object at run time.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
Will write Lisp code for food
With a mighty <············@newsie.cent.net>,
········@eval-apply.com uttered these wise words...
> You can rebuild the library on the fly. Just add
> another level of indirection.
Oh, yes. The "proxy" kludge. That's a hell of a proxy, tho. On the
other hand, once you've written a general OLE proxy, you should never
need to do it again.
Has anyone done it yet, or am I the first person to think of it? Not
that I'll bother writting it, of course. I can just wait for someone
else to do it, as I'm sure they will - or will have done already, if
it really is that easy. I'm sure that something (DylanWorks?) will be
available long before I begin working on it.
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Please note: my email address is gubbish
Will write Lisp code for food
Martin Rodgers writes:
> I'm forwarding your message to my boss, as he find your rantings very
> entertaining. I wish I did.
As I wish I could say the same for yours.
Regards,
jeh
* Martin Rodgers
| Careful, Erik. the message that you're giving is anti-Windows.
yeah, so? will the Microsoftian thought police come and arrest me, now?
| Some Lisp vendors believe that supporting Windows is a good idea. Are
| you disagreeing with me or them? Or are you simply flaming me because
| you don't like the idea that "Lisp is less than perfect"?
sometimes I wonder what kind of braindamage Windows produces. don't you
understand what I'm telling you, Martin? don't you realize that what I'm
telling you is very simply this: if _you_ want this crud that you have
wasted _months_ whining about, while the rest of us have done some really
hard work, and you neither want to pay for it nor help bring it about,
_you_ should shut the fuck up. this has nothing to do with Windows, it has
even less to do with Lisp, but it has everything to do with the specific
lack of correspondence between your whining and your actions.
you're not being constructive, Martin. there's nothing in your messages
that can possibly cause anybody anywhere to create or produce anything.
however, if I can get you to stop polluting newsgroups with your insane
ideas about what is and is not "the real world", people can perhaps focus
on issues worth talking about. to be even more brutally honest: you kill
discussions with your fanatic focus on your miserable Windows existence.
many interesting debates have turned into stupid Windows advocacy through
your fanatic and moronic repetition of your irrelevant points. you harm
Lisp significantly with your inaccurate descriptions of a "real world"
where Lisp does not live. not only do you offend people who work with Lisp
in the _real_ "real world", you tell idiots like your manager (well, if
he's entertained by my messages, he probably isn't quite the moron you have
communicated to us that he is) that there exists a "real world" wherein
Microsoft rules supreme and Lisp rules not at all. since idiot managers
already think that Microsoft rules supreme, and everybody think they live
in the "real world", they might just buy _your_ false arguments that Lisp
is not a part of that "real world", regardless of the _fact_ that it is.
| Pay me to use whatever tools you use, otherwise please don't lecture me
| on what tools I should be using.
ooooh, are we getting a little too snotty for our own good, too, now?
if you wish to dictate what people should talk about (I guess it's really
_you_ I should be "careful" not to offend with being anti-Windows, right?),
the least you can do is accept that you're at least as unwelcome with your
shit as you felt when you wrote that _stupid_ line above.
I don't want to use Windows, but you keep lecturing me (and everybody else
around here) about what the "real world" is like, and if you're getting
upset with a few scathing messages every three months, exercise your puny
little brain to get an idea how exhausted people who _don't_ subscribe to
your brainwashed ideas about "real worlds" must be after your "crusades".
| The message you're giving is that Lisp and Windows don't mix, while I'm
| asking what may be done to make them a _better_ mix.
the message I'm giving is that I'm fed up with people who whine constantly
while doing exactly nothing about their topic of whining. a fanatic, said
Winston Churchil, is a man who can't change his mind, and won't change the
subject. that's you. the message I'm giving is that I'm possibly even
more fed up with managers and users who think that Microsoft is a given and
that all problems that follow are somebody else's fault. I used to have a
signature that went like this: "Microsoft is not the answer. Microsoft is
the question. NO is the answer." this is not because I envy Bill Gates'
penis or some other standard Windows-zealot rationalization, but because
Bill Gates' braindamaged products brings me losses of both time and money.
fact is, I can't plan at all when Microshit is involved -- I can't trust
specifications, I can't trust the documentation, I can't believe the
marketing, and I can't base any rational decisions on anything coming out
of Microsoft, or even the behavior of _anything_ supposed to run under
Windows. Windows users care about colors, buttons, trivial issues in user
interface design, and they either don't have the brains or just lack the
knowledge to request robust software. I don't know Windows, but I ask
people who do for help whenever a client is married to Microsoft, and even
the experts with full-time exposure to Microshit can't give me straight
answers to simple questions about what works and what doesn't, what the
conditions of failure and success are, etc. I can't program shit like
that. I'm barely able to live with the randomness in the Unix world. I
don't consider it worth my while to work around hundreds of arbitrary,
product- and version-dependent bugs whose very workarounds effectively
prohibit fixes, but this is what modern computing is all about. there are
so many tricks of the Windows trade that there is no trade left.
| Which of us is being more constructive?
I am, obviously, since I do real work in Lisp for real clients. I don't
know what you do, but every time I get a little time on my hands to read
and post news, there's this idiot Cyber Surfer who clamors on about his
puny subsistence with Windows and why won't anybody give him a chance to
program in Lisp, which he claims to love, but shows no evidence of.
what really amazes me is that you're so totally bereft of any ability to
recognize that you're a royal pest that you actually think I'm criticizing
something _other_ than your fruitless _whining_. you could whine about
pigs not having wings for all I care -- I'm sick and tired _specifically_
of this Cyber Surfer's incessant whining. and I say so.
if you wish to be constructive, offer to do some work for a Lisp vendor,
and if you're turned down (_I_ would turn you down if I were a Lisp vendor,
as I have no evidence at all that you know Lisp from cricket), at least
work your ass off to pay for somebody else to do what you want done.
if you wish to be constructive, _solve_ problems, don't just repeat some
nonsense about their hypothetical existence.
now, _of_course_ it would be nice if Windows victims could use a real
programming language, but I don't really think this is possible. Microsoft
is even more married to C++ these days than Unix was to C in its heyday.
Microsoft takes particular care to destroy any investment in software that
tries to build abstractions on top of their randomness-by-design, even
making arbitrary changes just to annoy a competitor. _why_ should anyone
want to work with the dickheads in Redmond, WA, if they already have a
superior product to offer the intelligent remains of the planet's species?
now, _of_course_ it makes business sense to make money, but somehow, people
don't go into drug trafficking and prostitution just because they want to
make money. there's this _ethics_ element, and this _values_ element that
keep normal people away from the paths that Bill Gates has chosen from the
day he lied about his software for the Altair. self-respecting people just
don't succumb to this level of dishonesty and fraudulent behavior.
if it isn't possible to succeed in a particular trade by being good at what
you do, you can always change trades. if it is possible to succeed in a
particular trade only if you're some mediocre bum, good people won't even
desire to work in that trade.
| Followups adjusted.
no, you attempted to, and you failed.
#\Erik
--
GUI -- Graphics Under the Influence
From: Patrick Doyle
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <EB96zL.Anr@ecf.toronto.edu>
In article <·············@nospan.netright.com>,
David Hanley <·····@nospam.netright.com> wrote:
>Tom Thomson wrote:
>>
>> That first assertion there is amazing. Ten years ago, and for a long time
>> before that, home computers came WITHOUT any assembler and WITH
>> a Basic interpreter in their usual packaged forms.
>> So the language of
>> first choice for programming them was BASIC.
>
> Speaking of amazing assertions. Are you intending this to counter
>my statement? You would need to also state "applications were
>programmed in
>the toy teaching language that came with the machine." I don't think
>anyone
>would support the latter statement.
Was I the only one that wrote myself an assembler in BASIC? :-)
Oh, the good old Commodore 64. Those were the days.
-PD
--
--
Patrick Doyle
······@ecf.utoronto.ca
From: James Logajan
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <jameslEB9xrx.Mvt@netcom.com>
David Hanley (·····@nospan.netright.com) wrote:
: Tom Thomson wrote:
[elided]
: > That first assertion there is amazing. Ten years ago, and for a long time
: > before that, home computers came WITHOUT any assembler and WITH
: > a Basic interpreter in their usual packaged forms. So the language of
: > first choice for programming them was BASIC.
: Speaking of amazing assertions. Are you intending this to counter
: my statement? You would need to also state "applications were programmed
: in the toy teaching language that came with the machine." I don't think
: anyone would support the latter statement.
I can support that latter statement. I worked at a company that sold
an accounting package written entirely in Apple ][ Basic. The package
consisted of general ledger, accounts payable, accounts receivable, inventory,
payroll, and fixed assets. As Apple Basic programmers can tell you,
Apple ][ DOS was hacked into the Basic by rather ugly means (i.e printing
a line starting with a control-D indicated that a file operation followed:
PRINT "^DOPEN SOMEFILE"; PRINT "^DREAD SOMEFILE,R12"; INPUT a$
I could go on, but the point is, Basic WAS used to program significant
applications. (One of its few good points was that you could have customers
query the values of any program variables after a program stopped; sure
helped locate bugs in the field!)
Maybe this thread should be "Learning from the success of Basic."
After all, Bill Gates and Paul Allen got their start by providing
_INEXPENSIVE_ Basic to the masses. Borland made it big with the introduction
of an _INEXPENSIVE_ (US$50) Pascal compiler for CP/M. Prior to that,
you had to shell out US$300+ for any sort of compiler for micros.
In article <················@netcom.com>, James Logajan wrote:
>Maybe this thread should be "Learning from the success of Basic."
>After all, Bill Gates and Paul Allen got their start by providing
>_INEXPENSIVE_ Basic to the masses. Borland made it big with the introduction
>of an _INEXPENSIVE_ (US$50) Pascal compiler for CP/M. Prior to that,
>you had to shell out US$300+ for any sort of compiler for micros.
Before Bill Gates and Paul Allen, you could get BASIC for FREE.
But they did keep basic going when everyone else basically dropped it.
Their interpreters were a joke, and crashed often, but they actually
went ahead and improved the language (adding control structures and
such). Probably just tenacity. I would think the effort could have
been better spent elsewhere, but the old "be backwards compatible at
any price" attitude prevented them from actually making a new language
rather than an advanced basic.
--
Darin Johnson
·····@usa.net.delete_me
With a mighty <················@netcom.com>,
······@netcom.com uttered these wise words...
> Maybe this thread should be "Learning from the success of Basic."
> After all, Bill Gates and Paul Allen got their start by providing
> _INEXPENSIVE_ Basic to the masses. Borland made it big with the introduction
> of an _INEXPENSIVE_ (US$50) Pascal compiler for CP/M. Prior to that,
> you had to shell out US$300+ for any sort of compiler for micros.
I sometimes say that this should tried with Lisp. Visual Lisp, anyone?
Put the runtime into a DLL, use a VB-style IDE, and you'd have a
killer development system.
Alas, this seems to not be a popular idea. Of course, I may be wrong.
Perhaps this time I won't get flamed for suggesting that an idea that
worked for Basic and Pascal might also work for Lisp. Sometimes it
feels like threads like this should be called "not invented here".
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
From: Michael D. Kersey
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <339862ED.C92@hal-pc.org>
Cyber Surfer wrote:
>
> With a mighty <················@netcom.com>,
> ······@netcom.com uttered these wise words...
>
> > Maybe this thread should be "Learning from the success of Basic."
> > After all, Bill Gates and Paul Allen got their start by providing
> > _INEXPENSIVE_ Basic to the masses. Borland made it big with the introduction
> > of an _INEXPENSIVE_ (US$50) Pascal compiler for CP/M. Prior to that,
> > you had to shell out US$300+ for any sort of compiler for micros.
>
> I sometimes say that this should tried with Lisp. Visual Lisp, anyone?
> Put the runtime into a DLL, use a VB-style IDE, and you'd have a
> killer development system.
>
> Alas, this seems to not be a popular idea. Of course, I may be wrong.
> Perhaps this time I won't get flamed for suggesting that an idea that
> worked for Basic and Pascal might also work for Lisp. Sometimes it
> feels like threads like this should be called "not invented here".
> --
> <URL:http://www.wildcard.demon.co.uk/> You can never browse enough
> Martin Rodgers | Programmer and Information Broker | London, UK
> Please note: my email address is gubbish.
How funny you should mention it! I have in my hands a shrinkwrapped
software package from Raindrop Software called "Software Engineer". The
inside cover of the Reference manual) says it all: "Lisp Interactive
Programming Environment for Microsoft Windows - Version 1.0."
I wanted it to work badly! But alas, there were so many errors in the
documentation and code that it render the package almost useless.
Perhaps I should not have bought Version 1.0. Sadly it is now
shelfware...
With a mighty <············@hal-pc.org>,
········@hal-pc.org uttered these wise words...
> How funny you should mention it! I have in my hands a shrinkwrapped
> software package from Raindrop Software called "Software Engineer". The
> inside cover of the Reference manual) says it all: "Lisp Interactive
> Programming Environment for Microsoft Windows - Version 1.0."
I used to see ads for this, in Byte, hidden away at the back. I
couldn't find much info about it, like a review.
> I wanted it to work badly! But alas, there were so many errors in the
> documentation and code that it render the package almost useless.
> Perhaps I should not have bought Version 1.0. Sadly it is now
> shelfware...
How close was the IDE to Delphi/VB? I didn't even know it _had_ an
IDE. For all I knew, it was just another conventional Lisp for
Windows, perhaps even using an interpreter.
Nothing in the advert suggested that was remotely interesting, and by
the paucity of people in comp.lang.lisp who were using it you might
assume that it wasn't too popular. Of course, you might also have
assumed that Windows wasn't very popular, if comp.lang.lisp was your
only source of info. ;)
I wonder how much Borland have spent on Delphi over the last few
years? How much have MS spent on VB since 1.0 was released? Before we
criticise Raindrop Software for anything we should ask how much money
_they_ may have spent on their product, and how different it might've
been if they'd had the same resources as Borland or MS.
Did Raindrop Software ever have a presence on UseNet? The Internet?
For all I know, there may be dozens of small Lisp vendors with good
ideas, but which never get very far coz few people hear of them or
realise what makes _their_ product different from anything else.
Out of curiousity, could you please tell me if "Software Engineer" was
a standard Lisp dialect, like CL or Scheme, or was it one of the far
from standard variants, like newLisp?
Thanks.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note: my email address is gubbish.
In article <·················@lucent.com>,
Paul Campbell <·······@lucent.com> wrote:
>Ok so there has been a bit of a move away from assembler but even that
>may be
>just because there are more, as a proportion, user-level application v.s
>embedded systems.
Is suspect that the biggest reason for the move has been that it has become
too much work to try to optimize for increasingly cache CPU and memory
environments. "Is that value still going to be in the L2 cache? It depends
on the branch prediction!" It seems clear to me that it makes sense to leave
it to compiler writers to figure this stuff out. So I do believe that the
trend will be toward higher level languages. Java is the next step in this
painfully slow transition.
Paul Prescod
From: Richard A. O'Keefe
Subject: Re: Learning from C++'s success ( was C++ briar patch )
Date:
Message-ID: <5mbaid$klg$1@goanna.cs.rmit.edu.au>
Paul Campbell <·······@lucent.com> writes:
>To qualify my orignal reply: 10 years ago the the phrase
>"in 10 years time we won't have to worry about efficency" was very
>popular
>among prolog avocates
I believe this to be a libel on all the Prolog advocates that I personally
know. Certainly everyone at Quintus had the attitude that "efficiency will
always be an issue, and it's up to us to show that Prolog can deliver
over-all *system* efficiency." I _did_ hear the phrase "improved compiler
technology will save us", but then, many of the people who said that were
working hard on improving the compiler technology. The Aquarius work
showed that the compiler technology _could_ deliver very good efficiency,
and the Mercury project (for a language which is even *closer* to logic
than Prolog) has proven that logic programming is fully compatible with
efficiency rivalling C.
>and it was a commonly held view in academic circles that
>the availibility of cheap computing power would soon herald the end of
>3gls such as
>C in favor of the likes of prolog and lisp.
Which academic circles were those, exactly? I certainly never heard
those views. I think everyone who actually understood C, Prolog, and
Lisp thought that SILs like C would always have a place (although, like
Progol in the Edinburgh Prolog world, syspop in Pop-11, or the low level
functions I used in Xerox Lisp, the SILs might not have C syntax).
Take a look at the figures for Visual Basic some time. Add in Microsoft
Access. Look at the work being done using SQL. It looks to me as though
a lot of work _is_ being done in un-C-like languages. SQL may be a stinking
rotten excuse for a substitute for relational algebra, but C it ain't.
>People know that computers are getting ever faster so they expect them
>to either
>do more, or do the same job proportionately faster - I know I do !.
Yeah, but the things a C++ compiler has to do are growing fast too.
--
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.