[...]
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.
KBK I lay no claim to infallibility, either personal or on behalf of the TCT. In fact, the TCT has accepted several TIPs that in retrospect were ill-considered, and degenerated into unseemly political squabbling over several others. Our process is not the best imaginable process for developing the language. We partake of all the limitation that comes of being human.
I presume that the critics do not sincerely believe that development of any piece of software would succeed without some gatekeeper deciding what goes into it and what does not. (I would blench at the though of Wiki-style "edit wars" attaching themselves to a code base!) Whoever is entrusted with the responsibility of functioning as gatekeeper will be a fallible human being. Gatekeepers will arrive with prejudices, with pettiness, with narrow interests. We hope that they will try to set them aside when making decisions. It doesn't always happen, even with the best gatekeepers.
All of this is to say that gatekeeping is a political process. When political systems are established, the best of them offer checks and balances - the power of one individual or group is held in check by the power of another. In open-source development, the ultimate check on unbridled power by the development team is the fact that the comminuty has the right to fork - to establish a parallel project built on the same code base and steered in a different direction. To be successful, a fork needs to have enough developer excitement behind it to provide it with the "critical mass" that it needs to stay alive.
Many regard forks as a drastic measure and a slap in the face of existing project management. At this point, though, I'd say that I'd welcome a fork or two. I'm as frustrated as anyone by the pace of development; if the more energetic developers are put off by the fact that the TCT is inexorably bound to the past (because of having to maintain a stable platform for existing users), a fork would provide an ideal environment for them to try their more radical innovations. I might even contribute some of my own development effort to such a project. And I suspect that I'm not the only TCTer that feels that way.
Short of forking, what can be done? Well, TIP #0 is not set in stone; it can be amended by the TIP process. And - whether you believe it or not - I do try to be responsive. If you feel that the stewardship of the TCT has been inadequate, cry out in the public fora for our replacement (if you can find better), or for a new system of governance for the Tcl code base. Get the community behind you. Either you'll effect change, or at least you'll be building up a base of support for an eventual fork if politics fails.
In the meantime, I'm going to keep on muddling through as best I can. I'm not always going to agree with you, and I'm not always going to be right. I'll usually err on the side of being too conservative - it's much easier to reintroduce a good idea that was missed than to retract a mistake that has been made. And I suppose that part of the job is to face occasional strident complaints about my stewardship. If they get specific enough that I have something I can act on, I'll try to mend my ways. If they get widespread enough, I'll step down and give someone else a turn.