Information I hope will be passed to Larry Wall

  • Thread starter George Peter Staplin
  • Start date
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
 
S

smallpond

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/6b4...

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


Offtopic for this group. The email you want is (e-mail address removed)
--S
 
M

mcccol

Offtopic for this group. The email you want is (e-mail address removed)

It was in response to a public post regarding the current state of
PERL, and PERL's putative comparative virtues relative to tcl.

If the premises of the comparison are demonstrably false it's hardly
off-topic to correct them in the context in which they were given.

Colin.
 
U

Uri Guttman

m> It was in response to a public post regarding the current state of
m> PERL, and PERL's putative comparative virtues relative to tcl.

m> If the premises of the comparison are demonstrably false it's hardly
m> off-topic to correct them in the context in which they were given.


it is off topic in that larry doesn't read this group and hasn't in
years. also his state of the onion talks are very humorous and having
seen this one, any insults of tcl have to be taken with the jokes about
all the other scripting langs (and larry was trying to define that). so
to the OP who is whining about larry's comments, lighten up. you should
download the audio of the talk to really get it.

uri
 
M

Michele Dondi

Unfortunately it seems Larry Wall is lying about several aspects of Tcl
in his recent article on perl.com

I think you'll find that Larry Wall is a very fine and knowledgeable
person, but he's not perfect. If he claimed something that turns out
not to be true about Tcl, I could bet quite about anything that it was
not to spread fud about it, but just due to misinformation. And he's
shown on several occasions to be able to change his mind. You can
write to him directly, rather than ranting here.


Michele
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top