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? 
@ http://www.comtalk.net/Squeak/87 ...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) >> 
http://www.cdegroot.com/blog/2006/02/02/delay-after-delay/, and it 
really shouldn't be hard to implement Transactional Memory 
(http://www.cambridge.intel-research.net/~rennals/faststm.html) 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 
(http://swiki.krampe.se/gohu/32 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