Impressive , Cuis has 13 times less classes than Pharo. Maybe I should give it a closer look afterall.
Pity that does not translate well in hard disk space. Pharo 6 is 100mbs Cuis is just 70mbs. The VM alone is 50 mbs. On Wed, Nov 2, 2016 at 1:38 AM p...@highoctane.be <p...@highoctane.be> wrote: > Setting the Playground contents, yeah, I see what you mean. The old > Workspace worked better there. > > I disagree with your view on the modularity. > > And Cuis is nice indeed (and the UI is fast) - > https://github.com/Cuis-Smalltalk-Learning/Learning-Cuis shows the number > of classes. Definitely less than Pharo. > > But it is not boostrap anything, sorry. It is the same code that has > dependencies all over. Ok it is kind of a minimal image but not something > one can call bootstrap. > > Check the original intent: > http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/2016-January/118051.html > > So, starting from an empty object memory. That is important to have. So > that we can rebuild in other ways. > > Phil > > > > On Tue, Nov 1, 2016 at 9:21 PM, Dimitris Chloupis <kilon.al...@gmail.com> > wrote: > > I was trying just yesterday to do something super simple, change the > contents of Playground via code. I used the inspector to navigate , I ended > up running around and accomplish zero. > > Bootstraping will never make Pharo easy. Bootstraping is for making it > smaller and more modular. Completely different thing. > > Pharo is super hard to hack because many of its APIs even for new tools > like GTPlayground are huge pile of mess. The spaggetification of the Pharo > image is beyond repair and needs a complete rewrite. But that is not going > to happen any time this decade or the next. So for now we will have to > compromise with the idea that Pharo code is hard and it will keep getting > harder the more features are added even if the packages are reduced. > > On the other hand I am ok with hard code, as long as it gets the job done. > > Plus there was always a bootstraped "Pharo", Cuis, Wanna see how minimal > and clean code looks like , take a deep look in Cuis, its a beauty. But > Cuis is nowhere near as popular as Pharo. People prefer features over > simplicity and , unfortunately , you cannot have both. I am willing to bet > that we will still choose big Pharos image even when bootstrap becomes a > reality. Its as if there is a lot of room to move here, most of the > libraries inside Pharo are crucial to the system, others are very useful > for user interaction. > > Unless of course we follow the example of Cuis and decided to reduce the > features of Pharo, but I suspect that wont have many supporters. > > So yes its nice to have this extra options, no it wont make Pharo code > much simpler. > > On Tue, Nov 1, 2016 at 9:39 PM p...@highoctane.be <p...@highoctane.be> > wrote: > > Bootstrapping is needed to escape the big ball of mud that the current > image is. > It is already much much much better than Pharo 1x. > Having a smaller core can iron out a lot of issues and make it super > stable. > And decouple the various parts. That is no small feat indeed. > And frankly it is super hard to understand how the whole thing actually > works internally with all the stuff we have inside. > I see bootstrapping as being able to extract the nuclear core from the > current vehicle and be able to inject it into new forms. > > Phil > > > On Tuesday, 1 November 2016, Dimitris Chloupis <kilon.al...@gmail.com> > wrote: > > We already have a ton of ready made image in CI that pharolauncher has > access to and it is very easy to build your own. I build my own images > regularly with a makefile and startup script. You can do a lot of neat > tricks with those two combinations. > > Because my image grows quite large lately I was thinking maybe make an > image builder with pharo. Nothing fancy just a basic GUI that will ask me > questions what I want to build and I can tick which image I want inside and > let it run in the background. Essentially replacing both my makefile and my > startup script. So far though I cannot say I really need it > > Why a test would corrupt the image, that makes no sense. I am using Pharo > 5 years now and I did not have a single corrupted image, ever. > > Also about the claim that Pharo is "the best TDD" first time I heard that. > What makes a system best for TDD ? its not as if TDD is anything > sophisticated or even something new. The only difference is that lately it > went from being a library to being a religion. > > You may compare Ruby all you want with Pharo but then that gives me > motivation to compare Ruby with Python . Ruby basically has Ruby on Rails > and then.... nothing. Great language , lousy library system. > > Bootstrapping is more than welcomed but I am sorry to say that , its not > that important. > > You wanna proof , take a look at Python, huge library and coders love it. > Actually the huge size of its library was always its best selling point. > Python is pretty much everywhere nowdays and there is nothing stopping it. > Not that is a surprise Python always prioritised minimalism and ease of use > over amount of features , something desperately needed in todays incredible > complex software demands. > > >
