Hi Edgar, Trygve, others, 

The idea(s) behind CodeParadise should probably [*] lead to a situation in
which developing code is based on a number of relative small Smalltalk
images. Each image small enough to 'understand'. One image for the
application you're developing. One for the development environment. One for
the user interface (running inside the browser). Etc. Separating the
development environment means I won't be 'seeing' Compiler or Inspector
classes when working on my application. IF I do want to add or change a
feature of the development environment, I'll open a Browser on that
development image and change things there. Being able to change the full
environment (consisting of multiple images) should still be possible and
effective directly (Smalltalk design principles). Currently I'm mostly busy
realising/implementing the tiny image inside the browser (because it is a
difficult nut I'd like to crack first). I have chosen Pharo8 as my current
development environment, but it should be replaced by my own environment
because of the exact bloat Trygve and others refer to. I love Pharo,
Squeak(JS) and Cuis. All have their strengths.

I'm scheduled for a presentation about this 26th of August on the UK
Smalltalk user group (19hrs UK time). Please join if you're interested to
see and talk about this. 

(This part is not well thought out yet, but I'd like to have something like
this for CodeParadise:) 
If you need for example storage you'll probably have another image, somewhat
similar to applying a Microservice pattern. These services will not process
data (i.e. not your typical REST api), but process objects. These services
will at startup not contain the classes/methods of your (business) objects.
This also holds for the current tiny image in the browser. It does not
contain any code (classes and methods) for views/presenters. All this code
is added to the image/service when needed. This allows (but also requires)
more independent 'components'. This could lead to specifically compile time
configured services or more 'dynamic' services which are 'provisioned' at
runtime. 

So the idea I have is to move away from the traditional single (Smalltalk)
image philosophy. 

@Trygve, thanks for all your nice work. Hope you're doing well. My
description above is not the same as what you describe, but it feels like it
could have a similar end result (if I understand you correctly). 
Still so much to do...so I won't be offering a solution anytime soon. Wish I
could... 

[*] Things are still in early development and I haven't thought out all the
details yet. Some things might not work when theory meets practice ;-). 

Cheers, 
Erik 




--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html