Reading this dialog feels like getting the blindmen’s
view of an elephant.

Micheal I’ve been using balloon stuff in the form of
bitmapfill and have not run into any problems not
easily remedied.

You found some badly maintained classes. If they are
the ones I think they must be they are the only ones
using the flawed MatrixTransformationMorph.  See my
note further down.

Squeak is a strange animal. Maybe other smalltalks are
too, I’ve only played with squeak and I’m in most
departments still a newbie.

My take is that it is a living language.  It grows as
its users need it to grow and the words bump into
themselves. There are no pretensions of Squeak being a
production system.  For reasons of tradition and
politeness vestigial pieces remain around. Dead
language that doesn’t announce that its dead.  Like
the parts of our DNA that don’t do anything useful for
us.

My curiosity is what is it you are trying to
implement? 
Can you tell a paragraph story of what your thing
would do after you implemented it?
What made you examine squeak as the implementation
smalltalk?

You will have to judge what is best to implement your
project in. If its well defined you could choose from
a lot of well defined languages.
If you are still playing with what it might be. If you
are looking for useful ideas. If you are willing to
learn from your mistakes.Well squeaks not production
but its a pretty good scratch pad.


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

Actual it doesn’t. Michael wasn’t very specific but
the two classes he talks about are badly under
maintained.
They are the ones that use MatrixTransformationMarph
which probably never worked correctly and certainly
not correctly with the rest of squeak. (see mantis
#0000857). 

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


		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail