Java/Tcl?

1 view
Skip to first unread message

Frank D. Greco

unread,
Jul 20, 1996, 3:00:00 AM7/20/96
to

cyg...@well.com (Brian M. Long) sez:

>Can someone paint a "big picture" of how Java, Joe, Tcl/Tk all play
>together in Sun's strategy for the internet, or are they merely cases of
>a large corporation's right, middle, and left hands not knowing what each
>other are doing?

You really should ask SunSoft and JavaSoft this question.

But imho, thank goodness Sun modified the current cover page
of their web site. Their tcl/tk plugin for Nescape was
attempting to take some attention away from Java. It
read like it was a competitor for Java. Looked like
a PR screwup to me.

It should be Java, Java, Java...

The tcl/tk plugin is interesting, but it should have
been announced as a more powerful alternative to Javascript,
and not as an alternative to Java. Bad move imho.

Frank G.
- class Madness {
int method1()...
int method2()... "methods to my Madness"
int method3()...
};

+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Crossroads Technologies, Inc. |
| email: fgr...@crossroads-tech.com |
| voice: (908)-872-9048 |
| fax: (908)-872-9052 |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+

John Ousterhout

unread,
Jul 22, 1996, 3:00:00 AM7/22/96
to

In article <31f03e09...@news.monmouth.com>, fgr...@crossroads-tech.com (Frank D. Greco) writes:
|> cyg...@well.com (Brian M. Long) sez:
|>
|> >Can someone paint a "big picture" of how Java, Joe, Tcl/Tk all play
|> >together in Sun's strategy for the internet, or are they merely cases of
|> >a large corporation's right, middle, and left hands not knowing what each
|> >other are doing?
|>
|> You really should ask SunSoft and JavaSoft this question.
|>
|> But imho, thank goodness Sun modified the current cover page
|> of their web site. Their tcl/tk plugin for Nescape was
|> attempting to take some attention away from Java. It
|> read like it was a competitor for Java. Looked like
|> a PR screwup to me.
|>
|> It should be Java, Java, Java...
|>
|> The tcl/tk plugin is interesting, but it should have
|> been announced as a more powerful alternative to Javascript,
|> and not as an alternative to Java. Bad move imho.

Actually, that is exactly what it *was* announced as, except that Tcl/Tk
is intended more to compete with Visual Basic than JavaScript. Tcl/Tk is
no more a replacement for Java than sh is for C or Visual Basic is for C++.
Tcl/Tk is intended for scripting (e.g., little things), while Java is best
at system programming tasks (e.g., big things). This is said many times
in the Web story, as well as in the accompanying press release.

By the way, the cover story will be back again in a couple of weeks. We
temporarily gave up the cover for the House Of Blues story for the
Olympics.

Tientien Li

unread,
Jul 22, 1996, 3:00:00 AM7/22/96
to

In article <4t0bea$o...@engnews2.Eng.Sun.COM>, ous...@tcl.eng.sun.com (John Ousterhout) writes:
>In article <31f03e09...@news.monmouth.com>, fgr...@crossroads-tech.com (Frank D. Greco) writes:
[...]

>|>
>|> The tcl/tk plugin is interesting, but it should have
>|> been announced as a more powerful alternative to Javascript,
>|> and not as an alternative to Java. Bad move imho.
>
>Actually, that is exactly what it *was* announced as, except that Tcl/Tk
>is intended more to compete with Visual Basic than JavaScript. Tcl/Tk is
>no more a replacement for Java than sh is for C or Visual Basic is for C++.
>Tcl/Tk is intended for scripting (e.g., little things), while Java is best
>at system programming tasks (e.g., big things). This is said many times
>in the Web story, as well as in the accompanying press release.
>

John,... I like your Tcl/Tk and am impressed with the new plug-in...

But Tck/Tk scripts embeded on Web pages look and behave very much like Java
applets... The plug-in can do almost every *useful* things that Java applets
can do, and may be more... Therefore, it's not surprisingly so many people
see there is a significant overlap in the application domain between Java
Applets and Tcl/Tk plug-ins...

As you've said, the Tcl/Tk plug-in is intended more to compete with Visual
Basic than JavaScript... Unfortunately, Microsoft don't move VB to compete
with Java on the WebTop... instead, Bill G. correctly positioned VBScript to
against JavaScript, and embraced Java as their WebTop programming language!

That's a very smart move... The scripting language war is *THE* main battle
ground on the WebTop... Tcl/Tk could have been a powerful client/server side
scripting langague with GUI support... But, as I've pointed out 6 month ago,
NetScape and Sun have both missed the opportunity to do so... Now, NS/Sun
only have a much weaker JavaScript to compete against VBScript, instead of
using the much stronger and maturer technology like Tcl/Tk...

Sigh... it's not your fault... but, the Tcl/Tk plug-in is really at the
wrong place on the WebTop competing against no one but Java... and, to
make the problem worse, the plug-in can, in some cases, do a much better
job than Java can!

--
Tientien Li
l...@tientien.com


Jin Hong

unread,
Jul 23, 1996, 3:00:00 AM7/23/96
to

My platform is Win95.
Using jview.exe to start an application, System.out.println
works before show() a frame, but not working after.
Is this a bug?

java.exe works here but not working with VJ++ debug.

BTW, is there anything like Netscape's Java Concole in IE?
It's useful in debugging.

Jin

Werner Punz - Dipl

unread,
Jul 24, 1996, 3:00:00 AM7/24/96
to

> That's a very smart move... The scripting language war is *THE* main battle
> ground on the WebTop... Tcl/Tk could have been a powerful client/server side
> scripting langague with GUI support... But, as I've pointed out 6 month ago,
> NetScape and Sun have both missed the opportunity to do so... Now, NS/Sun
> only have a much weaker JavaScript to compete against VBScript, instead of
> using the much stronger and maturer technology like Tcl/Tk...
>
> Sigh... it's not your fault... but, the Tcl/Tk plug-in is really at the
> wrong place on the WebTop competing against no one but Java... and, to
> make the problem worse, the plug-in can, in some cases, do a much better
> job than Java can!
>
> --
> Tientien Li
> l...@tientien.com

I did some stuff with tcl/tk two years ago (a multiuser editor for a university course)
and I have to admit that it has some severe weaknesses which makes it the wrong choice
as a programming language:

1 almost as cryptical as perl with less functionality
2 no supported project management language structures (libraries,modules etc)
3 windowing support is somehow plugged (dirtily) onto the top of the language without
any possibility to extend it without writing extensions in C
4 no net support without extensions which are written in C \
5 no record/struct definition allowed
6 painfully slow
7 no object orientation

I don't give this language a future on the net (unless somebody wants to torture
himself by programming in that stupidity of a language).
(Thats just my opinion about this language, but I also hate VB )

Werner

Peter Sulc

unread,
Jul 26, 1996, 3:00:00 AM7/26/96
to

In article <31F67433...@inflab.uni-linz.ac.at>,

Werner Punz - Dipl <we...@inflab.uni-linz.ac.at> wrote:
>> That's a very smart move... The scripting language war is *THE* main battle
>> ground on the WebTop... Tcl/Tk could have been a powerful client/server side
>> scripting langague with GUI support... But, as I've pointed out 6 month ago,
>> NetScape and Sun have both missed the opportunity to do so... Now, NS/Sun
>> only have a much weaker JavaScript to compete against VBScript, instead of
>> using the much stronger and maturer technology like Tcl/Tk...
>>
>> Sigh... it's not your fault... but, the Tcl/Tk plug-in is really at the
>> wrong place on the WebTop competing against no one but Java... and, to
>> make the problem worse, the plug-in can, in some cases, do a much better
>> job than Java can!
>>
>> --
>> Tientien Li
>> l...@tientien.com
>
>I did some stuff with tcl/tk two years ago (a multiuser editor for a university course)
>and I have to admit that it has some severe weaknesses which makes it the wrong choice
>as a programming language:
>
> 1 almost as cryptical as perl with less functionality

