Inline.<br><br><div class="gmail_quote">On Wed, Sep 7, 2011 at 2:24 PM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu">leves@elte.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, 7 Sep 2011, Overcomer Man wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suggest a new fork or possibly a new orientation for the next Squeak<br>
release:<br>
</blockquote>
<br></div>
I guess we have too many forks already (compared to the number of active developers).</blockquote><div><br></div><div>+1 </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Adopt Cuis as the core image and focus on killer applications to attract new<br>
Smalltalk users.<br>
</blockquote>
<br></div>
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.<br>
To make the image smaller we should do two things (in parallel):<br>
- craving (make packages unloadable, remove dependencies, split packages)<br>
- building (use Spoon to rebuild the current image)<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
To make this happen we have to start with writing tests, which "document"<br>
the expected behavior of the system. So when we change it, we can be sure that we didn't lose anything important.</blockquote><div><br></div><div>+1! </div><div><br></div><div>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.</div>
<div><br></div><div>Let's start by merging the tests.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thousands of downloads are recorded on CNet for simple apps like a voice<br>
recorder.<br>
They could all be using and learning Smalltalk. Same for many other<br>
applications.<br>
That would help make Smalltalk popular again.<br>
</blockquote>
<br></div>
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.</blockquote><div><br></div><div>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.</div>
<div><br></div><div>If we lose badly, we've wasted our time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Recently I found Squeak / Cuis contains many Sound classes. So I wrote up<br>
an email suggesting it to a community college teacher friend who had asked<br>
for a sound recorder. Imagine my embarrassment when I found the files<br>
Squeak supports doesn't include .mp3.<br>
</blockquote>
<br></div>
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.</blockquote><div><br></div><div>Good news. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Squeak has so much unfinished half starts at programs, why not adopt Juan's<br>
work to flush the unnecessary, then get started on building a serious<br>
applications team to build truly useful free code.<br>
</blockquote>
<br></div>
See above.</blockquote><div><br></div><div>See below.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another example, Roxio is a million dollar software company making a video<br>
recorder app. which is not as good as an ordinary VCR and not supported<br>
(they have a staff but try getting any real help). Squeak could be<br>
capturing a slice of that market and enticing users to learn Smalltalk! And<br>
source code can substitute for most support.<br>
<br>
Another example, Solid Works is a 3D object drafting program that is simple<br>
and gets many thousands of users away from AutoDesk. Can Smalltalk deliver<br>
most or all of that function with a FFI to openGL and some programming?<br>
Certianly!<br>
<br>
Finally, the one complaint I've heard on the job about Smalltalk is it's<br>
slow. I recently added several thousand classes and find simply clicking on<br>
the class in a browser is now slow to respond. When end-users, not<br>
</blockquote>
<br></div>
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.</blockquote>
<div><br></div><div>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.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
programmers, can type at 80 words a minute and more in a C app. or they can<br>
be limited to 30 wpm or less in a Smalltalk app. they demand C. The new VM<br>
was a good improvement, now try to solve the speed issues in the image.<br>
</blockquote>
<br></div>
Are there other speed issues?<br></blockquote><div><br></div><div>'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. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Levente<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Kirk Fraser<br>
<br>
</blockquote>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br>Casey Ransberger<br>