Smalltalk philosophy

I'm not sure where the best place to ask this is so if you can redirect me that would be great.

Lets say instead of an operating system and applications all we ran was smalltalk. What are some of the benefits that we would have and disadvantages?

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.
* Less dependency on standards like XML or HTTP. Instead of everyone having to learn standards you just build an object and talk to that.

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.

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

What else can you guys think of?

2008/7/4 itgiawa <[hidden email]>:
This is not an issue. Because you don't write a giant program in
smalltalk, simply because you write quite small program which does all
you need :)

> What else can you guys think of?
>
> --
> View this message in context: http://www.nabble.com/Smalltalk-philosophy-tp18270563p18270563.html
> Sent from the Squeak - Dev mailing list archive at Nabble.com.
>
>
>



--
Best regards,
Igor Stasenko AKA sig.

I believe that Dan Ingalls (http://en.wikipedia.org/wiki/Dan_Ingalls)  
once defined an operating system as "whatever your programming  
language doesn't provide" with the implication that a good programming  
language (such as Smalltalk) would not need much of an operating  
system. Keep in mind that Smalltalk came out of the the 1970s, about  
the same era as UNIX.  The assumption that there would be a common,  
powerful operating system was not really the same then as it is now.

James Foster


On Jul 3, 2008, at 5:23 PM, itgiawa wrote:

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

Today, one can assume that given multi-core multi-processor multi-computer
interconnected networks, even within *just* the Squeak world, that there
will be reasons to run various images on multiple VMs with both the same and
different versions of Squeak across the network.

Thus, as the very least, trying to use Dan's definition decades later, a
Network OS is the part of a language standard that let you start, stop, and
interconnect multiple VMs with different views of the world that need to
communicate with each other and use shared resources (memory, processes,
sockets, hardware I/O). Occam and the parallel processing Transputer
architecture had some standards for that in the early 1980s.
  http://en.wikipedia.org/wiki/Transputer
QNX also had some good ideas about this in the early 1980s.
  http://en.wikipedia.org/wiki/QNX
The current crop of virtual computing tools like the Xen hypervisor
  http://www.xen.org/
are (stretching things a bit :-) in a way the philosophical legacy of some
of these ideals. Has any Smalltalk had this support? OTI's perhaps?

Even on a single core single processor stand-alone personal computer this
need to deal with versions is true to an extent. Eventually it practice you
may have multiple running programs using multiple versions of the same
language environment, and they need to cooperate. If this is handled poorly,
as is sometimes the case under GNU/Linux with incompatible versions of
libraries that can't be loaded together, you get failing applications or one
that can't be loaded together. So, the OS is perhaps best thought of as a
layer of tools for cooperation and to manage change and maximize
compatibility for the leas ongoing effort and requiring the least retesting.

Java has addressed these network issues somewhat from the beginning, mostly
by strong political central control of the Java trademark and an emphasis on
backward compatibility of certain core standards. You can typically still
load much 1.0 Java code in the latest JVM and expect it to run. But Java has
other issues, obviously. :-)

Once you allow for even more than one language in your wold, this layer for
cooperation becomes even more important and harder to write elegantly. :-)
You can even wind up with stuff like CORBA or XML or ODBC if you are not
careful. :-)
  http://www.arcavia.com/kyle/Rants/XML%20Sucks.html
And then versions of them. :-)

Smalltalk philosophically has often implicitly denied this notion of the
need for cooperation, and that has been its major weakness historically,
leading to any Smalltalk system over time being incompatible in practice
with *itself* eventually by bitrot and paradigm shifts. I'm not saying
Smalltalk can't play nice with other systems in theory, just that it is
typically an ad-hoc add-on, not a core feature, and it is awkward
philosophically as well as often technically.

Personally, I feel now that Java JVM and core libraries are truly free
  http://java.dzone.com/announcements/java-finally-free-and-open
I think it would make a good platform to support many of the ideals of
Squeak (obviously, using mainly the JVM, not mainly the Java language). On
the other end of things, I've long thought building on Forth, rather than C,
is a way to get a completely understandable system (since the core of Forth
is only about 1K in size). Right now, Squeak lives in the middle, leveraging
the limited C standard -- which has its own advantages and disadvantages.
Perhaps one might imagine some sort of larger Squeak beast that can live on
any of these three platforms -- Forth for simplicity, C for speed, and Java
for leveraging its portability and self-reflectiveness. But that is a very
different vision of "all we ran was smalltalk" than the original poster
probably meant. It's more like, what you deal with if you are clued in might
be mostly a Smalltalk environment and it helps you handle all the other
issues -- including managing the command line better, managing kernel
rebuilds and reboots better for you under GNU/Linux, and managing multiple
versions of Smalltalk VMs for you. It's a Smalltalk vision that does not try
to be under everything else, but rather a vision that tries to float above
everything else.

--Paul Fernhout

James Foster wrote:
> I believe that Dan Ingalls (http://en.wikipedia.org/wiki/Dan_Ingalls)
> once defined an operating system as "whatever your programming language
> doesn't provide" with the implication that a good programming language
> (such as Smalltalk) would not need much of an operating system. Keep in
> mind that Smalltalk came out of the the 1970s, about the same era as
> UNIX.  The assumption that there would be a common, powerful operating
> system was not really the same then as it is now.