Understanding Smalltalk for Modifying Scratch (Squeak version)

Hi Azka,

Thank you for helping us improve Scratch. :)

Perhaps I can guide you into the Smalltalk way of thinking and how
different it is from the usual application development paradigm
and workflow.

Imagine you're a Java developer and you use Eclipse for your IDE.
Imagine you
keep your source code in a SVN or similar repository which runs on a
database server. Imagine your development team keeps your entire
setup ... Eclips, SVN, repository, application data, operating system, and
configurations, in an Virtual Operating System
ram-memory-space-image-in-a-file which
VirtualBox, or VMWare can run ... so there is no "installation" to get
one's environment running. The VirtualBox
ram-memory-space-image-in-a-file has a "snapshot" to a single disk file
 of all the applications installed an running.

In the setup described above, one simple takes an VirtualBox snapshot
ram-memory-space-image-in-a-file and starts it with VirtualBox.
This has the Eclipse IDE, the application running in Eclipse, and the SVN
server running all at the same time from the moment the VirtualBox image
snapshot was taken. One just continues to make changes to the code in
Eclipse and the running application in Eclipse immediately reflects
those changes.

In (almost) all Smalltalk distributions, the Smalltalk development
environment has everything mentioned above, and works like everything
mentioned above.

The squeak.exe application is like the VirtualBox application which runs
snapshot saved ram-memory-space-image-in-a-file.

The squeak.image file is like the ram-memory-space-image-in-a-file
which has Eclipse and the developer's application all running all the time.

The .source file is like the SVN repository in a database. You'd never,
never edit the SVN source code database file directly, even if in theory
you could. It'd ruin the versioning and indexing among other problems.

The .changes file is like the SVN repository database journaling file. It's
just there for emergency recovery reasons. Not to be edited directly either.

Making snapshots of the ram-memory-space-image-in-a-file is like
selecting "save" or "save as" in the Squeak World menu to create a new
.image file.

Once the squeak.exe (in Windows, or the Linux, or OS X equivalent virtual
machine app) is running the .image file, one uses the World Menu
(like clicking on the Smalltalk desktop background to bring up the menu,
this might be disabled in the scratch version) one can select the
Browser menu option to start the Hierarchal Browser (Smalltalk's Eclipse
IDE equivalent  running in the app). Edit the code in the Hierarchal
Browser with each method save,
automatically saves it in the .changes file. Everything else automatically
gets save when the .image is saved from within the Smalltalk running
environment. This means you can't use your favorite text editor to edit
Smalltalk code. One must use the built-in Hierarchal Browser. However,
all the source code for running the Hierarchal Browser is in the Hierarchal
Browser itself, so you can edit the behavior of the IDE any way you like to add
your favorite IDE features ... in real time.

It's all one running app. There's no separate programs for the IDE or
viewing graphics or editing text or playing music or animating a game.
It's all one app, running in one memory space. So, every "application"
can see every other "applications" classes, instances, and field values.
A Vulcan mind meld of all applications into each other. That's Smalltalk.

Does this help?

Cheers,
Darius
_________________

On Fri, Jun 21, 2013 at 4:57 AM, Azka Niazi <[hidden email]>
 wrote: Thanks for the feedback Ron and Chris, but I have some
more questions now.

1. I am sorry I didn't fully understand what did you mean by "act as storage
space for the code you write in Smalltalk". Also please specify whether by
Smalltalk you meant Smalltalk-80 (i.e. Squeak) or did you mean Smalltalk
only. As in is there a custom to refer to Squeak as Smalltalk. Doesn't it
create am