Are you kidding? How about an extensive, reliable, tested library of networking, user interface, and I/O code which can be used to create "complex applications" extremely easily.
Tcl has had that for years. So does Python. Java has its good points, but they are buried under the piles of steaming 'hype', or to put it a different way:
"It has been said that java is great for engineering next generation solutions to enable maximization of developer income by means of enhanced buzzword use"
Tcl/Tk is great. Lots of people certainly get great mileage out of it doing "quick and dirty", but if you design your code right, it can be quite clean as well. Tcl is flexible enough, and has enough of its C API exposed that you can load OO as an extension - [incr Tcl] is a popular one, if you want to do OO. Of course, it's possible to do "design patterns" kinds of things even without that, you just have to be clever about it.
Re:From the people who brought you:
on
Effective Java
·
· Score: 1
"It's a tool to get your job done"
Which is a very sensible sentiment. The problem is that, because Sun has spent millions of dollars marketing it, management now thinks that it is the only tool to get the job done, when there are many other fine tools, such as C, Tcl, Python, etc... that each have good features.
That's what I find frustrating about Java. That and the fact that I like free software, and the Java comunity doesn't seem to have the strongest of relationships with those ideals.
Here are a few reasons why someone would want to use Tcl:
1) Its implementation is beautiful. The C code is some of the cleanest and most pleasant that I've ever had the pleasure to read.
2) The language itself is quite comprehensible, even to beginners. Python is maybe a tad easier, but Tcl is certainly not tough to pick up.
3) You can write control structures *in* Tcl. For example, even though the language doesn't have 'do... while', you could write it in Tcl itself.
4) Lots of neat stuff in the implementation, like the event loop.
5) It's extremely easy to embed and extend. It makes it incredibly easy to make your application scriptable. Also, it's not that big (although larger than Lua, for sure), so it won't bloat your app too much.
I think it's quite fitting. Ground up and spit out by the silicon valley mill. More than a critical mass of human talent, I see it as a modern day gold camp which has never given up the boom and bust cycle and mentality of the gold miners that built northern california.
Not really. Don't think they are quite as good as in some languages, but no worse, either.
Tcl's not perfect, but it's worth considering for a lot of things, especially when you need something to use from C, or where you want to extend it in C. Think of it as a C library that provides a programming language.
I would have liked to have at least seen Tcl listed in the "why we didn't choose X" section, as there are a lot of good reasons to use it, that jive very nicely with the reasons he gives for using PHP. AOL uses Tcl in their (free software) web server, for instance. There is also the stuff (disclaimer - I work on it) at:
even though it certainly isn't the fastest. One of the nice things about Tcl is that it's much easier to write C code to use from Tcl, or vice versa, which makes it very easy to speed up slow portions of your code with C.
With a good, clean interface, it's a lot of fun to write two-tiered applications, in addition to being an extremely powerful way of doing things. Look at any large enough app, and you are bound to find a scripting language of some kind, be it VB, Tcl, Lisp, Lua, elastiC, or something else...
Tcl certainly isn't as cool as Perl, but the implementation is very, very beautifully written C, and combining C and Tcl is a pleasure. It's fun, simple and easy. You also have access to a lot of neat internal features.
Perl, IMO, is the worst of the scripting languages to combine with C... the interface is not pretty. Other languages like Python aren't bad. Lua is good if you want something really small and fast.
This is the same silly argument people used with Linux for a while. There are a lot of people, however, who sell tech support for Debian, including my employer, Linuxcare.
Alpha, ARM, m68k, beginnings of a mips port, i386, ppc, sparc and ultrasparc. It runs pretty well on all of them, too, and they are given equal importance, even if most developers run i386.
I prefer usenet to lame web interfaces
on
Is Usenet Dying?
·
· Score: 2
Usenet is much nicer to browse through than nasty web based things like slashdot. You can use a variety of clients, instead of being stuck with a web browser - the lowest common denominator.
Slashdot Mirror
Technically, that would make it not Open Source, though.
Are you kidding? How about an extensive, reliable, tested library of networking, user interface, and I/O code which can be used to create "complex applications" extremely easily.
Tcl has had that for years. So does Python. Java has its good points, but they are buried under the piles of steaming 'hype', or to put it a different way:
"It has been said that java is great for engineering next generation solutions to enable maximization of developer income by means of enhanced buzzword use"
Tcl/Tk is great. Lots of people certainly get great mileage out of it doing "quick and dirty", but if you design your code right, it can be quite clean as well. Tcl is flexible enough, and has enough of its C API exposed that you can load OO as an extension - [incr Tcl] is a popular one, if you want to do OO. Of course, it's possible to do "design patterns" kinds of things even without that, you just have to be clever about it.
"It's a tool to get your job done"
Which is a very sensible sentiment. The problem is that, because Sun has spent millions of dollars marketing it, management now thinks that it is the only tool to get the job done, when there are many other fine tools, such as C, Tcl, Python, etc... that each have good features.
That's what I find frustrating about Java. That and the fact that I like free software, and the Java comunity doesn't seem to have the strongest of relationships with those ideals.
Here are a few reasons why someone would want to use Tcl:
... while', you could write it in Tcl itself.
1) Its implementation is beautiful. The C code is some of the cleanest and most pleasant that I've ever had the pleasure to read.
2) The language itself is quite comprehensible, even to beginners. Python is maybe a tad easier, but Tcl is certainly not tough to pick up.
3) You can write control structures *in* Tcl. For example, even though the language doesn't have 'do
4) Lots of neat stuff in the implementation, like the event loop.
5) It's extremely easy to embed and extend. It makes it incredibly easy to make your application scriptable. Also, it's not that big (although larger than Lua, for sure), so it won't bloat your app too much.
I think it's quite fitting. Ground up and spit out by the silicon valley mill. More than a critical mass of human talent, I see it as a modern day gold camp which has never given up the boom and bust cycle and mentality of the gold miners that built northern california.
You might consider either the eCos operating system, or one of the BSD's. They both allow you to do what you want.
Not really. Don't think they are quite as good as in some languages, but no worse, either.
Tcl's not perfect, but it's worth considering for a lot of things, especially when you need something to use from C, or where you want to extend it in C. Think of it as a C library that provides a programming language.
I would have liked to have at least seen Tcl listed in the "why we didn't choose X" section, as there are a lot of good reasons to use it, that jive very nicely with the reasons he gives for using PHP. AOL
uses Tcl in their (free software) web server, for instance. There is also the stuff (disclaimer - I work on it) at:
tcl.apache.org
There are reasons not to use it, too, but it's a pity that it wasn't even investigated.
Tcl isn't the slowest thing out there:
shootout
even though it certainly isn't the fastest. One of the nice things about Tcl is that it's much easier to write C code to use from Tcl, or vice versa, which makes it very easy to speed up slow portions of your code with C.
With a good, clean interface, it's a lot of fun to write two-tiered applications, in addition to being an extremely powerful way of doing things. Look at any large enough app, and you are bound to find a scripting language of some kind, be it VB, Tcl, Lisp, Lua, elastiC, or something else...
And by "cool", I mean cool as in "acceptable to the slashdot crowd". I use Tcl and C professionally, cool or not:-)
Perl, IMO, is the worst of the scripting languages to combine with C... the interface is not pretty. Other languages like Python aren't bad. Lua is good if you want something really small and fast.
It's easy to use, even for the web people who often don't have a lot of programming experience.
It has a great C API, so that you can write the really speed critical components in C, and call them from your Tcl code.
They recently fired Zack Brown, who does Kernel Traffic. It's now at http://kt.zork.net
There are quite a few bright people employed with Linuxcare: http://www.linuxcare.com/abou t-u s/os-dev/index.epl. I prefer postfix to qmail, myself:-)
Actually, Sun is an investor in Linuxcare. As is Dell: http://www.linuxcare.com/about-us/press-center/pre ss-release/2000/07-31-00-funding. epl
This is the same silly argument people used with Linux for a while. There are a lot of people, however, who sell tech support for Debian, including my employer, Linuxcare.
as well as Alpha, ARM, m68k, PPC, and sparc64, with work also being done on MIPS and PA-RISC. See http://www.debian.org/ports/
... by a bigfoot...splotch.
Alpha, ARM, m68k, beginnings of a mips port, i386, ppc, sparc and ultrasparc. It runs pretty well on all of them, too, and they are given equal importance, even if most developers run i386.
Usenet is much nicer to browse through than nasty web based things like slashdot. You can use a variety of clients, instead of being stuck with a web browser - the lowest common denominator.