There are quite a few extensions available, and extending the language is
relatively easy. There is significantly more functionality than perl (IMHO),
but its slower.

> 2 no supported project management language structures (libraries,modules etc)

I think the paradigm of tcl is that you write the complex code in C/C++, and
use tcl as the glue.

> 3 windowing support is somehow plugged (dirtily) onto the top of the language without
> any possibility to extend it without writing extensions in C

This is just eroneous. You can "extend" tcl either in C, C++, or by writing
other tcl procs. As far as Tk goes, I have GUIed with X/Motif, I have GUIed
with Windows SDK/MFC, I have GUIed with Java ... I have GUIed directly to
the graphics card, but I have never GUIed as quickly as with Tk.

> 4 no net support without extensions which are written in C \

You are missing the point, its relatively easy no extend, and there are
some absolutely superb net extensions (scotty comes to mind) that kick but.

> 5 no record/struct definition allowed

ah yes. The real (and only legitimate point you've made) downfall of tcl.

> 6 painfully slow

Tk is about 1000 times faster than Java AWT on HP's amd Suns.

> 7 no object orientation
>

Yes, but not a deadly blow. One of the interesting features of a scripted
language is the absence of the distinction between code and data. This
can be very powerful.

>I don't give this language a future on the net (unless somebody wants to torture
>himself by programming in that stupidity of a language).
>(Thats just my opinion about this language, but I also hate VB )
>
>Werner


It may not have much of a future, but its better than JavaScript, and
the reason is that Sun's putting all its marketing hype behind Java,
and can't really be bothered much with tcl ... although, I wish
Ousterhout would go over to the Java AWT folks and teach them how to do
geometry management :)


Eric Vought

unread,
Jul 27, 1996, 3:00:00 AM7/27/96
to

