[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.
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 send some of his valuable time onto this issue and came up with the post as references above.

Rather than take sides and debate which option is 'better' and use majority rules. 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 payes 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 antagonise those referenced.

'''We 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 a 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 furhter 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 everytime 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.

A long intro but necessary. So back to the title, If I were to complain about the TCT I would write thusly:

   1. The TCT should stop coding and become a change management team.
   1. The TCT should get of their collective arses and action all outstanding TIPS. If the proposers have not got there stuff together then reject the TIP. No one forced them to become members, step up to the responsibility.
   1. the TCT should modify their terms to set responce times  to respond to TIPS.

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 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 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.''

----