[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
|