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 at 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
>