···@gubbishwildcard.demon.co.uk (Martin Rodgers) wrote:
> something like this adds time to a project, which is, I suspect, where
> the real objection will be.
If you could use Lisp as well as you claim, and it isn't merely a cute
addition to your disk space, it should surely pay off to develop a useful
tool which can then be used again and again. Just as one usually doesn't buy
a new development platform and the related software for each small project,
it would be silly to account only one such project for the development of
a general tool. I see professional software development as investing some
cleverness and effort now, to be more productive later (where "productive"
does of course include the freedom to afford laziness). Maybe that's not
the fashion in the "real world" of programming under Windows? Frightening.
> Also, many Windows components use MFC, so
> this will require the creation of "proxy" classes to mimic the MFC
> classes used in the components.
If you can't leave such "components" alone with using whatever classes
they desire to use, and use whatever actually works for your stuff, I'd
refuse to call it components, but a dangerous binary variant of patching,
programming by wild cut-and-paste. Particularly if this Windows stuff is
changing as frequently as people say it is (and as I can observe when yet
another trivial mismatch between all those toys crashes applications),
I'd do whatever I can to isolate me from such so-called "interfaces" which
aren't even suffiently well-defined to deserve that name. I'll reserve
the notion of "software components" to something which is carefully and
intelligently designed to solve the problems which arise from the desire
to let software from heterogenous and mutually unknown sources cooperate.
Linking arbitrary unsafe code without clear, systematically developed and
stable abstract interfaces together (and hoping that it won't damage too
much whenever it crashes) not only isn't a move towards such a solution,
but despite all marketing claims and the large volume of this crap, is a
danger to the development of a sane technology and infrastructure solving
the important problems.
> Sure, once you've spent the time (I've no idea how long this might
> take), you could generalise it. You could write a utility that can
> read C++ headers and generate C++ code (the proxies) and Lisp (the
> Lisp side of the proxies).
Oops, I'm not talking about hacking together yet another FFI-generator
attempting to shape all programs according to the concepts of C++.
I'm talking about a high-level semantic specification of protocols, and
generating the low-level interface code on both sides from this, with
whatever consistency checking, documentation and debugging facilities one
considers useful. For you own sanity, I recommend you not to think too
much in terms of how C++ does something, trying to emulate C++ throughout
your whole software. If that's what you want, learn to use C++ well and
use it directly. (As Bjarne Stroustrup remarked, it doesn't usually help
to work against the structure of the language, and one shouldn't try to
use C++ as if it was e.g. Smalltalk. The same is also true the other way
around.)
> All I know is that MS keep changing the API, the rules, the language
> (VC++ acquires new featurses all the time, and not all of them will be
> documented), MFC and anything else they want to. Any task like this
> will be a race with MS.
I'm glad you've at least understood a tiny part of Erik's reasoning why
too much support for Windows might not be in the well-understood interest
of Lisp vendors. Working with clear specifications and abstractions isn't
just something one will need to do for portability, but essential to cut
down the superfluous complexity of software.
> Lisp vendors have good reasons to do this (Harlequin's DylanWorks is a
> good example), while lone developers not paid to do this may find it
> very hard work, and esp if only their own time is available.
If the vendors don't provide your desired Windows features so far, one
might think there's some reason for it. As it's hardly a fundamental
technical problem which they couldn't solve, or a lack of understanding
the technical usefulness of these features (as you show clearly with
the above example), what do you think is the reason, and why would you
think you understand _their_ interests better than they do?
Besides, if the Windows market would be even half as component-oriented
as all the marketing hype claims, instead of mostly throwing out lots
of ill-defined dangerous toys, and if you'd be as happy and productive
with Lisp as you seem to claim, why don't you and some fellow Windows
programmers who want to use Lisp pay someone to develop such a tool as
a component? If that isn't financially attractive, why do you think it
would be more attractive for Lisp vendors to invest considerable effort
for this market, and what keeps them from "seeing the light" as you do?
> Your entire arguement is based on a misconception about Windows. Why
> work so hard to not use a feature that is vital to Windows software?
Fortunately, that's your misconception; I'd work hard not to use Windows
whenever I can avoid doing so (at my job I have to use it, though only as
terminal for Unix or for a mainframe; it's already bad enough for that).
I don't care much which features a Lisp for Windows may or may not offer.
It's _you_ telling us that your wish is to use Lisp for your Windows work,
and that you supposedly cannot use it for technical reasons. I was only
trying to give you a few hints how you may be able to use Lisp on Windows
for the tasks you've mentioned.
It seems we agree by now that you indeed could use it - but somehow you
prefer not to use a sub-optimal but workable solution, only lamenting for
a superior solution which appearently just isn't on the market: the very
market which leads you to label Windows as the "real world" in contrast
to those areas where Lisp is actually used, right now. I'm certainly not
saying that there wouldn't be room for improving Lisp, both as a language
and as particular implementations, but the problem is far from being as
severe as you make it appear, and I can understand why some readers find
your articles annoying.
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
With a mighty <············@trumpet.uni-mannheim.de>,
··@ipx2.rz.uni-mannheim.de uttered these wise words...
> If you could use Lisp as well as you claim, and it isn't merely a cute
> addition to your disk space, it should surely pay off to develop a useful
> tool which can then be used again and again.
I agree. However, if you're talking about _my_ time, that's already
committed. In my spare time, I'm writing a Lisp to C++ compiler, while
I'm being paid to use C++ and Java. If you'd like to convince my boss
that I should be using Lisp, you're very welcome to try.
Not that I expect to be able to compete with Franz and Harlequin at
adding support to their Lisps. Good grief, no.
--
<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
| I agree. However, if you're talking about _my_ time, that's already
| committed. In my spare time, I'm writing a Lisp to C++ compiler, while
| I'm being paid to use C++ and Java. If you'd like to convince my boss
| that I should be using Lisp, you're very welcome to try.
I was paid to write C++ once. I couldn't stomach the redundancy and the
syntax, so I wrote more Emacs Lisp to write C++ for me than I wrote C++. a
good C++ programmer I asked to review the code told me I wrote "clean, good
C++", which I found very amusing at the time. (no, it's not reusable -- I
embedded a lot of the knowledge I couldn't express in C++ in the Lisp
form.) in the end, I could generate all the C++ code from the Lisp files,
and indeed, I did. it was faster to generate everything and build all than
to try to figure out what had changed and use make, so it's obvious that
this approach doesn't scale very well in the form I wrote it. now, I'm a
_big_ fan of metaprogramming, but I find few others who are, so this may
not give you anything.
C++ with Lisp syntax is a cool project. not only does it give you that
good feeling of unbraindamaging C++, it can save you from many stupid bugs
and needless writing, especially if you put most of your efforts into type
inference and propagation. ("static typing" doesn't mean _you_ have to do
it!) writing a Lisp to C++ compiler from the Lisp point of view is a waste
of time, unless you're doing it as a commercial project, like the Elwood
Corporation is doing a Lisp compiler that produces readable C code as
output.
there are many ways to be productive with Lisp without being able to deploy
Lisp code. all the very good programming modes for Emacs and the ease with
which more support for special needs can be added sort of prove this point,
even if you don't use Emacs. for instance, that WinMain->LibMain thing of
yours is probably not in any particular need of human intelligence, so the
right thing is to mechanize the task and thus get rid of it for godd.
that humans should repeatedly perform simple manual tasks so computers can
do less work is in my view a fundamentally wrong approach to computing, yet
this is what made Microsoft big and Windows a commercial success.
#\Erik
--
if DUI is "Driving Under the Influence"
then GUI must be "Graphics Under the Influence"
Erik Naggum <····@naggum.no> wrote in article <················@naggum.no>...
>
> that humans should repeatedly perform simple manual tasks so computers can
> do less work is in my view a fundamentally wrong approach to computing, yet
> this is what made Microsoft big and Windows a commercial success.
>
I totally agree about the wrong-headedness of such an approach, but I disagree
that this approach is what made MS a success. MS is simply a C-centric
organization, like most OS or shrinkwrap applications shops, so what looks like
an incremental improvement to a brain-dead language (say VC++ 5.0 over VC++
2.0), looks like a huge win to them -- it's all about perspective.
As for their success, well, that has way more to do with business practices and
marketing than technical issues, save one -- they know how to produce software
that 80% of all users will perceive as the software they want to use (note that
the other 20% of computer users are programmers and techies, who mostly don't
matter -- like lions, they must follow the herds to live). This is more
economic ecology than CS.
Bill House
--
Note: my e-mail address has been altered to
confuse the enemy.
With a mighty <··························@wjh_dell_133.dazsi.com>,
······@dazsi.nospam.com uttered these wise words...
> I totally agree about the wrong-headedness of such an approach, but I disagree
> that this approach is what made MS a success. MS is simply a C-centric
> organization, like most OS or shrinkwrap applications shops, so what looks like
> an incremental improvement to a brain-dead language (say VC++ 5.0 over VC++
> 2.0), looks like a huge win to them -- it's all about perspective.
Spot on, Bill. C++ people get excited about the most mundane features.
At least, they seem mundane to anyone used to using languages like
Lisp. (Lisp isn't unique in this respect.) As you said, it's all about
perspective. Like looking thru the wrong end of a telescope. C++
people see the details, but not the big picture, which is where the
really _big_ wins may be found.
To paraphrase Alan Perlis, C++ programmers know the cost of
everything, and the value of nothing.
> As for their success, well, that has way more to do with business practices and
> marketing than technical issues, save one -- they know how to produce software
> that 80% of all users will perceive as the software they want to use (note that
> the other 20% of computer users are programmers and techies, who mostly don't
> matter -- like lions, they must follow the herds to live). This is more
> economic ecology than CS.
If you want to make it big, it's the realistic approach. We can
question whether "making it big" is a desirable goal, but that may be
more of a politcal issue that a technical one. If we believe what we
see on TV, most people want success, and making it big is celebrated.
All I know is that a lot of programmers won't have much choice in the
matter. Perhaps if 80% of programmers wanted to use Lisp...How might
we arrange that? Probably not by questioning capitalism. Probably not
by pushing CS, either, but that sounds more likely to work. <sigh>
What did John le Carre say about the Cold War? Something like, "We
can't afford to be less ruthless than the opposition." Ouch. Let's
hope he's wrong, as I don't see any CS people with the same ruthless
ambition as Bill Gates.
--
<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