[squeak-dev] smalltalk evolution

Eliot Miranda eliot.miranda at gmail.com
Tue May 31 17:29:13 UTC 2011


2011/5/31 info at tomsik.cz <info at tomsik.cz>

> Sorry, I forgot about uselessness of array literals.
>
> I simply don't see any use-case in which I'd like to
> evaluate something in compile-time, it's feels to me
> like another form of static state.
>
> Are there any (major) advantages of array literals?
> Something which couldn't be done without them?
>

I remember anecdotes from the last decade on slow start-up of Java
applications that were either competing with VisualWorks or had been ported
from VisualWorks that in part were due to the lack of powerful literal
facilities in Java.  It appears that having the ability to define complex
data statically without having to construct it by running code is a
significant space and time saver (space, since the code to construct a
complex literal will almost certainly be bulkier than that literal unless
the code is sophisticated enough to be functioning like a decompressor, in
which case it'll likely be incomprehensible too).  For me, a string literal
syntax is an essential component of a good programming language and
Smalltalk excels here.

There /is/ an issue as to whether #() is necessary syntax.  After all one
could rely on the compiler to detect whether a { expr. expr } form can be
evaluated at compile time.  That's a position Gilad Bracha has taken in
Newspeak, and I think that design is driven by modularity concerns (in
Newspeak there is a desire for the class of literals to eventually be
determined at module instantiation time, based on what classes one imports,
not on compile time).  While this is a good argument in Newspeak it strikes
me as very bad for readability.  Using an easily recognised literal form
takes significant cognitive load off of the programmer and that's extremely
important (and fits with Smalltalk's ethos).

2¢
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110531/b937c10f/attachment.htm


More information about the Squeak-dev mailing list