Java vs. Tcl/Tk
Harald Beker
on their September issue regarding User Interface complaining and
their ommitance of Tcl/Tk while celebrating Java.
I would want to know from those of you who have a qualified opinion
on the issue, i.e. those who have used both packages what you think.
I am not really in this category because my java experience is
recent and hence limited.
On the other hand I am playing with it on and of for a month
and I haven't yet come up with a useful application, while
I got a one going in just one weekend after I bought Ousterhout's book
with tcl/tk. This seems to be a criterium by itself.(Either on
my own capabilities or the quality of the languages?).
I really would like to know what you are thinking, so why not start
a thread.
Here's the mail:
Karl Strickland
In article <324179...@richal1.cern.ch> Harald Beker <ha...@richal1.cern.ch> writes:
> One thing which makes Java useless for me who is not a Web designer
> is that when you use the graphics capabilities even in local mode your
> are forced to use either an appletviewer or a browser with security
> restrictions which make life even tougher than what it is. Of course
> I could 'recompile' the appletviewer, but why should I have to do such
> a thing ?
I think this is only a problem if you write your code as an applet.
If you write it as a standalone application (ie dont subclass Applet
& include a main() method), you shouldnt have these problems.
--
------------------------------------------+-----------------------------------
PGP 2.3a Public Key Available. | Internet: ka...@bagpuss.demon.co.uk
Jacob Levy
There already *is* a Tcl plugin. Visit http://www.sunlabs.com/tcl/plugin
for the goods.
--JYL
In article <324179...@richal1.cern.ch>, ha...@richal1.cern.ch says...
>
>This is a multi-part message in MIME format.
>
>--------------43CE7293477
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>--------------43CE7293477
>Content-Type: text/plain; charset=us-ascii; name="dobbs.comment"
>Content-Transfer-Encoding: 7bit
>Content-Disposition: inline; filename="dobbs.comment"
>
>
>While I do like your journal a lot and had my institution subscribe to
>it, I fully subscribe to a recent reader's comment on your share to the
>Java hype.
>
>Even more so after I read your recent issue on User Interfaces.
>An infinite number of articles on Java and NONE (!) on Tcl/Tk.
>This seems almost a political decision and its hard to believe in
>good faith. Don't worry I keep trying.
>
>Tcl/Tk offers most of the goodies of Java such as platform independence
>and a lot more. It is a much more powerful language. If you compare the
>demos Java is really ridiculous compared to it. The code of impressive
>demos is frighteningly short.
>
>It is much easier to learn. Many of my colleagues who are
>not professional computer scientist(physicists with only FORTRAN
>knowledge!) have learned it in just a couple of days. It offers a GUI
>builder worth its name(XF) which not only allows you to build the GUI
>but interactively run the application you are building including native
>language extensions.
>
>The language being very powerful, it lends itself much better
>to executable content as it is a lot more concise than the byte code
>which is full of dynamic links in the form of strings.Typical
>source code zips extremely well. The fact that you don't need to
>structure your application in many class files is an additional advantage
>as, - if I understand correctly, - every class opens a new http
>connection with the associated overhead. Above all the voluminous
>graphics routine reside in the interpreter hence on the client side
>and need no transfer.
>
>One of the short comings which is the safeness issue can easily
>be overcome by redefining the system, IO and socket calls when wanted.
>e.g creating a 'safe' wish.
>
>One thing which makes Java useless for me who is not a Web designer
>is that when you use the graphics capabilities even in local mode your
>are forced to use either an appletviewer or a browser with security
>restrictions which make life even tougher than what it is. Of course
>I could 'recompile' the appletviewer, but why should I have to do such
>a thing ?
>
>Another issue is performance:
>Being fully dynamically interpreted Tcl/Tk should intrinsically be at
>disadvantage. Alas:
>
>At least under UNIX and X-windows Tk is much more efficient than
>AWT as it treats painted objects (rectangles lines etc) as such
>rather than as pixel maps which have to be continuously redrawn by the
>client when ever they change colour position or whatever. It is the
>X-server who redraws them with very little traffic over the network.
>i.e. if I want to move a bitmap on the screen, I only have to send the
>new coordinates over the network not the bitmap !! Hence animation under
>Tk is infinitely faster on an X-terminal.
>
>Furthermore it is much easier and much more platform independent to
>include native code (C, C++, Fortran) into the interpreter as it is
>available in the form of a library.
>
>Tcl/Tk runs on ALL UNIX platforms and it is easy to port as you
>get the source code. (it took me 2 h to get it running
>on the minimal real time UNIX LynxOs)
>
>Tcl/Tk is easily installed as a helper application to either Netscape
>or Mosaic. The fact it does not run in the same window as the
>browser is an advantage rather than a limitation. Even if you
>like the funny Windows paradigm of window inside windows, it should
>be easy to make Tcl/Tk a plug-in.
>
>A major design limitation of Java is that it does not have pointers
>to functions which forces you to hard workarounds when it comes
>to call-backs.
>
>Other features which give Tcl/Tk a probably unsurpassable advantage
>over Java:
>
> a) transparent implementation of observables. You can link
> text and numbered variables to graphical elements on the
> screen. Just change the value of an variable in either
> Tcl or C and oops the text of a label, the position of
> a scrollbar changes 'by itself'
>
> b) Most events are handled by Tk without having to
> write any handlers. Even the ones you want to handle
> always go to the call-back of the right object without
> you having to find out which one it is.
>
> c) Motif look and feel.
>
> d) The tagging mechanism. How would you change
> the colour of all rectangles in a given canvas with
> just one command ?
>
> .canvas itemconfigure rects -foreground ,green does it
>
>Finally the number of available useful and free applications in Tk
>is infinitely higher.
>
>I have absolutely no understanding for your giving so much space
>to a promising but totally immature technology as Java while you
>totally ignore the existence of a much more advanced product.
>I hope the fact that it is free, is not the reason. I start to suspect
>Sun bought Tcl/Tk to close it down and pray that this is not so.
>
> While this time I (STRONGLY) disagree with your editorial
> line I will stay a faithful reader
>
> Best regards
>
> Harry Beker
>
>
>--------------43CE7293477--
>
Klaus Lindemann
Harald Beker wrote:
>
|> I would want to know from those of you who have a qualified opinion
|> on the issue, i.e. those who have used both packages what you think.
|> I am not really in this category because my java experience is
|> recent and hence limited.
Well, my opinion may not be qualified, having played around
with Java only a little bit.
|>
|> On the other hand I am playing with it on and of for a month
|> and I haven't yet come up with a useful application, while
|> I got a one going in just one weekend after I bought Ousterhout's
book
|> with tcl/tk. This seems to be a criterium by itself.(Either on
|> my own capabilities or the quality of the languages?).
|>
|> I really would like to know what you are thinking, so why not start
|> a thread.
|>
|> Here's the mail:
[mail deleted]
|>
|> Harry Beker
Of course you can get some things running in Tcl/Tk in a short
amount of time.
Some remarks:
1) Most of the benefits from Tcl/Tk come from the Tk side.
If you compare Tcl with Java without AWT you see that
Tcl on its own is rather limited. It is not suitable for
writing applications (and was not intended for this purpose).
With Java, you can write full applications.
2) Platform independence: only since its last release
(Tcl7.5/Tk4.1) Tcl/Tk supports Mac and Windows. And
if you look not only at the GUI, but at the part of
your applications which does the work, then Tcl/Tk
has to be coupled with C and C++. Platform independence
becomes a bigger problem, and you have to recompile it
for every platform. Java clearly has an advantage here.
3) Performance: Java will get better with JIT compilers
becoming available. Tcl/Tk only wins when you look
at the GUI elements, which are written in C. Java
should beat Tcl by a large margin.
4) Development Environments and Interface Builders: I haven't tried
XF, but I am very confident that Sun, Borland, Microsoft or
someone else will come up with something similar soon.
Tcl/Tk and Java are not in the same league. Tcl/Tk is
more convenient for creating GUIs, but Java can be
used to write whole applications, which is not what
Tcl/Tk was intended for.
You don't need an appletviewer or browser to run Java
applications. You need them only for applets. If you
don't understand the difference, you have to study Java more.
You complained that Dr. Dobbs convers Java and ignores Tcl/Tk.
If you look at the list of companies which have licensed Java
are are developing for Java, you will understand.
--
=============================================================================
Klaus Lindemann li...@iai.fzk.de (email)
Philippe.Le-Foll + iup.gis.prof
> >on their September issue regarding User Interface complaining and
> >their ommitance of Tcl/Tk while celebrating Java.
> >
> >on the issue, i.e. those who have used both packages what you think.
> >I am not really in this category because my java experience is
> >recent and hence limited.
I dont know if my opignon is "qualify" or not, but I have writen
applications in TCL/TK and in JAVA for almost 1 year.
Nevertheless I will give you my position on the subjet, I am sure
that this answer will be polimic, because speaking about languages
with developers is almost as dificult as talking religion or politics.
First I would like to cut thing between JAVA-AWT and TCL-TK, If we
just compare prgrammation language TCL and JAVA, comparison is quite
easy.
JAVA
- Language is compile
- Objet oriented
- multi threaded
- very nice syntaxe even if it more complex than TCL one.
TCL
- Interpreted
- Simple but heavy syntaxe
Common to BOTH
- Fast enought for many applications
- weak debug facilities
- Open licence (even if JAVA is more restrictive)
- Multi architecture (Unix, PC, ...)
- Nicely interface with the WEB
- major I/O facilities present (disk, network/socket, ...)
- possibility of embeding external program.
Obviousely this list is not exaustive, nvertheless it seems
enought for me to compare both languages. My position is:
- Java is a better language for real applications, the syntaxe is much
better, and it looks to me easier maintaning 10.000 lines of
java code than the same amount in TCL. Further more TCL
deeply miss a syntaxe checker, and in any case TCl "cruncher"
should not be compare with JAVA parsing.
- TCL the syntaxe is heavy but simple, my opignon is that TCL is
more a macro language that a language in itself. It as been
designed to be embeddable and not for writing long applications.
Note: Some facilities are emplemented in different way that make
them very hard to compare: example network sockets.
On JAVA the good approach is have a socket for all waiting part
of your program (for example on thread read the network). TCL
implement network incomming packet as event wich make all I/O
programation look like a user action on the GUI. I personally
like both, the thread approach more complex to understand for
a non specialist (ex: scientific), nevertheless it allows a more
flexible way of handling exception, as well as it allows a more
flexible managment of prioriry. On this point my opignon is:
- Thread, if you have no experience with multi-task or real-time
programmation avoid thread, you could loose your self
in your own code and further more at run time.
- Event, they are easy an simple "even a scientific can use them"
they are limitted for complex things (ex: dont try to write
a disk buffer cache with TCL event).
CONCLUSION: I would choose JAVA for any real software application,
I realy think that it is possible to design JAVA only programs. On
the opposit I will use TCL for interfacing a library, in this case
my TCL programs stay small enought to be maintained, as well as the
ratio interpreted-lines/machine-code will be keeped very low, which
is very important for performances. The typical example of
application for TCL are: Test program, Scientific applications where
TCL replace the old main FORTRAN program while all the library
are still Fortran or C writen.
As you can see, I realy thing both language are usefull, in theory
it should be very easy to you choosing one or the other.
Unfortunately people usally want TCL or JAVA for a user interface
and graphic toolkit is an other problem.
GRAPHIC/GUI
JAVA AWT, AWT if just one step after "no grahpic toolkit". AWT
provide a minimum level of widgets, for people comming from Unix
we could say that AWT is to JAVA what ATENA is to X11. Every
body that tryed to design a graphic application with such a weak
toolkit know it is a long an boring time.
TK, Tk toolkit is really one, or even the best graphic toolkit
curentely avaliable, it it very rich, fast, ...
CONCLUSION: Except if you like writing your graphic applications
by hand, handle the user interaction directely without having
an "call to event" facility, you SHOULD avoid using AWT for
any aplications.
NOTE: Current version of AWT is so bad and so limitted, that it looks
impossible that SUN dont change it. I have been told that a new
AWT will be soon avaliable, one thing is sure "it will be better".
GENERAL CONCLUSION
Until a "TK like" graphic tool kit wont be avaliable on JAVA,
I will continue designing my GUI with TCL-TK, but as soon JAVA
will have a real graphic tool kit, I will switch for all heavy
applications.
Neil Walker
Harald Beker was ranting about how much better Tcl/Tk is than Java.
Apart from an obvious "here, here", my impression was that tcl8.0/tk5? was
going to have all this byte-code compiler stuff in it - so then the decision
between Tcl/Tk and Java will be less religious, and more:
Which suits my task better?
Personally (as a database developer) I have next to no need for C - someone
else can do it better (Tom Poindexter and his oratcl extension, for example).
And I rather suspect I'll have no need for Java - it will become the library
development tool that's used to make applets that us hacks buy to add bells
and whistles to our otherwise serviceable Tk/Tcl scripts ...
Cheers
Neil
Joel Hug
Remarks and questions below concerning Java versus Python:
Klaus Lindemann <li...@iai.fzk.de> wrote in article
<324264...@iai.fzk.de>...
> Harald Beker wrote:
> >
> |> I would want to know from those of you who have a qualified opinion
> |> on the issue, i.e. those who have used both packages what you think.
> |> I am not really in this category because my java experience is
> |> recent and hence limited.
>
> Well, my opinion may not be qualified, having played around
> with Java only a little bit.
>
> |>
> |> On the other hand I am playing with it on and of for a month
> |> and I haven't yet come up with a useful application, while
> |> I got a one going in just one weekend after I bought Ousterhout's
> book
> |> with tcl/tk. This seems to be a criterium by itself.(Either on
> |> my own capabilities or the quality of the languages?).
> |>
> |> I really would like to know what you are thinking, so why not start
> |> a thread.
> |>
> |> Here's the mail:
> [mail deleted]
> |>
> |> Harry Beker
>
> Of course you can get some things running in Tcl/Tk in a short
> amount of time.
>
> Some remarks:
>
> 1) Most of the benefits from Tcl/Tk come from the Tk side.
> If you compare Tcl with Java without AWT you see that
> Tcl on its own is rather limited. It is not suitable for
> writing applications (and was not intended for this purpose).
> With Java, you can write full applications.
Python with tkinter (interface to Tcl/Tk) has access to the rich Tk GUI.
Python (unlike Tcl) was designed as a language and has good capability for
applications.
Is this not the best of both worlds?
>
> 2) Platform independence: only since its last release
> (Tcl7.5/Tk4.1) Tcl/Tk supports Mac and Windows. And
> if you look not only at the GUI, but at the part of
> your applications which does the work, then Tcl/Tk
> has to be coupled with C and C++. Platform independence
> becomes a bigger problem, and you have to recompile it
> for every platform. Java clearly has an advantage here.
The Python interpreter supports Unix, Windows, and Mac. No need to be
bound to
C / C++ for your apps. (Use of Tcl/Tk gives GUI platform independence.)
>
> 3) Performance: Java will get better with JIT compilers
> becoming available. Tcl/Tk only wins when you look
> at the GUI elements, which are written in C. Java
> should beat Tcl by a large margin.
>
I'm not sure of the comparison here though if there was a specific
performance
problem, a targetted functionallity may be moved to C code and linked into
the
Python interpreter.
> snipped
What does Java provide over Python?
---------------------------------------------------------
Joel Hug | E-Mail: jh...@morpho.wa.com
N. A. Morpho Systems | jh...@ix.netcom.com
Tacoma, WA | Tel: 206-597-8227
| Fax: 206-591-8856
---------------------------------------------------------
Glenn Vanderburg
> on their September issue regarding User Interface complaining and
> their ommitance of Tcl/Tk while celebrating Java.
Since the topic of the issue was user interfaces, Tcl really should
have been mentioned. In fairness, though, Dr. Dobbs has given Tcl and
Tk some excellent coverage in the past.
> I would want to know from those of you who have a qualified opinion
> on the issue, i.e. those who have used both packages what you think.
> I am not really in this category because my java experience is
> recent and hence limited.
OK, here's my input. You've focused on Tk and interface building, and
I'll address that, but I also want to address Tcl itself --- the
simple scripting language aspect.
I agree that it's much easier to build a nice user interface with Tk
than with Java. Good interface builders might close that gap (not the
silly absolute-placement builders like Visual Basic, but nice ones
with flexible layout management, such as SpecTcl or the pallette
that's been promised for Visual Cafe). Nevertheless, I think the Tk
way of doing things is wonderful for user interfaces, and I prefer it
to Java for that task.
The Tk user interface widgets are superior to the AWT, with a great
deal more functionality. It's unfortunate that Tk still doesn't
support native look-and-feel on Windows and Mac systems, but hopefully
that's not far off now. AWT's widgets are primitive by comparison.
On the other hand, Java's object-oriented architecture may give it an
advantage in the long run. Tcl's widgets can be combined using Tcl,
but to seriously extend them, you must write C, and you can't merely
inherit useful functionality and extend it. Java widgets are more
likely to gain functionality incrementally, in easy steps.
I consider it very good news that the Java Beans architecture (and, I
gather, the improved AWT) are explicitly designed to provide access to
scripting languages. From my reading of the Beans spec, it would not
be too difficult to write an interface which would make the AWT
widgets accessible from Tcl alongside the Tk widgets. It's not
trivial, but I didn't see any serious difficulties with that.
Which brings me to my real point: I don't think Tcl and Java are
competing. I think they complement each other perfectly, with Java as
a systems development language and Tcl a scripting language. This is
precisely the model that Tcl was designed for, and I think it's a
great way to build systems. Tk's widget set may someday be supplanted
by Java widgets and components, but I think that Tcl (and the Tk way
of building interfaces) will survive as a companion to Java.
There seems to be a growing realization in the Java community that
scripting languages have value. I believe Tcl is the best candidate
for a scripting language to complement Java. The other serious
candidates are probably JavaScript, one of Visual Basic's
incarnations, Perl, and Python. JavaScript is (in my opinion) a very
poor language, weak and quirky and *too* loose, even for a scripting
language. Visual Basic's only real claim to scripting language status
is that it is interpreted and not difficult to learn; it doesn't have
nearly the power or deftness that one usually associates with
scripting languages. As much as I like Perl, I don't think it's right
for this role; a good scripting language needs to be easy to learn
even for casual programmers, and Perl is definitely a "programmer's
language". (My preference for Tcl over Python is simply a matter of
taste; it may be that Python would be an excellent choice as well.)
I'll be glad when the interface between Tcl and Java improves. I just
sent the team at Sun a patch to map between Tcl and Java exceptions in
a natural way, and I hope they will include it in the next release. I
wrote about combining Java with scripting languages in my advanced
Java programming book, and Tcl was used as the example because it was
the only scripting language with a working interface to Java.
I look forward to being able to write the core functionality of
applications in Java, and then knitting those pieces together into a
full-fledged application using Tcl.
--
---glv
Jim Ingham
Hi all,
One other thing that is quite nice in Tcl but is not present (or at least
not in a really convenient fashion) in JAVA, is the easy access to the Tcl
interpreter. It is REALLY COOL to be able to get your application most
of the way up, and then sit in the Wish interpreter and hack at the
bindings, or the button callbacks. Once you have gotten used to this,
you really miss it! I have been teaching myself Java for two months now,
and I cannot count how many times I havegone looking for the wish shell!
It makes development so much more pleasant. You cannot do this with JAVA,
just as you cannot do this in C.
It also makes it much easier to learn how to do GUI development, and you
can improve your IDEAS on your application design much more easily.
Jim.
Jim Ingham
Reposting article removed by rogue canceller.
Graham Matthews
Joel Hug wrote:
> What does Java provide over Python?
a) proper garbage collection
b) better means for structuring large applications (such
as private variables, interfaces, NO multiple inheritance,
static typing, etc)
c) its faster than Python and will get even faster with JIT
compilers (static typing helps tremendously here).
Unfortunately Java also has some serious drawbacks when
compared to Python :-
a) AWT is terrible.
b) no syntactic support for things like dicts and lists (the
sorts of objects you code with all the time).
c) a convoluted package mechanism.
d) poor development environments (unless you are prepared
to spend $$)
In short I consider that for small to medium sized applications
Python is superior to Java because you can code that application
more quickly and more transparently. However for large scale
applications I think some of Java's more advanced (relative
to Python) features like (a) to c) above) really help.
I have the feeling that while Python has successfully stolen
Tcl's ground (small applications), Python in its current form
cannot steal some of Java's ground, namely the large scale
application "market". A lot of things would have to be added
to Python to do that.
graham
--
beating on a tin drum marching to a sound
what is it I think?
am I beating on a tin drum marching to a cause
when I don't know what it is I believe.
Klaus Lindemann
Larry W. Virden wrote:
>
> According to Klaus Lindemann <li...@iai.fzk.de>:
> :You complained that Dr. Dobbs convers Java and ignores Tcl/Tk.
> :If you look at the list of companies which have licensed Java
> :are are developing for Java, you will understand.
>
> in live situations, than are using Java. For just a _few_ of
> the examples, check out the commercial uses FAQ and unofficial
> commercial uses list at
> <URL:http://www.teraform.com/%7Elvirden/tcl-faq/>
>
That may be true, but I said "developing for Java" to indicate
not companies that use Java, but support it by writing
compilers, class libraries, IDEs. How many companies are
writing such tools for Tcl/Tk? And what companies?
This "more companies use Tcl/Tk than Java" is also almost meaningless,
because numbers don't tell you everything (more companies use
the Windows 3.1 interface than the Mac GUI, does this make the
Windows interface better?), and because Java and Tcl/Tk have
large areas where they simply do not compete, so the question
whether to use Tcl/Tk or Java is not even asked.
> --
> :s Larry W. Virden INET: lvi...@cas.org
> :s <URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
> :s Unless explicitly stated to the contrary, nothing in this posting should
> :s be construed as representing my employer's opinions.
Eric Cheung
Graham Matthews <graham....@maths.anu.edu.au> writes:
>Unfortunately Java also has some serious drawbacks when
>compared to Python :-
>a) AWT is terrible.
it is terrible at the moment, but it will get better.
There's an extended AWT coming out soon (hopefully).
--
Larry W. Virden
According to Klaus Lindemann <li...@iai.fzk.de>:
:You complained that Dr. Dobbs convers Java and ignores Tcl/Tk.
:If you look at the list of companies which have licensed Java
:are are developing for Java, you will understand.
More companies are using Tcl/Tk in real life applications today,
in live situations, than are using Java. For just a _few_ of
the examples, check out the commercial uses FAQ and unofficial
commercial uses list at
<URL:http://www.teraform.com/%7Elvirden/tcl-faq/>
--
Klaus Lindemann
Reposting article removed by rogue canceller.
Larry W. Virden wrote:
>
> According to Klaus Lindemann <li...@iai.fzk.de>:
> :You complained that Dr. Dobbs convers Java and ignores Tcl/Tk.
> :If you look at the list of companies which have licensed Java
> :are are developing for Java, you will understand.
>
> More companies are using Tcl/Tk in real life applications today,
> in live situations, than are using Java. For just a _few_ of
> the examples, check out the commercial uses FAQ and unofficial
> commercial uses list at
> <URL:http://www.teraform.com/%7Elvirden/tcl-faq/>
>
That may be true, but I said "developing for Java" to indicate
not companies that use Java, but support it by writing
compilers, class libraries, IDEs. How many companies are
writing such tools for Tcl/Tk? And what companies?
This "more companies use Tcl/Tk than Java" is also almost meaningless,
because numbers don't tell you everything (more companies use
the Windows 3.1 interface than the Mac GUI, does this make the
Windows interface better?), and because Java and Tcl/Tk have
large areas where they simply do not compete, so the question
whether to use Tcl/Tk or Java is not even asked.
> --
> :s Larry W. Virden INET: lvi...@cas.org
> :s <URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
> :s Unless explicitly stated to the contrary, nothing in this posting should
> :s be construed as representing my employer's opinions.
Larry W. Virden
Reposting article removed by rogue canceller.
According to Klaus Lindemann <li...@iai.fzk.de>:
:You complained that Dr. Dobbs convers Java and ignores Tcl/Tk.
:If you look at the list of companies which have licensed Java
:are are developing for Java, you will understand.
More companies are using Tcl/Tk in real life applications today,
in live situations, than are using Java. For just a _few_ of
the examples, check out the commercial uses FAQ and unofficial
commercial uses list at
<URL:http://www.teraform.com/%7Elvirden/tcl-faq/>
--
Eric Cheung
Donal K. Fellows
[ cljp removed - this isn't really programming related... ]
In article <wkg24d6...@oblivion.bizworks.com>,
Glenn Vanderburg <g...@metronet.com> wrote:
> Which brings me to my real point: I don't think Tcl and Java are
> competing. I think they complement each other perfectly, with Java as
> a systems development language and Tcl a scripting language. This is
> precisely the model that Tcl was designed for, and I think it's a
> great way to build systems. Tk's widget set may someday be supplanted
> by Java widgets and components, but I think that Tcl (and the Tk way
> of building interfaces) will survive as a companion to Java.
I have yet to see any Java interface builder even of the quality of
SpecTcl, so I would think that Tcl/Tk will be around for quite a long
time yet. This is a good thing IMHO
> There seems to be a growing realization in the Java community that
> scripting languages have value. I believe Tcl is the best candidate
> for a scripting language to complement Java. The other serious
> candidates are probably JavaScript, one of Visual Basic's
> incarnations, Perl, and Python. JavaScript is (in my opinion) a very
> poor language, weak and quirky and *too* loose, even for a scripting
> language. Visual Basic's only real claim to scripting language status
> is that it is interpreted and not difficult to learn; it doesn't have
> nearly the power or deftness that one usually associates with
> scripting languages. As much as I like Perl, I don't think it's right
> for this role; a good scripting language needs to be easy to learn
> even for casual programmers, and Perl is definitely a "programmer's
> language". (My preference for Tcl over Python is simply a matter of
> taste; it may be that Python would be an excellent choice as well.)
IMHO, JavaScript feels very clunky, VB is BASIC (and thus not a
serious language. Its main claim to being a scripting language is that
M$ says it is one...), Perl is targetted somewhere else entirely (and
usefully so as well, but I wouldn't want to use it as an applet
scripting language) and Python... Well, can you name a major company
that actively supports Python? It seems rather far off the beaten
track to me - I only know of it due to the substantial number of posts
by its advocates :^)
> I look forward to being able to write the core functionality of
> applications in Java, and then knitting those pieces together into a
> full-fledged application using Tcl.
I believe that Sun have this use in mind, and it would dovetail very
nicely with the original purpose of Tcl...
Donal. (a firm believer in having plenty of languages to program in,
and the maintainer of a still-growing 13000+ line mixed Tcl/C app)
--
Donal K. Fellows http://r8h.cs.man.ac.uk:8000/ (SAY NO TO COMMERCIAL SPAMS!)
(work) fell...@cs.man.ac.uk Dept. Comp. Sci, Univ. Manchester, U.K.
| do...@ugglan.demon.co.uk 6,Randall Place, Heaton, Bradford, U.K. (home)
+-> ++44-161-275-6137 Send correspondence to my office ++44-1274-401017 <-+
Mitch Chapman
Donal K. Fellows wrote:
>
> [ cljp removed - this isn't really programming related... ]
>
> In article <wkg24d6...@oblivion.bizworks.com>,
> Glenn Vanderburg <g...@metronet.com> wrote:
> IMHO, JavaScript feels very clunky, VB is BASIC (and thus not a
> serious language. Its main claim to being a scripting language is that
> M$ says it is one...), Perl is targetted somewhere else entirely (and
> usefully so as well, but I wouldn't want to use it as an applet
> scripting language) and Python... Well, can you name a major company
> that actively supports Python? It seems rather far off the beaten
> track to me - I only know of it due to the substantial number of posts
> by its advocates :^)
>
I haven't pushed the use of Python in my workplace because, until
recently, no books were available on Python programming. The availability
of programming guides seems to be an informal measure of a language's
suitability for "real work".
Nevertheless, in my own experience Python is an excellent language in which
to write small-to-medium-scale utilities -- graphical and otherwise -- and
to prototype GUI applications.
FWIW, I find it more reassuring to see a language in use in a commercial
package than to have that language supported by a major company.
After all, XView, OPEN LOOK, NeWS, and OpenStep were all supported by a
major company...
--
Mitch Chapman
mcha...@erinet.com
Andre Fuechsel
Hi,
whilst I agree mostly with your posting I have to make some notes.
Harald Beker wrote:
> One thing which makes Java useless for me who is not a Web designer
> is that when you use the graphics capabilities even in local mode your
> are forced to use either an appletviewer or a browser with security
> restrictions which make life even tougher than what it is. Of course
> I could 'recompile' the appletviewer, but why should I have to do such
> a thing ?
You can run JAVA-applications standalone with the java interpreter. Java
is just another programming language and the programs may be run in a
browser as an applet but they don't need to!
> At least under UNIX and X-windows Tk is much more efficient than
> AWT as it treats painted objects (rectangles lines etc) as such
> rather than as pixel maps which have to be continuously redrawn by the
> client when ever they change colour position or whatever. It is the
> X-server who redraws them with very little traffic over the network.
> i.e. if I want to move a bitmap on the screen, I only have to send the
> new coordinates over the network not the bitmap !! Hence animation under
> Tk is infinitely faster on an X-terminal.
I just started teaching myself Java so I don't know the AWT yet (but I
do know Tcl/Tk and X). If you are right this would be a large
performance bottleneck and was certainly not a good architectural
decsision. Does the AWT really treat every graphical object as a *PIXEL
MAP* not an object itself???
> Tcl/Tk is easily installed as a helper application to either Netscape
> or Mosaic. The fact it does not run in the same window as the
> browser is an advantage rather than a limitation. Even if you
> like the funny Windows paradigm of window inside windows, it should
> be easy to make Tcl/Tk a plug-in.
A plugin exitsts: http://www.sunlabs.com/research/tcl/plugin/index.html
> I start to suspect
> Sun bought Tcl/Tk to close it down and pray that this is not so.
I hope they won't!
Andre
--
Andre Fuechsel Phone: +49 221 8299 228
SEMA GROUP Deutschland GmbH Fax: +49 221 8299 266
Siegburger Str. 215, 50679 Koeln, Germany E-Mail: af...@sema.de
Larry W. Virden
According to Mitch Chapman <mcha...@erinet.com>:
:FWIW, I find it more reassuring to see a language in use in a commercial
:package than to have that language supported by a major company.
:After all, XView, OPEN LOOK, NeWS, and OpenStep were all supported by a
:major company...
and in fact, these all were, and still are, used in commercial packages as well.
XView in fact was in many more commercial and free packages than Motif for
many years. Open Look was in many commercial packages, and NeWS was
even used in at least one commercial product where you didn't see it
(Sun's print server). OpenStep - is that one formally released yet? Certainly
NextStep, it's ancestoral basis, has been used in commercial products for
years.
Gerald W. Lester
Andre Fuechsel <Andre.F...@sema.de> wrote in article
<324780E2...@sema.de>...
> > I start to suspect
> > Sun bought Tcl/Tk to close it down and pray that this is not so.
>
> I hope they won't!
Sun did *not* buy Tcl/Tk, they hired the "father" of the language. Sun has
issued
several statements that Tcl/Tk will remain free set
http://www.sunlabs.com/tcl/team.html
and the Tcl/Tk copyrights for evidence.
Ron A. Zajac
> Andre Fuechsel <Andre.F...@sema.de> wrote in article
> <324780E2...@sema.de>...
> > > I start to suspect
> > > Sun bought Tcl/Tk to close it down and pray that this is not so.
> >
> > I hope they won't!
If Sun bought tcl/Tk to snuff it, they're doing a lousy job! B^)>
Ron A. Zajac
Jim Fulton
In article <324352...@maths.anu.edu.au> Graham Matthews
<graham....@maths.anu.edu.au> writes:
Joel Hug wrote:
> What does Java provide over Python?
a) proper garbage collection
I suspect that Python will get one eventually.
b) better means for structuring large applications (such
as private variables, interfaces, NO multiple inheritance,
static typing, etc)
I have to respectfully disagree with regard to multiple inheritence.
I've looked at the Java ORB support and it is a mess because of
"NO multiple inheritance". You have to either design your class
hierarchies within the ORB hierarchy or use a code generator to
generate a parallel ORN hierarchy that delegates all allplication
calls to the application hierarchy. Bleh.
c) its faster than Python and will get even faster with JIT
compilers (static typing helps tremendously here).
Unfortunately Java also has some serious drawbacks when
compared to Python :-
a) AWT is terrible.
b) no syntactic support for things like dicts and lists (the
sorts of objects you code with all the time).
There is also no support for generating user-defined containers
without resorting to stupid, if harmless casts.
(snip)
--
Jim Fulton Digital Creations
j...@digicool.com 540.371.6909
Daniel Ockeloen
[zapped]
: > Some remarks:
: >
: > becoming available. Tcl/Tk only wins when you look
: > at the GUI elements, which are written in C. Java
: > should beat Tcl by a large margin.
: >
: I'm not sure of the comparison here though if there was a specific
: performance
: problem, a targetted functionallity may be moved to C code and linked into
: the
: Python interpreter.
: > snipped
: What does Java provide over Python?
Hype, Money, Support, 40.000.000 installed systems (100 next year)
wallstreet, netscape, ibm, att ... ,.. ,.. ... need i go on ?
Why go over why is X,Y,Z not better than Java ? Java is a option now
to use it is much better than before and has the market/timeframe
to be used by us and to extend to a point where it is more 'oke' (its
a early bird). Maybe Dylan, Python etc etc are better on some point(s)
but lets face it Java seems to a good mix of the old/new/hypable/sellable
to have become the fastest growing lang. in history ... lets stop
talking and start doing :) ..
and about no good for servers (somewhere in this thread) not true we make
servers in java and will release one again soon and it _rocks_ ... upto 175
hits/sec is not bad for cgi like stuff ...
Greetings,
Daniel Ockeloen
VPRO-Digital.
Dean Schulze
Larry W. Virden wrote:
> More companies are using Tcl/Tk in real life applications today,
> in live situations, than are using Java. For just a _few_ of
> the examples, check out the commercial uses FAQ and unofficial
> commercial uses list at
> <URL:http://www.teraform.com/%7Elvirden/tcl-faq/>
Well, yes, but Tcl/Tk has been around much longer than
Java so that's not a valid measure of the merits of the two
languages.
For those of you who question whether Java is ready for serious
development right now here's a reference for a large "real world"
application written in Java over the past year:
Patricia Seybold, Computer World, Aug. 5, 1996, Pg. 33
The application is called Via World Network. It is a multi-airline
scheduling and reconciliation program that was written for Anderson
Consulting. It consists of 200,000 lines of Java, and it was written
and deployed in 9 months. The leader of the project lauded the
quality control aspects of Java compared to other languages.
It says a lot for Java that a project of this magnitude could
be built with version 1.0 (or 1.01) of the JDK and have both faster
deployment and higher quality than would have been achieved if
C or C++ had been used.
Tcl has problems scaling up to large projects. Is anyone
aware of a project similar in scope to Via World Network that
has been done in Tcl?
Tcl is a scripting language that saves you
from writing shell scripts, but I wouldn't use Tcl for a large
project, however. Tk saves you from writing Motif code and it is
probably superior to the AWT right now, but AWT is only at version 1.2.
I see Tcl/Tk and Java as complementary to each other because
they are good tools for different problem domains; not as
competing technologies.
Dean Schulze
======================================================================
"You plot the growth of the NEA [National Education Association] and
the dropping of SAT scores, and they're inversely proportional.
The problems are unions in the schools. The problem is bureaucracy.
I'm one of these people who believes the best thing we could ever do
is go to the full voucher system."
Steve Jobs
Wired Magazine, Feb. 96
http://www.hotwired.com/wired/4.02/features/jobs.html
=====================================================================
Jeffrey Hobbs
In article <324997...@cassini.lpl.arizona.edu>,
Dean Schulze <sch...@cassini.lpl.arizona.edu> wrote:
->Consulting. It consists of 200,000 lines of Java, and it was written
->and deployed in 9 months. The leader of the project lauded the
....
-> It says a lot for Java that a project of this magnitude could
->be built with version 1.0 (or 1.01) of the JDK and have both faster
->deployment and higher quality than would have been achieved if
->C or C++ had been used.
I don't think anyone is defending C/C++ here, with relatively good
reason based on the premise of the discussion. I would recommend the
use of Java over C++ in a new project any day.
-> Tcl has problems scaling up to large projects. Is anyone
->aware of a project similar in scope to Via World Network that
->has been done in Tcl?
Yes, you'd be surprised. It's not really all that much different than
trying large projects in straight C. However, "large" is relative to
the language because most don't do a GUI hello world in:
pack [button .b -text "Hello World" -command exit]
I think 200,000 lines of Tcl/Tk would be one hairy, complex system, but
100K lines is manageable with good coding style and documentation (and
[incr Tcl] would help). +'s and -'s aside, it can be - and is - done.
Java's primary failing is AWT. The Java guys should've been embarassed by
their alpha run (only given how much everyone was touting such a buggy
product). It's now stabilized, but I pray that ExtendedAWT will be a real
toolkit instead of Another Waste of Time.
--
Jeffrey Hobbs office: 541.683.7891
Nomad of the 'Net email: jho...@cs.uoregon.edu
URL: http://www.cs.uoregon.edu/~jhobbs/
Larry W. Virden
One thing that someone recently mentioned to me in a totally different
context is that with Java, you can easily reference various packages,
while with Tcl, it is quite difficult to distribute programs which need
particular extensions. Basically, you end up having to either distribute
everything, and hope that folk don't want to use it on any peculiar OS
and that they already have a C compiler, etc. or you have to build a
suite of binaries for the interpreter (or write your app in C and
embed the interpreter in it). This is much less convenient for
developers than Java's approach for packages.
I proposed quite some time ago that a Java-ized version of tcl, which
could be distributed in Java byte format and which used Java for
extensions, might be an alternative to the painful way folk have to
deal with extensions even with Tcl 7.5p1.
Graham Matthews
Daniel Ockeloen wrote:
> Maybe Dylan, Python etc etc are better on some point(s)
> but lets face it Java seems to a good mix of the old/new/hypable/sellable
> to have become the fastest growing lang. in history
Java is not a "good" mix of the old/new because :-
a) there is nothing new in Java -- all the ideas in Java are already in
existing languages.
b) most of the good parts of the "old", such as parametric typing,
have been left out of Java.
Java is principally hype, and the Java bandwagon driven principally
by that hype and promises of what is to be. Whether those promises
are ever fulfilled ...
graham
--
---------------------------------------------------------------
Bang, bang, Maxwell's silver hammer came down on her head
Bang, bang, Maxwell's silver hammer made sure that she was dead
---------------------------------------------------------------
Roger Oberholtzer
Larry W. Virden wrote:
>
> One thing that someone recently mentioned to me in a totally different
> context is that with Java, you can easily reference various packages,
> while with Tcl, it is quite difficult to distribute programs which need
> particular extensions. Basically, you end up having to either distribute
> everything, and hope that folk don't want to use it on any peculiar OS
> and that they already have a C compiler, etc. or you have to build a
> suite of binaries for the interpreter (or write your app in C and
> embed the interpreter in it). This is much less convenient for
> developers than Java's approach for packages.
How does the Java interpreter get on a system? Surely it is a
byte-interpreter that is compiled. I see no functional difference here.
And, there are additional things to distribute as well. The difference
is that the user probably has Netscape and so Java is already there.
Just luck that someone else handled the distribution/installation
details for Java. Not a real difference in Tcl and Java. Perhaps the TCL
plugin does exactly this for TCL/TK.
As for different packages, there is a proposed change to TCL that will
allow separate package installations without modification to TCL itself
(not loadable objects, but the runtime library stuff that makes the
application itself).
>
> I proposed quite some time ago that a Java-ized version of tcl, which
> could be distributed in Java byte format and which used Java for
> extensions, might be an alternative to the painful way folk have to
> deal with extensions even with Tcl 7.5p1.
Can the Java interpreter itself be in Java byte format?
I could run TCL/TK on UnixWare long before Java came via Netscape. There
was an early port by OSF, but it became available just as the world
switched to a newer Java API.
We still wait for JDK. (Other than Jeti-like CDs that never make it to
Sweden...)
This is not a strong argument, as the Java environment is soon to be as
prevalent as C is.
A few question: Can you do character-based apps in Java? We use TCL to
do software testing. A GUI to most tests is irrelevant. Also, Can you
mix C and Java as you can mix TCL and C? We have a TCL app that is a
wrapper around an NT-based DLL that allows us to control the DLL via TCL
- even from a remote host.
I really do not know the answers.
> --
> :s Larry W. Virden INET: lvi...@cas.org
> :s <URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
> :s Unless explicitly stated to the contrary, nothing in this posting should
> :s be construed as representing my employer's opinions.
--
_______________________________________________________________________
=======================================================================
Roger Oberholtzer E-mail: ro...@opq.se
OPQ Systems AB Phone: Int + 46 8 314223
Tomtebogatan 19 Fax: Int + 46 8 302602
113 39 Stockholm
Sweden
"Accuracy is addictive." - FUGRO
Donal K. Fellows
In article <324662A0...@erinet.com>,
Mitch Chapman <mcha...@erinet.com> wrote:
> FWIW, I find it more reassuring to see a language in use in a commercial
> package than to have that language supported by a major company.
> After all, XView, OPEN LOOK, NeWS, and OpenStep were all supported by a
> major company...
It's better if a language is both supported _and_ used, which is
definitely the case with Tcl and Java (I believe)
Donal.
John M Sadowski
Jim Fulton wrote:
>
> In article <324352...@maths.anu.edu.au> Graham Matthews
> <graham....@maths.anu.edu.au> writes:
>
> Joel Hug wrote:
>
>
> I suspect that Python will get one eventually.
I'm not so sure I would call Java's garbage collection "proper". Each
impimentation of the JVM is free to do as it pleases, so long as it
sticks to a IMHO standard which leaves too much room for interpretation.
--Mark Storer
Cameron Laird
In article <52cblf$7...@srv13s4.cas.org>,
Larry W. Virden <lvi...@cas.org> wrote:
>
>One thing that someone recently mentioned to me in a totally different
>context is that with Java, you can easily reference various packages,
>while with Tcl, it is quite difficult to distribute programs which need
>particular extensions. Basically, you end up having to either distribute
>everything, and hope that folk don't want to use it on any peculiar OS
>and that they already have a C compiler, etc. or you have to build a
>suite of binaries for the interpreter (or write your app in C and
>embed the interpreter in it). This is much less convenient for
>developers than Java's approach for packages.
>
>could be distributed in Java byte format and which used Java for
>extensions, might be an alternative to the painful way folk have to
>deal with extensions even with Tcl 7.5p1.
.
.
It's a sticky problem. Most of my work involves creating
applications which bind together Tcl extensions, modules
coded in C or C++, and often a proprietary language.
Installation is often a mess, one which I still haven't
worked out to my satisfaction. Java inspires little enthu-
siasm in me for now because, while its package mechanism
is superficially more straightforward, it's not an exten-
sion language--that is, it's not as easy to "glue"
together C-coded functionality as with Tcl.
--
Cameron Laird http://starbase.neosoft.com/~claird/home.html
cla...@NeoSoft.com +1 713 623 8000 #227
+1 713 996 8546 FAX
James F'jord Lynn
In article <324A29...@opq.se>, Roger Oberholtzer <ro...@opq.se> wrote:
>How does the Java interpreter get on a system? Surely it is a
>byte-interpreter that is compiled.
>plugin does exactly this for TCL/TK.
This is true that there isn't a big difference here, just luck that
Java has been more widely distributed (not good or bad luck, just luck).
One thing that should be pointed out here is that in addition to Navigator
bringing Java to the systems, OS/2 Warp 4 will include Java as part of the
operating systems, so that users do not need to download and install the JDK.
In addition to this, MicroSoft has also pledged to do this in Windows 95
(alhough I am unsure about NT 4.0), and some people invloved in linux added
it into there, although because of some lisencing issues which I haven't had
the chance to look at yet, there hasn't been a full integration.
>Can the Java interpreter itself be in Java byte format?
While it could, it would be useless to do so. In actuallity, implementing
the Java runtime is not a major undertaking. Apart from the GC, there really
isn't much to it. The main problem is implementing the JDK.
Oh, the reason that it would be useless is because you would need a
Java runtime to run the runtime, and thus it would defeat any of the purpose.
>We still wait for JDK. (Other than Jeti-like CDs that never make it to
>Sweden...)
If you have netscape, you can use it as a compiler for Java. You need
to get the JDK, take out the classes.zip file it will have, add it to your
CLASSPATH, and use 'netscape -java javac Foo.java' to compile Foo.java.
A hack, but it works.
>A few question: Can you do character-based apps in Java?
Yes. You can use System.in and System.out to read/write to the screen.
However, this will give the interface of those old Zork games. Doing an app
like vi is different, since that type of app needs the be able to move the
cursor around. I haven't tried it, and it should be possible, but I would
imagine it is ugly (actually, I imagine it is ugly under C too).
>Also, Can you
>mix C and Java as you can mix TCL and C?
I don't knoe if you can mix it like TCL and C, but you can mix C and Java
by having the C code in a DLL (or shared library) that is interfaced
through Java. I don't know enough about TCL to comment on similarities of
interfaces.
> We have a TCL app that is a
>wrapper around an NT-based DLL that allows us to control the DLL via TCL
>- even from a remote host.
This kind of thing can be done in a two-tier system. On the NT server,
there could be a Java interface with a UI to the DLL and a TCP/IP server
that aaccepts incoming sockets from a client (don't have to be Java). In
JDK 1.1, the TCP/IP server/client can be replaced with RMI. but we'll
just have to wait for that.
>I really do not know the answers.
That's okay. That's why there are newsgroups :)
--
Royalty free widgets - http://www.undergrad.math.uwaterloo.ca/~j2lynn/java.html
Kent Anderson
In <324A29...@opq.se>, Roger Oberholtzer <ro...@opq.se> writes:
>Larry W. Virden wrote
(other stuff clipped)
>A few question: Can you do character-based apps in Java? We use TCL to
YES!
>do software testing. A GUI to most tests is irrelevant. Also, Can you
>mix C and Java as you can mix TCL and C? We have a TCL app that is a
>wrapper around an NT-based DLL that allows us to control the DLL via TCL
>- even from a remote host.
>
Yes, you can have DLL written in C and use it from java. You do this through
native methods. The drawback to this is that you lose machine-independence
and then must create a version of the DLL (or shared library/object) for each
platform that your application will be used on. This might be a big deal, but
most C/C++ code is immediately portable (unless you wrote it to take
advantage of a particular architecture).
Donal K. Fellows
In article <DyD4K...@undergrad.math.uwaterloo.ca>,
James F'jord Lynn <j2l...@undergrad.math.uwaterloo.ca> wrote:
> In article <324A29...@opq.se>, Roger Oberholtzer <ro...@opq.se> wrote:
>> How does the Java interpreter get on a system? Surely it is a
>> byte-interpreter that is compiled. Not a real difference in Tcl
>> and Java. Perhaps the TCL plugin does exactly this for TCL/TK.
There is a fair difference between Java and Tcl at the moment though,
since the former relies on the distribution of pre-compiled byte-codes
and the latter relies essentially on the distribution of source (and
doesn't have any compilation step). In this respect, the scheme used
by Perl (source distribution with compilation to bytecode) comes
somewhere in-between. I suppose that there is a continuuum here:
C ------- Java ------ Perl ------ Tcl
Stuff to the left is compiled, stuff to the right is interpreted, and
development times tend to decrease as you go to the right (well, not
between perl and tcl, but you see my point)
> This is true that there isn't a big difference here, just luck that
> Java has been more widely distributed (not good or bad luck, just
> luck). One thing that should be pointed out here is that in
> addition to Navigator bringing Java to the systems, OS/2 Warp 4 will
> include Java as part of the operating systems, so that users do not
> need to download and install the JDK. In addition to this,
> MicroSoft has also pledged to do this in Windows 95 (alhough I am
> unsure about NT 4.0), and some people invloved in linux added it
> into there, although because of some lisencing issues which I
> haven't had the chance to look at yet, there hasn't been a full
> integration.
It always struck me as particularly odd to put Java in the OS itself.
Yes, support it enough so that java apps can be fired off with the JVM
when attempting to execute them (FYI, this is what Linux does - it is
a little like supporting shell scripts), but putting the JVM in the
OS? Why bother? It will only make the security of the system harder
to check and fix (and Microsoft's brouhaha with compiling Java to
native code is probably one of the daftest ideas to come out of
Redmond since BOB...)
Larry W. Virden
According to Dean Schulze <sch...@cassini.lpl.arizona.edu>:
: Tcl has problems scaling up to large projects. Is anyone
:aware of a project similar in scope to Via World Network that
:has been done in Tcl?
Sure. For instance, read the Tcl Commercial Uses FAQs, part 2, and you
will see things like:
"... The first is a "manager", or a graphical shell that is written entirely
as a wish script and ties together over 100 component programs, manages
the files they use, and gives the overall system a more unified look
and feel. The second is Leo, which is a grid visualizer that is partly
written in Tcl and partly in C++, and allows the user to examine and
modify computational meshes that are potentially very large. ..."
and the company (ICEM CFD Engineering, in Berkeley), goes on to
describe several others.
Then there is Computerized Processes Unlimited, whose entry contains the
statement:
"...CPU's Tcl/Tk efforts for SCL System Integration Technology and Auger have
resulted in excess of 250,000 lines of Tcl/Tk code, the largest known
Tcl/Tk project to date."
There are also entries by Entropic Research, where a very large project
to do software only text to speech systems using a Tcl/Tk GUI.
There are other commercial efforts as well (Sybase's huge retrogressive
test suite comes to mind) - but not all have been documented in the FAQs.
James F'jord Lynn
Donal K. Fellows <fell...@cs.man.ac.uk> wrote:
>It always struck me as particularly odd to put Java in the OS itself.
>Yes, support it enough so that java apps can be fired off with the JVM
>when attempting to execute them (FYI, this is what Linux does - it is
>a little like supporting shell scripts), but putting the JVM in the
>OS?
Yeah, I knew this was the way linux did it. I believe that this is
the same strategy that OS/2 used (adding the JVM as an Object). I anticipate
that Microsoft will do the same, using their ActiveX JVM.
By "Putting it in the OS," I only meant bundling it with the OS and
setting it all up so that the user doesn't have to. I would not have
suggested putting it into the kernal.
As for Reasons why you would want it more closely integrated, think
about launch time. To run a Java App, you need to launch the JVM and the app
in the linux model. I would like to see the JVM more persistant (yeah yeah
memory constrains, blah blah. RAM is cheap now :P ). Also, with
just one JVM powering all of the apps, there could be easier interprocess
communication (of course, then you'll get killer applications like the
killer applets, but that'll all be fixed).
Incidentally, the putting of the JVM in these OS's is only for
applications, not applets. Browsers will still prpbably use their own
JVM (except in the ActiveX case, where MIE will surely take it from
the OS, since it just instantiates a JVM object and doesn't
care if it's the one it has or the one that the OS has. Hmm, that was
convoluted. Nevermind). Once this is done, we can start shipping
shrinkwrap java apps.
> Why bother? It will only make the security of the system harder
>to check and fix
I don't really follow this reasoning other than protecting apps from
each other (and I'm not sure you want to do that, either. I mean a
normal app can kill other apps. The virus checkers will have to
be expanded though). Applications don't have a security manager and
if you want one, you have to write it.
> (and Microsoft's brouhaha with compiling Java to
>native code is probably one of the daftest ideas to come out of
>Redmond since BOB...)
Hmmmm, I don't think so. This is a highly requested product, and
if the OS support wasn't going to be there, I'd look at it. Java has
a very strong API and it keeps getting stronger (please kept the AWT
slags to a minimum. If it worked properly, it would be powerful too, and
it works pretty good regardless). JDBC, RMI, Object oriented windows,
Multimedia, GIF and JPEG support, and a million other goodies (net) that
are causing many people to come over to Java. They want to make
shrinkwrapped apps, too, so that they tuly have a larger market base
(remember you can only sell a Java application to someone with an
application oriented JVM, where as compiled Windows app can run on
all the Win95 and NT boxes).
Not to mention that the stupidest thing out of Redmond since BOB is
probably Blackbird. Oh, no, blackbird may squash Java, ;).
Paul B. Lamere
Along these lines, how does ToolTalk compare to Java Beans?
Chan Benson
: Along these lines, how does ToolTalk compare to Java Beans?
ToolTalk is a procedural API with a set of conventions. I believe that
it does not cover activation-in-place or other inset-type functionalities
(as does for instance, Microsoft's OLE).
Java Beans will presumably be a set of classes and interfaces that
implement a component architecture. I think it's safe to say that it
will be cleaner and simpler than Microsoft's component architecture
(DDE/OLE/COM/DCOM/ActiveX), because it would take some real effort to
not be.
Anyone got the scoop on what the relationship between OpenDoc and Java
Beans will be? I thought I had seen Sun endorsing OpenDoc in
association with Java.
-- Chan