CL macros and such ... [Re: [Q] CCodeGenerator and inlining]]

Dwight Hughes dwighth at ipa.net
Sat Jan 22 00:54:12 UTC 2000


agree at carltonfields.com wrote:
> 
> > There _is_ a way to nail down a lot of Smalltalk and even do a lot of
> > static inlining at compilation time (though you would > normally only want
> > to do this for application delivery or embedded systems). > This is to use
> > a "closed world" model of compilation. Basically you make the > assumption
> > that all of the current code is final and the values of most of the
> > global, class, and pool variables will not change and start crunching.
> 
> I think the point made by others is that, in Smalltalk, this is almost
> never a reasonable assumption. Late binding is a fundamental feature
> of Smalltalk.

I did not claim it was a *good* idea, just that it _can_ be done. I have
little love for Smalltalk MT as a system (in spite of its interesting
capabilities) because I feel they compromised too much of the dynamic
nature of Smalltalk and discarded too many of its historical advantages
(like unequaled debuggability and an cleanly defined, understandable GUI
architecture) to attain their goals. No flame meant - just that I feel
it lost too much of what I consider to be the fundamental nature of
Smalltalk to be enjoyable for me to use. So yes, I quite understand.

> It is true that we can always change a language to be more like others,
> but then we should quite directly confront the question: what are the
> specific advantages; what are the specific costs?  Let's put those on
> the table and make a decision.  Smalltalk is not CL, neither are C++. 
> There are certainly advantages to each, but when developing language
> hybrids, we should make sure that what we are doing is not to simply
> write in one language using the syntactic sugar of another -- so doing,
> we can lose the best features of each.
> 
> Let's not speak in generalities, and allusions to advantages "known"
> by others -- let's get down to specifics.  What can't we presently do
> in Squeak that can be done in CL?  What is proposed to enhance the
> language?  What are the costs related to making the change?  Does the
> benefit outweigh the costs?
> 
> Obviously, the step of weighing is highly subjective, but the rest of
> the analysis is not.  Let's get down to brass tacks, otherwise we are
> just devolving into another abstract and probably unproductive language
> jihad.

Hmmmm, I don't remember having any revolutionary or antagonistic intent
when I wrote my little essays, nor any plans to hybridize anything, and
certainly no plans to devolve. And if I had all the answers to
everything I could charge a lot more for my time.

-- Dwight





More information about the Squeak-dev mailing list