Le 11/05/2015 22:27, Igor Stasenko a écrit :
On 10 May 2015 at 10:23, stepharo <[email protected]> wrote:
i think there is a fundamental difference between 'stream' and 'update on
the screen' . Choose one and stick to it.
We shall separate such responsibilities and NEVER ever merge them again ,
even if it was cool, nice, soft and puffy in the past.
Yes, sure, we can then build the facade on top of that providing similar
behavior of what was in the past..
But if not, then it will always be something that will forever be causing
problem, since it is conceptually wrong and looks like attempt to cross
breed two different species.
<OT>
I have no particular opinions about Transcsript, but I would like to say
that I am very happy to have Igor back in the Squeak/Pharo/Cuis/Smalltalk
discussions. I may not agree with everything, but I really appreciate his
thoughtful perspective. There are a few people whose posts I will always
read, and Igor is one of them.
</OT>
Thanks Dave. I share the same feelings.
Dave
Guys, that was completely unnecessary. :)
My problem with transcript was always a multiple layers penetration to get
things done.
And Cuis version is good demonstration to that (sorry, Juan):
- who the heck needs APIs, protocols and overall design rules, if we can
just cut through things to get to the functionality we need and put things
one the screen right away without dabbling with Morphic/whatever?
Because why not? Half of Squeak (and subsequently, Pharo) code is written
that way anyways.. Following such development style, then i should rewrite
everything in assembler, make it work blazingly fast, and who are you to
criticize thing that works well and outperforms everything that ever
written before?
Right?
What is broken, needs to be fixed. Who opposed that?
I just have different than Eliot view on what is broken and consequently,
what is needed to fix it.
Note, that i *want* the very same behavior at the end. I want transcript
that can handle immediate updates on the screen.
But i want it to be async, and do not impact the performance of the system,
because it is awful, when console output takes 99% of your computation
resources.
Sure, it may be cool for VM devs, but have you thought about rest of use
cases?
Because there's plenty of them, and not all of them require immediate
feedback on the screen.
My 'doctrine' is to have a versatile tool that suits well for many use
cases, not just one.
P.S. Please note, i said nothing new about Transcript that i wasn't saying
couple years ago to Stef and to other people i was communicating with..
Yeah time runs fast, and not everything you want can be done, but it
doesn't means that i changed my mind.
I wonder, how other people feel, when they stating obvious (to their
thinking), and others look at them as a doctrinal dumbass. That's how i
feel. :)
Igor, of course nobody never saw you as a 'doctrinal dumbass'
you are 100% correct on all you said, Elliot is just pragmatic here and
does want to go into
other considerations that would break the workflow he likes and
introduce complexity where there is largely enough,
may be that made him overreacting a little...
this can happen to anybody
If he needs some tools or has some specific requirements that are
doable, why not
trying to give him and Clement even if they are not the bests ?
I see the CuisTranscript as a pragmatic solution that does not change
too much things since vm developement is complex and needs a proven
basis, plus as explained by Clement too sophisticated tools cannot be
used sometimes.
That said, about Transcript being asynchronous, I fully agree that it
would be be better, but I guess it would also imply some serious changes
in UI process and the World>>doOnecycle concept (that would be good
anyway, it is weird).
I also think my suggestion of asynchronous do-it has some other
interests (exploration of futures in asynchronous processing for
example), but I am not interested in fighting on that, it's overkill
here with too much complexity introduced.
:)
--
Regards,
Alain
