- Why python instead of squeak ?

I hope I have not given the impression that this is a Squeak vs [your favourite language] type of discussion. As originally stated, I'm trying to get to the nitty gritty of why Squeak/Smalltalk is largely ignored and to see what if anything can be done about it. Of course I hope that I can convince others that to give it a go but not as an alternative, more as an additional (and fun) way to explore what can be done on your tablet.

- Python was inspired from SmallTalk and is compatible with the GPL.

Yup, since "discovering" Squeak/Smalltalk I have surprised at how much other languages have been inspired by and/or borrowed from it. Indeed I reached the conclusion that generally the trend in language features is heading right back to where most of it started, ie, Smalltalk. Although I do admit that Smalltalk itself may appear lacking in areas where other languages have progressed. I don't have an answer for this except to say that any apparent omissions don't seem to have hindered developers (in one recent posting regarding "pipes" most of the required functionality could be readily implemented within Smalltalk itself).

Re licencing: I'm no expert but a new "MIT style" licence is being worked on and I am trying to get clarification. I do wonder though exactly what are the concerns to non-commercial developers, which I assume are the majority here? Do Nokia impose any restrictions contradicting GPL? Do they themselves comply fully or even in spirit, ie, are some aspects of Maemo closed-source? I also wonder how any Squeak licence may differ from say Java, which I avoid for years due to not being clear on what I could/ could not do with it?

Some feedback from Squeak irc channel: It has been relicensed under the Apache License allowing inclusion in the OLPC project

(me, I'm still none the wiser what the implications are )

- Runs on unix, Mac, PC

Squeak does as well, as do some other Smalltalk VM's (eg, Syx).

- It is well documented.

They tell me Smalltalk is "self documenting"

- It tends to favor simplicity.

Agree but I'd say the same for Squeak/Smalltalk.

- There are binding for many GUI Framework (wxWidget, pygtk, pygame, tkinter ...)

Squeak has bindings for other GUI frameworks but I think the general preference is to use Morphic as it is dynamically modifiable by the user (but can be locked down to an extent). Croquet, the second-life-like 3D environment based on Squeak, uses Tweak which aims to be an event-driven version of Morphic.

- Nice function/method calling capabilities (positional parameters,
named parameters, defaults).

I'm fairly certain these can be catered for in one way or another. For example there is a package for positional parameters to ease transition for OpenGL programmers.

- And it has an impressive collection of features, and they are well
implemented. Classes, exception handling, name spaces, collections,
reflexive programming and networking are all built in and all cleanly
implemented.

With the exception of name-spaces, which seems to be a religious point-of-order, all others are to be found in Squeak/Smalltalk, if not originated from.

Many thanks for your reply. I still find myself scratching my head and wondering about the lack of interest. As an aside, I recently read one Canola post about being able click a button without scrolling it up to the middle of the screen. There may be good reason but as a general point I still wonder why users are not offered more flexibility in this and other areas (there are exceptions, I know). Squeak offers this degree of flexibility and more.

PS: Khertan, you don't say if you have tried Squeak/Smalltalk?

Squeak just get a look to the documentation, Smalltalk a lot ... but i prefers python and obj-c ... but i can't really say why ... it s like colors ... i prefer blue ... but why ? =)

Umm, sorry for my ignorance but can you compile your squeak application to (relatively small) executable that uses other (shared) libraries? I thought you just dump/copy your (big) squeak enviroment to be your application and only disable some stuff in it so only your application window is shown but otherwise it is full blown squeak environment in every applications you make.

fanoush, some Smalltalks do give you the facility to produce exe's but IMHO this detracts from one of the major benefits, namely having a live environment that can be customised on the fly.

Squeak consists of a VM containing machine dependent code while all else (the bulk) of code is straight smalltalk in the "image" file. The VM I currently have on my 770 is ~2.5meg but is not customised and still contains plug-in's that could be excluded. The Squeak image file I am using is the one found at Squeak.org/. It is 15meg *but* this can be reduced significantly while still retaining much of the core functionality. For example, the "SqueakLight" image is 5meg, "KernalImage" more/less than 5meg depending on your focus, while others are working on VM's and images in the 100'sk range. There is plenty of scope for tailoring VM/image size to your requirement and even package that do the job for you. Keep in mind you get a lot of bang for your buck in these images, even the smaller one's.

Shared libraries can be accessed via plug-in's compiled either internal/external to the VM or in most cases simply via the Foreign Function Interface (FFI) directly from Smalltalk.

If speed is an issue then Exupery (wip) may eventually offer the ability to selectively compile byte-code to native. It does now, at least for x86. In practice I haven't found Squeak to lacking speed-wise.

Spoon is considered by some to be a possible direction for a future Squeak. It is very small and designed from the ground up to load modules(?) on demand possibly from a remote server. So you end up only with what you use, plus the base image of course. Beyond that I am not familiar with it.

For those with no knowledge of Squeak/Smalltalk it may help to think of it more like VMWare than python, java, etc. The "image" truly represents a virtualised machine and just like VMWare it retains full state between runs (assuming you "save" of course).

Yes, that's what I thought. This is great for prototyping/developing phase but not very good for the last step i.e. finalizing your app and packaging it for end users. I find this good for academia (we had smalltalk classes at university and it was good for understanding OO design) and for situations where the target group is developers but not for standalone applications for end users.

So each squeak application has 5-15 mb penalty on disk and (maybe even more) in ram. Not very good for mobile devices :-)

Even on 200-300MHz machine with 64-128MB of total memory? On n770 you just boot clean system and most of memory is already used. N800 is better but still resources are low.

Yes, sounds like this is trying to solve the issue of monolithic vm snapshots, IMO this is the way to go :-)

I totally agree smaller is better. In this case though that 5-15meg should be viewed as containing a whole bunch of applications. In practice for a specific single application it would probably be a lot less because any non-relevant code could be stripped from the image.

In case anyone is interested in Squeak, a free book has just been released. Get it >here<

PS: A custom version of Squeak is running on the OLPC

Not to mention that you don't need an IDE to develop Python apps; or you can use whatever you are familiar with, from plain text editors to bloated monsters like Eclipse.