Making Squeak more accessible and used - reversing the trend

J J azreal1977 at hotmail.com
Sun Feb 4 08:24:42 UTC 2007


>From: Brad Fuller <brad at bradfuller.com>
>Reply-To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>To: The general-purpose Squeak developers 
>list<squeak-dev at lists.squeakfoundation.org>
>Subject: Re: Making Squeak more accessible and used - reversing the trend
>Date: Sat, 03 Feb 2007 15:45:14 -0800
>
>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.

Yes.  That and proving to others how good Squeak/Smalltalk is by constantly 
being ahead of them.  I should also mention, I don't mean native as in 
"compiles to machine code".  It will still be the same system, just with 
unused components stripped out of the package.

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

But having the ability to generate native looking doesn't mean we can't 
still build in Squeak in this way.  In fact, we still have to *develop* this 
way.  It is just that when we make a new "application" or update an older 
one, we press a "deploy" button and now we have a package that we can use 
with all the native package tools of the different operating systems.

In other words, we can be on a high horse and say "no compromise!  This is 
the future and you must take the whole or you can have nothing!" and 
everyone will continue to choose their less capable languages (except for 
web programming where we don't have this issue).  Or we can reach out just a 
little and prove what we can do.

I am not talking about something radical like getting source files.  Not 
having source files is a big part of what gives Smalltalk it's advantage and 
I would never want to see that changed just to look more familiar.  I would 
never want to change Smalltalk in any way just to look familiar.

But I do care about playing well with others where it makes sense.  And to 
me, an ability like this makes sense.  Right now, if I made some cool 
application in Squeak what does the average user have to do to see it?  They 
use their native app installer to get squeak, then they have to learn the 
Squeak interface to be able to use *our* app installer to finally get it.  
That puts us at a rather large disadvantage.

Right now, people are doing this kind of packaging for stand alone 
applications anyway.  Look at Sophie for example.  And what about commercial 
apps?  We want to support those right?  If a vendor releases something for 
the desktop, it will be a stand alone app.

But if we make the stand alone application generator, we can do anything we 
want.  For example, we can have the default error handler to pop up a window 
to the user, much like MS windows does now, and give them an option to send 
a "bug report".  The "bug report" would actually zip up the image, right 
where it is and mail it to the developer so when he runs it in his own 
image, he has the full debugger et al. to rapidly find and fix the problem.  
We can have the built in auto-update system just load a change set.  Using 
the power of Smalltalk, our application can update itself while running.  No 
application restarts for updates.

>What we need is to convince Mr. Dell to sell computers with Squeak on it 
>and nothing else. That would be the ultimate.

Squeak isn't ready to fit that roll, even if there was interest.

_________________________________________________________________
Laugh, share and connect with Windows Live Messenger 
http://clk.atdmt.com/MSN/go/msnnkwme0020000001msn/direct/01/?href=http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=hmtagline




More information about the Squeak-dev mailing list