I agree with you Marcus, I think the driver should be the future, not the past, and more OO is definitely better. It is clear now that hardware is not the problem but the cost of maintaining software...
On Tue, Jun 30, 2009 at 6:54 AM, Marcus Denker <[email protected]> wrote: > > On 30.06.2009, at 11:44, Douglas Brebner wrote: > > > Marcus Denker wrote: > >> I personally think that with today's resources (my laptop has 4GB of > >> Ram, not 256Kb), we should rethink some of the design-desicions taken > >> 30 years ago. But many people are violently against this, fighting a > >> battle by citing "embedded systems". If one manages to convince them > >> that "embedded" these days does not equal "small", they mumble about > >> "smart dust" and obscure things just to be able to fight for hacks > >> not needed these days... > >> > >> Exploring new ways with the resources we have today does not mean > >> that everything needs to live in the image. It means that one can > >> affort to invest resources into very general, reusable solution to > >> problems like this. > > > > Didn't Tim change CompiledMethods so they referred to their source > > using > > a pointer so the source could be stored anywhere? > > > > Yes, Tim did some changes (in 1998) to make compiledMethods normal > objects > that have a ByteArray for the bytecode and a normal instvar for the > pointer to > the source. IMHO the way to go, but it was never added to squeak... > mostly because > people feared the overhead (there are 40.000 methods, so adding > another 40.000 is > indeed noticable, as we have seen in 3.9 with the MethodProperties...). > > I personally like this change, as it makes the implementation higher- > level and more > OO, which I think is a good thing. I personally think that "more OO" > is better than > "more compact", considering that a laptop these days has 4GB (this is > GIGABYTES) of RAM. > I always wonder how Smaltalk would look like if it was disgned with > the same philosophy > in 1976 that people apply today. Using the "but it costs memory" > philosphy that everyone > favors today, Smalltalk would never have been done in 1976 at all. > > There is another patch floating around that allows larger sources/ > changes without > changing the mechanism too much. > > >> One interesting aspect of the source/changes "outside the image" is > >> that this problem of data that is not used often and thus can live on > >> disk vs. memory is a general one. Hacking it into the system just for > >> the sources is just that: a hack. Providing a general, scalable way > >> to let objects live on disk that are not needed is much better, as > >> everyone can than use it. The system can use it for other resources > >> (fonts, images...). Programmers can use it to keep their domain data > >> on disk automatically. > > > > > > You mean something like LOOM? I would love to have that :) > > > Yes! :-) > > Marcus > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