> I doubt it. The code is interpreted as is. No p-code compilation, no
> Just in time compilation. The only fact that it might be faster on
> several occasions is-> there are no complex data structures to
> maintain, no object orientation (thus no VMT's), no moduling, etc...
> (All these things which make code to maintain easier and more readable
> if it is well written)

1000 times is probably an exageration (it is in my experience) but I
have seen many instances of where Tcl outpaces java AWT. One of the
large factors is loading time- it takes much less time to load some
Tcl/Tk programs than it does an "equivalent" (whatever that means) java
application. Another factor is that the Tk toolkit spends the majority
of its time in C code, not in interpreted code. The Tk widgets are very
high level and very efficient (on UNIX platforms which it is optimized
for). The scripting code is just glue in many instances. Think about
user interaction with a text widget, for instance. The text widget has
much more higher level functionality than the java equivalent. The
programmer has to write less Tcl code to get an equivalent level of
functionality than one would have to write java code to extend the java
text widget. With the inefficiencies in the
java<->AWT<->Motif/WinAPI/Whatever communication, this is a significant
difference.

I also disagree with your statement that tcl extensions are not
portable- they are highly portable if the are written against the Tcl
API and do not perform other non-portable work. They are, in fact just
as portable as the C code for the core Tcl functionality. Secondly,
extensions do get migrated into the core, especially from the TclX
package. Thirdly, there is simply no way to do non-portable operations
portably
(duh) the Java API misses a lot in this area as well and I have written
a good deal of C code to tie in with java in my own work.

I would have to agree that pure Tcl is not worthwhile for large (or even
medium) applications- possible, but not worthwhile. On the other hand,
the java AWT, as a library, is just not up to par. It is buggy,
incomplete, unstable, and much harder to extend than the Tk toolkit. At
the moment, the solution I am trying is combining Tcl and Java instead
of Tcl and C. The interface, configuration, and command language is Tcl,
and the internal structure and networking is provided by Java. So far,
this seems to be an ideal combination.


Werner Punz

unread,
Jul 27, 1996, 3:00:00 AM7/27/96
to

ps...@nyx10.cs.du.edu (Peter Sulc) wrote:
>> 1 almost as cryptical as perl with less functionality
>
>There are quite a few extensions available, and extending the language is
>relatively easy. There is significantly more functionality than perl (IMHO),
>but its slower.
>

Yes there are but none of them made it into standard tcl which is the
only thing which is truly platform independent and all my statements
regarded the standard tcl. And perl is still unsurpassed in string
handling. I once had to write some bigger CGI scripts. The person I
wrote them for wanted them in (standard)tcl but I implemented them in
perl because those scripts did lots of string operations and thats one
weak points of tcl (in fact I switched to perl after I saw it couldn't
be done in standard tcl and I hadn't enough time to do it in C).


>> 2 no supported project management language structures (libraries,modules etc)
>
>I think the paradigm of tcl is that you write the complex code in C/C++, and
>use tcl as the glue.

Thus increasing developement time and loosing platform independence.
Be serious tcl alone for bigger projects just gives severe headaches.
It is only a scripting language nothing more and nothing else.


>
>> 3 windowing support is somehow plugged (dirtily) onto the top of the language without
>> any possibility to extend it without writing extensions in C
>
>This is just eroneous. You can "extend" tcl either in C, C++, or by writing
>other tcl procs. As far as Tk goes, I have GUIed with X/Motif, I have GUIed
>with Windows SDK/MFC, I have GUIed with Java ... I have GUIed directly to
>the graphics card, but I have never GUIed as quickly as with Tk.

I worked at that time with XF and came from some OOP libraries and I
hated the approach of Osterbout how he tried to do windowing paradigm
in a procedural language (but thats only a personal opinion, no
subclassing of widgets to extend the functionality without itcl or C
what I wanted to do to gain some kind of reusability of my modified
widgets was pretty impossible to do)

>
>> 4 no net support without extensions which are written in C \
>
>You are missing the point, its relatively easy no extend, and there are
>some absolutely superb net extensions (scotty comes to mind) that kick but.


I know I worked with one of them (tcl/dp) to do the multiuser editor.
But the fact is, dp is one of the things which never made it into
standard tcl and it is written entirely in C thus there is no platform
independence either (hopefully you'll get the library for every
platform you have to implement your program in). Standard tcl is
nothing better than a scripting language with an X-Windows interface.
(And I didn't like the syntax of tcl either because it is simply
cryptic, but thats a problem of most scripting languages which came
from the unix side)


>> 6 painfully slow
>Tk is about 1000 times faster than Java AWT on HP's amd Suns.

I doubt it. The code is interpreted as is. No p-code compilation, no


Just in time compilation. The only fact that it might be faster on
several occasions is-> there are no complex data structures to
maintain, no object orientation (thus no VMT's), no moduling, etc...
(All these things which make code to maintain easier and more readable
if it is well written)


Werner

we...@inflab.uni-linz.ac.at
http://witiko.ifs.uni-linz.ac.at/~werpu

----------------------------------------------
Lets face the truth.Again you're stuck in the
ususal information highway rush hour traffic
jam.

Tony Parand Darugar

unread,
Jul 28, 1996, 3:00:00 AM7/28/96
to

> > 4 no net support without extensions which are written in C \

Just to keep the facts straight: tcl 7.5 supports socket connections.
See the "socket" command.

Tony

Werner Punz

unread,
Jul 29, 1996, 3:00:00 AM7/29/96
to

Oops sorry my fault. It has been two years now that I did something in
tcl and at that time there was nothing in standard tcl for tcpip
networking.

Peter Sulc

unread,
Jul 29, 1996, 3:00:00 AM7/29/96
to

In article <31fa11f...@news.uni-linz.ac.at>,

Werner Punz <we...@inflab.uni-linz.ac.at> wrote:
>ps...@nyx10.cs.du.edu (Peter Sulc) wrote:
>>> 1 almost as cryptical as perl with less functionality
>>
>>There are quite a few extensions available, and extending the language is
>>relatively easy. There is significantly more functionality than perl (IMHO),
>>but its slower.
>>
>
>Yes there are but none of them made it into standard tcl which is the
>only thing which is truly platform independent and all my statements
>regarded the standard tcl. And perl is still unsurpassed in string
>handling. I once had to write some bigger CGI scripts. The person I
>wrote them for wanted them in (standard)tcl but I implemented them in
>perl because those scripts did lots of string operations and thats one
>weak points of tcl (in fact I switched to perl after I saw it couldn't
>be done in standard tcl and I hadn't enough time to do it in C).
>
>

Isn't C portable?

:))))))

