[Cuis-dev] Cuis, Dynabooks, Teaching and Learning (was Re: Haver a Cuis based Smalltalk with Modules)

Gerald Klix cuis.01 at klix.ch
Fri Apr 30 13:43:55 PDT 2021


Hi Juan,

wow! See below...

On 2021-04-30 15:50, Juan Vuletich via Cuis-dev wrote:
> Hi Hilaire, Folks,
> 
> On 4/29/2021 4:52 PM, Hilaire Fernandes via Cuis-dev wrote:
>>
>> Hi Gerald,
>>
>> From my point of view of a high school teacher, after porting DrGeo to 
>> Cuis, I want to explore a reinterpretation of the Dynabook concept 
>> from both the teachers and students point of view.
>>
> 
> After stabilizing VectorGraphics, I also want to explore the 
> possibilities to build a "real Dynabook".  I have been wanting to do 
> that for a long time. My focus is on Open Science / Reproducible 
> Research, and in general the pov of researchers and students. I think a 
> good Dynabook could be a great alternative to scientific papers. I don't 
> think this use is in conflict with teaching and learning at any age 
> level. I hope we can collaborate in this adventure, and I'm sure we can 
> share ideas and have useful discussion.

That got me really thinking.
I once had similar dreams.

Haver has less far reaching goals, I just want some means to create and 
distribute portable
applications with seamless support for
orthogonal persistence.

The most far reaching idea is
to distribute packages and complete
applications (images) by a peer to peer
network, something like IPFS
(https://en.wikipedia.org/wiki/InterPlanetary_File_System).

If I think about the "requirements" of your
idea:

- Knowledge should be represented as Code
- Inexperienced pupils should be able to
   manipulate Code/Knowledge

therefore:

- An even simpler editor

   A really simple editor, something like
   Scratch/Blocky, however without the huge
   gap between a text editor and the blocks
   editor.
   With your VectorGraphics package,
   this will be great fun.

- Much easier recovery from mistakes.
   The current image, change-log,
   file-your-code-into-a-clean-image rigamarole
   is much to complicated.

   I don't know whether this can be solved with a
   database and transactions. Perhaps we need
   something like Python's virtual environments.
   Maybe a pack of Smalltalk images that are
   controlled from a master image; e.g. automate
   the aforementioned procedure.

- Runaway recursions should also be caught,
   be before virtual memory is exhausted.

- Debugging the code the runs in the UI-Process
   should be easy. Remote debugging a dependent
   image? A separate UI-Process that draws in a
   PasteUpMorph?

- A suitable system for interactive
   development/teaching.

- An easy interface to version control.
   GIT is a nightmare for newbies.
   (I still prefer mercurial and, believe me,
   the first Source Code Control System I used in
   my life was SCCS ...)
   I has to have the feeling of the undo function
   in MS Office.

- A simpler module system than mine,
   for this use case explicit imports are
   probably best.

*We need funding, this looks like a big project*

Just my sundry thoughts.

> 
>> Among other things, it means to imagine and to conceive knowledge 
>> model for various taught domains (as DrGeo is for geometry).
>>
> 
> Great. I love the words "to conceive knowledge models". I think that as 
> we discover what they mean, and how to do it in general (a great 
> philosophical question!), we must build examples the best we can, as you 
> have been doing with DrGeo.
> As a first example, I would like to focus on Signal Processing 
> (including audio and images). I want to start by building introductory 
> college level material, always keeping an eye on scientific papers too.
That would be great, that's a domain I know
nothing.

BTW: Isn't Jupyter a valuable tool for this
purpose? I never used it, I just want to know
the opinion of some one more experienced.

> 
>> Module may be a handy things to avoid collision between independently 
>> developed knowledge model.

>>
> 
> Indeed an idea to consider.
> 
>> Draft thought
>>
>> Hilaire
>>
>> -- 
>> GNU Dr. Geo
>> http://drgeo.eu
>> http://blog.drgeo.eu
> 
> Thanks,
> 
> 

Best Regards,

Gerald


More information about the Cuis-dev mailing list