Interesting mail. I would like see the answers of experts.

2006/5/12, Viktor Svub <gilrandir at centrum.cz>:
> 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
>
>
>


-- 

::Mi blog::
http://blog.lordzealon.com