Well, ok, portable across Unixes ... except AIX ... and come to think
of it, Solaris, HPUX ... never mind ... just don't use sockets and pipes :)


>>> 2 no supported project management language structures (libraries,modules etc)
>>
>>I think the paradigm of tcl is that you write the complex code in C/C++, and
>>use tcl as the glue.
>
>Thus increasing developement time and loosing platform independence.
>Be serious tcl alone for bigger projects just gives severe headaches.
>It is only a scripting language nothing more and nothing else.
>
>

Isn't C++ portable?

>>
>>> 3 windowing support is somehow plugged (dirtily) onto the top of the language without
>>> any possibility to extend it without writing extensions in C
>>
>>This is just eroneous. You can "extend" tcl either in C, C++, or by writing
>>other tcl procs. As far as Tk goes, I have GUIed with X/Motif, I have GUIed
>>with Windows SDK/MFC, I have GUIed with Java ... I have GUIed directly to
>>the graphics card, but I have never GUIed as quickly as with Tk.
>
>I worked at that time with XF and came from some OOP libraries and I
>hated the approach of Osterbout how he tried to do windowing paradigm
>in a procedural language (but thats only a personal opinion, no
>subclassing of widgets to extend the functionality without itcl or C
>what I wanted to do to gain some kind of reusability of my modified
>widgets was pretty impossible to do)
>

Maybe I'm strange or something, but I can spew a GUI out in TCL in
no time ... of course if its sufficiently complex, then my head will hurt.

>>
>>> 4 no net support without extensions which are written in C \
>>

>>You are missing the point, its relatively easy no extend, and there are
>>some absolutely superb net extensions (scotty comes to mind) that kick but.
>
>
>I know I worked with one of them (tcl/dp) to do the multiuser editor.
>But the fact is, dp is one of the things which never made it into
>standard tcl and it is written entirely in C thus there is no platform
>independence either (hopefully you'll get the library for every
>platform you have to implement your program in). Standard tcl is
>nothing better than a scripting language with an X-Windows interface.
>(And I didn't like the syntax of tcl either because it is simply
>cryptic, but thats a problem of most scripting languages which came
>from the unix side)
>

Scotty is portable across practically every Unix. you can write
lots of extremely useful scripts very quickly. Yes, there are problems
with trying to apply this tool to a complex task, but for small jobs,
I don't know of anything that can compare.

>
>>> 6 painfully slow
>>Tk is about 1000 times faster than Java AWT on HP's amd Suns.
>
>I doubt it. The code is interpreted as is. No p-code compilation, no
>Just in time compilation. The only fact that it might be faster on
>several occasions is-> there are no complex data structures to
>maintain, no object orientation (thus no VMT's), no moduling, etc...
>(All these things which make code to maintain easier and more readable
>if it is well written)
>
>

Tk is superior in geomtery management and overall performance. Its not
even close. But the thrust of your argument is valid ... it starts to
break down as things get complex due to the global name space and no
structure problem.

I think you are correct in identifying tcl's weaknesses. I think, however,
that there are some strengths which you are overlooking. I'm hoping that
Ousterhout will one day take a trip over to Java division and explain some
computer graphics concepts to the AWT group :)

Ok, that's way too harsh, I'm sorry.


Peter


Jeremy L. Rosenberger

unread,
Jul 29, 1996, 3:00:00 AM7/29/96
to

Werner Punz wrote:

> Tony Parand Darugar <tdar...@eb.com> wrote:
>

