Q) Preception is not reality?
getwel...@yahoo.ca
I am amazed at how quick it is to get some message boxes on the
screen, lables and dialog boxes.
I am more amazed that more people do not seem to be aware of the speed
of getting an "idea" up and running in Tcl/Tk. I wonder if with all
the media and promotion (about 5 or more glossy mags) of Java, that
people are just not aware of how useful Tcl/Tk can be? It seems to me
that much of what people use Java for can be done in Tcl/Tk. I found
that doing simple things in Tcl/Tk runs so much faster in "runtime"
than Java on my old computer 200MHz.
I will be taking a more seriously look into Tcl/Tk. It seems that
Tcl/Tk does "multi-platform" write once and run everywhere better than
Java without being too slow on older computers.
TIA
js
// signature ------------------------------------
Improve your life, get better health and income!
See http://www.lifeforce-intl.com/134808
Hundreds of people believe it is very good!
// ---------------------------------------------------
Jeff Godfrey
<getwel...@yahoo.ca> wrote in message
news:3d2337df...@news.bcsupernet.com...
[...]
>
> I will be taking a more seriously look into Tcl/Tk. It seems that
> Tcl/Tk does "multi-platform" write once and run everywhere better than
> Java without being too slow on older computers.
Ding, ding, ding! Get that boy a prize! :-)
Jeff Godfrey
[...]
>
> I will be taking a more seriously look into Tcl/Tk. It seems that
> Tcl/Tk does "multi-platform" write once and run everywhere better than
> Java without being too slow on older computers.
Ding, ding, ding! Get that boy a prize! :-)
Cameron Laird
<getwel...@yahoo.ca> wrote:
>Hello All:
>
>I am amazed at how quick it is to get some message boxes on the
>screen, lables and dialog boxes.
>
>I am more amazed that more people do not seem to be aware of the speed
>of getting an "idea" up and running in Tcl/Tk. I wonder if with all
>the media and promotion (about 5 or more glossy mags) of Java, that
>people are just not aware of how useful Tcl/Tk can be? It seems to me
>that much of what people use Java for can be done in Tcl/Tk. I found
>that doing simple things in Tcl/Tk runs so much faster in "runtime"
>than Java on my old computer 200MHz.
>
>I will be taking a more seriously look into Tcl/Tk. It seems that
>Tcl/Tk does "multi-platform" write once and run everywhere better than
>Java without being too slow on older computers.
.
.
Yes. Essentially all the evidence known to the locals here
confirms the accuracy of these propositions:
* Tcl/Tk does multi-platform ... better than
Java and is not too slow on older computers.
* Nearly all of what people do with Java can
be done with Tcl/Tk.
* Simple things are MUCH faster in Tcl/Tk than
Java.
* No, programmers as a whole do not have cor-
rect perceptions of Tcl/Tk.
Two of the desktops I most often use are rated at 100 and 133
MHz, respectively. Tcl/Tk gives me no performance problems.
For entertaining reading on the productivity of Java, see
<URL: http://groups.google.com/groups?th=5d11fda0f4672ef8 >
(keep reading until you come to the Java part, then realize
that this is no parody--everybody's serious).
--
Cameron Laird <Cam...@Lairds.com>
Business: http://www.Phaseit.net
Personal: http://starbase.neosoft.com/~claird/home.html
Wojciech Kocjan
> Hello All:
>
> I am amazed at how quick it is to get some message boxes on the
> screen, lables and dialog boxes.
>
> I am more amazed that more people do not seem to be aware of the speed
> of getting an "idea" up and running in Tcl/Tk. I wonder if with all
> the media and promotion (about 5 or more glossy mags) of Java, that
> people are just not aware of how useful Tcl/Tk can be? It seems to me
> that much of what people use Java for can be done in Tcl/Tk. I found
> that doing simple things in Tcl/Tk runs so much faster in "runtime"
> than Java on my old computer 200MHz.
True. True. This was also discussed on linux kernel discussion list -
since Tk is used in 'make xconfig' and somebody wondered about changing
it to Java (but I'm not sure I'm correct).
Tcl/Tk is definitely faster than Java widgets. It is multiplatform and
for Windows it can easily be wrapped, either with prowrap or freewrap.
The binary is much smaller (I once managed to get it down to about 500k
:). Take a look at snackAmp's binary version - it just cannot be done
with Java - at least not in about 1MB.
> I will be taking a more seriously look into Tcl/Tk. It seems that
> Tcl/Tk does "multi-platform" write once and run everywhere better than
> Java without being too slow on older computers.
Yeap. I use Tk for writing backends for managing websites.
It proved to be faster in development than web based administration
engines. The beginning was hard, but after I got the protocol and base
widget classes, adding new features mostly takes just hours. Not to
mention that it downloads everything at once, so you can edit data
without having to reload every god damn time. When I'll have time, I'll
write a very descriptive information on the project - it seems a quite
good success story for Tcl (especially that the web server is AOLserver
- and it all runs on Tcl).
I couldn't imagine writing same as above in Java... At least as quick
and convenient.
Besides, Tcl has one big advantage - it's very easy to write C/C++ code
for things that really do need a kick. Then it's faster than Java when
doing calculations.
ps. I agree with Jeff, you should get a prize :)
--
WK
"Data typing is an illusion. Everything is a sequence of bytes."
-Todd Coram
Donal K. Fellows
> For entertaining reading on the productivity of Java, see
> <URL: http://groups.google.com/groups?th=5d11fda0f4672ef8 >
> (keep reading until you come to the Java part, then realize
> that this is no parody--everybody's serious).
With rather more experience than I'd prefer, the problem with Java is really
that often not only is it taking a sledgehammer to crack a nut, it's a red
inflatable squeaky sledgehammer with a picture of a cartoon character on it...
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- A large ASCII art .sig is the Usenet equivalent of walking around in
public with your asscrack sticking out past the top of your sweatpants.
You be the judge. -- Mike Hoye <mh...@prince.carleton.ca>
Donal K. Fellows
> Ding, ding, ding! Get that boy a prize! :-)
For his prize, he gets the ability to quickly create surprisingly fast
cross-platform applications. That's my kind of prize... ;^)
Roy Terry
Bryan Oakley
>
> With rather more experience than I'd prefer, the problem with Java is really
> that often not only is it taking a sledgehammer to crack a nut, it's a red
> inflatable squeaky sledgehammer with a picture of a cartoon character on it...
>
> Donal.
Donal, I love your way with words! I'm going to have to stick this one
up on my wall.
getwel...@yahoo.ca
Oops, my fingers slipped, I mistyped Perception.
js
Mewtwo
Time for a reality check here.
Tcl/Tk is a great programming tool. I use it extensively and wish
I could use it for everything.
However:
1. Tcl does not have the programming coverage of Java, C/C++ or even Perl.
Java and C have APIs and libraries for everything you could need. Tcl
does not come close. Once you go beyond "simple" programs you quickly
run into trouble with standard Tcl/Tk and you need extensions.
2. As soon as you start using Tcl extensions like TclX, etc then the
cross-platform advantage goes out the window. And you nearly always do
need an extension. Standard Tcl/tk provides no facilities for handling
Unix signals or Windows events, nor does it suport any form of IPC other
thana simple TCP socket so it is not suitable for a large class of programs.
3. Writing your own Tcl extensions in C also removes the cross-
platform advantage and you have a maintenance problem to deal with. And
your advantage of rapid development compared to C and Java will be lost
to some extent. You also need developers to be competent in C and Tcl
instead of one programming language.
4. Tcl is not object-oriented. This is a debatable point. But the
slowness of adoption of support for object-oriented programming in Tcl
has been disappointing. And examples of OO Tcl in books and published
code seem almost non-existent.
So there it is. Tcl is great but it is not perfect yet.
George Peter Staplin
news:eb0be410.02070...@posting.google.com...
> Wojciech Kocjan <wojc...@n0spam-kocjan.org> wrote in message
news:<3D233FB...@n0spam-kocjan.org>...
> > getwel...@yahoo.ca wrote:
> > True. True. This was also discussed on linux kernel discussion list -
> > since Tk is used in 'make xconfig' and somebody wondered about changing
> > it to Java (but I'm not sure I'm correct).
> >
> > Tcl/Tk is definitely faster than Java widgets. It is multiplatform and
> > for Windows it can easily be wrapped, either with prowrap or freewrap.
> > The binary is much smaller (I once managed to get it down to about 500k
> > :). Take a look at snackAmp's binary version - it just cannot be done
> > with Java - at least not in about 1MB.
> >
> > > I will be taking a more seriously look into Tcl/Tk. It seems that
> > > Tcl/Tk does "multi-platform" write once and run everywhere better than
> > > Java without being too slow on older computers.
> > I couldn't imagine writing same as above in Java... At least as quick
> > and convenient.
> >
> > Besides, Tcl has one big advantage - it's very easy to write C/C++ code
> > for things that really do need a kick. Then it's faster than Java when
> > doing calculations.
> >
> > ps. I agree with Jeff, you should get a prize :)
>
> Time for a reality check here.
I agree.
> Tcl/Tk is a great programming tool. I use it extensively and wish
> I could use it for everything.
>
> However:
>
> 1. Tcl does not have the programming coverage of Java, C/C++ or even Perl.
> Java and C have APIs and libraries for everything you could need. Tcl
> does not come close. Once you go beyond "simple" programs you quickly
> run into trouble with standard Tcl/Tk and you need extensions.
This reminds me of the Bill Gates quote. IIRC he said that "Tcl is great
for writing a cross-platform Hello World application" (quoted on the
tclsucks website (if that still exists)).
> 2. As soon as you start using Tcl extensions like TclX, etc then the
> cross-platform advantage goes out the window. And you nearly always do
> need an extension. Standard Tcl/tk provides no facilities for handling
> Unix signals or Windows events, nor does it suport any form of IPC other
> thana simple TCP socket so it is not suitable for a large class of
programs.
Most of my projects have eventually led to using platform specific
extensions due to some attribute of Tcl and/or Tk being too slow.
> 3. Writing your own Tcl extensions in C also removes the cross-
> platform advantage and you have a maintenance problem to deal with. And
> your advantage of rapid development compared to C and Java will be lost
> to some extent. You also need developers to be competent in C and Tcl
> instead of one programming language.
Java suffers from slowdowns in many areas, so maybe the one language
approach is problematic, but it sure seems nicer.
> 4. Tcl is not object-oriented. This is a debatable point. But the
> slowness of adoption of support for object-oriented programming in Tcl
> has been disappointing. And examples of OO Tcl in books and published
> code seem almost non-existent.
Well, I doubt the father (Alan Kay) of the term object-oriented would
disagree. Subclassing a widget seems like a common thing to do, but it
feels hackish doing it in the current Tcl and Tk. If Tcl had a proper
mechanism for this it would be nice. Early on Tcl had BOS for Tcl and Tk
that provided subclassing, but AFAIK it's a dead project:
http://www.idiom.com/free-compilers/LANG/Tcl-1.html
I would really like to see a way to overload/extend core Tcl and Tk
functions without dealing with private functions and structs. Encapsulation
may be useful in some cases, but often it hinders progress, unless an
interface is very well thought out.
There are OO Tcl books, but they don't appear in bookstores where I live. I
ordered the [Incr Tcl/Tk] from the Ground Up book, and I decided afterwards
that I didn't like Incr Tcl. I then wrote my own object system for a little
game I was working on.
> So there it is. Tcl is great but it is not perfect yet.
It probably will never be perfect until all comments are removed and a
person with modest skills can understand it regardless of whether or not a
comment exists. This would probably require a rewrite from the ground up in
a language other than C (unless a new C standard is more dynamic). You comp
science geeks will probably hate this, because it makes all those hours of
ripping your hair out trying to figure out why some random address is
getting overwritten seem wasted.
Regards,
George
Michael Schlenker
libraries or the huge java class library.
Take a standard wish/tclsh and fill in about 6 MB of extensions to come
close to java in volume. The only benefit
of Java, that i see is the large amount of libraries.
>
> 2. As soon as you start using Tcl extensions like TclX, etc then the
> cross-platform advantage goes out the window. And you nearly always do
> need an extension. Standard Tcl/tk provides no facilities for handling
> Unix signals or Windows events, nor does it suport any form of IPC other
> thana simple TCP socket so it is not suitable for a large class of programs.
Not entirely true. Have you seen Combat by Frank Pilhofer, a CORBA ORB
in pure Tcl...,
and there is SOAP etc, also pure TCL.
>
> 3. Writing your own Tcl extensions in C also removes the cross-
> platform advantage and you have a maintenance problem to deal with. And
> your advantage of rapid development compared to C and Java will be lost
> to some extent. You also need developers to be competent in C and Tcl
> instead of one programming language.
Depends. Yes, C-Code is stopping some of the impact, but coding a simple
extension is very easy,
especially if using things like CriTCL. It largely depends on the volume
of C-Code or Java Code (TclBlend) involved.
>
> 4. Tcl is not object-oriented. This is a debatable point. But the
> slowness of adoption of support for object-oriented programming in Tcl
> has been disappointing. And examples of OO Tcl in books and published
> code seem almost non-existent.
True, but the count of TCL only or C-Extensions that provide OO is
large, using OO with TCL is not really a problem.
> So there it is. Tcl is great but it is not perfect yet.
Tcl will never be, but maybe we can move it inside a small epsilon
environment of perfection :-).
Michael Schlenker
Mark O'Connor
direction in the TCL language.
The learning curve is too steep, not because TCL is complicated, but
because by the time you realise that TCL can solve any problem you
throw at it, you need to be quite experienced.
In the 7.6 days (Admittedly I was a novice then, so please don't flame
me for historical inaccuracies) TCL was infuriating because all the
extensions I needed all seemed to be statically compiled into the
interpretor executable.
Version 8.0 came along and changed my world. Not only was it faster
but it also had dynamically loaded extension libraries.
Slowly people began to write their extensions as dynamically loaded
packages.
Finally with version 8.xxx, TCL was language that encompassed all the
advantages of PERL and PYTHON however if one reads the internet you
still told that PERL or PYTHON have features that TCL lacks.
Python has an enormous amount of goodies that come with the standard
distribution. This means I can write a piece of code in python and
simply mail it to a colleague secure in the knowledge that it will run
on his machine.
The TCLLIB project has helped in the area but there are not enough
projects being included in the Active State distribution.
I am promoting code bloat! Why not? I want the TCL luminaries out
there to endorse MORE packages and get them included in the "batteries
included" distributions from Active State.
If maintanence is an issue then perhaps the role of TclLib should be
expanded?
Standardisation does not restrict a developer in any way but it might
go some way to improving the image of TCL.
It would I believe have a knock-on effect:
1) Documentation is improved because more people are using the code
(Incr TCL should be more widely supported to demonstrate that TCL can
support OOP).
2) More platforms supported (Many XML extensions do not support
Windows)
Regards,
MArk
Cameron Laird
Mark O'Connor <ma...@tellcare.com> wrote:
.
.
.
>2) More platforms supported (Many XML extensions do not support
>Windows)
.
.
You're working with XML-oriented extensions to Tcl
unsupported on Windows? Which are those? I suspect
that someone has already addressed that deficiency;
perhaps we can help point you toward a more modern
version that will serve you better.
Donal K. Fellows
> Well, I doubt the father (Alan Kay) of the term object-oriented would
> disagree. Subclassing a widget seems like a common thing to do, but it
> feels hackish doing it in the current Tcl and Tk. If Tcl had a proper
> mechanism for this it would be nice. Early on Tcl had BOS for Tcl and Tk
> that provided subclassing, but AFAIK it's a dead project:
> http://www.idiom.com/free-compilers/LANG/Tcl-1.html
FWIW, I don't like subclassing widgets at all. I'd much rather have widgets
that are configured like in Tcl as it currently stands, as their behaviour tends
to be much easier to predict. I believe that many people use subclassing
because (a) that's the only way their toolkit provides for customizing look,
feel and behaviour, and (b) OO is the only hammer they know, so naturally
widgets look like nails to subclass...
</rant>
Donal.
--
"[He] would have needed to sell not only his own soul, but have somehow gotten
in on the ground floor of an Amway-like pryamid scheme delivering the souls
of kindergarten students to Satan by the truckload like so many boxes of Girl
Scout Cookies." -- John S. Novak, III <j...@concentric.net>
Donal K. Fellows
> 1. Tcl does not have the programming coverage of Java, C/C++ or even Perl.
> Java and C have APIs and libraries for everything you could need. Tcl
> does not come close. Once you go beyond "simple" programs you quickly
> run into trouble with standard Tcl/Tk and you need extensions.
Tcl is *meant* to be used with extensions! That you can do useful amounts of
stuff without them is cool, but the extensions are the most important part of
the language (and I include Tk in the list of extensions; they just happen to
almost always be distributed together.)
Note that people are encouraged these days to get their distributions from
ActiveState who do a very nice batteries-included distribution which gives you a
lot of the bits you might want in a single piece.
> 2. As soon as you start using Tcl extensions like TclX, etc then the
> cross-platform advantage goes out the window. And you nearly always do
> need an extension. Standard Tcl/tk provides no facilities for handling
> Unix signals or Windows events, nor does it suport any form of IPC other
> thana simple TCP socket so it is not suitable for a large class of
> programs.
Unix signals aren't portable to non-Unix platforms. :^)
Tk (on X) supports an additional mode of IPC via the [send] command, though that
is completely X-specific at the moment. IIRC, there's something on Macs too,
and we distribute a DDE extension for Windows. Aside from that, there's a
number of (non-core) extensions that do IPC in various forms, such as TclDP and
various embeddings of both ORBs and (D)COM (or whatever MS wants to call it
today.) Sure, they might not be distributed with the core, but they are
first-class citizens.
> 3. Writing your own Tcl extensions in C also removes the cross-
> platform advantage and you have a maintenance problem to deal with. And
> your advantage of rapid development compared to C and Java will be lost
> to some extent. You also need developers to be competent in C and Tcl
> instead of one programming language.
You say that Tcl extensions can be written in C, but then in almost the same
breath you complain that this means you need a programmer that knows both Tcl
and C! Well, duh! (Actually, with the use of SWIG and ffidl, this can be made
much simpler, and CriTcl allows for RAD Tcl/C co-development.)
> 4. Tcl is not object-oriented. This is a debatable point. But the
> slowness of adoption of support for object-oriented programming in Tcl
> has been disappointing. And examples of OO Tcl in books and published
> code seem almost non-existent.
OO's not all its cracked up to be, but as there's been the highly-stable Itcl
available for ages as a packaged extension, and there's also XOTcl and Stooop
(and probably others) available, I don't see what the big fuss is about. OO is
there for anyone who wants it.
And on the topic of books, there just plain doesn't seem to be enough Tcl books
(either in relation to OO or not) in print at the moment. But then the whole
computer book publishing output has been rubbish for several years now. Don't
know why. Come on, people! If you can get books worth buying into the
bookstores, I'll buy them! I just won't shell out for "Dummies in a Nutshell
Unleashed in 24 Hours, Third Edition" if it doesn't have something worthwhile in
it...
Cameron Laird
Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
.
.
.
>FWIW, I don't like subclassing widgets at all. I'd much rather have widgets
>that are configured like in Tcl as it currently stands, as their behaviour tends
>to be much easier to predict. I believe that many people use subclassing
>because (a) that's the only way their toolkit provides for customizing look,
>feel and behaviour, and (b) OO is the only hammer they know, so naturally
>widgets look like nails to subclass...
.
.
We really need to write this up as a coherent essay: "Two
perspectives on GUI toolkit configuration". There's quite
a gulf between people who truly believe subclassing is the
only possible approach and, well, us.
In different words: I get your point, and I'd like to see
it said more completely.
Part of my interest in this is a suspicion that, if I worked
on this more, I might renew my sympathy for object-oriented
subclassing. Right now I have little (although, for example,
I recognize George is a programmer who makes good use of it).
Cameron Laird
>> 1. Tcl does not have the programming coverage of Java, C/C++ or even Perl.
>> Java and C have APIs and libraries for everything you could need. Tcl
>> does not come close. Once you go beyond "simple" programs you quickly
>> run into trouble with standard Tcl/Tk and you need extensions.
>
>Tcl is *meant* to be used with extensions! That you can do useful amounts of
>stuff without them is cool, but the extensions are the most important part of
>the language (and I include Tk in the list of extensions; they just happen to
>almost always be distributed together.)
>
>Note that people are encouraged these days to get their distributions from
>ActiveState who do a very nice batteries-included distribution which gives you a
>lot of the bits you might want in a single piece.
.
.
I think Mewtwo wrote things that need to be said; a portrayal
of Tcl without them is incomplete. What Mewtwo wrote is also
incomplete.
On Mewtwo's point 1., I want to reinforce and even extend
Donal's counterclaims. Yes, "Tcl does not have the programming
coverage of Java, C/C++ or even Perl." As a regular worker in
Java, C/C++, and Perl, I think it's important to emphasize that
Tcl isn't necessarily inferior to these others, just different.
If it accomplishes a meaningful purpose, I can tell of PLENTY or
problems in STL, J2EE, CPAN, and most of the other decorations
that are supposed to establish Tcl's inferiority.
Here's one, in particular: when I teach about Web Services, I
prefer to use Tcl. Yes, all those other languages (well, not C--
the situation there is hilariously deformed) have WS capabilities
that, on paper, far exceed Tcl's. They're all a mess, as far as
I'm concerned. I can start someone who doesn't know Tcl from
scratch, and have ActiveTcl or Kitten downloaded and installed,
and start real programming, even by a first-time Tcl-er, in less
time than it takes to get a Perl or Java development environment
fixed up to where it does anything recognizable. Claims that J2EE
or CPAN solve all library problems simply don't connect to the
reality I experience (incidental remark: I'm a CPAN contributor,
and I've got stuff I've been trying to correct for YEARS, with no
resolution in sight. Yes, Larry, I know you're waiting on me).
Almost exactly the same can be said about GUI toolkits. Java's
cross-platform ... well, let's leave this subject for another time.
Mark O'Connor
Sorry Cameron,
That statement was a bit dramtic and should be qualified :-(
I am currently doing a lot of XSLT programming and I cannot get a good
TCL extension available on windows.
Pure TCL extensions will obviously also work under Windows however there
are a number that rely on 3rd party libraries or C code that needs to be
first compiled (Example tclDOM and tDOM projects).
Currently I "exec" the Sablotron program within my TCL code in order to
transform XSLT.
Regards,
MArk
Donal K. Fellows
> Almost exactly the same can be said about GUI toolkits. Java's
> cross-platform ... well, let's leave this subject for another time.
Java/Swing is the red squeaky inflatable sledgehammer of GUI toolkits...
Rolf Ade
Mark O'Connor <ma...@tellcare.com> wrote:
>I am currently doing a lot of XSLT programming and I cannot get a good
>TCL extension available on windows.
>Pure TCL extensions will obviously also work under Windows however there
>are a number that rely on 3rd party libraries or C code that needs to be
>first compiled (Example tclDOM and tDOM projects).
At least for tDOM this should not be a problem anymore. (If it was
ever. I've provided MS .dll's for a couple of tDOM versions in the
last almost two years.) Just point your browser to
http://sdf.lonestar.org/~loewerj/tdom.cgi or
http://loewerj.freeshell.org/tdom.cgi (which ever of the two urls is
working at the moment) and grab the ready to run .dll.
Compiling the dll by yourself was a bit a not so easy task in the
past, but I've tantalized myself, to even improve this. With VC 6.0 it
should now simply a matter of `nmake -f makefile.vc` in the win dir.
Just let me know, if you have any problem.
rolf
Darren New
> 4. Tcl is not object-oriented. This is a debatable point. But the
> slowness of adoption of support for object-oriented programming in Tcl
> has been disappointing. And examples of OO Tcl in books and published
> code seem almost non-existent.
I think the need for OO techniques is greatly reduced by a language with
[eval] and [info] and dynamically-sized structures built in. This may be why
you see less OO in Tcl than in some of the other languages.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
** http://home.san.rr.com/dnew/DNResume.html **
** http://images.fbrtech.com/dnew/ **
Proud to live in a country where "fashionable"
is denim, "stone-washed" faded, with rips.
Michael Schlenker
>
> Sorry Cameron,
>
> That statement was a bit dramtic and should be qualified :-(
>
> I am currently doing a lot of XSLT programming and I cannot get a good
> TCL extension available on windows.
> Pure TCL extensions will obviously also work under Windows however there
> are a number that rely on 3rd party libraries or C code that needs to be
> first compiled (Example tclDOM and tDOM projects).
>
them from the usual places.
Michael Schlenker
lvi...@yahoo.com
According to Donal K. Fellows <fell...@cs.man.ac.uk>:
:Mewtwo wrote:
:> 1. Tcl does not have the programming coverage of Java, C/C++ or even Perl.
:> Java and C have APIs and libraries for everything you could need. Tcl
:> does not come close. Once you go beyond "simple" programs you quickly
:> run into trouble with standard Tcl/Tk and you need extensions.
:
:Tcl is *meant* to be used with extensions! That you can do useful amounts of
:stuff without them is cool, but the extensions are the most important part of
:the language (and I include Tk in the list of extensions; they just happen to
:almost always be distributed together.)
I don't see how Java and C are any different than Tcl in this respect.
Java the language has very little functionality - most of it is in the
various APIs that were (and continue to be) defined. C also has little
functionality.
The most important thing that C or Java have that Tcl does not have is
a concerted effort to hammer out APIs as a community. But then, the same
is true of C. Java's increasing class libraries distributed in the SDK
come from community work on defining and implenting the the APIs for
experimentation.
--
Support Internet Radio <URL: http://saveinternetradio.org/ >
Join Tcl'2002 in Vancouver http://www.tcl.tk/community/tcl2002/
Even if explicitly stated to the contrary, nothing in this posting
should be construed as representing my employer's opinions.
Kristoffer Lawson
>
> 4. Tcl is not object-oriented. This is a debatable point. But the
> slowness of adoption of support for object-oriented programming in Tcl
> has been disappointing. And examples of OO Tcl in books and published
> code seem almost non-existent.
I think this misses the point. Tcl is a commant-oriented language. In a way
one of the greatnesses of Tcl is that it is not really structure-oriented.
The syntax itself does not provide for any programming methodology. [proc]
itself is just a command. So fundamentally Tcl allows you to apply any
programming style. OO doen't come by default with "tclsh", but you
only need one line to use that particular style.
In the future, when new styles (like aspect oriented programming) emerge, Tcl
will be there to support them.
Kristoffer Lawson
>> Almost exactly the same can be said about GUI toolkits. Java's
>> cross-platform ... well, let's leave this subject for another time.
>
> Java/Swing is the red squeaky inflatable sledgehammer of GUI toolkits...
QOTW ;-)
Gerald W. Lester
>
> Wojciech Kocjan <wojc...@n0spam-kocjan.org> wrote in message news:<3D233FB...@n0spam-kocjan.org>...
> > getwel...@yahoo.ca wrote:
> Time for a reality check here.
>
> Tcl/Tk is a great programming tool. I use it extensively and wish
> I could use it for everything.
>
> However:
>
> 1. Tcl does not have the programming coverage of Java, C/C++ or even Perl.
> Java and C have APIs and libraries for everything you could need. Tcl
> does not come close. Once you go beyond "simple" programs you quickly
> run into trouble with standard Tcl/Tk and you need extensions.
To get all of the Java APIs, try TclBlend. Of course you still have do
download the jar files and stick them in your classpath (unless you want
to assume that you are connected to the net when you need them).
As for the C APIs, those are a bit more trouble, as you point out
later. Of course getting and installing (correctly) all those APIs are
a bit of trouble, particularly if it is on Windows and require registry
entries.
> 2. As soon as you start using Tcl extensions like TclX, etc then the
> cross-platform advantage goes out the window. And you nearly always do
> need an extension. Standard Tcl/tk provides no facilities for handling
> Unix signals or Windows events, nor does it suport any form of IPC other
> thana simple TCP socket so it is not suitable for a large class of programs.
Red herring alert!!!! Unix signals and Windows events are by their
nature non-portable. If you are using them, then by definition your
code is non-protable. Of course, in Tcl you can overcome this to an
extent by doing different package requires based on the contents of
::tcl_platform(platform) -- it is a bit harder (impossible?) to do in
C/C++/Java.
> 3. Writing your own Tcl extensions in C also removes the cross-
> platform advantage and you have a maintenance problem to deal with. And
> your advantage of rapid development compared to C and Java will be lost
> to some extent. You also need developers to be competent in C and Tcl
> instead of one programming language.
Red herring alert!!!! As opposed to doing the entire program in C/C++?
Or if the Java API is not available for what you need (see comment about
TclBlend) using JNI???
> 4. Tcl is not object-oriented. This is a debatable point. But the
> slowness of adoption of support for object-oriented programming in Tcl
> has been disappointing. And examples of OO Tcl in books and published
> code seem almost non-existent.
There is not one, but several OO "extensions" for Tcl -- at least one
for each OO camp. In Java/C++ you are stuck with a particular OO camp.
As to the dearth of books ... IMHO there are a lot of Java/C++/etc books
out there -- most are really bad.
> So there it is. Tcl is great but it is not perfect yet.
This side of the Second Coming, nothing is perfect!
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester | "The man who fights for his ideals is
|
| Gerald...@cox.net | the man who is alive." -- Cervantes
|
+--------------------------------+---------------------------------------+
Mark O'Connor
I would have to agree with this comment whole-heartly. Tcl's lack of
structure is both a blessing and a curse.
A blessing in that it proves that programming does not have to be
difficult.
The main reason one has types is normally because of the restrictions
imposed by the underlining hardware abstractions.
In the old days TCL was critized for it's lack of types, "everything is
a string" became a mantra equated with "TCL is slow".
I must admit that some programming applications require complex data
structures and this is where my TCL code has become a nightmare to read.
incrTCL has allows me to address this point add as much structured data
complexity as my little mind can dream up!
HOWEVER. I submit that most people I interact with professionally either
do not know TCL or have been wedded in the past to languages such as
Perl, Python or Java.
When compared to these languages TCL has always been dismissed with the
old cliches: "Not strongly typed", "Not object oriented", "Poor
performance".
Why cannot we publish and promote that TCL is object oriented?
Endorse incrTCL to the world and provide MANY more examples of its use.
Like it or not this is currently the world's most popular programming
doctrine and without this pre-requisite TCL will not be taught or
recommended.
We all know the truth and can always choose not to use the extension to
the language.
Arjen Markus
>
> I think the need for OO techniques is greatly reduced by a language with
> [eval] and [info] and dynamically-sized structures built in. This may be why
> you see less OO in Tcl than in some of the other languages.
>
I would like to propose the above for the QOTW!
Regards,
Arjen
Donal K. Fellows
> Of course, in Tcl you can overcome this to an extent by doing different
> package requires based on the contents of ::tcl_platform(platform) -- it
> is a bit harder (impossible?) to do in C/C++/Java.
It is most certainly possible to load different code depending on the platform
using Java. Just look at the right system property (which I'm not about to look
up), and use that to change what class you ask for, what native library you load
or what class-loader you use.
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ fell...@cs.man.ac.uk
-- Anyone using MFC desperatly needs a nasal enigma.
-- David Steuber <tras...@david-steuber.com>