[squeak-dev] Smalltalk philosophy

Brenda asparagi at hhhh.org
Fri Jul 4 22:42:50 UTC 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

itgiawa wrote:
| Lets say instead of an operating system and applications all we ran was
| smalltalk.

Count me in!

You're aware of SqueakNOS, right?  http://wiki.squeak.org/squeak/1762

| Pros:
| * There would be a common interface between EVERYTHING. So now if I wanted
| to make changes to a GUI I could do that. The only way to do this in
OS X or
| windows is with messy hacks.

I might rephrase this to be:
* There exists a consistent set of tools for examining and modifying all
objects in the system (top to bottom), including code.
This is the main reason I would like to use Squeak for all my computing
needs.

| * Less dependency on standards like XML or HTTP. Instead of everyone
having
| to learn standards you just build an object and talk to that.

How would everything being in Smalltalk achieve this?  It seems like
this is a library availability and quality problem, which exists
regardless of language consistency.  Possibly also a social and
collaborative maintenance problem.

More pros:
* Changes to the behavior of any part of the system take effect immediately.
* Less distinct boundary between users and programmers (i.e. culture
which encourages users to build & use what they actually want, and tools
that make it possible, vs. trying to keep users & programmers separate).

| Cons:
| * There would still be some sense of "platform dependency." Even though
| there is no "operating system" we still have a collection of objects that
| preform the tasks of an OS like memory management and cpu scheduling.

These become regular old code dependencies, I think.  This is a major
problem, but again, it exists whether or not the OS is in Smalltalk.
Spoon's approach to code sharing is a necessary prerequisite to what
you're talking about.  I think the real equivalent of platform
dependency here is:
* Hardware support.  Somebody has to write all those drivers.

| * Scaling. Would this be as hard to scale as a giant c/java program?

What do mean by scaling?  Are you talking about performance, or
maintenance, or...?  I don't see a big con here, for either use of the
word scaling.

More cons:
* Application availability.  Unless the whole world suddenly switched
(I'm not holding my breath), major new applications written by
programmers are going to keep coming out on non-Squeak platforms, people
using Squeak platforms will want or need to use them, and therefore it
will be hard to use only Squeak.


If you actually want this, I think it needs a three-pronged approach (in
terms of technical work to do; I'm not going to get into whether anybody
not already on this list would want to use the results):

- - bottom-up: Get SqueakNOS, Spoon & Exupery working together smoothly,
so Squeak can run directly on hardware, as natively as possible.
- - top-down: Get a really good set of basic desktop applications working,
so people don't have to switch out of Squeak (whether or not there's an
OS underneath).
- - middle layer: Write, maintain & clean up libraries everybody depends
on so that it's easier to do more high-level stuff, faster.

Lucky for me & other crazy Squeak-is-all-I-ever-want-to-see people,
there are things going on in each of these categories already.

- --B


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)

iD8DBQFIbqdqjIInAF656BkRAuqvAJ4tu/cNTCaI7Jzu3lhouoTKiCdRDwCgqwUT
cgDd+FQKJR+Zv8bFIV/azV4=
=Nhl4
-----END PGP SIGNATURE-----




More information about the Squeak-dev mailing list