-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "CS" == Cyber Surfer <············@gubbish.wildcard.demon.co.uk> writes:
CS> With a mighty <··········@engnews2.Eng.Sun.COM>,
CS> ······@tcl.eng.sun.com uttered these wise words...
>> Wow, there's been quite a party going on over here on
>> comp.lang.scheme!
CS> I'm not MFC expert, either, nor do I wish to be one, but I have
CS> used it enoigh to know that I wouldn't write such code to create a
CS> button or two, using a particular font. Instead, I'd create a
CS> dialog resource, and if I wanted to place it within part of a
CS> window, then I'd make it a child of that window and size it
CS> accordingly.
CS> In other words, Your Mileage May Vary. A contest between VB and
CS> Tcl might be more realistic, as it seems to me that their
CS> strengths are very similar.
IMHO, Ousterhout's paper isn't about how TCL is better than VB as a
scripting language (this bias may show through but it isn't the main
thrust) but how scripting languages have a definite role to play.
- From this standpoint having players who are on the same "team" compete
against one another is meaningless.
- From the point of the white paper, we should have contests between VB
and VC++ to illustrate the the paper's thesis in the Win-tel realm and
we should have contests between TCL and <insert your favorite *system
programming* language> to illustrate the thesis in the UNIX realm.
--
Changing the subject, I'd have to say that MFC used with MSVC++ is
much more productive than writing directly to the Win32 API (I'm not
going to quibble about the exceptions to this generalization). While
much of this could be attributed to MSVC++'s gui building
functionality, I think that *implementation inheritance* works well
for MFC (contradicting Ousterhout's proposition ...).
--
As for VB verses MSVC++, I know several windows developers who have
used both environments for professional development and they all rave
about how great VB is for creating (non computationally intensive)
applications.
I haven't heard one person slander VB's ability to build GUI
applications quickly and effectively.
This anecdotal evidence supports Ousterhout's claim that "scripting"
language are better at being "glue".
Cheers,
--jfc
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBM0ljqdg65GR/Kx7xAQFNsgP+JppjeA9zcEejjnG1L3AR+WnAYW91+2+I
+GuydoGYKrZ1AWoOjFmLn53NIx1cgvI7KqsxZeMjMSd4Y3o0JtXhlyAVYIXGj300
EW6EeFNBJZhJSigwrJ5mBWcsIgYvbPuCYlhUMkIW/9Sd+Rr7FRXFnr16yMrQ0nSc
fgfUL4QRvQQ=
=oGKe
-----END PGP SIGNATURE-----
With a mighty <···············@prism.loc201.tandem.com>,
····@loc201.tandem.com uttered these wise words...
> IMHO, Ousterhout's paper isn't about how TCL is better than VB as a
> scripting language (this bias may show through but it isn't the main
> thrust) but how scripting languages have a definite role to play.
If anyone is going to discuss tools for easily creating Windows
programs, then VB has some relevance. To most people, Tcl is far
behind VB in terms of the ease of developing Windows apps. We should
really be comparing Visual Basic with Visual Tcl, of course.
Comparing Tcl/Tk with C++/MFC is certainly interesting. If you've read
the Tcl/Tk review in Windows Tech Journal, you may have noticed that
Tcl/Tk is compared to VB, not the other way around. (Not that this
means anything: readers of that review will more likely already be
familiar with VB.) A text box mentions that Ousterhout is working on
an interface building tool, "similar to Visual Basic and NeXTStep,
called SpecTcl." Is SpecTcl available yet? It sounds like it could
make Tcl/Tk a lot more attractive for Windows developers.
Unfortunately, the closest material that I can find in this magazine,
for the last year, is stuff about AciveX scripting. Almost everything
else is about VB or C++.
> - From this standpoint having players who are on the same "team" compete
> against one another is meaningless.
Which team is this? If you mean VB and Tcl programmers, well, I'm not
sure that they even know that each other exist, never mind playing on
the same "team". While two tools may address similar problems, you'd
have to be pretty naive to expect the people who use them to
appreciate the value of any alternatives.
This thread should be more than enough evidence of that, but if it
isn't, then consider the years of bickering about the value of this,
the virtues of that, and frustration of the other.
> - From the point of the white paper, we should have contests between VB
> and VC++ to illustrate the the paper's thesis in the Win-tel realm and
> we should have contests between TCL and <insert your favorite *system
> programming* language> to illustrate the thesis in the UNIX realm.
There's also the "look and feel" factor. I've read that Tk for Windows
can now do a Windows "look and feel", which is excellent. Tk really
needs that, if you want Windows people to accept it. The X Windows
"look and feel" just won't do, I'm afraid. I know that X Windows is a
lot more flexible than MS Windows, but this is _exactly_ why Windows
people won't accept anything that deviates from the "standard"
behaviour - unless it's MS software, of course.
Encarta is a prime example of how MS can break their own rules and get
away with it, if they make the software atrractive enough. I gues if
you define the "rules", you can change 'em, too. Anyway...
> Changing the subject, I'd have to say that MFC used with MSVC++ is
> much more productive than writing directly to the Win32 API (I'm not
> going to quibble about the exceptions to this generalization). While
> much of this could be attributed to MSVC++'s gui building
> functionality, I think that *implementation inheritance* works well
> for MFC (contradicting Ousterhout's proposition ...).
It's certainly more productive than a lot of things, for apps that
have a user interface that uses features already supported by MFC. For
example, the document/view classes help with a lot of MDI apps. This
is another "look and feel" issue, only at the app level rather than
the "window manager" level. If you prefer to ignore the official style
guide (I have the old IBM CUA book, but not the more recent MS guide),
then you'll probably have more work to do, even if you do use MFC.
> As for VB verses MSVC++, I know several windows developers who have
> used both environments for professional development and they all rave
> about how great VB is for creating (non computationally intensive)
> applications.
Most Windows apps are "non computationally intensive", as many of them
only need to call code in other components - written in C++, no doubt.
This is one the qualities that VB has in common with Tcl. VB is great
for glueing components (OLE,OCX,DLL,etc) together. The VB part of an
app need only provide the user interface, and even that might mostly
be done by OCX components. Does this sound like Tcl/Tk or what?
> I haven't heard one person slander VB's ability to build GUI
> applications quickly and effectively.
Same here. I'd love to see the same kind of interface builder working
with other languages. Borland did this with their Pascal (yes, son,
Pascal is _still_ alive and kicking), with stunning results. If you
think that Pascal is obscure, then consider what could be done with a
more "popular" language (take your pick).
> This anecdotal evidence supports Ousterhout's claim that "scripting"
> language are better at being "glue".
Err, what? Did I miss something? Better than C++, maybe, but that's
not saying anything. Delphi can beat the crap out of VC++, as can VB.
If you look at other platforms, let's not overlook Guile, or any other
alternative. However, for Win32, it would be pretty hard to beat VB.
I'm wondering if ActiveX might help change that, but it's too early to
tell. Right now, ActiveX looks like a great way to embed VB or Java in
your MFC apps! Not exactly what many of us would prefer, I bet!
If "anecdotal evidence" is such a good argument, then VB/Java/C++ will
easily beat everything else. Most people think they _already have_. I
don't think that any of our arguments will convinec them otherwise,
but we can certainly try. However, IMHO we may need to be a little
more honest about the strengths and the failings of our tools, coz I'm
sure that the marketing folk at MS and Sun won't be.
Ousterhout at least got one thing "right", in that his arguments for
Java will be very welcome to all the people who've already chosen (or
think that _they've_ chosen) that language. Your pro-Tcl arguments
will probobaly fall on as many deaf ears as my pro-Lisp arguments. ;)
BTW, if your newsreader can't crosspost, then ignore this criticism -
we can't all choose our newreaders, but most of us can, hence the use
of the "cheap trick" (see below) with followups. So, just let us know,
and we can reset the newsgroup list accordingly.
However, I see that you're using Gnus v5.1. Either this software is
unable to crosspost (which I seriously doubt!), or you should upgrade
to a more recent version, like Gnus v5.3. So...
Thanks for setting your followups to comp.lang.tcl, but I'm not stupid
enough to fool for that old trick. If you want a "debate", then let's
have one where everyone can join in, rather than just those who will
more likely agree with you. I could easily set the followups for
_this_ article to comp.lang.basic.visual.misc, but I don't use cheap
tricks like that.
--
<URL:http://www.wildcard.demon.co.uk/> You can never browse enough
Martin Rodgers | Programmer and Information Broker | London, UK
Please note the "gubbish" in my email address.