MC in basic

Michael Latta lattam at mac.com
Mon Dec 13 23:35:14 UTC 2004


The new compiler sounds like a step forward by many measures.  The 
performance issue needs to be quantified more.  When you say it is 
slower, is it 5% slower? That would be tolerable.  If it is 20% slower 
it might not be tolerable.  If it breaks eToys, I would think you will 
need to get an estimate from them for what is required to deal with 
this.

Your situation sounds much like mine at my day job.  There is a large 
code-base, and you would like to improve the core.  Some people (we 
have one) only care about end-user features, while at the same time 
they complain about aspects of the core (like performance).  When 
making changes to such a large code base, without good regression 
tests, there is always the risk of impact.  Getting the buy-in of the 
stake holders to a change can take time and effort.  Sometimes they 
never understand how your work will benefit their concerns.  If you 
have done good work in the past (as you have) you can to a degree ask 
for trust.  But, you still need to be careful about the impact of your 
work on others.

In your defense I would say that any time a regression happens in code 
depending on your code, and the breakage is not detected before 
release, it is partly the fault of the dependent code maintainer.  
Without an active maintainer code calcifies and dies.  I hope the 
Squeak community does not choose to hold unmaintained code inviolate.  
This will kill Squeak faster than anything.  I do not know the details 
of the issue with Wonderland, but it sounds like there is no maintainer 
keeping it current, and as such it should not remain on the list of 
supported packages.  If there is a maintainer, then they need to be 
involved in the release process for each release.

The more time I spend in this industry the more respect I have for the 
need for testing, and QA activities.  Without a QA process prior to a 
release, you can not achieve a stable product.  And, from my experience 
the  unit testing like SUnit or JUnit provide is only about 10% of the 
effort.  It is System level testing at the UI level that is most 
critical.  Having automated API testing helps reduce the risk, but 
without full UI level testing, you are still at risk.

Michael




On Dec 13, 2004, at 2:49 PM, stéphane ducasse wrote:

>
>> Pardon my ignorance.  Is the "new" compiler a better Smalltalk to 
>> bytecode compiler, or a bytecode to binary compiler?  It is not clear 
>> from earlier posts I have access to.
>
> The new compiler is just a better text to byte-code compiler. Sorry no 
> JIT :(.
>
> The new compiler is slower than the old one:) BUT make the possibility 
> of building new things (MOP, byte code to byte code translation,  AST 
> transformation) much much much easier.  It is also really cool to read 
> and understand. :) It uses the
> RB AST, is based on SmaCC so you can get a good Smalltalk syntax.
>
> For example, we can expect to have a really cool late binding method 
> compilation (which would allow us to have state extension adding 
> instance variable to a class and not having to recompile everything 
> just right now, which is a really cool
> feature that etoy project manager would dream to have (ok they hard 
> time but build a system that pays attention to that))
> but with the new compiler implementing such a kind of schema is easy.
>
> Another example is that this compiler will ease the creation of real 
> mop for Smalltalk may be new AOP frameworks, all kinds of analysis 
> tool or trick based on byte-code rewriting. So it will enable creation 
> of new assets that are right now not
> really possible to dream about.
>
> After for people that really want to change the language (not me) we 
> can imagine that it is trivial to introduce
> annotation as in tweak for example without having to DUPLICATE and 
> PATCH the compiler :))))))
> Yes we can do it in another way. :)
>
> So you see we want to enable creativity with this new compiler (thanks 
> to anthony)
>
> Stef
>
>




More information about the Squeak-dev mailing list