The Future of Squeak or Squeaking at the Future?

Viktor Svub gilrandir at
Fri May 12 11:43:46 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.

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.

I've read enough of the discussions and articles regarding 
Squeaks/Smalltalks future, and this is a sum of the main issues with 
some personal remarks:

-> *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 ^^; )

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

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

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

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?

Viktor Svub

More information about the Squeak-dev mailing list