Hello all,

I continue to think the community is really missing the point on a few
fundamental topics.  Some think the only route to success is to get
developers to use Squeak to churn out native-widget apps for end users;
others fire back with things like there should be no OS, no difference
between users and developers, and other idealistic beliefs.  All are
bickering, to the detriment of Squeak.

Our goal should be to collaborate on making both approaches, and others,
possible!  Personally, I would be thrilled with some slight pluggable
control of Morphic's appearance, combined with a LOT of attention to
making it feel the way they typical end user would be willing to
tolerate.  As I have said many times, the "out of the box" look of
Squeak has been improving from some time, but the feel is going to tank
Squeak for anything but niche use right now - sorry, but it's true. 
Since many Squeakers appear to like the feel, fine, make that
configurable.  We do not have to shoot each other in the foot to have
what we each want.

I recently talked to a really bright recent CS graduate.  Brace
yourself: he had never heard of Alan.  He has now of course :)   I blame
academia for this outrage, not the student.  The reality is that
Smalltalk does not get a particularly fair shake, and probably will not
for some time.  From one perspective, we can use that to our respective
personal advantages: crush the competition by having an edge.  We all
individually found Smalltalk, so others can too.

The best source of new developers will be those who already "get it" -
aka current Smalltalkers.  For them, ANSI compatibility is probably the
best thing we can strive to provide.  Squeak's read streams should catch
up with exception handling; reading off the end of a stream should
default to an error, with #nextOrNil and #nextAvailable: signaling a
willingness to accept less than the requested amount of data.  Squeak
should stop electively grumbling about underscores (it really is getting
to be elective at this point).  Want single-key assignment?  Fine, make
it an optional feature of the editor.

The modularization effort provides a wonderful opportunity to give
Squeak a frame-up restoration for 3.10 and  beyond.   I continue to hope
that we will take a collective deep breath and clean up the modules as
they go into the next image; now is the time.  3.9 could have some tools
to check/correct old code for export to newer releases, perhaps using
the RB to attempt to automate fixes.  As the governator might say, no
pain, no gain.

J.J., FWIW, the few end user apps I have seen written in Squeak all use
SystemWindow for their top-level window.  The result is one main window
with a Squeak-generated title bar inside the VM's main window - that's
wrong from a user's perspective.  To them, the Squeak/VM window will be
"the window" and so the client area (to borrow from MS) should be an
alignment morph or something covering the current world.  From that
perspective, and with the pluggable look and corrected feel I mention
above, I doubt you or your potential users would much miss the latest
and greatest native widgets.  That would be all the more true if your
hint of an exodus from Windows occurs.

Happy Smalltalking,

Bill





Brad Fuller brad at bradfuller.com
Sat Feb 3 23:45:14 UTC 2007:
One of smalltalk's wonderful features is it's prototyping ability, 
that's true. I think what you are proposing is to create native apps 
with Squeak to get developers excited about the development 
possibilities of Squeak.

But, I think we would go down the wrong road, and do a real disservice, 
if we encouraged building native OS applications. Squeak moves beyond 
the OS and vertical applications (or, never been there) into a world not

necessarily requiring an operating system - on into a personal 
environment where user's can manipulate objects for their own needs on 
any hardware.

(I used the word "application" in my original msg because I didn't know 
what else to use. Using the word "object" is ok, but doesn't convey the 
idea of an object that is feature-rich to satisfy a particular higher 
order need (like a web browser does.))

What we need is to convince Mr. Dell to sell computers with Squeak on it

and nothing else. That would be the ultimate.



J J wrote:
> I have been thinking about this stuff as well.
> 
> Vista is out, and the places I read think Microsoft may have opened
the 
> door for some competition (due to trying to force DRM down everyone's 
> throats, etc.).  If Steve Jobs goes for it, Micheal Dell said he is 
> interested in shipping Dells with Mac OS on them.  Some people are
even 
> saying Linux may gain some big market share.
> 
> So what this means to me is, people will be looking for an easy way to

> make GUI applications on these platforms.  I know nearly nothing about

> the MAC world, but in Linux the only RAD tool I am aware of is a code 
> generator for GTK.
> 
> Now in Smalltalk we always say (and I believe) that we can be much
more 
> productive then other languages.  So I think it may be time to prove
it.
> 
> I don't know how many of you have used Dolphin, but it is an amazing 
> system.  It only works on windows, but the GUI is wonderful and looks 
> just like a normal windows app.  And what is more, after you build an 
> application, it has tools to automatically package up the application 
> you write and turn it into a MSI kind of package.  This includes
turning 
> certain parts into DLL's so that if you write multiple applications
they 
> can share libraries, etc., etc..
> 
> And I think Dolphin is currently the perfect system for building
native 
> windows apps.  You get as much, or more speed then a VB environment
but 
> vastly more power.
> 
> What would be nice, is if Squeak had something like this.  A great GUI

> builder (maybe it has already) and some way that we could use some 
> system to turn an application we write into a native Linux/Mac OS 
> package.  Well, native looking.  If you check what Dolphin installs
you 
> would find a smalltalk interpreter in there.  The payback with the 
> installer is, we can then submit "binaries" to distributions like
Debian 
> for any applications we make.  The end user doesn't need to know it is

> Smalltalk.  If we end up becoming a big player in the Linux and/or MAC

> world, people will be *begging* us to share how we are doing it.
> 
> With a rapid GUI development tool bound with the productivity of the 
> Smalltalk language and the platform independence of Squeak we could
have 
> quite an advantage in the native UI space.  And I understand the 
> concerns about making apps that do things that already exist, but what

> we have to remember is that all applications change all the time. 
What 
> a Word processor looked like 5 years ago is a little different then
what 
> they look like today and will be still more different in another 5. 
Not 
> drastically, but new features are being added.  All we have to do is 
> keep up with the features they have and add our own here and there. 
To 
> take a page from Paul Graham's book, when ever a "competitor" adds a 
> feature, we can have it the next day.
> 
> Think about Mozilla for example.  They are pretty advanced, but it is
an 
> enormous code base in C.  They can't add new core features quickly.
> 
> I still believe the web will play an even larger roll in the future
then 
> now, but we will always have to have *some* native apps (a browser if 
> nothing else).  And if MAC gets a bigger percentage of the desktop 
> market share (and maybe even Linux), this could open up an opportunity

> that wasn't there before.  And I don't think anyone can move to cover 
> that gap as quick as Smalltalk can.
> 
>> From: Brad Fuller <brad at bradfuller.com>
>> Reply-To: The general-purpose Squeak developers 
>> list<squeak-dev at lists.squeakfoundation.org>
>> To: squeak-dev at lists.squeakfoundation.org
>> Subject: Making Squeak more accessible and used - reversing the trend
>> Date: Tue, 30 Jan 2007 18:05:01 -0800
>>
>> All,
>> <sniped>

Wilhelm K. Schwab, Ph.D.
University of Florida
Department of Anesthesiology
PO Box 100254
Gainesville, FL 32610-0254

Email: bills at anest4.anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029