[squeak-dev] Fork Proposal: Cuis & Killer Apps.

Casey Ransberger casey.obrien.r at gmail.com
Thu Sep 8 00:10:46 UTC 2011


On Wed, Sep 7, 2011 at 2:24 PM, Levente Uzonyi <leves at elte.hu> wrote:

> On Wed, 7 Sep 2011, Overcomer Man wrote:
>  I suggest a new fork or possibly a new orientation for the next Squeak
>> release:
> I guess we have too many forks already (compared to the number of active
> developers).


 Adopt Cuis as the core image and focus on killer applications to attract
>> new
>> Smalltalk users.
> Cuis is nice, but lacks features that are important for those killer apps
> (e.g. internationalization). Also throwing aways years of work (3.8, 3.9,
> 4.1, 4.2 and 4.3) sounds like a bad idea. We should pick good stuff from
> Cuis (and Pharo) instead.
> To make the image smaller we should do two things (in parallel):
> - craving (make packages unloadable, remove dependencies, split packages)
> - building (use Spoon to rebuild the current image)

Yes, we should merge the best things from Squeak into Cuis, We should merge
the best things from Cuis into Squeak. Until all are one.

WRT internationalization, though, I do feel that most end users don't need
20 languages they don't speak in the core system. Most users will want to
use the system in a primary language. This stuff should all be available as
rock-solid external packages. Not saying it isn't important, not saying that
at all. If we hope to rebase Etoys on Squeak, internationalization is

> To make this happen we have to start with writing tests, which "document"
> the expected behavior of the system. So when we change it, we can be sure
> that we didn't lose anything important.


A living system needs a living specification, and the closest thing I know
how to do to a living specification is a great suite of tests.

Let's start by merging the tests.

 Thousands of downloads are recorded on CNet for simple apps like a voice
>> recorder.
>> They could all be using and learning Smalltalk.  Same for many other
>> applications.
>> That would help make Smalltalk popular again.
> If popularity is the goal, then this is a possible path, though most users
> won't care about the language their software is written in.

Popularity, along with usability, *is* _massively_ important. Picture three
clocks in your mind. For every second, Ruby gains a second. For every
second, Squeak and Pharo lose two.

If we lose badly, we've wasted our time.

Recently I found Squeak / Cuis contains many Sound classes.  So I wrote up
>> an email suggesting it to a community college teacher friend who had asked
>> for a sound recorder.  Imagine my embarrassment when I found the files
>> Squeak supports doesn't include .mp3.
> I guess it does (there's Mpeg3Plugin). Btw I think using PortAudio or
> LibVLC may have advantages over the current platform specific
> implementations of audio and video support.

Good news.

Squeak has so much unfinished half starts at programs, why not adopt Juan's
>> work to flush the unnecessary, then get started on building a serious
>> applications team to build truly useful free code.
> See above.

See below.

> Another example, Roxio is a million dollar software company making a video
>> recorder app. which is not as good as an ordinary VCR and not supported
>> (they have a staff but try getting any real help).  Squeak could be
>> capturing a slice of that market and enticing users to learn Smalltalk!
>>  And
>> source code can substitute for most support.
>> Another example, Solid Works is a 3D object drafting program that is
>> simple
>> and gets many thousands of users away from AutoDesk.  Can Smalltalk
>> deliver
>> most or all of that function with a FFI to openGL and some programming?
>> Certianly!
>> Finally, the one complaint I've heard on the job about Smalltalk is it's
>> slow.  I recently added several thousand classes and find simply clicking
>> on
>> the class in a browser is now slow to respond.  When end-users, not
> Interesting. Did you add all classes to the same class category? In that
> case it will be slow, but this is a unrealistic case. I'm not saying we
> shouldn't fix it, but it's something that has a pretty low priority.

I have a feeling there's an obvious fix for this. He might have ended up
with a dictionary larger than was optimized for. Not going to worry about it
until we see a performance profile.

 programmers, can type at 80 words a minute and more in a C app. or they can
>> be limited to 30 wpm or less in a Smalltalk app. they demand C.  The new
>> VM
>> was a good improvement, now try to solve the speed issues in the image.
> Are there other speed issues?

'Cause Levente will probably be all over that:) straight up wrecking the bad
numbers with new optimized code. 'Cause he's pretty much awesome that way.

>> Thanks,
>> Kirk Fraser

Casey Ransberger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110907/c473360c/attachment.htm

More information about the Squeak-dev mailing list