Inline.

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).


+1

 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
essential.


> 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.


+1!

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.

Levente
>
>
>> 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