btw... as someone pointed here, I need to clarify something I said: I didn't mentioned Eliot because I was talking about the plugins... When we talk about the VM itself, the number of people who are capable of work on it reduces from 10 to maybe 5 (Eliot and some others like Igor... but certainly not me :)
Disclaimer done... is so obvious for me that Eliot is "the master-guru" that I just forget to mention him (I'm really sorry for that). Esteban On Apr 17, 2013, at 6:30 PM, Esteban Lorenzano <esteba...@gmail.com> wrote: > you're right... I will cut&paste and write something extra next days :) > > On Apr 17, 2013, at 4:25 PM, p...@highoctane.be wrote: > >> Very interesting email, worth a post somewhere. >> >> >> 2013/4/17 Esteban Lorenzano <esteba...@gmail.com> >> Hi, >> >> On Apr 17, 2013, at 11:23 AM, kilon <theki...@yahoo.co.uk> wrote: >> >> > Anyway, my only objection is the fact that we will have twice the code to >> > maintain and more to worry about. >> >> let me explain this little thing a bit... >> >> Do you think that code doesn't need to be maintained and taken care how it >> is right now? >> >> I will draw you a picture of how it works this now >> >> /----------------------------------------------\ >> | "Pretended wonderland" (image) | >> =========================== >> | Lots of things: I/O, FFI, etc. | >> ----------------------------------------------- >> | Virtual Machine (Cog, Stack, Int) | >> \----------------------------------------------/ >> >> This is your world right now. You work on "pretended wonderland" side, >> assuming that everything below will work and hence you "don't need" to >> maintain what is below wonderland, isn't? >> >> Well, wrong. >> >> Everything need to be maintained. What you do not see too (you do not see >> it, but it is there, oh yes). >> The difference is: >> >> - in wonderland, everybody can try to fix things (even id they fail, it is >> there to play/change/adapt) >> - in levels below, there are just a few people on earth who actually can >> maintain that: Igor, myself and some others, but is for sure less than ten >> people. >> In fact, what happens now is that I have to maintain not two, but three >> different versions of the same thing (for each platform), in two different >> languages (C and Objective-C) and three different sets of libraries. And >> yes, I "personalize" and use the "I" instead "we" because most of the times >> is me, with some really valuable from Igor and Camillo (but well, they do >> Athens and a PhD respectively, so many times is just a one-man-work). >> >> So, what actually happens now is that problems stack waiting for a solution, >> a solution which btw will never be of total satisfaction of users. >> As an example, let's see the display plugin (which of course is not a plugin >> at all, if you remove that from vm, it stops to work). >> >> Display plugin is based in BitBlt, who creates/transforms bitmaps and >> renders them into screen. >> Forget about 2D vectorial graphics (or any thing that can bebefict of using >> of GPU). >> This technology is obsolete and retina displays on mac prove that: there is >> no way to do it work fine (that means: good rendering and good performance). >> >> So we need to change that. >> >> How to do it? There are two basic approaches possible: >> The traditional one says that some "gurus" should write a new plugin >> (ideally backward compatible with the previous one). Then you have an >> updated plugin (and probably a perfect one, if you don't want to maintain >> it), until next time technology changes and then the gurus can be summoned >> again to do their magic. >> As you can see, since our community of potential gurus is (with luck) ten >> persons in the world, that does not scales at all. >> >> Then it is our approach: move to the image all the things that can be moved. >> Then you will have this: >> >> /----------------------------------------------\ >> | "Pretended wonderland" | >> ----------------------------------------------- >> | Abstract system layer in image | >> | (that most of people will never | >> | see anyway) | >> =========================== >> | Virtual Machine (Cog, Stack, Int) | >> \----------------------------------------------/ >> >> With NativeBoost we can achieve same performance that we achieve using plain >> C. >> And we have an incredible huge extra bonus: it is there so everybody can try >> to modify/fix/update if needed, not just the gurus. >> And we also have much more advantages to show: this is moving also the low >> level programing to "pharo way", and as I showed in my silly videos, is >> bring the "immediate feedback" experience also to that level (something that >> you could never achieve with older way of thinking) >> And finally... been in image does not need that you will need to deal with >> that. How many of you know of the internals of Zinc/Zodiac or the Weak >> Registry? (just to put a couple of examples). Most of us just take it and >> use it. >> >> Our path is to bring to the whole community the power to change everything >> in your environment. To change it live, in the pharo way. >> And some times I feel that it is a power that the community is afraid to >> take :) >> >> lose your fear: having that power feels good :) >> >> And again: do you still think there is no need for maintain low level stuff? >> Think again. >> >> cheers, >> Esteban >> >> >> >
