Approach to discussions
Approach to discussions
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.
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: Approach to discussions
Thank you Robert.
I agree with your separation of interests into policy and implementation.
-Doug
I agree with your separation of interests into policy and implementation.
-Doug
-
- Posts: 204
- Joined: Wed Sep 18, 2013 10:06 pm
- Contact:
Re: Approach to discussions
Very good points Robert. I have a couple of observations:
1. When trying to decide whether or not an agreed solution should be part of the standard distribution, or external (on CPC) I would ask the following questions:
If the answer to either of those questions is 'No' then it should be implemented as part of the standard distribution unless there is a compelling reason to do otherwise.
2. Many recent proposed solutions have been just been presented as solutions. I am unable to decide whether or not to support a particular solution unless the problem that it is intended to solve is clearly explained. If the requirements are clearly spelt out and agreed upon before solutions are presented it is much easier to determine whether one solution is preferable to another.
1. When trying to decide whether or not an agreed solution should be part of the standard distribution, or external (on CPC) I would ask the following questions:
- Can it be implemented without requiring any modification to the standard distribution?
- Could it have been implemented in the past when the source code of BlackBox was not available?
If the answer to either of those questions is 'No' then it should be implemented as part of the standard distribution unless there is a compelling reason to do otherwise.
2. Many recent proposed solutions have been just been presented as solutions. I am unable to decide whether or not to support a particular solution unless the problem that it is intended to solve is clearly explained. If the requirements are clearly spelt out and agreed upon before solutions are presented it is much easier to determine whether one solution is preferable to another.
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Approach to discussions
I agree that there should be some general features policy. We should be careful for not making BlackBox full of "bells and whistles".
I want to add two more case to points to those which were mentioned by Chris.
1. The Center should provide some standards. The example is Dialog.OpenExternal. It was possible to use separate extensions, however there was the mess with links in third-party subsystems. Somebody using i21Sys, another InfoCmds etc.
2. The Center should adapt the BlackBox Component Builder to modern challenges (this is written in our wiki).
There was no multiple stacks support in Kernel. With this feature we will have several coroutines realizations as extension packs. This will give some experience to introduce the basic BlackBox coroutines later. I am unhappy not only about WinApi in Kernel, but also in strange Tasks pattern without balancer. This is much more complex than just coroutines or Services.Actions. I am not sure, that this Tasks pattern should be basic feature of BlackBox at all. Also there is one more comment of Dmitry that should not be ignored, that call of Transfer should be possible only from the main coroutine. Josef ignores this comment. I forced the discussion of this topic several times. It is hard to "be the good citizens" with that situation.
IMHO, Console module for read/write command line will give some standard for console apps interface. It can be distributed as an "official" extension approved by the Center. And we are returning to the question about Center Extensions Store.
The tool for low-level debugging is very optional. IMHO we should not include it in the basic distribution. There is the wiki page and that is enough for people who wants to debug Kernel.
I want to add two more case to points to those which were mentioned by Chris.
1. The Center should provide some standards. The example is Dialog.OpenExternal. It was possible to use separate extensions, however there was the mess with links in third-party subsystems. Somebody using i21Sys, another InfoCmds etc.
2. The Center should adapt the BlackBox Component Builder to modern challenges (this is written in our wiki).
There was no multiple stacks support in Kernel. With this feature we will have several coroutines realizations as extension packs. This will give some experience to introduce the basic BlackBox coroutines later. I am unhappy not only about WinApi in Kernel, but also in strange Tasks pattern without balancer. This is much more complex than just coroutines or Services.Actions. I am not sure, that this Tasks pattern should be basic feature of BlackBox at all. Also there is one more comment of Dmitry that should not be ignored, that call of Transfer should be possible only from the main coroutine. Josef ignores this comment. I forced the discussion of this topic several times. It is hard to "be the good citizens" with that situation.
IMHO, Console module for read/write command line will give some standard for console apps interface. It can be distributed as an "official" extension approved by the Center. And we are returning to the question about Center Extensions Store.
The tool for low-level debugging is very optional. IMHO we should not include it in the basic distribution. There is the wiki page and that is enough for people who wants to debug Kernel.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Approach to discussions
I have proposed to add Coroutines to the standard distribution because it is not possible to
add them in an external package.
The Co_ package didn't work reliably and there was not even a warning included.
In addition it has a very special idea of what a coroutine is and it is not exactly what
someone familiar with the concept of a coroutine would expect.
So I tried to design a more 'mainstream' version and I thought the result is not too bad
and therefore I published it.
Now regarding the Transfer-main limitation.
Good citizens, in my opinion, know what they are talking about,
in particular when insisting on a particular suggestion.
I have explained why this Transfer-main limitation is a bad idea but it seems to be ignored.
We had similar cases of this kind, for example issue-#126. It is very instructive to
go back to this issue and to analyze the contributions.
Usually it turns out that there are fundamental misunderstandings or, in other words,
lack of knowledge but the amount of work and confusion it creates is enormous.
- Josef
add them in an external package.
The Co_ package didn't work reliably and there was not even a warning included.
In addition it has a very special idea of what a coroutine is and it is not exactly what
someone familiar with the concept of a coroutine would expect.
So I tried to design a more 'mainstream' version and I thought the result is not too bad
and therefore I published it.
Now regarding the Transfer-main limitation.
Good citizens, in my opinion, know what they are talking about,
in particular when insisting on a particular suggestion.
I have explained why this Transfer-main limitation is a bad idea but it seems to be ignored.
We had similar cases of this kind, for example issue-#126. It is very instructive to
go back to this issue and to analyze the contributions.
Usually it turns out that there are fundamental misunderstandings or, in other words,
lack of knowledge but the amount of work and confusion it creates is enormous.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Approach to discussions
You gave your explanation here: viewtopic.php?f=41&t=610&start=20#p5808Josef Templ wrote:Now regarding the Transfer-main limitation.
Good citizens, in my opinion, know what they are talking about,
in particular when insisting on a particular suggestion.
I have explained why this Transfer-main limitation is a bad idea but it seems to be ignored.
The problem that with such freedom that you want to give to developer you is allowing to develop software in GOTO way. That's the problem.
One of strong idea of Oberon is the limitations for software engineer to prevent stupid design errors (prevent shotting in a leg).
So the freedom is not always a good idea.
During this discussions you share some knowledge in the board which is a kind of developer documentation which is essential for the further BlackBox support and development. Thank the God that we have such qualified person like you in the Center team! Without this stupid questions and disputes there is no chance to have this kind of informationJosef Templ wrote:We had similar cases of this kind, for example issue-#126. It is very instructive to
go back to this issue and to analyze the contributions.
Usually it turns out that there are fundamental misunderstandings or, in other words,
lack of knowledge but the amount of work and confusion it creates is enormous.
![Smile :)](./images/smilies/icon_e_smile.gif)
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Approach to discussions
It is not a GOTO. Seems to be another misunderstanding.Ivan Denisov wrote: You gave your explanation here: viewtopic.php?f=41&t=610&start=20#p5808
The problem that with such freedom that you want to give to developer you is allowing to develop software in GOTO way. That's the problem.
One of strong idea of Oberon is the limitations for software engineer to prevent stupid design errors (prevent shutting in a leg).
So the freedom is not always good idea.
It is what it is, a coroutine transfer. It is more like a suspend/resume in multi-threading.
And it is needed for implementing any application specific patterns such a simulation framework.
Fact is that with coroutines you can avoid many GOTO like constructs.
GOTOs can be implemented in a language that does not support a GOTO statement
by transforming the program into a state machine (contained in a loop).
Switching the state corresponds to executing a GOTO then.
Coroutines avoid this transformation of a program into a state machine.
This is particularly useful for tasks like discrete event simulation. The behavior of a simulated object
is typically represented as a coroutine (please note the duality of state and behavior:
a simulated object has state+behavior. The combination of both aspects into one concept is the "Object").
Actually this is what coroutines (and objects) have been originally invented for.
In principle, it can also be done using a state machine, but then it is very
much like using a GOTO.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Approach to discussions
I see the misunderstanding. I am not saying it is GOTO. I am saying that it is like GOTO.Josef Templ wrote:It is not a GOTO. Seems to be another misunderstanding.
https://community.blackboxframework.org ... t=164#p947
Dmitry wrote:The problem is, that Co.Transfer(this.from) is used instead of Co.Yield statement. So FILO calling sequence not guaranteed.
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: Approach to discussions
Coroutines are a general purpose concept.
Like any general purpose concept it can be used to make programming mistakes.
A WHILE loop can create an endless loop.
A procedure call can create an infinite recursion.
A coroutine transfer can transfer to the wrong coroutine.
All these are simply programming mistakes.
Nobody would limit a WHILE or a procedure call nowadays
but in the past there have been discussions indeed. They are all over.
Transfer can be used for creating application specific patterns
as is the case for Iterator and Task.
For both, there is no need to use Transfer directly.
But assume you want to create a simulation framework by providing
coroutine subclasses useful for simulation purposes.
Those are supposed to use Transfer for implementing the application specific
behavior. Without that a coroutine is no longer a general purpose concept
and it is not possible to define any application specific pattern on top of
the basic coroutine concept.
- Josef
Like any general purpose concept it can be used to make programming mistakes.
A WHILE loop can create an endless loop.
A procedure call can create an infinite recursion.
A coroutine transfer can transfer to the wrong coroutine.
All these are simply programming mistakes.
Nobody would limit a WHILE or a procedure call nowadays
but in the past there have been discussions indeed. They are all over.
Transfer can be used for creating application specific patterns
as is the case for Iterator and Task.
For both, there is no need to use Transfer directly.
But assume you want to create a simulation framework by providing
coroutine subclasses useful for simulation purposes.
Those are supposed to use Transfer for implementing the application specific
behavior. Without that a coroutine is no longer a general purpose concept
and it is not possible to define any application specific pattern on top of
the basic coroutine concept.
- Josef
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: Approach to discussions
Ok, I got your point. So you want to give more freedom for developer so he/she can design some code that we even will not be able to understand
like the worst GOTO examples. Nevertheless we are again discussing some technical details.
Let's talk about general policy for features. I believe that we should avoid to add platform dependent code in the Kernel. In future it is better to remove all WinApi dependencies from Kernel at all. This is some strategy which will help to support cross-platform capabilities. I think that this should be included in features design policy.
![Smile :)](./images/smilies/icon_e_smile.gif)
Let's talk about general policy for features. I believe that we should avoid to add platform dependent code in the Kernel. In future it is better to remove all WinApi dependencies from Kernel at all. This is some strategy which will help to support cross-platform capabilities. I think that this should be included in features design policy.