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 fadxv@yahoo.com:
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?
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.
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:
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?
-- View this message in context: http://www.nabble.com/Smalltalk-philosophy-tp18270563p18270563.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
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.
-----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
squeak-dev@lists.squeakfoundation.org
-
Brenda -
Igor Stasenko -
itgiawa -
James Foster -
Paul D. Fernhout