The Future of Squeak or Squeaking at the Future?

Viktor Svub gilrandir at centrum.cz
Fri May 12 16:50:16 UTC 2006


stéphane ducasse napsal(a):
>> 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.
That's good news, but how? ^_-
> 
>> 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 ideas.
Not completely true - some smaller, not-enough-informed companies and
even universiti laboratories thing kind of "Smalltalk? that's no real
programming language..."
I thing there's not enough examles & tutorials for newcomers solving
trivial everyday tasks - we concentrate too much on things that can't be
done (or are very difficult to do) in other languages... losing the
forest for the trees.

> 
> 
> Pay attention Smalltalk is not equal to Squeak. Look at Dolphin
> Smalltalk: it is really cool!
It may be cool, but it's not completely open, you can't modify the VM
(afaik) ...and if anybody says 'Smalltalk', i understand 'Squeak' (or
VW, worstcase).

> 
> 
>> -> *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 ^^; )
> 
> 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.
The web site is *really nice* now ^_^. I know of the fonts. And i don't
think there's no one who could make a good design as a bachelor or
diplom work (have you seen Skylark, without the rounded corners? it
looks nice, clean, simple and professional enough for me).

> 
> 
>> -> *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 ^_^
> 
> Exact!
> 
>>     -->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).
> 
> Namespaces are not the solution.
> Manpower is! If you want the new compiler, contact marcus and help
> improving it.
Maybe a part of the solution... i think a better package dependency
system wold help (like Debians dpkg/apt, but better, of course ^_^ ).

> 
>> -> *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.
I'll do my best ^_-

> 
>> 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)
'Perfect' is still too far for me... until i can say "well, i'll do this
in Smalltalk", i a don't get an anwer like "wth? o_O" ... ^_~

> 
> Stef
>>
>> Viktor Svub
>>
>>
> 
> 
Thank you very much for the answers, i'll at least try to begin
'somewehere' ^__^

Viktor




More information about the Squeak-dev mailing list