The Future of Squeak or Squeaking at the Future?
ducasse at iam.unibe.ch
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? @ 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.
> -> *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).
Namespaces are not the solution.
Manpower is! If you want the new compiler, contact marcus and help
> -> *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