This page has some interesting things on it,
http://www.icemcfd.com/tcl/comparison.html
It is the "TCL compared with other languages" page.
In particular it debunks some of the myths such as the "small footprint"
of TCL.
As far as all of this Java verses C verses TCL stuff goes, I have only one
comment:
"A House Divided Against Itself Cannot Stand."
Note that Honest Abe was not talking about the "North/South" divide here.
He was talking about how the "South" was divided against itself, and so
could not stand up to a protracted attack from a determined competitor.
Consider different camps inside Sun Microsystems as an example.
Java States, and TCL States. Sure, a lot of talk about cooperation.
But consider that the base model Unix environment doesn't even have
a common exception handling mechanism for system programs, and you
know the language toolsmiths have their work cut out for them even if
they spent every waking momement thinking about how great the other guys
language is to talk to.
Then consider Microsoft, who hve been dealing with cross-language procedure
calls and shared libraries for the better part of a decade, and have "found
religion"
in language-independed component integration, through various renamings,
such as VBC, and OCX, and OLE and ActiveX, but still pretty much the same
thing
headed in the obvious direction. Recapitulation. You want to add your own
favorite
scripting language to the web browser? No problem. To the web server? No
problem.
So, say you wanted to integrate Java and TCL. On which environment is it
easier?
Unix or Microsoft? Obviously somebody has a problem, and it isn't INTEL.
If it is a war analogy, then the Unix side is like the South in the
"American Civil War"
and Microsoft is like the North.
And ORACLE is like Great Britain. So far they have pretty much stayed out
of the conflict.
And while we are at it, three cheers for the AS-400 and VMS, two other
recent (younger than unix) operating environment with good
language-independant
component integration techniques. Although the users of the systems never
quite caught on to the ferver of the original developers.
From: Mike Haertel
Subject: OS support for exception handling (was: Re: TCL comparison ...)
Date:
Message-ID: <slrn5kuev7.p71.mike@ducky.net>
In article <··························@gjchome.nis.newscorp.com>, George J. Carrette wrote:
>But consider that the base model Unix environment doesn't even have
>a common exception handling mechanism for system programs, and you
>know the language toolsmiths have their work cut out for them even if
>they spent every waking momement thinking about how great the other guys
>language is to talk to.
This raises an interesting question, which I'd like to address to
you and anyone else with experience implementing advanced languages:
* Do you really want the OS to mandate an exception handling model?
* What if the OS's concept of exceptions doesn't match your language's?
* Even if the semantics of OS exceptions and your language's exceptions
are compatible, do you want the OS to dictate your implementation?
I've never implemented any language with a sophisticated runtime, but
I have given it some thought. I'm especially interested language
implementations that discard the conventional control stack in favor
of alternative approaches.
It's always seemed to me that OS's with any sort of asynchronous event
model (Unix signals, NT's exceptions, whatever VMS has) would constitute
a particular thorn in the side of a language implementor, since merely
by pushing stuff on a user process stack the OS has already gotten
chummy with the user runtime system.
So I am very surprised to hear you, a language implementor, saying you
*want* the OS to do stuff like this. Of course, your particular
implementation (SIOD) was designed to not be much of a departure from
garden variety C runtime conventions...
--
Mike Haertel <····@ducky.net>