On 11 May 2015 at 23:22, Alain Rastoul <[email protected]> wrote:
> 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 > > Don't think i am overreacting on Eliot's overreacting whatever.. We're a good friends, and pike fight on mailing list is not gonna change that. I just stating my POV, he stating own.. and that's how i see it, if you remove the giggles :). > 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. > > So, why complaining? Why not just do it. Or do you think i will scream 'over my dead body' or what? If you know how to make it better, do it. I popped-out here mainly to explain the motivation of changes we did,and to point out on the problems we had in the past and shared some insights how i would deal with it. > 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. > > One thing at a time. I don't think it is too hard to do, or make things overly complex. What is true,is that we got little or no incentive/resources among people, to do that. > :) > > -- > Regards, > > Alain > > > -- Best regards, Igor Stasenko.
