Tcl is, of course, superior to Java in many ways. (What else were you expecting to read on the Tcl'ers Wiki?) This page documents significant differences between the languages. Most of it is quite factual, but there might be a little bit of ranting.
If you want to see more about how the languages can work together, see Java and Tcl, or look through the pages referenced by Category Java. (Go to that page, click on the page title, and see pages in the category.)
In response to this comment in comp.lang.tcl,
The reason is that it seems a greater likelihood that the runtime for a Java .jar would be present on a random client computer than the tclkit runtime. For that matter, I'd expect there to be more precompiled and ready to download platform binary distributions for Java runtime than tclkit runtimes.
Jeff Hobbs responded on 16-March-2004
... this is totally java FUD. Let's correct this GROSSLY incorrect statement with basic FACTS:
That's 32 platforms, and I know a few other experimental plats exist that aren't available for public consumption.
And now let's get to some anti-FUD, some thoughts that I am fairly sure on, but won't call fact (unlike Java bullshiteers):
Interesting Java article, criticizing the "promise of java" vs the actual delivery:
http://sakima.ivy.net/~carton/academia/java_languageoftomorrow.html
LV Aug 11, 2005 So far, in 8+ years of reading and looking at Java, I've only found 2 applications that were useful and worked, for me, out of the box — one is a command line app that generates DOC files for the Palm Pilot, and the othe other is the GUI driven application jPodder! I continue to seek useful applications written in Java that work out of the box.
TP I'll add a few more that work out of the box:
LV notes that Jacl isn't an application, and so doesn't qualify as an exception to the rule. As for jedit — it failed the LV test — after downloading the installer.jar file, java generates an error message. Shrug.
RS quotes from [L3 ] that Tcl's
set out [open file.txt a]
is in Java only
PrintWriter out = new PrintWriter(new FileOutputStream("file.txt",true));(FW: corrected slightly)
The usual graphical toolkits for Java are AWT and Swing, though each has its deficiencies (notably colossal verbosity relative to Tk...) See for example Click me.
Swank is a Tk-like toolkit as an extension to JTcl Interpreter and Jacl.
escargo I think there should be a distinction made between the Java language, the implementations of Java compilers, and the Java Virtual Machine. The Java language is a hybrid object-oriented langauge (hybrid in the sense that there are both primitive types and objects) with single inheritance. (Some aspects of multiple inheritance can be simulated using interfaces.) Source code in the Java language is often translated into Java class files (which contain byte codes) that are interpreted by a Java Virtual Machine (JVM). There are native compilers that translate Java source code into native machine code that does not require the JVM (and isn't cross platform anymore, of course).
davidw I think one of Tcl's advantages over Java is that it scales down, in a number of ways. Let's have a look:
If you are working on a large project, all this extra overhead might not make a difference, but if you need to scale down, to something small, fast, easy, light and portable, Tcl is probably a better bet.
Notes on comparison between, and connection of, Java and Tcl — pasted from the Tcl chatroom
[What is the this Donal is referencing?]
dkf: Java is faster at this than Tcl (optimised data structures make a difference) and much more maintainable than C (garbage collection... 'nuff said!)
suchenwi: But I've heard several times on c.l.t that Java engines are very slow?
dkf: Java's graphics are *ultra* slow. If you're not running graphically, then recent runtimes are pretty nippy. It certainly seems to be possible to get to around 50% of optimised C code's speed without too much effort.
dkf: The problem with Java's graphics is that they have a very sophisticated model inside, with full affine transforms and anti-aliasing. Very instructive to read about it; I think a really nice implementation of Jacl will be possible at some point. However, since it does all this and does it in Java, the performance on anything other than the very fastest of computers is disgusting. And in many people's eyes, graphical performance is the only kind of performance that counts. Which is not true, of course, as you well know... [In a subsequent conversation, Donal expressed this as, "Support for this sort of thing [anti-aliasing] is the main reason why Java Swing is such a slow dog."]
dkf: Faults with Java libs: no select() equivalent, Java2D too slow by far. Faults with Java language: no assert(), no return-type polymorphism, no generic classes. I think that covers most of it.
NEM: Note: Java 1.4 has an assertion mechanism (although, oddly the compiler won't recognize it unless you pass the right flags), and the new IO library looks a lot better. There also seems to be a general speedup and other enhancements (like a RE engine). The Jacl/Java alternative to Tcl/C/C++ is getting better, and is quite a nice environment to work in.
NEM I see 1.5 is introducing generics too (like C++ templates). By the way, I was of the impression that Swing is slow because of synchronization.
Cameron: One of the points I keep trying to make about Tcl Blend is that it's an incredible blessing to anyone working with legacy code in the sense of C bindings. A Java IDE plus JNI is sloooooooow and cumbersome and flaky, and Tcl Blend just feels like all sorts of fun. And is also a bit fragile on occasions.
Jeffrey Hobbs (in comp.lang.tcl, but it fit here so well): I've come to the realization that there are so many more Java jobs than Tcl jobs because it takes 10 Java programmers to do what I can do in Tcl. I'm only half-joking...
DKF: Swing isn't synchronized; it uses an event model that is at least superficially similar to Tk's. I'd hate to see how slow Swing would be if it had loads of synchronization all over the place.
Rick Hedin (also from comp.lang.tcl — again, because it fits so well):
Okay, I can't stand this anymore. I know I'm the only person in the multiverse who feels this way, but I'm going to say it.
Java doesn't work.
I posted to that effect on the java group, and I got answers that basically amounted to: no, it doesn't. But no one summarized: well, then, we've agreed -- Java doesn't work.
There are four reasons why I say that Java doesn't work.
After spending a year messing with Java, we moved the project to Tcl/Tk. Guess what? It works.
Another c.l.t snippet, by Ioi Lam, on Kanji display in Java: And by the way, TK is WAAAAAAYYYY better than Java in this respect. Trying to get Java to display Kanji chars on English win32 is like soliciting sex with a nun. You know all the equipments are there, but she just won't do it.
Larry Virden says "I'm still looking for a useful Java application that I can just download and use. I've tried about a dozen Java apps, each required that I mess around with wrapping scripts, weird sets and unsets of various shell environment variables, downloading various versions of various run time packages — and in the end, the programs didn't work and the authors weren't able/interested in resolving the problems.
Larry did eventually find one useful Java application — MakeDocJ — which converts text files to PalmOS document format and vice versa. That remains one of the few programs that he has found that he could download and use without problems. However, he continues to seek more.
LV Amusing antedote. This morning I downloaded the latest version of makedocj to use it to create a Palm version of the Tcl and Tk doc. Tried it... and the result is a weird Java error that prevents me from creating said file. So much for an app that can just be downloaded and used...
DKF: I've had great success with Apache Ant, and some success with Apache Tomcat and Apache Axis. I also use the Unicore[L4 ] suite a lot, but that's possibly because I'm one of the developers. :^)
<anonymous> wrote in comp.lang.tcl on Mar 1, 2001: Only intelligent people should use Swing. It's got thousands of classes and hundreds of thousands of methods and fields. Whenever I need to do something, like, "How do I put a character into this seemingly simple widget", I'd have to look up 5 different interfaces and classes and still fail to compile.
With a complex beast like Swing, it's not just a matter of "what button should I push", but rather "How do I put myself into a nice metamorphosis so that I am deemed acceptable by the Swing Gods." In contrast, most stuff in Tk can be explained within a single manpage.
Cameron Laird on comp.lang.tcl: Java: the performance of a prototyping language, the convenience and portability of Assembler.
PSE --- I was asked to evaluate the applicability of JAVA to something that will be at least a 10 man-year project, and could not find anyone who could deliver a well-considered evaluation of the solaris/linux interoperability and core development path (for JAVA) projected over the next couple of years. This surprised me, since I expected to hear that they proceeded in lock-step. Of course, this does not mean that they don't... but it is bothersome that the folks who I thought would KNOW could only guess.
The least convincing argument I heard was the one about how "gcc includes a JAVA compiler now, so JAVA must be 'it'". I guess that means that CHILL was 'it', and before that Objective C was 'it', etc.
It looks to me like JAVA is the greatest beneficiary of high hopes and wishful thinking... and not much else besides.
One CS prof explained to me that M$ provided every student in his class with a free copy of J++, so of course that was what he used to teach the class. Apparently the (Large University System I May One Day Be Working For Not Mentioned Here) system is utterly ignorant of free software.
Larry McVoy on Tcl being an order of magnitude superior to Java in GUI programming memory, speed, ...: [L5 ]
Feb 19, 2002, kennykb wrote on comp.lang.tcl about Java and Tcl:
My experience is that managers don't give a rat's arse about the looks and themes. The biggest resistance that I get to Tcl/Tk from managers comes in arguments like, "Tcl? Where am I going to hire developers that know that outdated stuff? I get dozens of Java-developer resumes on my desk every week," and "Scriptics went under, what are you going to do if ActiveState does the same?" Eye candy has nothing to do with it.
Presenting Tcl as a C library doesn't help very much, because that gets into "C applications aren't reliable, they have pointer errors and memory leaks, why aren't you using Java?" TclBlend gets the same reaction because of the amount of C in it, and Jacl does nothing to civilise Swing.
Have we mentioned lately that Tcl programs tend to be FAR thriftier than Java in memory usage? At one time "embedded Java" seemed like a good idea. Now it's mostly a joke.
Java will not disappear. It will become even more widely used than it is now. Why? Java Enterprise (J2EE) is the Cobol of the 21st century. Something had to replace 20th century Cobol... But, does that make Jacl/TclBend JCL? ;-) -- Todd Coram
TP Todd's analogy slightly more detailed:
Of course, between 'then' and 'now', we had the client-server model, fat clients connecting directly to a database.
Kevin Kenny wrote in comp.lang.tcl: To your colleagues who think you're crazy, I say, "Tcl is not C." Perhaps you can sell them on the idea by saying it's more like Java. In fact, it is, in that
foreach foo $bar { ... }is similar in flavor to the more verbose Java code
Iterator it = bar.iterator();
while ( it.hasNext() ) {
Foo foo = (Foo) it.next();
...
}NEM I think the Java example is more like:
for (Enumeration e = bar.elements();
e.hasMoreElements();) {
Foo foo = (Foo) e.nextElement();
}That's assuming you've already imported java.util.Enumeration, and that you are sure that all the elements will be of type Foo (otherwise, you want a try/catch around the cast looking for ClassCastException). Enumerations or iterators are nice. I think the Java ones even allow you to delete elements in the container you are iterating without screwing up the loop.
NEM Actually, I think Kevin's example works too. I hadn't noticed Iterators appearing on the scene. Iterator is the new version. I guess the name change is the result of Java packages not being versioned (unlike Tcl's packages of course). FW: There is a versioning system, but it's so ineffective (especially for Java Beans) that no one's using it, and a fix is expected eventually.
DKF: Actually, Java 1.5 has some language support for doing this sort of thing even more neatly:
for (Foo foo: bar) {
...
}If your collection isn't actually specialised to be a collection of Foo instances (generics are such a good idea, given that they are effectively based on something that looks very much like type variables, which are a very good idea as any SML or Haskell hacker can tell you), you'll need this instead:
for (Object o: bar) {
Foo foo = (Foo) o;
...
}IL IDE edit, compile, start app, test, rinse repeat. vs. edit, start app, test.
Depending on machine you could be dying of old age before your Java app even through an error.
Verbosity is such a huge problem as well, as Java code increases in complexity easily it becomes harder to read while tcl's "archaic" and "child-like" syntax grows gracefully.
puts [command -arg [command [string concat $var0 "string"] [command $var1 $var2]]]
System.out.println( obj.method( obj2.method2( new String( var0 + "string" ) obj4.method( var1 var2 ) ) ) );Most likely the Java call would span two lines adding to fun reading later. I'd add more examples here, but I have to get back to compiling, grumble grumble.
in an argument FOR Java, there are more jobs available, and it's object oriented (out of the box).
Lars H: The Tcl example would more naturally be
puts [command -arg [command2 "${var0}string" [command4 $var1 $var2]]]but this seems easy to miss, if you're coming from an Algol-family language. I spent quite some time when I first learnt Tcl to search for the command for concatenating strings, until I realised that there wasn't any need for it.
edit — oops! yeah i knew that but clearly my tcl is slipping away from me without use ;)
RS: In fact, the quotes are redundant too, as they're only needed to span explicit whitespace in word grouping, so make that
puts [command -arg [command2 ${var0}string [command4 $var1 $var2]]]MSW About the verbosity of Java (and e.g. C++): this is truly an argument for the language, at least in a "business" setting. Yeah, it gets big, complex and weird quickly. Great, that's ensuring you'll be coding the mess tomorrow still.
29sep04 jcw: The above is one half of the coin. Compare the verbosity of "a+2*b[3]" with
expr {$a+2*[lindex $b 3]}Tcl is more macro-expander like and string friendly, languages such as Java use algebraic notation.
TV (Spet 30, 2004) I've glanced over the page, and I didn't see a mention of a great and essential difference between tcl and jave:
And on top of that, the resulting java code is still machine-independently interpreted, which is not all too efficient a principle. So, one has AND the disadvantage of having to compile code, AND still interpreted end results.
Interpretetion has advantages for example like
> Give the formula to plot:
2*$x+1Try that in a compiled language in general.
Java of course has a decent use (as I knew it long before it was popular) as webpage applet, that on itself is fun, though contemporary javascript (of course a completley differen, interpreted, language) has uses in that direction, too.
But jave isn't very decent with it's version, I often ran into incompatibilities using java applets/code. Tcl/Tk thus far runs even my oldest scripts (though I don't have the very oldest scripts hanging around...) without any change, like the examples, too, though I got some trouble with requiring a close on a self-closed channel for fileevent.
DKF: It's still nicer to use Tk than Swing. Tcl vs. Java is less clear cut; they're suited for different things.
Scott Nichols I've worked both with Tcl's C API and Java's C API (Java Native Interface or JNI) and Tcl's C based API is much easier to use. Java requires any libraries written in JNI to be loaded statically (shared by all instances of the currently loaded object, threads, etc.) yuck !. This means the C library author has to program their sources to be thread safe and follow a strange Java threading model. But, I agree with a comment above about Java applets. They are kind of fun to write and add some life to a normally dull web page, but not all browsers support them and are frowned upon by some other developers. Some may consider writing a Java applet cheating.
DKF: Actually, if you code with Tcl's C API you pretty much have to follow Tcl's threading model too. It just tends to not be too onerous in practice.
IL: Java 1.5 update, Aug 11, 2005. The new support in 1.5 (Tiger, RAWR!) for a foreach construct in Java makes for some added coding convenience and legibility, but the new autoboxing support seems dubious and contrary to the original design of the language. If I have ever seen a language in the middle of an identity crisis it's Java.
Also, as if it weren't already a major bone of contention, IBM's SWT code base is basically screaming, "Swing, Awt, we don't care: they're broken, Sun wont fix it, so we'll make our own". Instead of "Write once, run anywhere" it promises "Write once, run natively". Java as a wrapping language? More and more Java is making strides towards becoming the world's largest scripting platform. And with languages like Groovy coming into the picture, the future of it seems uncertain indeed.
In spite of all that, with Eclipse 3.1, I have to say coding Java is a lot nicer now than it was say 2 years ago, Eclipse removes a laaarge part of the tedium. It's not so bad now, hah. What saves it time and time again is that there are a million open source packages available for it, which I attribute mostly to the success of the Sun advertising machine.
I don't think Java will ever "scale down"[L6 ], which is why I'm working on Hecl; to make it possible to do things easily in Java based systems, which will make it more fun and faster for good programmers, and open up possibilities to people who previously wouldn't have had had them. — davidw.
Quotes from the Tcl chatroom on 2005-09-22, triggered from the fold page:
suchenwi Tcl is just such a great laboratory for CS concepts arjen If that were only understood and appreciated by the rest of the world! stevel Tcl is a great CS laboratory, Java is a CS factory ... stevel students need a laboratory not a factory suchenwi ..where the sweaty workers toil their long days... arjen Isn't it more like a labour camp? suchenwi Java is a serious language. The coders smile so seldom. arjen Given the vast amounts of boring code they must write to achieve something