The Future of Squeak or Squeaking at the Future?

stéphane ducasse ducasse at
Fri May 12 15:31:25 UTC 2006

> I'm a 'Squeak Newbie' for more than a year now, and i really love  
> the language and environment. Now with full closures, traits,  
> Seaside, Magritte, Exupery... (Tweak?, pragmas?) the language is  
> truly limitless and still clean-and-simple (I'm one of the people  
> who really like the Smalltalk syntax ^_^ ).


> What's really bugging me is the lack of possibility to use Squeak  
> for 'everyday tasks', like linux scripting, small apps and so on...  
> i don't say it's "impossible", but totally discouraged, unsupported  
> and "forsaken" by most employers.

We started to work on a scripting syntax but we stop. This would be  
easy to get one.

> As it stands now, Squeak *is* a language for long-time Squeakers,  
> OOP learning and language-hacker, maybe mid-sized web apps, but  
> *nothing more*.

> I'm forced to learn Ruby (and probably Python) to be able to do my  
> work now, and i do really hate the utterly ugly and evil perl-like  
> syntax, lack of dev environment (Browser? Shout? ...impossible) and  
> the complexity (perplexity?) of this languages.

The fact that companies want to use Ruby or python is not really  
related to the language but the trends around it.
If I would have couple of Million dollars to spend I would have some  

Pay attention Smalltalk is not equal to Squeak. Look at Dolphin  
Smalltalk: it is really cool!

> -> *GUI DESIGN* of Squeak is kind-of weird/childish: we don't  
> really need look like window$, but the UI is the first thing man  
> gets to see, so adding a bit of sanity would be nice (anyone using  
> the Skylark theme? @ ...imo this  
> should replace the default one, but porting in 3.9 involves kind of  
> black magic; an alternative theme mimicking the 'redmont' look wold  
> be /though ugly/ nice too ^^; )

Yes. We started to change the web site. Andrew Tween is working on  
true type fonts support and we should certainly
pay someone to design a look for squeak.

> -> *no native apps* - kind-of part of GUI, but shouldn't be too  
> hard to get right: we have wxSqueak, maybe we will get Ffenestri...  
> make the first-time users see them ^_^


> 	-->complex graphical apps use the host system only to get a plain  
> window and draw their content by themself (Winamp, most of Miranda,  
> almost all games...) - we should be able to mimick this behavior:  
> make the native windows 'wrap around' SystemWindows and other  
> morphs/Tweak costumes and let BitBlt do it's work.
> 	-->i don't really see a reason for the main window being  
> controlled by the VM: it should be possible to show/hide it on- 
> demand and so everybody could choose: Squeak UI like it's now, or  
> loose apps in native windows and let the main window act like the  
> 'java console', but not-even-comparable better.
> -> *threading* - good to use soft-threads, bad to not-be-able to  
> use host threads, most in the times of multi-core CPUs

> 	-->I've read an *really* interesting blog concerning the use of  
> realtime delays (another pain-in-ass) >> 
> blog/2006/02/02/delay-after-delay/, and it really shouldn't be hard  
> to implement Transactional Memory ( 
> without breaking image format  
> (breaking delay-using code is no argument, even between minor  
> versions of Squeak, half of the packages get regularly unusable)
> 		--->if we had transactional memory *and* externalized VM state,  
> we could fork the interpret for every transaction... or use a  
> predictive scheduler to assign the transactions to a fixed number  
> of host threads ... or there are sure other ways (only guessing,  
> I'm not very proficient in this field).
> -> *foreign languages* are another long-time problem: english is  
> good enough for the dev environment, but not for end-user apps, and  
> until the whole image works in Unicode (utf-8), using any language  
> with non-standard charset involves very deep hacking of the image  
> and fonts, much of the free distributed TTF files have complete- 
> enough utf-8 charset, but loading them, the national characters are  
> still unusable (not talking about input conversions).
> -> *packages/namespaces* - I've tried VW, and it's packaging system  
> is evil, taking away the simplicity and so the usability;  
> Monticello is good, but not good enough, and without namespaces  
> ( is really enough), the image gets  
> very bloated in no time... waiting for M2, waiting for namespace  
> support in newCompiler (could hack it into by myself, but for a  
> compiler generated by SmaCC, it'd be a more-than-dirty solution).

Namespaces are not the solution.
Manpower is! If you want the new compiler, contact marcus and help  
improving it.

> -> *host integration* - no callbacks, insufficient FFI (limited  
> parameters) - it's true anyone can write an own wrapper plugin, but  
> it's very discouraging and complicating the work (a language should  
> aid the developer, not adding tasks).
> I thing there is a way Squeak can stay a small, simple and fast  
> environment for embedded dev on one hand and a robust dev language/ 
> environment/framework/engine/call-it-as-you-like for system  
> scripting, web/desktop apps, and with Exupery maybe system apps and  
> games too ^__^ (just dreaming..?)

No I think that this is possible but just help!
Everybody can help.

> Of course i could do a lot of these 'tasks' myself, and/or aid in  
> others, but by now, there is really no motivation to do it without  
> the community support - it's a lot of changes, depending on each  
> other and sometimes breaking compatibility, and i really don't want  
> to end up with my own branch of VM and image, unsupported and so  
> unusable in the real world out there...

Just start with some simples changes, get confidence and trust.
Help in harvesting for example, writing tests, helping people, trying  
other codes. I think that stepwise we can slowly get there.

> Is there a real possibility to do this kind of 'step in the dark',  
> and evolve Squeak for the use in real word, in our everyday jobs...  
> without losing the community?

I really hope but we need to have more people working for squeak and  
not simply using it (which is already perfect)

> Viktor Svub

More information about the Squeak-dev mailing list