Marcus Denker 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 so wish that had made it in. > 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. Yes, it feels like an optimisation that simply isn't necessary any more. Worse, it makes it hard for tools to work on them. I can imagine quite a few tools that could be made with Tim style CompiledMethods. > 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. Smalltalk (and Lisp too) have always looked to me like they were designed for future hardware rather than whatever was contemporary. Didn't Alan say something about that? The mind boggles at what a Smalltalk properly designed today would look like. Though I do believe it would feel similar to todays since the basic ideas of message passing and a live systems containing the tools would probably remain though on a much larger scale with multiple images working together. Personally, I feel that people are looking too hard at the artefacts like the image, the class structure and forgetting *why* they were built the way they were. >>> 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! :-) I'd also like to be able to store on remote images or even internet sites. Something like Craigs Spoon perhaps :) _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
