I am trying to use Squeak in a new project. I really want to use Squeak, and keep running into questions about the quality of the Squeak image, and would like some community comment on the following observations.
1) The VM seems quite solid and has decent performance. This is not the current concern. 2) The implementation of Balloon is only partially complete. The handling of text and transforms is not done. 3) The old ST80 image had a lot of design elegance in the classes, while too much of the Squeak image I am running into seems less organized. 4) Where in the ST80 image there was a hierarchy of objects ending in Paragraph that deal with displaying, in Morphic I find NewParagraph that has no superclass other than Object. This in and of itself is not a problem, but that asParagraph returns the old one, and it can not be directly displayed on a Canvas is an issue. It looks almost like Morphic was really ported from Self and was not tied into the Smalltalk class library more than was minimally necessary.
What I guess I am questioning is whether the image has enough integrity / quality of design to use in a production project. If there are a lot of unfinished stuff in the image, then our maintenance effort grows with the amount of the existing code we try to use. Nothing is without bugs, but part of what I associate with "Smalltalk" is more attention to design elegance. If I had plenty of time I might be tempted to take it down to the base image (minimal computing model) and build it up with a clean OpenGL based UI. But, that would be way too much effort for the advantages Smalltalk offers. I do not mind fixing bugs, but the regularity of lost time on them is getting old, and it is very difficult to know what the proper behavior is in too many cases.
Michael
Michael Latta lattam@mac.com wrote:
What I guess I am questioning is whether the image has enough integrity / quality of design to use in a production project. If there are a lot of unfinished stuff in the image, then our maintenance effort grows with the amount of the existing code we try to use.
The crushing argument that Squeak has enough XYZ to use for production projects, is that people are successfully using Squeak in production projects. Given this reality, there must be *some* hole in any argument along the lines of "Squeak does XYZ and thus can't be used in production". It's being used in production. Notable examples are SqueakSource and Swiki. Swiki alone has 256,000 google hits.
So how can this be, given your concerns about code quality? My answer: because this code you are grousing about, actually works. You have been complaining about Balloon and getting it wrong. Now you are saying maybe Balloon works, but its design is bad. Consider this: serious engineers don't rewrite everything from scratch whenever they change a design. Serious engineers have to allocate their resources carefully, and often it is a flat out mistake to spend time prettying up the code. If Morphic text processing reuses some of the text processing code from MVC, then so what? Isn't that good engineering?
If you want perfect pristine code, then there are plenty of toy languages around you could play with, where people rewrite everything from scratch all the time. If you want something that is useful and works, Squeak will be here waiting for you.
So there.
Lex
I think there is a big difference in perspective between how you see the world and myself.
1) If a piece of code does what it advertises to do, great. If it advertises an API and only implements 2/3 of that API, that is a problem. 2) Yes you can produce a working system by tip toeing around the unfinished/broken/inelegant parts of any system. If there was documentation or even comments that would be much easier. 3) Citing applications that serve the Squeak community as evidence of Squeak's production quality is not sufficient if your target is end-users that do not care about Squeak and only care about getting their work done. There may be uses of swiki that fit this example, but I suspect that swiki uses a small percentage of the code in the full image.
Your last line is only true if what I want to do is what others have wanted Squeak to do, and have invested the effort in fixing/finishing. I would like to use Squeak, but that is difficult given the breakages of pretty basic functions I have been encountering. Balloon is advertised as a graphics model supporting scaling and transformation, but in fact only bezier curves support these functions. Ovals and text do not support these features. The 3.8 release is advertised as supporting multi-lingual features, but the code is completely uncommented, and I was unable to find external documentation, or get a simple answer from the list on the level of support.
I compare this with other open source projects that have regular build schedules, code documentation and comments, and bug tracking that is clearly available from their website and that provides status notification on resolution to the submitter. There are a lot of assumptions built into the Squeak community about how to run a project that I find difficult to bet my living on. I much prefer Smalltalk and the ability to persist (in the image) both the data and the execution artifacts. Once I really give up on using Squeak I will stop bothering you with my "complaining", but given the number of threads on this type of subject, I very much doubt that I am alone in this perception.
Michael
On Jan 30, 2005, at 11:08 AM, Lex Spoon wrote:
Michael Latta lattam@mac.com wrote:
What I guess I am questioning is whether the image has enough integrity / quality of design to use in a production project. If there are a lot of unfinished stuff in the image, then our maintenance effort grows with the amount of the existing code we try to use.
The crushing argument that Squeak has enough XYZ to use for production projects, is that people are successfully using Squeak in production projects. Given this reality, there must be *some* hole in any argument along the lines of "Squeak does XYZ and thus can't be used in production". It's being used in production. Notable examples are SqueakSource and Swiki. Swiki alone has 256,000 google hits.
So how can this be, given your concerns about code quality? My answer: because this code you are grousing about, actually works. You have been complaining about Balloon and getting it wrong. Now you are saying maybe Balloon works, but its design is bad. Consider this: serious engineers don't rewrite everything from scratch whenever they change a design. Serious engineers have to allocate their resources carefully, and often it is a flat out mistake to spend time prettying up the code. If Morphic text processing reuses some of the text processing code from MVC, then so what? Isn't that good engineering?
If you want perfect pristine code, then there are plenty of toy languages around you could play with, where people rewrite everything from scratch all the time. If you want something that is useful and works, Squeak will be here waiting for you.
So there.
Lex
squeak-dev@lists.squeakfoundation.org