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
|