Le 11/05/2015 22:27, Igor Stasenko a écrit :
On 10 May 2015 at 10:23, stepharo <stepharo@free.fr> 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