I'd like to:
- comment on Richard's remarks
- address some issues that I haven't seen anywhere else
- refrain from addressing issues that have been dealt with elsewhere
>The principal lesson of Emacs is that a language for extensions should
>not be a mere "extension language". It should be a real programming
>language, designed for writing and maintaining substantial programs.
>Because people will want to do that!
Then why call it an extension language? You can't compare extending an
application like emacs with extending a programming language like C/C++.
In the first case you *have* to write "substantial" programs, because
you can't or don't want to (ever looked at the emacs source code?) modify
the application. In the second case (Tcl) you make an engineering tradeoff
about which parts of your software change so rapidly that it is better to
implement them using Tcl.
>Another lesson from Emacs is that the way to make sure an extension
>facility is really flexible is to use it to write a large portion of
>the ordinary released system. If you try to do that with Tcl, you
>will encounter its limitations.
I would disagree with that statement as well. Usually the domains of
building a system and building applications that are built on top of
that system have characteristics different enough to warrant different
languages.
Gnu software always looked to me as wanting to solve all the problems
at once and providing little structuring of the problem space. So this
disagreement might just be an irreconcilable difference of philosophies.
>Tcl has a peculiar syntax that appeals to hackers because of its
>simplicity. But Tcl syntax seems strange to most users. If Tcl does
>become the "standard scripting language", users will curse it for
>years--the way people curse Fortran, MSDOS, Unix shell syntax, and
>other de facto standards they feel stuck with.
So what? You seem to overlook the simple fact that the only purpose of
writing software is to make money - either from your customers or from
your University. We chose Tcl/Tk because:
- some applications similar to ours already exist
- it is easy to learn (a couple of days to get started)
- it is robust and has support both from the developer and the user community
- there is a critical mass of developers out there (according to the
resumes I received for summer jobs)
- most likely it can be ported to other platforms in the near future
and therefore our software investment seems to be most secure for the next
couple of years.
These factors by far outweigh any shortcomings of the syntax, which
certainly couldn't win at a beauty contest.
>Some people plan to use Tcl because they want to use Tk. Thankfully,
>it is possible to use Tk without Tcl. A Scheme interpreter called STk
>is already available. Please, if you want to use Tk, use it with STk,
>not with Tcl. One place to get STk is from
>ftp.cs.indiana.edu:pub/scheme-repository/imp/STk-2.1.tar.Z
Thanks for the pointer. Can we incorporate it in commercial products?
Thomas
-- Thomas Werthmann-Auzinger MTS, Software Architecture Siemens Corporate Research, Inc. (609) 734-3697 755 College Road East (609) 734-6565 (Fax) Princeton, NJ 08540 twa@scr.siemens.com