Approach to discussions
Posted: Wed Apr 12, 2017 8:47 pm
There has been some intense discussion on various topics recently, a little while ago, and also a long time ago.
Discussion is good; even intense discussion is good as it shows active interest and promotes progress. But we have to be very careful not to be disrespectful. We are a very small group, with different backgrounds, skills, ages, temperaments, cultural backgrounds, and many are using a foreign language. So please make the effort to accommodate different peoples approaches, and be tolerant of people expressing different opinions with apparently more force than necessary. It may well be unintended.
As Chairman I do not want to preside over a breakup of the group; we can't afford to loose a single member.
I shall give one example. I rather forceably disagreed with a suggestion of Doug about documenting IEEE maths functions, as I thought he was not clear enough about the difference between the two ideas "Bit patterns" & "Real numbers". In retrospect I should have been more careful as my understanding was also pretty far from clear. (The standard carefully distinguishes the four ideas: "Extended real numbers", "Floating point data", "Floating point representations", & "Bit strings". The fifth idea "Real numbers" also needs to be acknowledged as it is the only one of these ideas one can assume the reader is familiar with - albeit informally for people without advanced mathematical training.)
The point is we need to be able to discuss, and hold, differences of opinion without giving or taking offence, even if this is not always easy.
Ultimately I want to discuss the two current topics Consoles & Coroutines, but on the way I shall discuss Xmlcore & Pac, as maybe we can learn something from them.
Firstly I think they are both good subsystems; they may both be great subsystems but I am not expert enough to really say.
Xmlcore (which includes an XML file parser) is very useful when you need it, but not every one does. So having it available on CPC is, I think, a good option. There is no need to make an equivalent subsystem part of the standard distribution.
Pac comes into a different category; most people at some time need (or want) to use Pac, or somthing equivalent such as StdCoder, and so it really wants to be part of the standard distribution. (This was even more important years ago when many people only had access to slow or expensive internet.)
Pac is better than StdCoder because:
- It compresses more effectively
- It has more user options / tools
- It has an API allowing its compression engine to be used by other applications.
StdCoder is better than Pac because:
- It predates it, so is the established choice
- It is simpler to use (less options!)
- As it is part of the standard distribution one can be confident that other people have easy access to it.
But, in an ideal world, there would only be one choice comprising the best aspects of both.
My point?
Where are we going with Coroutines? Should they be a minority external add-on, like Xmlcore?, or a mainstream standard facility like StdCoder?, or are we sleep-walking into the Pac / StdCoder situation with competing options that serve to confuse the average user, even acknowledging that each option has its strong points?
I think we want to discuss / reach consensus at this policy level separate from discussing the implementation specific details. I propose summarising the policy arguments or decisions in this thread, while keeping the implementation detailed discussions in the existing threads.
Other policy level topics / decisions seem to be:
Coroutines: - Where do we stand on the cross-platform support issue - keeping platform specific code localised? Cross-platform, to me, includes different OS's, different assemblers (eg System.Math), and even different compilers on the same OS / hardware (GPCP).
Console: - Do we need / want two different solutions targetted at different uses (low-level logging, Console apps)?
Console: - Should these (1 or 2) solutions be part of the standard distribution, or external (on CPC)?
Console: - Where do we stand on the cross-platform support issue - as above?
By keeping these policy discussions separate from the implementation discussions it will be much easier for those of us who don't have the time, skill, or motivation to follow the detail to make positive contributions (like voting sensibly!). Also, I suspect, if we can agree the policy direction early it may make completing the implementation more efficient.
Forgive my long talk; I am only trying to inject a new direction into discussions that currently seem to be struggling to make efficient progress, and which have become too complex for most of us to follow.
Discussion is good; even intense discussion is good as it shows active interest and promotes progress. But we have to be very careful not to be disrespectful. We are a very small group, with different backgrounds, skills, ages, temperaments, cultural backgrounds, and many are using a foreign language. So please make the effort to accommodate different peoples approaches, and be tolerant of people expressing different opinions with apparently more force than necessary. It may well be unintended.
As Chairman I do not want to preside over a breakup of the group; we can't afford to loose a single member.
I shall give one example. I rather forceably disagreed with a suggestion of Doug about documenting IEEE maths functions, as I thought he was not clear enough about the difference between the two ideas "Bit patterns" & "Real numbers". In retrospect I should have been more careful as my understanding was also pretty far from clear. (The standard carefully distinguishes the four ideas: "Extended real numbers", "Floating point data", "Floating point representations", & "Bit strings". The fifth idea "Real numbers" also needs to be acknowledged as it is the only one of these ideas one can assume the reader is familiar with - albeit informally for people without advanced mathematical training.)
The point is we need to be able to discuss, and hold, differences of opinion without giving or taking offence, even if this is not always easy.
Ultimately I want to discuss the two current topics Consoles & Coroutines, but on the way I shall discuss Xmlcore & Pac, as maybe we can learn something from them.
Firstly I think they are both good subsystems; they may both be great subsystems but I am not expert enough to really say.
Xmlcore (which includes an XML file parser) is very useful when you need it, but not every one does. So having it available on CPC is, I think, a good option. There is no need to make an equivalent subsystem part of the standard distribution.
Pac comes into a different category; most people at some time need (or want) to use Pac, or somthing equivalent such as StdCoder, and so it really wants to be part of the standard distribution. (This was even more important years ago when many people only had access to slow or expensive internet.)
Pac is better than StdCoder because:
- It compresses more effectively
- It has more user options / tools
- It has an API allowing its compression engine to be used by other applications.
StdCoder is better than Pac because:
- It predates it, so is the established choice
- It is simpler to use (less options!)
- As it is part of the standard distribution one can be confident that other people have easy access to it.
But, in an ideal world, there would only be one choice comprising the best aspects of both.
My point?
Where are we going with Coroutines? Should they be a minority external add-on, like Xmlcore?, or a mainstream standard facility like StdCoder?, or are we sleep-walking into the Pac / StdCoder situation with competing options that serve to confuse the average user, even acknowledging that each option has its strong points?
I think we want to discuss / reach consensus at this policy level separate from discussing the implementation specific details. I propose summarising the policy arguments or decisions in this thread, while keeping the implementation detailed discussions in the existing threads.
Other policy level topics / decisions seem to be:
Coroutines: - Where do we stand on the cross-platform support issue - keeping platform specific code localised? Cross-platform, to me, includes different OS's, different assemblers (eg System.Math), and even different compilers on the same OS / hardware (GPCP).
Console: - Do we need / want two different solutions targetted at different uses (low-level logging, Console apps)?
Console: - Should these (1 or 2) solutions be part of the standard distribution, or external (on CPC)?
Console: - Where do we stand on the cross-platform support issue - as above?
By keeping these policy discussions separate from the implementation discussions it will be much easier for those of us who don't have the time, skill, or motivation to follow the detail to make positive contributions (like voting sensibly!). Also, I suspect, if we can agree the policy direction early it may make completing the implementation more efficient.
Forgive my long talk; I am only trying to inject a new direction into discussions that currently seem to be struggling to make efficient progress, and which have become too complex for most of us to follow.