"Mark Mullin" mark@vibrant3d.com wrote: For the record, C++ iteration is what we use to deal with problems that really vex the computer but that the user could care less about. Smalltalk has a richer and more powerful set of iterators and collections than STL, but the costs of such a dynamic flexible solution are more than we can bear.
I really want to stress that it is not the architecture of Smalltalk container classes or iteration that is "more than [someone] can bear". The issues are - fixed program -vs- dynamically loading program - native code generation -vs- JIT -vs- byte codes - type system - "expanded" objects or not - inline code expansion - special treatment of "primitive" types -vs- everything's an object ...
Take Eiffel, compiled using SmallEiffel - compiles whole program in one go so has excellent knowledge of what is used, what is polymorphic, what isn't (which is most things, even though Eiffel has no monomorphic constructs as such) - generates native code (via C) - static type system with *simple* templates (unlike C++, Eiffel type- checking isn't a Turing-complete problem) - expanded classes and individual expanded objects are available - inlines like crazy - BUT is pure OO: everything's an object, even 77.
That compilation technology would allow collection classes, streams, and iterations with recognisably the Smalltalk architecture to work at C++ speeds or better.
The "assertion" technology (inherited class invariants, method preconditions, and method postconditions; loop variants and invariants; specific checks) helps to pinpoint errors quicker than you could with a debugger.
What Eiffel sacrifices is the DYNAMIC character of Smalltalk, and of course its IDE. (I haven't tried ISE's system and don't know how well "Melting Ice" works in practice.)
The beauty and power of Squeak is amazing; its fragility is scary. By this I mean the way things stop working between one release and the next, the number of projects out there that just don't load any more. On the one hand that kind of thing practically doesn't happen in Eiffel; on the other hand such projects could never have been written in Eiffel in the first place.
But let's NOT blame the collections/streams ARCHITECTURE for anything, OK?
"Richard A. O'Keefe" ok@atlas.otago.ac.nz writes:
The beauty and power of Squeak is amazing; its fragility is scary. By this I mean the way things stop working between one release and the next, the number of projects out there that just don't load any more.
Nicely put, I want to highlight this. It's an important insight for newcomers, whose first instinct is to load a bunch of projects off BSS and squeakland in order to see some interesting stuff.
When this works reliably squeak will start spreading more quickly, and be a more pleasant end-user tool.
On the one hand that kind of thing practically doesn't happen in Eiffel;
I'd really like to be able to sling around this phrase with "Squeak" on the end of it. Hmm, what else could we be doing to make better use of assertions/tests/peer-review-type safety nets ?
I was thinking about cost-effective ways to improve the project loading experience. One might be to do semi-automated distributed testing of project loading, something like this:
- gather image compatibility data for projects: every time a project is loaded from a super swiki, record the outcome and this image's version (its highest-numbered update from the main stream) on the server. Eg save a couple of fields on the project's swiki page:
successfullyLoadedWith: #(4599@1 4640@9 ...) failedToLoadWith: #(4640@1 4102@5 4664@3 ...)
The second number is a count. Reset these lists or the counts whenever the project changes.
- optionally, have one or more robots loading projects in various images to find the problems before we do. Something like mozilla's tinderbox.
- use this data in various clever ways. In particular when browsing projects for download indicate up front how likely they are to work in this image. Eg green = "many people have successfully loaded this project recently in an image resembling yours", red = the opposite, black = unknown status. For newbies eg in the squeakland image, list only projects known to be currently compatible with this image.
Comments ? I won't get further with this in the short term, if anyone feels so moved please jump right in.
-Simon
squeak-dev@lists.squeakfoundation.org