> >> > 4 no net support without extensions which are written in C \
> >

> > Just to keep the facts straight: tcl 7.5 supports socket connections.
> >See the "socket" command.
>
> Oops sorry my fault. It has been two years now that I did something in
> tcl and at that time there was nothing in standard tcl for tcpip
> networking.

Now that we've got this cleared up, let's start flaming Java for features it lacked
two years ago... :)

Regards,
Jeremy

--

Jeremy L. Rosenberger
mus...@henge.com

Phil Ptkwt Kristin

unread,
Jul 30, 1996, 3:00:00 AM7/30/96
to

In article <4tbv3b$3...@nyx10.cs.du.edu>,

Peter Sulc <ps...@nyx10.cs.du.edu> wrote:
>In article <31F67433...@inflab.uni-linz.ac.at>,
>Werner Punz - Dipl <we...@inflab.uni-linz.ac.at> wrote:
>>> --
[a bunch of stuff snipped]

>
>other tcl procs. As far as Tk goes, I have GUIed with X/Motif, I have GUIed
>with Windows SDK/MFC, I have GUIed with Java ... I have GUIed directly to
>the graphics card, but I have never GUIed as quickly as with Tk.
>

I have not used Tcl/Tk much, but I have used Perl/Tk (I started to do a
project in Tcl/Tk and decided that I didn't want to learn Tcl just then -
not trying to trash Tcl, but my first impression was not favorable). I do
think that Tk's canvas is more elegant than Java's. Tk's canvas keeps
track of objects that are drawn on it. In Java's canvas you have to use a
for loop to find out if a mouse click fell within an objct drawn on the
canvas. Tk's canvas is "smarter", its much easier to write code to click
on an object and move it around the screen, for example. It would be nice
to see some of Tk's canvas features implemented in Java's Canvas.

Phil


--
pt...@teleport.com Aloha, OR USA

Brian M. Long

unread,
Jul 30, 1996, 3:00:00 AM7/30/96
to

Frank D. Greco (fgr...@crossroads-tech.com) wrote:

: cyg...@well.com (Brian M. Long) sez:

: >Can someone paint a "big picture" of how Java, Joe, Tcl/Tk all play
: >together in Sun's strategy for the internet, or are they merely cases of
: >a large corporation's right, middle, and left hands not knowing what each
: >other are doing?

: You really should ask SunSoft and JavaSoft this question.

I guess that I was hoping that someone from Sun, SunSoft, and/or JavaSoft
would reply in this forum for the benefit of all the other folks out
there who are confused and attempting to guess at where this is leading...

I currently have RMI, IDL, and Joe and am unclear about the overlap there.
I'm also curious about my first question (didn't know I'd start a thread
about the details of Tcl - there's a seperate newsgroup for that). Since
I still haven't seen anything resembling a roadmap for this, I'll assume
that like every other large organization they've just got too many things
going on at once and even they don't know how it'll turn out. Kind of
makes directing training for my developers a little more difficult:
guess we'll just have to learn it all...


--
Brian M. Long
VisAge Systems, Inc.
cyg...@well.com
http://www.well.com/user/cygnus/brian.html


Narayan Behera

unread,
Aug 1, 1996, 3:00:00 AM8/1/96
to nar...@numeritec.com

Werner Punz wrote:
>

>
> >> 6 painfully slow
> >Tk is about 1000 times faster than Java AWT on HP's amd Suns.
>
> I doubt it. The code is interpreted as is. No p-code compilation, no
> Just in time compilation. The only fact that it might be faster on

I was going through the Tcl FAQ, and they seem to imply
that Tcl is about 1000 times slower than C compiled, so
if Java-AWT has to be 1000 times slower than Tk what would
be your guess on the performance of Java vs. C?

Some books on Java claim it to be about 20 times slower
than C++/C, and apparently Sun claims that even this disparity
can be removed thru just-in-time compilation of the byte-code.

It is quite hard to put all these in perspective without some
sort of benchmark. Is there one?

