[Cuis-dev] new YouTube video on Cuis Smalltalk

[ken.dickey at whidbey.com]

On 2024-06-23 01:19, Jaromir Matas via Cuis-dev wrote:

>> Juan explains Smalltalk and Cuis from first principles, with 
>> historical context and highlighting perspectives
> 
> I'm not sure I understand the part about "knowledge" though: "Write, 
> describe, communicate knowledge" - what does it mean exactly? Is it 
> about Smalltalk as a language? The language itself is not that 
> different from other (high-level) languages. A good language certainly 
> is a great help to formulate things but it's still a "programming 
> language". I guess there more to it I didn't get :)

I think of the development of Entity-Relation databases plus Ontology 
plus simulation plus human/computer interaction, all of which was 
happening at this time.  Smalltalk-80 is a well-grounded simplification 
which works.

https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
https://en.wikipedia.org/wiki/Ontology_(information_science)

> Other question - Smalltalk was originally supposed to be the universal 
> environment above the hardware level. Everything below the VM is the 
> hardware (a machine language), everything above the VM is Smalltalk 
> (the UI, apps...). Even the VM is written in a simplified Smalltalk 
> (Slang); what was supposed to be the role of C - to stay as an 
> intermediary between the Smalltalk level and the hardware or was (is?) 
> it supposed to be eliminated somehow eventually?

That depends on your psychology, goals, and pragmatics.

The Squeak folks noted Scheme48, which is/was a Scheme written in Scheme 
which compiled to C and had decent performance on computers of the day 
-- so they knew it could be done.

https://www.s48.org/

Bee Smalltalk does direct to machine code.  CogNos does direct to 
machine.

Bee paper refs in 
https://github.com/KenDickey/BeeYourself/blob/main/README.md

https://github.com/nopsys/CogNOS

Personally, my pragmatics follow Juan.  Use the things that exist where 
one has no interest. In my case I have little interest in writing device 
drivers for x86+arm64+RISCV64+..  My minimalist system is Alpine Linux 
and a Framebuffer (no Window system, but disk & network & minimal OS).

[This is why the OpenSmalltalk framebuffer works again now. ;^)
https://github.com/OpenSmalltalk/opensmalltalk-vm/tree/Cog/platforms/unix/vm-display-fbdev]

Where is your "value added"?  If you are doing disk fragmentation, you 
want direct access to disk drive hardware.  If not, use a File System!

HTH,
-KenD