PWQ 31 Jan 04
From comments made in Dictionaries as Arrays.
The purpose of the aforementioned page was to suggest a way of addressing differing views on how TCL would allow concepts to be expressed that currently cannot be. Prior to this post ,the general discussion was of the form:
Dear TCT, Can we please have arrays as first class variables?
Dear Geek, No but here are dicts that do the same thing.
Dear TCT, But dicts dont use the same syntax.
Dear Geek, We are not breaking TCL backward compatibility just to
support your desire to have this feature.So Philip put his thinking cap on and spent some of his valuable time onto this issue and came up with the post as referenced above.
Rather than take sides and debate which option is 'better' and use majority rules and political manovering, I looked for a proactive solution (a solution that is better than the current one when applied to issues outside the current problem scope).
I looked at the issue from the point What is the least we can do that would allow all parties to go forward.
The solution I put proposed a small change to the core that had nothing to do with dictionaries or arrays (nothing about them enters into the discussion other than as examples for clarification).
As I am not a TCL CORE developer I am not aware of the ramification of the changes I put, so I left the specifics of my suggestion to be commented on by those more familiar.
Instead of comments like:
A) It is more complicated than that, but put in a TIP so that this thread can be captured formally ...
B) Please supply more information on ... so that we can comment.We get remarks on The tone of the post and who pays who for what.
While I share some of the burden for the waste of bandwidth, this is due more to cultural differences rather than a deliberate desire to antagonize those referenced.
Why do we need to change the TCL core?
There are two parts to this, the first is that the language is not complete at the script level. Some things can only by done as a 'C' extension but with a desire to be invoked from the script level.
The seconds reason is that TCL is a solution looking for a problem. Every TCL programmers applies TCL to an instance of a problem to generate a solution (read application). In doing this most programmers find that they have to expend more effort that first thought. If an analysis is done, is may point to some design decision made at some point in TCL's creation (or extension/modification). The analysis further shows that if a different decision had been made, then the extra effort would not have been needed.So they desire the original decision be revoked an a new one instantiated so that similar jobs in the future require less work.
From the Q Paradigm, a new system will be adopted only when it achieves a lower entropy than the present system and the change process provides the activation engery to enact such change of state. To express this crudely.
People are lazy and will always take the easy way out.
Q. Why Don't I just submit a TIP then?
A. First I would like to know why 50% of the TIPS dating back to 2000 have not been finalised (archived, rejected, voted on, suspended et al). They have been raised, discussed, and then no further action has been taken by the TCT. It seems a waste of time to contribute insightful input to have it sit around until is is no longer relevent.
Q. Don't talk about it, just do It, make same changes to the core and put them on the net get on with life.
A1. Because OSS relies on the collective input from developers. If no-one contributed to a collective goal then there would be no OSS. My goal is to write code once, not have to change it every time a new version of TCL is released. This is why I don't contribute extensions to TCL.
A2. This again is reactive development. It also sets in motion a path of least resistance. That is, because someone has already written the code we will adopt it. While the change proposer should be expected to contribute substantively to the coding effort, this should be done only after discussion on the change has been concluded. Put more simply, changes that have already been written stand more chance of being adopted.
A long intro but necessary. So back to the title, If I were to complain about the TCT I would write thusly:
I would prefer to see the TCT as a body that sets the standards and framework for change rather than implementing the change. For example if someone wants a change, the TCT sets the ground rules for how it would be implemented in both the C and script api's without ruling on it inclusion or exclusion from the core. This is a big stick (to beat you with) that if in the future the TCT were to include this feature in the core, this is how they would do it. The carrot is that if you adopt their way you will not have to expend effort in reimplenting your change to stay compatible with future versions of TCL.
This means that if the change is adopted to become part of the core then the all the proposers work will be of immediate use to other users.
In Closing
Anyone that submits opinions in the public domain, must accept critism, this includes myself and the TCT. By nature critism is expresed in the negative.
Also when we wish to prove something we test the assertion by attacking it with examples to disprove it. We consider the assertion proved when we run out of examples to disprove it. In the same way, when someone suggest that a given change results in a better system, the only way we can test this is to though repeated argument against it.
This argument by its very nature must be expressed in a negative way. When I have expressed negative comments posted in the public domain it is because my goal is to help make TCL All it can be. I don't ask that software be easier, I just ask that it be better.
And thanks to the person that adds the category links that I am too lazy to add.
FW: My criticism about the TCT is that Tcl progress is so ... slow. Yes, in a language used by so many, precision and consistency are valued. But somehow I just don't think the TCT are pondering and laboring continuously for the 3 years it takes to get Tcl features added. There's got to be some padding there.
My guess as to how the TCT works is that the actual pondering is done on the team members' individual time, e-mails are sent back and forth, and a vote is held once a majority of members have developed some kind of opinion. Complaints are raised, but the amount of people, all individually busy, who have to discuss something, can hardly result in a fiery, back-and-forth debate that ultimately convinces a majority toward one side, since the information flow is slow enough that a debate that tackles all issues takes years. Plus, anything that raises so much controversy in the first place would confabulate and set off even more slow-motion debate on whether it's worth changing the language for something so controvertial. And by the time it hits the voting block, surely not every member will have a strong opinion, and many will vote against change by default merely due to the degree of controversy. And the same process of distraction and skepticism, even after approving a change, fillibusters the eventual actual implementation of it as well.
Tcl is run by a comittee, a system notorious for, well, y'know. A slow-motion, long-distance comittee. It's amazing anything has changed at all. I'm not blaming anyone. This is all speculation verging on fantasy, so I'm open to any TCT members who'd like to correct me here on what exactly the process is like.
RS: I have used Tcl since 7.4/4.0 and have seen many changes over the years (for a deeper look back in time, see Tcl 2.1). I liked it then, I like it now, and have over eight years not found a language that better fits my needs. Of course, history has left some nooks and crannies in the architecture and syntax details (e.g. llength vs. string length - but C and C++ have them as well...). But most important, I think of Tcl as a "gift horse" - take it as it is, and make the best of it. You can't "ask your money back" for free software. You can't tell unpaid volunteers, as the TCT is, how they better run the shop. - And re backwards compatibility: a little more than a year ago, I had to modify a script distributed as example (Euro converter) to run under an early 8.0 where even the :: syntax for globals was unknown. It took me just a few lines, and made me appreciate the overall stability of Tcl over years, which is great for an inhomogenous environment. Thanks to the TCT for their involvement, thanks to AS for providing ActiveTcl! Changes to the language can be a good thing, but even if Tcl were frozen now forever, I think I could still live with it for a long time, and discover new possibilities...
FW: I'm clearly pro-Tcl, I'm here after all ;) I love all the progress the core team has made. I didn't tell them how to run the shop, and even suggested that they're running it in the best way possible considering realities. I just speculated on what exactly causes the percieved shortcomings that causes complaints such as PWQ's, and invited commentary. I don't see why that requires a refution.
ulis, 2004-1-01-31. All the days I code I thank J. Ousterhout, the TCT and the Tclers. But I complain. Because if I think Tcl the best, I want it better. I've a gripe about some weirdness of Tcl: namespaces/environments, string/list/script Hell, expressions... But I can do a larger list of the jewels of Tcl: list handling, control constructs, input/output, interpreters(!)...
For the evolution of Tcl I find it substancial but opaque. For me it lacks bright guidelines. If I understand well, the evolution of Tcl follows the availability of code from the Tclers. So, yes I think that the role of the TCT is to be revisited: to decide of the future of Tcl, to define the goals of Tcl, the parts that need to evolve and the overall taste of Tcl, to prepare the evolutions decided and to call for design and coding. All that with the help and the approbation of the Tclers.