G
George Peter Staplin
Unfortunately it seems Larry Wall is lying about several aspects of Tcl
in his recent article on perl.com
I hope that some of you will please pass this thread along to him, or
that he will read it, and post a correction on perl.com
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/6b4aac569dadaba8?tvc=2
At the very least he could state that his knowledge of Tcl is
outdated. It would be the noble thing to do.
"The string metaphor tends to have bad performance ramifications, but
that's not why Tcl languished, I think. There were two reasons for
that."
He talks about Tcl as though it's dead or dying. There are TIPs (Tcl
improvement proposals) being submitted, performance improvements, bug
fixes, etc. going on almost everyday. It's not very respectful of the
work of others.
"First, Tcl stayed in the Unix mindset that controlling tools was the
opposite of creating tools, so they didn't optimize much. The fast parts
can always be written in C, after all."
I'm a Tcl core developer (though not on the core team) and I can tell
you that pure-Tcl speed is of upmost importance to most developers, and
many man hours have gone into optimizing, benchmarking, and figuring
out solutions. He does the Tcl community a disservice by stating
we don't optimize much.
"The second reason was the lack of a decent extension mechanism, so you
ended up with separate executables for expect, incr-tcl, etc."
This has not been true for many years. Expect and Incr-Tcl work as
loadable extensions. An extension is loaded using dlopen()/dlsym() in
POSIX/Unix and LoadLibrary()/etc. in Windows. A stubs mechanism is also
provided to allow for backwards compatibility in C extensions for Tcl.
Another common misconception is that Tcl doesn't support binary, which
also is untrue, and has been for many years. Though Larry didn't
specifically mention that.
Please Larry Wall, don't misinform developers that don't know any
better. I would appreciate a correction.
Thank you,
George
in his recent article on perl.com
I hope that some of you will please pass this thread along to him, or
that he will read it, and post a correction on perl.com
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/6b4aac569dadaba8?tvc=2
At the very least he could state that his knowledge of Tcl is
outdated. It would be the noble thing to do.
"The string metaphor tends to have bad performance ramifications, but
that's not why Tcl languished, I think. There were two reasons for
that."
He talks about Tcl as though it's dead or dying. There are TIPs (Tcl
improvement proposals) being submitted, performance improvements, bug
fixes, etc. going on almost everyday. It's not very respectful of the
work of others.
"First, Tcl stayed in the Unix mindset that controlling tools was the
opposite of creating tools, so they didn't optimize much. The fast parts
can always be written in C, after all."
I'm a Tcl core developer (though not on the core team) and I can tell
you that pure-Tcl speed is of upmost importance to most developers, and
many man hours have gone into optimizing, benchmarking, and figuring
out solutions. He does the Tcl community a disservice by stating
we don't optimize much.
"The second reason was the lack of a decent extension mechanism, so you
ended up with separate executables for expect, incr-tcl, etc."
This has not been true for many years. Expect and Incr-Tcl work as
loadable extensions. An extension is loaded using dlopen()/dlsym() in
POSIX/Unix and LoadLibrary()/etc. in Windows. A stubs mechanism is also
provided to allow for backwards compatibility in C extensions for Tcl.
Another common misconception is that Tcl doesn't support binary, which
also is untrue, and has been for many years. Though Larry didn't
specifically mention that.
Please Larry Wall, don't misinform developers that don't know any
better. I would appreciate a correction.
Thank you,
George