[...]
George A. Howlett is the author of the BLT package.
Michael McLennan referred to him as "a programming god" while presenting a paper on data objects at the 2001 edition of the Tcl Conferences.
George Peter Staplin 2007 For various reasons some people on the TCT consider Howlett "difficult." I however do not. He was at one point a Tcl Core Team member. He didn't seem to always agree with others, and why should he? They didn't seem to respect his ideas, but that could have just been from past experience -- I don't know. Howlett ended up unsubscribing from the Tcl core list.
I don't happen to agree with everyone on the TCT -- According to KBK (a Tcl Core Team member), the team doesn't want to take outside ideas very seriously for Tcl 9 "We don't actually want to follow the user community too closely." - KBK I asked why this was, and was told "because the user community wants Tcl to be more like Blub." - KBK This was in a public chat, so I haven't betrayed his confidence. Others saw it. Some agree, others disagree.
So that's what some of the Tcl Core Team thinks of your ideas for Tcl, and the TIPs you propose. Happing Tcling ;)
KBK (2007-11-19) apologizes for an ill-considered remark.
I'm in the habit of offering, from time to time, needlessly inflammatory remarks, particularly in informal fora like the Tclers' Chat, sometimes as "devil's advocate," sometimes merely to provoke thought. The remark above was reminiscent of my remark, "the secret to success in software development is to listen carefully to your users, and then ignore them." By both remarks, I mean that those who use the products that we software developers develop are all too eager to tell us how to solve their problems. Both customers and managers would sometimes be happier if engineers were mindless automata that simply produced what was specified. Nevertheless, what our job as engineers entails is to figure out, from all the suggestions of how to solve a problem, what the problem actually is -- and then to develop a solution to the real problem, which may or may not be the demanded one.
Applying this concept to requests to the TCT from the Tcl community, I believe that any user request indicates an unmet need. The need may be as simple as user education ("did you know we already had a command that does that?"), may indicate a need that is too specific to a small set of users ("We don't have support for the Foobarmatic libraries in the core, but there's a tclFoobarmatic extension that's just what you need"), or may indicate an unmet need in the language. In any case, the proposed solution that a single user comes up with may or may not "fit". "Fit" may be evaluated in the narrow sense of "not breaking anything else" or in a broader sense of "preserving the conceptual integrity of the language." If the TCT "listens to the user community too closely" in the sense of accepting proposals without trying to improve on them, I'd argue that we're missing an important part of our job.
The remark about "more like Blub," if I recall correctly, was intended to convey the idea that many proposals to "improve" Tcl by making it appear more familiar to users of C, Java, Perl, and so on, are actually not improvements if they erode the concepts that set Tcl apart. I suspect that it we were simply accede to the demands of the majority of the community (or at least the majority of postings in comp.lang.tcl), we would wind up reinventing C, very badly.
If this process indicates that I "don't want to take outside ideas very seriously," I plead guilty.
RT Cute. I believe this is called "the non-apology apology". Wherein one claims to apologize but really just issues a string of self justifications. Fair enough, Kevin. Still, you rational gives pause because, 1) there is no acknowledgment of fallibility or limitation apparent for the TCT side of things. 2) there is no notice that many of the mere "users" are very long time and expert software developers who have an equal claim of expertise as anyone on the TCT. So your notion of the TCT protecting Tcl users from themselves, as it were, seems a bit stretched. It is hard to argue against the notion of "conceptual integrity of the language" Except as soon as one actually tried to detail that integrity they would likely be met with a fog of exceptions and fuzzy cases. Dead languages can often have great integrity too.
LV Of the over 300 TIPs submitted, approx. 10% were rejected or withdrawn by the proposers. The rest have either been implemented into the core, or away further action by the proposers.
Seems like, to me, that plenty of outside ideas - by people who are serious enough about their ideas to follow the documented procedures - have been accepted.