In case Java is on the average three orders of magnitude,
or even two orders of magnitude slower than Tk, does Java
have a future as a GUI development language/tool?

Thanks...

Narayan

_______________________________________________________

Narayan Behera Numeritec Corporation
voice: (603) 448-3499 42 Wolf Road, Suite 312
Fax: (603) 448-0070 Lebanon, NH 03766

e-mail: nar...@numeritec.com
www: http://www.numeritec.com
_______________________________________________________

Peter Ruczynski

unread,
Aug 2, 1996, 3:00:00 AM8/2/96
to rucz...@x500.bt.co.uk

Peter Sulc wrote:
>
> In article <31F67433...@inflab.uni-linz.ac.at>,
> Werner Punz - Dipl <we...@inflab.uni-linz.ac.at> wrote:

Interesting that you didn't cross post this to comp.lang.tcl.
Were you afraid of getting all your questions answered? ;-)

> > 1 almost as cryptical as perl with less functionality
>
> There are quite a few extensions available, and extending the language is
> relatively easy. There is significantly more functionality than perl (IMHO),
> but its slower.

Languages are a matter of taste when it comes to syntax and semantics.
If you don't like it then fine, however to my mind it is one of the
most powerful languages around and, if written properly, can be very
readable and much more understandable than perl.

> > 2 no supported project management language structures (libraries,modules etc)
>
> I think the paradigm of tcl is that you write the complex code in C/C++, and
> use tcl as the glue.

Tcl has packages to enable easy compartmentalisation and modular
programming. Namespaces are also high on the list of things being worked on.
Extensions can be loaded in at runtime by use of dynamically loaded
shared libraries. This sounds like more than enough for me!

> > 3 windowing support is somehow plugged (dirtily) onto the top of the language without
> > any possibility to extend it without writing extensions in C
>
> This is just eroneous. You can "extend" tcl either in C, C++, or by writing

> other tcl procs. As far as Tk goes, I have GUIed with X/Motif, I have GUIed
> with Windows SDK/MFC, I have GUIed with Java ... I have GUIed directly to
> the graphics card, but I have never GUIed as quickly as with Tk.

Agreed. The main advantage of the fact that Tk is plugged in to the
Tcl core is that it can be replaced with whatever GUI you like.
For instance, the X windows version of Tk has been replaced by a
curses implementation for use on character based unix terminals!

> > 4 no net support without extensions which are written in C \
>

> You are missing the point, its relatively easy no extend, and there are
> some absolutely superb net extensions (scotty comes to mind) that kick but.

This is wrong. Tcl has a socket command for creating network channels.

> > 5 no record/struct definition allowed
>
> ah yes. The real (and only legitimate point you've made) downfall of tcl.

I would not say this is true. Tcl has a very powerful associative array
construct which can provide almost object oriented features if used correctly.

> > 6 painfully slow
>
> Tk is about 1000 times faster than Java AWT on HP's amd Suns.

It is however slow to execute internal code... a compiler is being
written and is scheduled for version 8.0

> > 7 no object orientation
> >
>
> Yes, but not a deadly blow. One of the interesting features of a scripted
> language is the absence of the distinction between code and data. This
> can be very powerful.

No! There are numerous OO extensions to Tcl [incr Tcl] is just one.

[snip]

> >Werner
>
> It may not have much of a future, but its better than JavaScript, and
> the reason is that Sun's putting all its marketing hype behind Java,
> and can't really be bothered much with tcl ... although, I wish
> Ousterhout would go over to the Java AWT folks and teach them how to do
> geometry management :)

This is not strictly true. There is a lot of work going on in the
Tcl team. The plugin is at a very early stage and I can see it being
used extensively along side java applets. My personal preference
would be to use Tcl as the main language with java extensions
to provide speed where it is necessary.

Pete.
--
Peter Ruczynski
work: rucz...@x500.bt.co.uk
home: pe...@softbase.demon.co.uk
play: http://www.wokingham.luna.net/~graeme/as.htm

Reply all
Reply to author
Forward
0 new messages