Contents:
BareMetal | The Genius of RISC-V Microprocessors
ZokuTalk Design | Squeak, Pharo, COG, ... vs The ZokuTalk Execution Engine
ZokuTalk WalkAndTalk | 20221209 Building A Sustainable Installed App Base
BareMetal | Kinds of Computers: CPU, GPU, AI
"If Smalltalk is so great why are we not all using it?"
MountainWest RubyConf 2014 - But Really, You Should Learn Smalltalk
Idempotence, a Safe Parallel Key Feature for ZokuTalk While Respecting Object & Data State Changes
Dead Programs Are Spooky Boo Zombies
Smalltalk: Getting started with the language
BareMetal | X64 | AMD Zen 4 7950X 8/16 Core Processors with AM5 Socket, X670e, PCIe5, DDR5
Fast and Dynamic
From Smalltalk to Squeak by Dan Ingalls
"Liberating the Smalltalk lurking in C and Unix"
A Canticle for Smalltalk
Brain Upgrade Going Well
Smalltalk Blocks and Closures
ZokuTalk
On Messaging, Objects, Encapsulation, Late Binding, & Idempotence
Smalltalk Systems
Components
Contribute
Legacy Smalltalk.org Articles at Archive.org
BareMetal | The Genius of RISC-V Microprocessors
ZokuTalk Design | Squeak, Pharo, COG, ... vs The ZokuTalk Execution Engine
ZokuTalk WalkAndTalk | 20221209 Building A Sustainable Installed App Base
BareMetal | Kinds of Computers: CPU, GPU, AI
"If Smalltalk is so great why are we not all using it?"
MountainWest RubyConf 2014 - But Really, You Should Learn Smalltalk
Idempotence, a Safe Parallel Key Feature for ZokuTalk While Respecting Object & Data State Changes
Dead Programs Are Spooky Boo Zombies
Smalltalk: Getting started with the language
BareMetal | X64 | AMD Zen 4 7950X 8/16 Core Processors with AM5 Socket, X670e, PCIe5, DDR5
Fast and Dynamic
From Smalltalk to Squeak by Dan Ingalls
"Liberating the Smalltalk lurking in C and Unix"
A Canticle for Smalltalk
Brain Upgrade Going Well
Smalltalk Blocks and Closures
ZokuTalk
On Messaging, Objects, Encapsulation, Late Binding, & Idempotence
Smalltalk Systems
Components
Contribute
Legacy Smalltalk.org Articles at Archive.org
[Article
series: ⁅ BareMetal Processor Series ⁆
title: ⁅ BareMetal | The Genius of Risc-V Microprocessors ⁆
by: ⁅ Peter Lount ⁆
videoBy: ⁅ Erik Engheim at ACCU 2022 Conference ⁆
date: ⁅ 20230110, 20230117 ⁆
circa: ⁅ 20220714⁆
version: ⁅ v0004 ⁆
discussOn: (Discuss).
⁅
⁅ From single core IoT embedded Risc-V core chips to Super Computers in one or more 42U by 19" Racks with 300,000+ Cores per Rack and everywhere inbetween! The Brilliant design of Open Souced Risc-V Architecture design! The Future of Smalltalk-80+ Descendant Systems and ZokuTalk as well!
"This talk about Risc-V microprocessors, so I just talked about the word here genius, so it doesn't mean quantum mechanics or theory relativity of that kind of smarts there's nothing in Risc-V there isn't anything that's fundamentally new and super clever so this is more about the kind of things when you you look at a small piece of code and you think maybe it doesn't do anything revolutionary new but you're thinking wow that's kind of very clever or smart way of doing this thing it's a very neat way of doing it and that's a lot of what i feel when um looking at how risk five has been put together it's a lot of existing ideas that exist but they've been put together in in a kind of a clever way a smart way that sort of um can be impressive." - Erik Engheim.
Risc-V: "Impressive, most impressive." - Darth Vader
ZokuTalk development is being targeted at current real existing #BareMetal processors (#NoBCVM, #NoByteCodes, to access the #FullPowerOfTheMachine, with #OS or #NoOS) such as X64, ARM64 and Risc-V64 with 32 bit versions comming after, as well as some possible future architectures when their chips are available for development or on the market. The goal is hit N Billion Devices running ZokuTalk Applications! That is doable with Windows, MacOSX, iOS, Android, Linux, *BSD, RaspberryPI and other large installed volume operating systems!
For other Smalltalk-80 descentant systems such as Squeak, and Pharo that use the legacy COG ByteCode VM architecture as well as commercial Smalltalk-80 desendant systems you need to check with their particular version.⁆
⁅
[ Video
⁅There are many versions of the Risc-V chip fro a small System-On-a-Chip (SOC) to massive chips with over 1092 cores for doing massive compute work with low energy such as for Robotic or other AI applications! How much compute power do you need to run ChatGPT along with ZokuTalk?⁆.
⁅
⁅While all the Ricv-V chips are a target for ZokuTalk the Esperanto ET-SOC-1 chip is of special interest for proving ZokuTalk's Massive Safe Parrellel computational Execution Engine!⁆
⁅
⁅Wow! 1088x parallel compute cores + 4x OS host cores! That is what ZokuTalk is designed for, running this bad boy to the max! We have come a long way from the Transputer, Tilera or Parallel Boards!
For example take an OrderedCollection with a million accounts and send it #doInParallel: distributing the accounting work load to this set of 1088 cores! Wow, get it done fast!
The Esperanto ET-SOC-1 chip has 24 Billons transistors with 1088x ET-Minion 64-bit Risc-V cores in-order cores with a vector unit plus 4x ET-Maxion 64-bit Risc-V out-of-order cores! An AI Inference engine matrix GPU. no doubt this chip will see many upgrades such as the number of cores and the PCIe 5 and 6 specs which will increase the DRAM speeds to DDR5 and beyond. Massive memories as fast as possible are what ZokuTalk requires for massive performance. I of course would love to start with the development board with mutliple Esperanto ET-SOC-1 chips as show in the video!
"Esperanto ET-SOC-1 features:
(1) 1088x energy-efficient ET-Minion 64-bit RISC-V in-order cores, each with a custom vector/tensor unit optimized for ML applications; (2) 4x high-performance ET-Maxion 64-bit RISC-V out-of-order cores for running an OS in self-hosted mode;
(3) Over 160 million bytes of on-chip SRAM;
(4) Interfaces for large external memory with low-power LPDDR4x DRAM and eMMC FLASH; (5) PCIe Gen4 x8 and other common I/O interfaces.
The video goes into much more depth about the slices taken from the video.⁆.
⁅
⁅
⁅
⁅
[ Video
].
[ Video
].
[ Video
].
[ Video
[ Video
].
⁅
⁅3 Cent Single Core IoT Chip 32-bit general-purpose RISC-V MCU-CH32V003 ⁆.
⁅
series: ⁅ BareMetal Processor Series ⁆
title: ⁅ BareMetal | The Genius of Risc-V Microprocessors ⁆
by: ⁅ Peter Lount ⁆
videoBy: ⁅ Erik Engheim at ACCU 2022 Conference ⁆
date: ⁅ 20230110, 20230117 ⁆
circa: ⁅ 20220714⁆
version: ⁅ v0004 ⁆
discussOn: (Discuss).
⁅
⁅ From single core IoT embedded Risc-V core chips to Super Computers in one or more 42U by 19" Racks with 300,000+ Cores per Rack and everywhere inbetween! The Brilliant design of Open Souced Risc-V Architecture design! The Future of Smalltalk-80+ Descendant Systems and ZokuTalk as well!
"This talk about Risc-V microprocessors, so I just talked about the word here genius, so it doesn't mean quantum mechanics or theory relativity of that kind of smarts there's nothing in Risc-V there isn't anything that's fundamentally new and super clever so this is more about the kind of things when you you look at a small piece of code and you think maybe it doesn't do anything revolutionary new but you're thinking wow that's kind of very clever or smart way of doing this thing it's a very neat way of doing it and that's a lot of what i feel when um looking at how risk five has been put together it's a lot of existing ideas that exist but they've been put together in in a kind of a clever way a smart way that sort of um can be impressive." - Erik Engheim.
ZokuTalk development is being targeted at current real existing #BareMetal processors (#NoBCVM, #NoByteCodes, to access the #FullPowerOfTheMachine, with #OS or #NoOS) such as X64, ARM64 and Risc-V64 with 32 bit versions comming after, as well as some possible future architectures when their chips are available for development or on the market. The goal is hit N Billion Devices running ZokuTalk Applications! That is doable with Windows, MacOSX, iOS, Android, Linux, *BSD, RaspberryPI and other large installed volume operating systems!
For other Smalltalk-80 descentant systems such as Squeak, and Pharo that use the legacy COG ByteCode VM architecture as well as commercial Smalltalk-80 desendant systems you need to check with their particular version.⁆
⁅
[ Video
title: ⁅ The Genius of RISC-V Microprocessors ⁆.
⁅There are many versions of the Risc-V chip fro a small System-On-a-Chip (SOC) to massive chips with over 1092 cores for doing massive compute work with low energy such as for Robotic or other AI applications! How much compute power do you need to run ChatGPT along with ZokuTalk?⁆.
⁅
⁅While all the Ricv-V chips are a target for ZokuTalk the Esperanto ET-SOC-1 chip is of special interest for proving ZokuTalk's Massive Safe Parrellel computational Execution Engine!⁆
⁅
⁅Wow! 1088x parallel compute cores + 4x OS host cores! That is what ZokuTalk is designed for, running this bad boy to the max! We have come a long way from the Transputer, Tilera or Parallel Boards!
For example take an OrderedCollection with a million accounts and send it #doInParallel: distributing the accounting work load to this set of 1088 cores! Wow, get it done fast!
The Esperanto ET-SOC-1 chip has 24 Billons transistors with 1088x ET-Minion 64-bit Risc-V cores in-order cores with a vector unit plus 4x ET-Maxion 64-bit Risc-V out-of-order cores! An AI Inference engine matrix GPU. no doubt this chip will see many upgrades such as the number of cores and the PCIe 5 and 6 specs which will increase the DRAM speeds to DDR5 and beyond. Massive memories as fast as possible are what ZokuTalk requires for massive performance. I of course would love to start with the development board with mutliple Esperanto ET-SOC-1 chips as show in the video!
"Esperanto ET-SOC-1 features:
(1) 1088x energy-efficient ET-Minion 64-bit RISC-V in-order cores, each with a custom vector/tensor unit optimized for ML applications; (2) 4x high-performance ET-Maxion 64-bit RISC-V out-of-order cores for running an OS in self-hosted mode;
(3) Over 160 million bytes of on-chip SRAM;
(4) Interfaces for large external memory with low-power LPDDR4x DRAM and eMMC FLASH; (5) PCIe Gen4 x8 and other common I/O interfaces.
The video goes into much more depth about the slices taken from the video.⁆.
⁅
⁅
⁅
⁅
[ Video
title: ⁅ RISC-V is the future of computing | Chris Lattner and Lex Fridman ⁆.
[ Video
title: ⁅RISC-V Chips will be everywhere ⁆.
[ Video
title: ⁅MeganWachs - Keynote RISC-V and FPGAs: Open Source Hardware Hacking ⁆.
[ Video
title: ⁅ RISC-V: How much is open source? Featuring the new ESP32-C3 ⁆.
[ Video
title: ⁅EEVblog 1524 - The 10 CENT RISC V Processor! CH32V003 ⁆.
description: ⁅";Checking out the new 10 cent WCH CH32V003 48MHz RISC V [single core IoT chip] processor demo board and the MounRiver Eclipse IDE. Getting to blinky. The CH32V003 is a pin-for-pin alternative to the [ARM based] STM8S003 at 1/3rd the price, with more features."⁆
description: ⁅";Checking out the new 10 cent WCH CH32V003 48MHz RISC V [single core IoT chip] processor demo board and the MounRiver Eclipse IDE. Getting to blinky. The CH32V003 is a pin-for-pin alternative to the [ARM based] STM8S003 at 1/3rd the price, with more features."⁆
⁅
⁅
[Article
series: ⁅ZokuTalk Design⁆
title: ⁅ZokuTalk Design | Squeak, Pharo, COG, ... vs The ZokuTalk Execution Engine⁆
by: ⁅Peter Lount⁆
date: ⁅20230107⁆
version: ⁅v0013⁆
tags: ⁅#ZokuTalk. #DesignDecisions⁆.
⁅Been trying out the latest Squeak 6 and it looks pretty nice as they appear to really have improved it from the primary kid only focused system. Have been using Pharo since Squeak 3.5 or so as it was better being focused on serious work. In some ways the latest Squeak 6 is well packaged better than the Pharo 10, which is a bit broken (needs to be cleaned up).
In any event the entire Squeak 1-6+ and Pharo 1-10+ class libraries will be absorbed, analyzed, classified, categorized and each class (or package) will be considered, as well as the Procedural COG Virtual Machine versions, potential for reuse. At some point in time a fork from a fractured Squeak and a fractured Pharo for the best of those legacy systems will occrur once the analysis, which has started, is complete.
However COG is procedural and thus is not up to snuff as all the elements of the ZokuTalk Meta Execution Engine which is not a bytecode VM as it must a be Fully Meta First Class Message Passing with Objects using Reified expanded MOBS-ZT Syntax! For objects to be first class everything must be and use the Full Powers of message passing objects with blocks as per Alan Kay's vision!
Yes COG is still using obsolete procedural ByteCode VM technology, sure it is a very good system indeed and works well for ST-80+ descentant languages, no doubt. I will likely use COG for running on Smalltalk dot org using Squeak and/or Pharo until I get a ZokuTalk variant up and running.
The Meta capabilities of ZokuTalk are required to be message passing object oriented not procedural as with COG! Just as there are benefits of regular programs being message passing object oriented there are benefits of the Full Meta Execution Engine (not a byte code VM) for ZokuTalk being Fully message passing object oriented!.
It is MOBS-ZT all the way down to the BareMetal (#NoBCVM, #NoByteCodes, #FullPowerOfTheMachine, with #OS or #NoOS) of the processor (X64, ARM-64, Risc-V64, and later 32 bits)!
MOBS-ZT: Messages and expanded methods, Objects and data, Block Closures and other scoped brackets, extended Syntax (MOBS-ZT).⁆.
⁅
⁅MOBS-ST-80+ is the more limited MOBS grammar set inherited from and used by Smalltalk-80 descendant languages. Byte Code Virual Machines for computer languages are hampered by the VM, such as COG, as they neglect most of the machine capabilities by using simplistic byte codes; that is a small subset of possible machines instructions, sure they work but today's processors are far more capable than just being limited to a small set of byte codes to simulate.
Rumors have it that it is Turtles all the way down, nope! It is ZokuTalk Full Execution Engine's using Full MOBS-ZT Syntax (Messages, Objects, Blocks, Syntax) all the way down to the BareMetal of the processor (#NoVM, #NoByteCodes, #OS, #NoOS) with Full use and Power of the native assembly language!
In other words every component of the execution engine is a live object passing messages with meta capabilities and all the capabilities of the general purpose programming syntax of Messages, Objects and data, Block scopes, Syntax (MOBS-ZokuTalk).
It makes a difference because much of the magic of ZokuTalk happens at the Execution Engine and that is what makes it different from the existing all the other Smalltalk-80+ descendant systems such as Squeak, Pharo, etc, where they have only shallow similarity that extends to part of the their limited MOBS-ST-80+ legacy syntax. ZokuTalk inherits the ZokuTalk Full MOBS-ZT Syntax (including parts that are still relevant MOBS-ST-80+ and exjecting some legacy syntax such as antiquated primitve, file out, etc... syntax) and has the Full Meta Execution Engine for that special Safe Parallel Magic!
ZokuTalk provides a Uniform Safe Parallel Fault Tolerant Distributed Computational Model and Environment scaling from one native OS thread to T OS-Threads runnng in one OS-Process to running in P OS-Processes running on one Compute-Box-Server to being distributed across D Compute-Box-Servers where T OS-Threads, P OS-Processes, and D Compute-Box-Servers are large integers from one to very large integers indeed.
The only practical limits are hard OS limits on number of: (1) threads typical OS Limits in the man thosans or more and which can be transparently mitigated with fallback to green threads, more than one green thread on an actual OS-Thread, dynamically; (2) processes limits on a Compute-Box-Server or OS typically in the many thousands or more; (3) and, due to how many Compute-Box-Servers you can obtain or your ability to share accross the network considering your network security issues or how big a private cluster you can construct.
While the ZokuTalk Uniform Safe Parallel Fault Tolerant Distributed Computational Model and Environment does impose a set of contraints to ensure safe parallel fault tolerant computing it is really the number of CPU cores/threads, DRAM sizes, hard drives, number of compute-boxes and of course bandwidth that are always the practical hard limits in reality that will limit a real project.
Yes there are limits depending the computational resources you have access to. The ability to compute in parallel safely and easily, for the majority of users and programmers, provides a major win!
Another hard limit has to do with the Theory and Limits of Serial and Parallel Compution and unless one uses or of comes up with other algorithms one can't beat the inherent nature of Serial|Parallel|Serial|Parallel|Serial|Parallel|Serial|Parallel|Serial|... ordering of steps inherent in the order of computations. Hey I guess that is what Map+Reduce attempts to do, violate the laws of computational physics. lol? Innovative algorithms fpr splitting up work loads will always be needed!
In summary, ZokuTalk uses real message passing between objects underneath the Meta Execution Engine making this Meta Level Entirely First Class Message Passing with Objects with Full-MOBS-ZT. It does so without using VM-Byte-Codes so that every capability of the Bare Metal of the particular machine can be taken advantage of to the max!
ZokuTalk has solved the inherent parallel unit of work multithreading problem that every Smalltalk system has ever had and ZokuTalk can do so safely with the ZokuTalk Uniform Safe Parallel Fault Tolerant Distributed Computational Model and Environment! Yes we can also do so with a minimum of rewriting system and applications code, for example thread safety, in most cases, is orthogonal to existing Smalltalk-80 style such as objects, collections, and other most objects in the class library. Yes you read that correctly, most collections and object classes can be used in parallel safely without rewriting with this appoach! This means that most applications can be rewritten into parallel and/or distributed thread safe versions while minimizing the effort. The unit of work protects parallel data integrity. Some other approaches are needed for some applications cases of course!
This approach requires actual first class objects and messages within the ZokuTalk Meta Execution Engine to provide the ZokuTalk Uniform Safe Parallel Fault Tolerant Distributed Computational Model and Environment! A uniform design from the top to the baremetal of the machine!
Towards this purpose the burning of the disk packs progresses, aka burning down the COG Byte Code VM, to create the ZokuTalk Meta Execution Engine, for particular reasons some of which are mentioned in this article! In addition ZokuTalk appears to much closer to Alan Kay's vision described above in the quote/meme and below in detailed paraphrased summary:
⁅
⁅"As Korzybski and others before him have pointed out, we are doomed by nature to deal with the world via mere beliefs that just can't be in accord with "what's out there?". We are all delusional, and by rights should consider ourselves and others as "crazy" -- that's a good place to start in trying to better "see" the world (and it's where science starts)." - Alan Kay quoting A. Korzybski.
Fortunately via computer science we can conceive of worlds where things can be much simplier than full objective reality and where we can get much closer to our idealized worlds. ZokuTalk is such an idealized practical realizeable world with the ZokuTalk Uniform Safe Parallel Fault Tolerant Distributed Computational Model and Environment that provides mechanisms, policies and systems that enforce a set of constraints to ensure a consistent objective reality simulation is provided with the desired outcomes of safe parallel fault tolerant computation across one or more compute devices.
ZokuTalk is a major breakthrough in computer languages.
To quote Elon Musk on a more complex ambitious endevor, "... success is one of the possible outcomes, which I always think is, when embarking on an endeavor success should at least be one of the possible outcomes. And for this design that is the case." - https://www.youtube.com/watch?v=XxcWX8vKvfs&t=736s.
All the best,
Peter Lount
Hard Core System Design & Implementation
Real World Applications
SLS, BRS, AIC, http://Zoku.com
⁆.
].
Contents
series: ⁅ZokuTalk Design⁆
title: ⁅ZokuTalk Design | Squeak, Pharo, COG, ... vs The ZokuTalk Execution Engine⁆
by: ⁅Peter Lount⁆
date: ⁅20230107⁆
version: ⁅v0013⁆
tags: ⁅#ZokuTalk. #DesignDecisions⁆.
⁅Been trying out the latest Squeak 6 and it looks pretty nice as they appear to really have improved it from the primary kid only focused system. Have been using Pharo since Squeak 3.5 or so as it was better being focused on serious work. In some ways the latest Squeak 6 is well packaged better than the Pharo 10, which is a bit broken (needs to be cleaned up).
In any event the entire Squeak 1-6+ and Pharo 1-10+ class libraries will be absorbed, analyzed, classified, categorized and each class (or package) will be considered, as well as the Procedural COG Virtual Machine versions, potential for reuse. At some point in time a fork from a fractured Squeak and a fractured Pharo for the best of those legacy systems will occrur once the analysis, which has started, is complete.
However COG is procedural and thus is not up to snuff as all the elements of the ZokuTalk Meta Execution Engine which is not a bytecode VM as it must a be Fully Meta First Class Message Passing with Objects using Reified expanded MOBS-ZT Syntax! For objects to be first class everything must be and use the Full Powers of message passing objects with blocks as per Alan Kay's vision!
Yes COG is still using obsolete procedural ByteCode VM technology, sure it is a very good system indeed and works well for ST-80+ descentant languages, no doubt. I will likely use COG for running on Smalltalk dot org using Squeak and/or Pharo until I get a ZokuTalk variant up and running.
The Meta capabilities of ZokuTalk are required to be message passing object oriented not procedural as with COG! Just as there are benefits of regular programs being message passing object oriented there are benefits of the Full Meta Execution Engine (not a byte code VM) for ZokuTalk being Fully message passing object oriented!.
It is MOBS-ZT all the way down to the BareMetal (#NoBCVM, #NoByteCodes, #FullPowerOfTheMachine, with #OS or #NoOS) of the processor (X64, ARM-64, Risc-V64, and later 32 bits)!
MOBS-ZT: Messages and expanded methods, Objects and data, Block Closures and other scoped brackets, extended Syntax (MOBS-ZT).⁆.
⁅
⁅MOBS-ST-80+ is the more limited MOBS grammar set inherited from and used by Smalltalk-80 descendant languages. Byte Code Virual Machines for computer languages are hampered by the VM, such as COG, as they neglect most of the machine capabilities by using simplistic byte codes; that is a small subset of possible machines instructions, sure they work but today's processors are far more capable than just being limited to a small set of byte codes to simulate.
Rumors have it that it is Turtles all the way down, nope! It is ZokuTalk Full Execution Engine's using Full MOBS-ZT Syntax (Messages, Objects, Blocks, Syntax) all the way down to the BareMetal of the processor (#NoVM, #NoByteCodes, #OS, #NoOS) with Full use and Power of the native assembly language!
In other words every component of the execution engine is a live object passing messages with meta capabilities and all the capabilities of the general purpose programming syntax of Messages, Objects and data, Block scopes, Syntax (MOBS-ZokuTalk).
It makes a difference because much of the magic of ZokuTalk happens at the Execution Engine and that is what makes it different from the existing all the other Smalltalk-80+ descendant systems such as Squeak, Pharo, etc, where they have only shallow similarity that extends to part of the their limited MOBS-ST-80+ legacy syntax. ZokuTalk inherits the ZokuTalk Full MOBS-ZT Syntax (including parts that are still relevant MOBS-ST-80+ and exjecting some legacy syntax such as antiquated primitve, file out, etc... syntax) and has the Full Meta Execution Engine for that special Safe Parallel Magic!
ZokuTalk provides a Uniform Safe Parallel Fault Tolerant Distributed Computational Model and Environment scaling from one native OS thread to T OS-Threads runnng in one OS-Process to running in P OS-Processes running on one Compute-Box-Server to being distributed across D Compute-Box-Servers where T OS-Threads, P OS-Processes, and D Compute-Box-Servers are large integers from one to very large integers indeed.
The only practical limits are hard OS limits on number of: (1) threads typical OS Limits in the man thosans or more and which can be transparently mitigated with fallback to green threads, more than one green thread on an actual OS-Thread, dynamically; (2) processes limits on a Compute-Box-Server or OS typically in the many thousands or more; (3) and, due to how many Compute-Box-Servers you can obtain or your ability to share accross the network considering your network security issues or how big a private cluster you can construct.
While the ZokuTalk Uniform Safe Parallel Fault Tolerant Distributed Computational Model and Environment does impose a set of contraints to ensure safe parallel fault tolerant computing it is really the number of CPU cores/threads, DRAM sizes, hard drives, number of compute-boxes and of course bandwidth that are always the practical hard limits in reality that will limit a real project.
Yes there are limits depending the computational resources you have access to. The ability to compute in parallel safely and easily, for the majority of users and programmers, provides a major win!
Another hard limit has to do with the Theory and Limits of Serial and Parallel Compution and unless one uses or of comes up with other algorithms one can't beat the inherent nature of Serial|Parallel|Serial|Parallel|Serial|Parallel|Serial|Parallel|Serial|... ordering of steps inherent in the order of computations. Hey I guess that is what Map+Reduce attempts to do, violate the laws of computational physics. lol? Innovative algorithms fpr splitting up work loads will always be needed!
In summary, ZokuTalk uses real message passing between objects underneath the Meta Execution Engine making this Meta Level Entirely First Class Message Passing with Objects with Full-MOBS-ZT. It does so without using VM-Byte-Codes so that every capability of the Bare Metal of the particular machine can be taken advantage of to the max!
ZokuTalk has solved the inherent parallel unit of work multithreading problem that every Smalltalk system has ever had and ZokuTalk can do so safely with the ZokuTalk Uniform Safe Parallel Fault Tolerant Distributed Computational Model and Environment! Yes we can also do so with a minimum of rewriting system and applications code, for example thread safety, in most cases, is orthogonal to existing Smalltalk-80 style such as objects, collections, and other most objects in the class library. Yes you read that correctly, most collections and object classes can be used in parallel safely without rewriting with this appoach! This means that most applications can be rewritten into parallel and/or distributed thread safe versions while minimizing the effort. The unit of work protects parallel data integrity. Some other approaches are needed for some applications cases of course!
This approach requires actual first class objects and messages within the ZokuTalk Meta Execution Engine to provide the ZokuTalk Uniform Safe Parallel Fault Tolerant Distributed Computational Model and Environment! A uniform design from the top to the baremetal of the machine!
Towards this purpose the burning of the disk packs progresses, aka burning down the COG Byte Code VM, to create the ZokuTalk Meta Execution Engine, for particular reasons some of which are mentioned in this article! In addition ZokuTalk appears to much closer to Alan Kay's vision described above in the quote/meme and below in detailed paraphrased summary:
Object-Oriented Programming or Message-Object-Oriented-Programming with more and more details:
In other words:
Objects are reified (made real) as:
⁆.
1) messaging;
2) (local retention, protection, and hiding) of state-process;
3) extreme late-binding of all things."
2) (local retention, protection, and hiding) of state-process;
3) extreme late-binding of all things."
In other words:
1) message passing is signalling between objects including oneself, the only way work gets done;
2) local retention is storing "state" locally;
3) protection is requiring the accessing of internal state of an object via messages;
4) encapsulation is information hiding and accessing via messages;
5) "state-process" is the thread of execution.
2) local retention is storing "state" locally;
3) protection is requiring the accessing of internal state of an object via messages;
4) encapsulation is information hiding and accessing via messages;
5) "state-process" is the thread of execution.
Objects are reified (made real) as:
(1) memory for state, with various layouts;
(2) methods for accessing to set or retrieve state via messages or performing computations;
(3) a thread of execution with the CPU that enables the processor to alter the state, retrieve, or set the state, perform computations, as well as send and receive messages;
(4) a unit of work permits a series of steps to be done in sequence as a part of a coherent protected atomic whole, the unit of work protects parallel data integrity.
(2) methods for accessing to set or retrieve state via messages or performing computations;
(3) a thread of execution with the CPU that enables the processor to alter the state, retrieve, or set the state, perform computations, as well as send and receive messages;
(4) a unit of work permits a series of steps to be done in sequence as a part of a coherent protected atomic whole, the unit of work protects parallel data integrity.
⁅
⁅"As Korzybski and others before him have pointed out, we are doomed by nature to deal with the world via mere beliefs that just can't be in accord with "what's out there?". We are all delusional, and by rights should consider ourselves and others as "crazy" -- that's a good place to start in trying to better "see" the world (and it's where science starts)." - Alan Kay quoting A. Korzybski.
Fortunately via computer science we can conceive of worlds where things can be much simplier than full objective reality and where we can get much closer to our idealized worlds. ZokuTalk is such an idealized practical realizeable world with the ZokuTalk Uniform Safe Parallel Fault Tolerant Distributed Computational Model and Environment that provides mechanisms, policies and systems that enforce a set of constraints to ensure a consistent objective reality simulation is provided with the desired outcomes of safe parallel fault tolerant computation across one or more compute devices.
ZokuTalk is a major breakthrough in computer languages.
To quote Elon Musk on a more complex ambitious endevor, "... success is one of the possible outcomes, which I always think is, when embarking on an endeavor success should at least be one of the possible outcomes. And for this design that is the case." - https://www.youtube.com/watch?v=XxcWX8vKvfs&t=736s.
All the best,
Peter Lount
Hard Core System Design & Implementation
Real World Applications
SLS, BRS, AIC, http://Zoku.com
⁆.
].
Contents
[Article
title: ⁅ZokuTalk WalkAndTalk | Building A Sustainable Installed App Base⁆
series: ⁅ZokuTalk WalkAndTalk⁆
by: ⁅Peter Lount⁆
videoAuthor: ⁅Peter Lount⁆
date: ⁅20221209, 20221214⁆
version: ⁅v0001⁆
tags: ⁅#ZokuTalk. #WalkAndTalk. #Applications.⁆
⁅In this video Peter explores ZokuTalk Walk & Talk Production Reality Targets, Possibility of Compiling using Zag Smalltalk notions might get the ZokuTalk Meta Execution Engine closer, etc, bonus W&T on NoteBooks + ZokuTalk 6+ Forms of Blocks.
You might find it useful to watch at 1.25% or 1.5% as I take time to consider my thoughts and words.⁆.
⁅
⁅A summary of aspects of some of the innovative ZokuTalk MOBS language enhancements so far, more coming.⁆.
⁅
].
Contents
title: ⁅ZokuTalk WalkAndTalk | Building A Sustainable Installed App Base⁆
series: ⁅ZokuTalk WalkAndTalk⁆
by: ⁅Peter Lount⁆
videoAuthor: ⁅Peter Lount⁆
date: ⁅20221209, 20221214⁆
version: ⁅v0001⁆
tags: ⁅#ZokuTalk. #WalkAndTalk. #Applications.⁆
⁅In this video Peter explores ZokuTalk Walk & Talk Production Reality Targets, Possibility of Compiling using Zag Smalltalk notions might get the ZokuTalk Meta Execution Engine closer, etc, bonus W&T on NoteBooks + ZokuTalk 6+ Forms of Blocks.
You might find it useful to watch at 1.25% or 1.5% as I take time to consider my thoughts and words.⁆.
⁅
⁅A summary of aspects of some of the innovative ZokuTalk MOBS language enhancements so far, more coming.⁆.
⁅
].
Contents
[Article
series: ⁅ BareMetal Processor Series ⁆
title: ⁅ BareMetal | Kinds of Computers: CPU, GPU, AI, & Divergent Processors ⁆
by: ⁅ Peter Lount ⁆
videosBy: ⁅ Dr Ian Cutress of Tech TechPotato, Jim Keller & Ljubisa Bajic ⁆
date: ⁅ 20221029-20221031 ⁆
circa: ⁅ 20210621, 20220907, 20220522 ⁆
version: ⁅ v0006 ⁆
discussOn: (Discuss).
⁅ ~"There are genuinely three kinds of BareMetal[1] computers! CPUs, GPUs, AI" - Jim Keller, [and Tensor TPUs, and AI Divergent Processors!]
CPUs Processors/Programs: ~"80% of execution is about 6 [assembly] instructions!:
GPUs Processors/Programs: ~"GPU guys will say look there is no branch predictor because we do every thing in parallel the chip has way more adders and subtractors and that is true if that is the problem you have but they are crap at running C programs! GPUs were built around shaders and pixels. ... thousands of threads... An army of ants crarrying around grains of sand! The shader problem is inherently small as there are so many pixels." - Jim Keller.
AI Processors/Programs: ~"Bigger Matrix Mutliplies and smaller number of threads that do a lots more math because the problem is inherently big!" - Jim Keller.
The fourth kind of computer (that is relevant for this article and Smalltalk-80 descendants⁆ is Divergent Processors using (300mm or larger) large waffer scale (or smaller chips) that can vary the mixture of CPU cores, GPU cores or AI cores (possibly TPU cores) on the same chip die! I know of one so far that is propostously very wide long word instruction words (really bit streams) that can bring together the transistor compute resources in 8-bit computing chunk units gluing them together for the type of computing and data flows that are needed; need an instruction that brings together maxtrix math with short Brain Integer or BFloat data cells but that also combines long 24 to 96 or more bit addresses for a computation space, and you can create custom - possibly higly parallel instrutions that correctly parallel flow the data from the on the fly transistor compute-memory-data-buses as needed resources, and in the next instruction that can be different! Both Smalltalk-80 descendant pure ZokuTalk™ MOBS™ (Messages, Objects & Data, Blocks Syntax) Messages based Object Oriented style programs "All The Way Down to The BareMetal[2] No Virtual Machine", Smalltalk-80 style virtual machine BareMetal[3] procedural & C-Style programs, GPUs stype massive pixel computations, or massive data intaking AI programs with many thousands of layers are all possible at the same time! Not to mention impressive Input/Output capacity, as the chip grows the communications grows in the third dimention!
Or combinations of any of these as well. ZokuTalk™ is being designed and is being implemented to keep up the the state of the art processors from all the top vendors (such as Apple, ARM, Intel, AMD, SiFive and many others first on 64 bits and then backtracking to 32 bits not mention the 128 bits of platentary scale server address spaces (e.g. Risc-v-128 Death Star); if and when the Divergent Propostously Very Long Bit-Stream Instruction Set Computing chip (excellent for CPU, GPU and AI processing word loads) comes out with motherbards and coputer boxes ZokuTalk will be there! ⁆.
[ Video
].
[
[
[Video
].
[Video
].
⁅ ZokuTalk is adopting AI in a major way. ZokuTalk will take years and it will transform the very nature of programming. ⁆
[Definiton
series: ⁅ BareMetal Processor Series ⁆
title: ⁅ BareMetal | Kinds of Computers: CPU, GPU, AI, & Divergent Processors ⁆
by: ⁅ Peter Lount ⁆
videosBy: ⁅ Dr Ian Cutress of Tech TechPotato, Jim Keller & Ljubisa Bajic ⁆
date: ⁅ 20221029-20221031 ⁆
circa: ⁅ 20210621, 20220907, 20220522 ⁆
version: ⁅ v0006 ⁆
discussOn: (Discuss).
⁅ ~"There are genuinely three kinds of BareMetal[1] computers! CPUs, GPUs, AI" - Jim Keller, [and Tensor TPUs, and AI Divergent Processors!]
CPUs Processors/Programs: ~"80% of execution is about 6 [assembly] instructions!:
(1) Load,
(2) Store,
(3) Add,
(4) Subtract,
(5) Compare,
(6) Branch! [and, sometimes]
(7) Call &,
(8) Return!
Instruction Sets (X64, ARM, Risc-V) only matter a little bit! .. What limits computer performance? The two big ones are instruction/branch-predictability and data locality." - Jim Keller.(2) Store,
(3) Add,
(4) Subtract,
(5) Compare,
(6) Branch! [and, sometimes]
(7) Call &,
(8) Return!
GPUs Processors/Programs: ~"GPU guys will say look there is no branch predictor because we do every thing in parallel the chip has way more adders and subtractors and that is true if that is the problem you have but they are crap at running C programs! GPUs were built around shaders and pixels. ... thousands of threads... An army of ants crarrying around grains of sand! The shader problem is inherently small as there are so many pixels." - Jim Keller.
AI Processors/Programs: ~"Bigger Matrix Mutliplies and smaller number of threads that do a lots more math because the problem is inherently big!" - Jim Keller.
The fourth kind of computer (that is relevant for this article and Smalltalk-80 descendants⁆ is Divergent Processors using (300mm or larger) large waffer scale (or smaller chips) that can vary the mixture of CPU cores, GPU cores or AI cores (possibly TPU cores) on the same chip die! I know of one so far that is propostously very wide long word instruction words (really bit streams) that can bring together the transistor compute resources in 8-bit computing chunk units gluing them together for the type of computing and data flows that are needed; need an instruction that brings together maxtrix math with short Brain Integer or BFloat data cells but that also combines long 24 to 96 or more bit addresses for a computation space, and you can create custom - possibly higly parallel instrutions that correctly parallel flow the data from the on the fly transistor compute-memory-data-buses as needed resources, and in the next instruction that can be different! Both Smalltalk-80 descendant pure ZokuTalk™ MOBS™ (Messages, Objects & Data, Blocks Syntax) Messages based Object Oriented style programs "All The Way Down to The BareMetal[2] No Virtual Machine", Smalltalk-80 style virtual machine BareMetal[3] procedural & C-Style programs, GPUs stype massive pixel computations, or massive data intaking AI programs with many thousands of layers are all possible at the same time! Not to mention impressive Input/Output capacity, as the chip grows the communications grows in the third dimention!
Or combinations of any of these as well. ZokuTalk™ is being designed and is being implemented to keep up the the state of the art processors from all the top vendors (such as Apple, ARM, Intel, AMD, SiFive and many others first on 64 bits and then backtracking to 32 bits not mention the 128 bits of platentary scale server address spaces (e.g. Risc-v-128 Death Star); if and when the Divergent Propostously Very Long Bit-Stream Instruction Set Computing chip (excellent for CPU, GPU and AI processing word loads) comes out with motherbards and coputer boxes ZokuTalk will be there! ⁆.
[ Video
title: ⁅ Jim Keller: Arm vs x86 vs RISC-V - Does it Matter? ⁆.
].
[
[
[Video
title: ⁅ Overclocking AI w/ Ljubisa Bajic and Jim Keller at Future Compute ⁆
description: ⁅ "We've hit a point where some of the bigger models out there are so big that the next step is just not on the horizon ... The way we chose to try to solve that problem is by making the computer machinery more intelligent as opposed to just bigger.
~"AI is so weird, a millewatt to ten megawatts, that's a really wide range of computing for fairly similar models! Today the world today is like cloud computing, mobile computing, and a little bit of AI and they call it AI Accelleration, and the wolrd is going to flip over and it is going to 80%-90% "AI computing" in the not too distant a future! ... The best I can tell is that AI computers are between 10,000 times to a million times too slow!" - Jim Keller
" Tenstorrent's CEO Ljubisa Bajic + President and CTO Jim Keller were invited to discuss the future of AI at MIT Technology Review's Future Compute Conference" ⁆
video: ⁅
⁆description: ⁅ "We've hit a point where some of the bigger models out there are so big that the next step is just not on the horizon ... The way we chose to try to solve that problem is by making the computer machinery more intelligent as opposed to just bigger.
~"AI is so weird, a millewatt to ten megawatts, that's a really wide range of computing for fairly similar models! Today the world today is like cloud computing, mobile computing, and a little bit of AI and they call it AI Accelleration, and the wolrd is going to flip over and it is going to 80%-90% "AI computing" in the not too distant a future! ... The best I can tell is that AI computers are between 10,000 times to a million times too slow!" - Jim Keller
" Tenstorrent's CEO Ljubisa Bajic + President and CTO Jim Keller were invited to discuss the future of AI at MIT Technology Review's Future Compute Conference" ⁆
video: ⁅
].
[Video
title: ⁅ Ian Interviews #6: Ljubisa Bajic and Jim Keller, Tenstorrent ⁆
description: ⁅ "With all the money flowing into AI processor startups right now, trying to tell them apart can be tricky. Most are aiming for inference, others for training, and some are in the middle, all looking for that edge to put them above the rest. Tenstorrent believes it has the solution for both inference, training, and can be scaled from 16 chips to 16 million. Ljubisa Recommendation is a veteran of the semiconductor industry, working extensively in VLSI design and debug coupled with extensive accelerator architecture and software experience. Ljubisa spent a decade inside AMD as an ASIC architect working on power management and DSP design, before a spell at NVIDIA as a senior architect, and then back to AMD for a couple of years working with Jim on the hardware that powers AMD’s balance sheet today. He left AMD to start Tenstorrent with two other co-founders in 2016, has raised $240m in three rounds of funding, and created three generations of processors, the latest of which is shipping this year. At least two more generations are on the way. ~"The three big areas of AI processing today are: Image Processing, [Human] Language Processing and Recommendation." - Jim Keller ⁆
video: ⁅
⁆description: ⁅ "With all the money flowing into AI processor startups right now, trying to tell them apart can be tricky. Most are aiming for inference, others for training, and some are in the middle, all looking for that edge to put them above the rest. Tenstorrent believes it has the solution for both inference, training, and can be scaled from 16 chips to 16 million. Ljubisa Recommendation is a veteran of the semiconductor industry, working extensively in VLSI design and debug coupled with extensive accelerator architecture and software experience. Ljubisa spent a decade inside AMD as an ASIC architect working on power management and DSP design, before a spell at NVIDIA as a senior architect, and then back to AMD for a couple of years working with Jim on the hardware that powers AMD’s balance sheet today. He left AMD to start Tenstorrent with two other co-founders in 2016, has raised $240m in three rounds of funding, and created three generations of processors, the latest of which is shipping this year. At least two more generations are on the way. ~"The three big areas of AI processing today are: Image Processing, [Human] Language Processing and Recommendation." - Jim Keller ⁆
video: ⁅
].
⁅ ZokuTalk is adopting AI in a major way. ZokuTalk will take years and it will transform the very nature of programming. ⁆
[Definiton
term: ⁅ #BareMetal ⁆ or: ⁅ Bare Metal Processor ⁆ or: ⁅ Baremetal ⁆ or: ⁅ Practical Baremetal ⁆ or: ⁅ Baremetal Application with or without an OS ⁆
definition: ⁅
].definition: ⁅
The "BareMetal Processor Series" is about the hardware the we run ZokuTalk™ and Smalltalk-80 Descentant Systems on regardless how or in what configurations of these processor systems you are using them. In this regard this article touches one or more of these various usages or definitions of "baremetal":
⁆
Baremetal[1]: The Baremetal+RAW-Processor: such as the new Zen4 7950X from AMD itself regardless of any software at all;
BareMetal[2]: The Baremetal-NoByteCode-NoVirtualMachine program: maximizing the native instruction set down to the #BareMetal, with or without an OS, and without Virtual Byte Code Machines (No-BC-VM) technologies of the inefficient past in the application or OS; and,
BareMetal[3]: Baremetal+App+ByteCode-VirtualMachine+NoOS or WithAnOS: Applications+ByteCodeVirtualMachines+No-Operating-Systems as the original Palo Alto Xerox computers that originally ran Smalltalk-80 and predessor systems! Later Smalltalk-80 descendants often generate C and Assembly Virtual Machine interpreters or compile to procedural programs in Assembly and/or C; but they still have a layered Byte Code design.
(4) Baremetal with other variations or any combinations of these or other relevant aspects to accurately and fully describt and distinguish them from the others.
BareMetal[2]: The Baremetal-NoByteCode-NoVirtualMachine program: maximizing the native instruction set down to the #BareMetal, with or without an OS, and without Virtual Byte Code Machines (No-BC-VM) technologies of the inefficient past in the application or OS; and,
BareMetal[3]: Baremetal+App+ByteCode-VirtualMachine+NoOS or WithAnOS: Applications+ByteCodeVirtualMachines+No-Operating-Systems as the original Palo Alto Xerox computers that originally ran Smalltalk-80 and predessor systems! Later Smalltalk-80 descendants often generate C and Assembly Virtual Machine interpreters or compile to procedural programs in Assembly and/or C; but they still have a layered Byte Code design.
(4) Baremetal with other variations or any combinations of these or other relevant aspects to accurately and fully describt and distinguish them from the others.
[Article
title: {"If Smalltalk is so great why are we not all using it?"}
series: {Why Smalltalk Died?}
by: {Peter Lount}
videoBy: {Noel Rappin, and Robert Martin}
date: {20221027}
circa: {20090508, 20140428}
version: {v0002}
tags: {#Smalltalk. #Pharo. #WhyAreWeNotAllUsingSmalltalk}
{At the end of his video "Noel Rappin" he asks why are we not all using Smalltalk? Noel Rappin's assessment and conclusion is dead on target ◎!.}.
{From the beginning Smalltalk, even before Smalltalk-80 came out to the world, was the Operating System! In clear terms Smalltalk lost the OS Wars to C based OSes such as *nix aka NeXTStep/OpenStep/MacOS/iOS, oh and of course Unix, and later on Linux OSes where C Reigns Superme! Ironically Steve Jobs saw Smalltalk at Xerox Parc PLace labs that one day and created the MacIntosh! Later on Steve Jobs created NeXTStep using Objective-C a C based Smalltalk-like extention to C... sort of; at least it was messages and the NSApplication Kit is pretty wicked especially NSView which kicks ass in the GUI UX space.}
{
{This is one reason ZokuTalk is absorbing the Alien Data Formats and Alien Language Syntaxes with the ZokuTalk Tower of Babel™ Syntax Tool, to "play well with others". That is not the whole story as many other things need to happen to play well with others! For instance creating DLLs aka Shared Libraries from Smalltalk-80 descent code and have that be called by other programs from Alien Languages such as C or C++! Consider it Alien FFI's (Foreign Function Interfaces)! ZokuTalk has impressive access to FFI's with minimal effort as well.}.
{Unlike some others embracing Smalltalk-80 as "the one true and only solution", I play well with others using whatever the work demands! Yes that includes C or C++ or even C#! Or "shell" scripts on *nix or Windows! How dare I use Windows! Why would I not use Windows when almost a billion people are using Windows? Sure I love the MacOS and iOS and have owned many Apple products from the Apple ][ to the first MacIntosh with 1 MiB to the MacII with a 5GiB Harddrive to the last MacBookPro with an actual hardware ethernet port! Building ZokuTalk I embrace every major OS and Processor that exists much like COG does to support Squeak, Pharo and other Smalltalk-80 descendants! Oh, I support the awesome processors that don't yet exist as ASIC Chips (other than FPGA existence) that show promise! The goals it not take over the world with the "one true system" but to "play well with others" in the global computing landscape of the interwebs!}
{"Ruby is Smalltalk without the image with C syntax" - Robert Martin quoting Kent Beck.}
{
{Test driven development was and is the core disipline at Geiko's Smalltalk Development team with something like 10,000 or so tests (taking four or more hours to run) that had to pass for your code to be accepted, and it had to also pass a number of code reviewers who could kick it back to you! Oh and they used an extensively evolved version of SUnit. This approach enabled few bugs to get into production as the costs of shutting down some 10,000 Geico Telephone Operators was astronomical! One day such a shutdown happened as they rolled out a new version of the system and I got the call to come in and help! When I arrived there where already 50 people working the problem! Yikes!
Within a few hours after I backtracked to their annoyance going over the problem from the start I did testing and with the help of a Mainframe IBM Database Cobol expert who was in our section of the office I found the beg and documented as proof that it was a bug on the Cobol side! Her and I walked to her neck of the woods about two blocks away indisde the builing's widy path and presented the findings! They didn't believe me but hey evidence is evidence in computer science when you are following the scientific method as I do!
Later that day one of the Smalltalker's on our team who had extensive Cobol experience and I (mostly him with me verifying if it made sense) found the problem and tested it making the bug go away! They then reviewed the problem and went live an hour later; basically it was IBM's version of Cobol DLL Hell loading the prior version of the Cobol Library (one character was not updated in the database of which Cobol Library to load instead of the new one! Test driven development rules! Loss of one day's work of 10,000 operators, and the loss of customers having changes to their vehicle insurance policies adjusted, and 50+ techical people spending the day solving the problem.
ZokuTalk uses many tests for TDD even in the finished product so that Applications can test that ZokuTalk is working correctly as ZokuTalk has many Invariants that Must Hold True in order to Provide Guaranteed Safety of Transactions and other aspects of the Run Time and ZokuTalk Execution Engine.
}
].
Contents
title: {"If Smalltalk is so great why are we not all using it?"}
series: {Why Smalltalk Died?}
by: {Peter Lount}
videoBy: {Noel Rappin, and Robert Martin}
date: {20221027}
circa: {20090508, 20140428}
version: {v0002}
tags: {#Smalltalk. #Pharo. #WhyAreWeNotAllUsingSmalltalk}
{At the end of his video "Noel Rappin" he asks why are we not all using Smalltalk? Noel Rappin's assessment and conclusion is dead on target ◎!.}.
{From the beginning Smalltalk, even before Smalltalk-80 came out to the world, was the Operating System! In clear terms Smalltalk lost the OS Wars to C based OSes such as *nix aka NeXTStep/OpenStep/MacOS/iOS, oh and of course Unix, and later on Linux OSes where C Reigns Superme! Ironically Steve Jobs saw Smalltalk at Xerox Parc PLace labs that one day and created the MacIntosh! Later on Steve Jobs created NeXTStep using Objective-C a C based Smalltalk-like extention to C... sort of; at least it was messages and the NSApplication Kit is pretty wicked especially NSView which kicks ass in the GUI UX space.}
{
{This is one reason ZokuTalk is absorbing the Alien Data Formats and Alien Language Syntaxes with the ZokuTalk Tower of Babel™ Syntax Tool, to "play well with others". That is not the whole story as many other things need to happen to play well with others! For instance creating DLLs aka Shared Libraries from Smalltalk-80 descent code and have that be called by other programs from Alien Languages such as C or C++! Consider it Alien FFI's (Foreign Function Interfaces)! ZokuTalk has impressive access to FFI's with minimal effort as well.}.
{Unlike some others embracing Smalltalk-80 as "the one true and only solution", I play well with others using whatever the work demands! Yes that includes C or C++ or even C#! Or "shell" scripts on *nix or Windows! How dare I use Windows! Why would I not use Windows when almost a billion people are using Windows? Sure I love the MacOS and iOS and have owned many Apple products from the Apple ][ to the first MacIntosh with 1 MiB to the MacII with a 5GiB Harddrive to the last MacBookPro with an actual hardware ethernet port! Building ZokuTalk I embrace every major OS and Processor that exists much like COG does to support Squeak, Pharo and other Smalltalk-80 descendants! Oh, I support the awesome processors that don't yet exist as ASIC Chips (other than FPGA existence) that show promise! The goals it not take over the world with the "one true system" but to "play well with others" in the global computing landscape of the interwebs!}
{"Ruby is Smalltalk without the image with C syntax" - Robert Martin quoting Kent Beck.}
{
{Test driven development was and is the core disipline at Geiko's Smalltalk Development team with something like 10,000 or so tests (taking four or more hours to run) that had to pass for your code to be accepted, and it had to also pass a number of code reviewers who could kick it back to you! Oh and they used an extensively evolved version of SUnit. This approach enabled few bugs to get into production as the costs of shutting down some 10,000 Geico Telephone Operators was astronomical! One day such a shutdown happened as they rolled out a new version of the system and I got the call to come in and help! When I arrived there where already 50 people working the problem! Yikes!
Within a few hours after I backtracked to their annoyance going over the problem from the start I did testing and with the help of a Mainframe IBM Database Cobol expert who was in our section of the office I found the beg and documented as proof that it was a bug on the Cobol side! Her and I walked to her neck of the woods about two blocks away indisde the builing's widy path and presented the findings! They didn't believe me but hey evidence is evidence in computer science when you are following the scientific method as I do!
Later that day one of the Smalltalker's on our team who had extensive Cobol experience and I (mostly him with me verifying if it made sense) found the problem and tested it making the bug go away! They then reviewed the problem and went live an hour later; basically it was IBM's version of Cobol DLL Hell loading the prior version of the Cobol Library (one character was not updated in the database of which Cobol Library to load instead of the new one! Test driven development rules! Loss of one day's work of 10,000 operators, and the loss of customers having changes to their vehicle insurance policies adjusted, and 50+ techical people spending the day solving the problem.
ZokuTalk uses many tests for TDD even in the finished product so that Applications can test that ZokuTalk is working correctly as ZokuTalk has many Invariants that Must Hold True in order to Provide Guaranteed Safety of Transactions and other aspects of the Run Time and ZokuTalk Execution Engine.
}
].
Contents
[Article
title: {MountainWest RubyConf 2014 - But Really, You Should Learn Smalltalk}
series: {Learning Smalltalk}
by: {Peter Lount}
videoBy: {Noel Rappin}
date: {20221027}
circa: {20140428}
version: {v0001}
tags: {#Ruby. #Learning. #Smalltalk. #Pharo}
{In the video by "Noel Rappin" he explores Learning Smalltalk fast to Ruby users at the Mountain West Conference in 2014.}.
{"Smalltalk has mystique. We talk about it more than we use it.
It seems like it should be so similar to Ruby. It has similar Object-Oriented structures, it even has blocks. But everything is so slightly different, from the programming environment, to the 1-based arrays, to the simple syntax. Using Smalltalk will make you look at familiar constructs with new eyes.
We'll show you how to get started on Smalltalk, and walk through some sample code. Live coding may be involved. You'll never look at objects the same way again."}.
{
].
Contents
title: {MountainWest RubyConf 2014 - But Really, You Should Learn Smalltalk}
series: {Learning Smalltalk}
by: {Peter Lount}
videoBy: {Noel Rappin}
date: {20221027}
circa: {20140428}
version: {v0001}
tags: {#Ruby. #Learning. #Smalltalk. #Pharo}
{In the video by "Noel Rappin" he explores Learning Smalltalk fast to Ruby users at the Mountain West Conference in 2014.}.
{"Smalltalk has mystique. We talk about it more than we use it.
It seems like it should be so similar to Ruby. It has similar Object-Oriented structures, it even has blocks. But everything is so slightly different, from the programming environment, to the 1-based arrays, to the simple syntax. Using Smalltalk will make you look at familiar constructs with new eyes.
We'll show you how to get started on Smalltalk, and walk through some sample code. Live coding may be involved. You'll never look at objects the same way again."}.
{
].
Contents
[Article
title: {Idempotence, a Safe Parallel Key Feature for ZokuTalk While Respecting Object & Data State Changes}
series: {Idempotence. Burn The Disk Packs}
by: {Peter Lount}
date: {20221026. 20221027}
circa: {20221026}
version: {v0003}
tags: {#Idempotence. #ZokuTalk. #BurnTheDiskPacks. #WalkAndTalkVideo}
{In the video "Peter Lount" by Idempotence in ZokuTalk explored in depth.}.
{"Idempotence: a math and computational quality given the exact same input objects/data operation messages the result will be the same ("same power") regardless of where or which computer it runs on or when it runs, in 1986 or 2022. Of course you need to run same version of the code if the outputs will be changed in a new version - fortunately the version of the code that is run for any computation is logged with the transaction, idempotent or not! After all ZokuTalk is fully versioned object+data system!"}.
{
}.
{
{ZokuTalk's research has focused on bringing advanced Live Programming features to life in many ways with all kinds of different models.
For example:
{
(1) Going far beyond Closure's simplistic technocratic expertise required expertise for doing programming with complex "state" machinations and at the same simplifying the model and making one far more powerful that also enables wide and diversified program safety as well as Functional - when one wants it - Idempotent as appropriate and if needed.}.
ZokuTalk treats the changes to "state" of the "data/objects" as a primary aspect of the purpose of a progam, not to be avoided or feared but embraced and done in a safe atomic transactional manner with integrity and consistency isolated from other changes in a fully mulithreaded manner on N-Core-Threading processors or across distributed compute servers and being fully versioned durable on strorage as required!).
On the other hand functional languages have a helter-shelter problem with the flux of state changes in a typical enterprise application which is very strange as in real world applications most of the entire point is making correct and appropriate changes to data objects being modified aka changing (adding, deleting, adjusting, modifying) the state! At successful commits a new version of the object graph being modified or created is produced with a "version state", the same result that functional programs jump through many unnecessary mental hoops to achieve!.
Important Note: Idempotence as a programming technique is not owned by solely by Functional Programming as they would like you to magically believe, I used Idempotence as a key feature in "Gemstone Healer" in 6502 Assembly in the 1980's to generate the entire Dungeon Network and Room Details 100% from one 12 digit seed input!!! Two users entering the same seed get the same dungeon map as someone else does, sharing the seed value! In 1985 or in 2022!).
Smalltalk can do idepotence if one is manually very careful while ZokuTalk can do Systematic Idempotence to ensure it happens when required (all inputs accounted for and versioned, no external inputs not in the definded inputs) and Systematic Idempotence can be very important when doing massive distributed calculations across a cluster of compute servers across the Interwebs or inhouse on the available corporate computers especially when fault tollerance is important.
Oh and we don't have to confuse the matter as Functional Languages do by mixing State with Idempotence and being anti-state as a result! Lol, they have confusion at the core... by denigrating "changing state" as having no value! Changing State is how the Computational Universe operates as Stephen Wolfram has proven and it is wise to not go against his proofs!!!
Idempotence is an important technique for producing the same computational results for the same inputs! That is especially important in many (but not all) distributed processing requests across mutiple threads on one box or across a distributed cloud cluster on the interwebs. Why? if a distributed thread fails, say due to a loss of network communications, the particular thread work unit can be restarted on another server for fault tolerance recovery and completion of the distributed work flow!
{
(2) Easy distributed programming! Same process with real Native Threads! Different processes on the same box! Different distributed boxes/nodes in a compute cloud or shared across the Interwebs!...
(3) The GUI UX design brings the most advanced Visual Spaces for Work Productivity and Graphical Display of information! Bringing the best of most advanced Dynamic Interface Builders that are inherently flexible for dynamic rearrangement within a live programming GUI-UX design and live data, objects, messages, threads! Yes you can see processes and kill as needed! And bring them back to life if you need to!
...
...
...
(N) The list goes on and on, as the ZokuTalk research is very extensive with over 35+ years of research! The design of ZokkuTalk has talk a number of decades to solve certail problems to be performant and solve the safe parellel problem with millions of possible threads on a X64 bit scale CPU. I am working on implementing the ZokuTalk systems and writing about the ZokuTalk research. Suppport in form of funding is required.
I first read about Smalltalk in 1979 in an American Scientific article, followed by the Byte Magazine dedicated to Smalltalk in 1980! Wow that blew my mind! During working in 6502 Assembly Language for Gemstone Warrior, and later Gemstone Healer, video games I implemented my first Objects in 6502, yes there were only nine objects but they had some uniform characteristics, call them "map objects" for each game room. I also ported Gemstone Warrior to the Macintosh with a Motorola 32-Bit Hard Core 680000 CPU. After the games I worked in 6502 Assembly on a game system with many more objects and attempted to make a tiny Smalltalk, and failed when I realized the PC was ascendant.
In 1985 I obtained Smalltalk from Apple for the Mac Plus with 1 MiB of RAM! Wow! The next six months was warping my mind with unary, binary and keyword message sends and learning the Smalltalk Object library! It took about six months for me to feel comfortable with Smalltalk and to break out of 10+ years of procedural programming (that I started in my teens).
In 1987 I worked for Synaptec making a clone of Smalltalk for the Intel 386/486 based on ForthTalk, a variation on forth that had been objectified with Smalltalk message syntax too. I worked with Synaptec a number of times over the subsequent years as that was the era of the post 1987 Black Friday Stock Market kerfuffle.
Doing projects in Digitalk V/286 on the PC and Macintosh II I created a number of wicked apps in cad and desktop publishing! That lead to working with Condor Rebar Detailing where a civil engineer, an expert in segmental bridges, and I build the Vancouver Sky Train (it is a raised bridge above land) Bridge Extension into Surrey. I worked with Condor many times on the bridge program to extend it for vechicle bridges crossing rivers and waterways. A total of about 25 bridges where made with this software and we ported it to Digitalk V/Win where it was excellent! I also extensively worked on the Condor Rebar Detailing Program.
In 1992 I worked at JP Morgan at 60 Wall Street on Das Kapital using ParcPlace VisualWorks on the Core Technology Team and two former Parc Pllace people including one of the people who made up the original Smalltalk team!.
The reason I dive into a bit of history about my Smalltalk working experiences is to illustrate the path towards ZokuTalk has been a windy road with lots of mountains to climb from a learning and techniceal point of view with a continued research interest at making Smallktalk-80 better and better since I decided that in about 1987 after the first stint at Synaptec, my first Smalltalk-Variant Vendor. One of the issues to make better was real yet safe native-OS multithreading for Smalltalk. A thousand other aspects are affected by these Design Decisions including the ZokuTalk MOBS Extensions.}
{Building Live Programs is the Future!}
}.
{
{
}
].
Contents
title: {Idempotence, a Safe Parallel Key Feature for ZokuTalk While Respecting Object & Data State Changes}
series: {Idempotence. Burn The Disk Packs}
by: {Peter Lount}
date: {20221026. 20221027}
circa: {20221026}
version: {v0003}
tags: {#Idempotence. #ZokuTalk. #BurnTheDiskPacks. #WalkAndTalkVideo}
{In the video "Peter Lount" by Idempotence in ZokuTalk explored in depth.}.
{"Idempotence: a math and computational quality given the exact same input objects/data operation messages the result will be the same ("same power") regardless of where or which computer it runs on or when it runs, in 1986 or 2022. Of course you need to run same version of the code if the outputs will be changed in a new version - fortunately the version of the code that is run for any computation is logged with the transaction, idempotent or not! After all ZokuTalk is fully versioned object+data system!"}.
{
}.
{
{ZokuTalk's research has focused on bringing advanced Live Programming features to life in many ways with all kinds of different models.
For example:
{
(1) Going far beyond Closure's simplistic technocratic expertise required expertise for doing programming with complex "state" machinations and at the same simplifying the model and making one far more powerful that also enables wide and diversified program safety as well as Functional - when one wants it - Idempotent as appropriate and if needed.}.
ZokuTalk treats the changes to "state" of the "data/objects" as a primary aspect of the purpose of a progam, not to be avoided or feared but embraced and done in a safe atomic transactional manner with integrity and consistency isolated from other changes in a fully mulithreaded manner on N-Core-Threading processors or across distributed compute servers and being fully versioned durable on strorage as required!).
On the other hand functional languages have a helter-shelter problem with the flux of state changes in a typical enterprise application which is very strange as in real world applications most of the entire point is making correct and appropriate changes to data objects being modified aka changing (adding, deleting, adjusting, modifying) the state! At successful commits a new version of the object graph being modified or created is produced with a "version state", the same result that functional programs jump through many unnecessary mental hoops to achieve!.
Important Note: Idempotence as a programming technique is not owned by solely by Functional Programming as they would like you to magically believe, I used Idempotence as a key feature in "Gemstone Healer" in 6502 Assembly in the 1980's to generate the entire Dungeon Network and Room Details 100% from one 12 digit seed input!!! Two users entering the same seed get the same dungeon map as someone else does, sharing the seed value! In 1985 or in 2022!).
Smalltalk can do idepotence if one is manually very careful while ZokuTalk can do Systematic Idempotence to ensure it happens when required (all inputs accounted for and versioned, no external inputs not in the definded inputs) and Systematic Idempotence can be very important when doing massive distributed calculations across a cluster of compute servers across the Interwebs or inhouse on the available corporate computers especially when fault tollerance is important.
Oh and we don't have to confuse the matter as Functional Languages do by mixing State with Idempotence and being anti-state as a result! Lol, they have confusion at the core... by denigrating "changing state" as having no value! Changing State is how the Computational Universe operates as Stephen Wolfram has proven and it is wise to not go against his proofs!!!
Idempotence is an important technique for producing the same computational results for the same inputs! That is especially important in many (but not all) distributed processing requests across mutiple threads on one box or across a distributed cloud cluster on the interwebs. Why? if a distributed thread fails, say due to a loss of network communications, the particular thread work unit can be restarted on another server for fault tolerance recovery and completion of the distributed work flow!
{
(2) Easy distributed programming! Same process with real Native Threads! Different processes on the same box! Different distributed boxes/nodes in a compute cloud or shared across the Interwebs!...
(3) The GUI UX design brings the most advanced Visual Spaces for Work Productivity and Graphical Display of information! Bringing the best of most advanced Dynamic Interface Builders that are inherently flexible for dynamic rearrangement within a live programming GUI-UX design and live data, objects, messages, threads! Yes you can see processes and kill as needed! And bring them back to life if you need to!
...
...
...
(N) The list goes on and on, as the ZokuTalk research is very extensive with over 35+ years of research! The design of ZokkuTalk has talk a number of decades to solve certail problems to be performant and solve the safe parellel problem with millions of possible threads on a X64 bit scale CPU. I am working on implementing the ZokuTalk systems and writing about the ZokuTalk research. Suppport in form of funding is required.
I first read about Smalltalk in 1979 in an American Scientific article, followed by the Byte Magazine dedicated to Smalltalk in 1980! Wow that blew my mind! During working in 6502 Assembly Language for Gemstone Warrior, and later Gemstone Healer, video games I implemented my first Objects in 6502, yes there were only nine objects but they had some uniform characteristics, call them "map objects" for each game room. I also ported Gemstone Warrior to the Macintosh with a Motorola 32-Bit Hard Core 680000 CPU. After the games I worked in 6502 Assembly on a game system with many more objects and attempted to make a tiny Smalltalk, and failed when I realized the PC was ascendant.
In 1985 I obtained Smalltalk from Apple for the Mac Plus with 1 MiB of RAM! Wow! The next six months was warping my mind with unary, binary and keyword message sends and learning the Smalltalk Object library! It took about six months for me to feel comfortable with Smalltalk and to break out of 10+ years of procedural programming (that I started in my teens).
In 1987 I worked for Synaptec making a clone of Smalltalk for the Intel 386/486 based on ForthTalk, a variation on forth that had been objectified with Smalltalk message syntax too. I worked with Synaptec a number of times over the subsequent years as that was the era of the post 1987 Black Friday Stock Market kerfuffle.
Doing projects in Digitalk V/286 on the PC and Macintosh II I created a number of wicked apps in cad and desktop publishing! That lead to working with Condor Rebar Detailing where a civil engineer, an expert in segmental bridges, and I build the Vancouver Sky Train (it is a raised bridge above land) Bridge Extension into Surrey. I worked with Condor many times on the bridge program to extend it for vechicle bridges crossing rivers and waterways. A total of about 25 bridges where made with this software and we ported it to Digitalk V/Win where it was excellent! I also extensively worked on the Condor Rebar Detailing Program.
In 1992 I worked at JP Morgan at 60 Wall Street on Das Kapital using ParcPlace VisualWorks on the Core Technology Team and two former Parc Pllace people including one of the people who made up the original Smalltalk team!.
The reason I dive into a bit of history about my Smalltalk working experiences is to illustrate the path towards ZokuTalk has been a windy road with lots of mountains to climb from a learning and techniceal point of view with a continued research interest at making Smallktalk-80 better and better since I decided that in about 1987 after the first stint at Synaptec, my first Smalltalk-Variant Vendor. One of the issues to make better was real yet safe native-OS multithreading for Smalltalk. A thousand other aspects are affected by these Design Decisions including the ZokuTalk MOBS Extensions.}
{Building Live Programs is the Future!}
}.
{
{
}
].
Contents
[Article
title: {Dead Programs Are Spooky Boo Zombies}
by: {Peter Lount}
date: {20221023, 20221025}
circa: {20220923-20220924}
version: {v0004}
tags: {#StrangeLoop. #DeadPrograms. #LivePrograms. #SpookyBoo. #BurnTheDiskPacks}.
{In the video "Stop Writing Dead Programs" [1] by Jack Rusher of Applied Science Studio who explores the insanity of dead programs that continue onward as zombies dessicated without any any life to them.}.
{
{"Most new programming languages are accidentally designed to be backwards compatible with punchcards. This talk argues that it would be better to focus on building new live programming environments that can help us solve the problems of the future. Jack Rusher's long career as a computer scientist includes time at Bell Labs/AT&T Research and a number of successful startups. His current work focuses on the deep relationship between art and technology."}.
{
}
{
{"... even though it's 40 years old, this Seymour Papert quote saying that we're still digging ourselves into a kind of a pit by continuing to preserve practices that have no rational basis beyond being historical." - Jack Rush qouting Seymour Papert.}.
{As a result of this ZokuTalk burns the diskpacks to quote Alan Kay.}.
{
{ZokuTalk's research has focused on bringing advanced Live Programming features to life in many ways with all kinds of different models.
For example:
(1) Going far beyond Closure's simplistic technocratic expertise required expertise for doing programming with complex "state" machinations and at the same simplifying the model and making one far more powerful that also enables wide and diversified program safety as well as Functional - when one wants it - Idempotent as appropriate and if needed.}.
ZokuTalk treats the changes to "state" of the "data/objects" as a primary aspect of the purpose of a progam, not to be avoided or feared but embraced and done in a safe atomic transactional manner with integrity and consistency isolated from other changes in a fully mulithreaded manner on N-Core-Threading processors or across distributed compute servers and being fully versioned durable on strorage as required!).
On the other hand functional languages have a helter-shelter problem with the flux of state changes in a typical enterprise application which is very strange as in real world applications most of the entire point is making correct and appropriate changes to data objects being modified aka changing (adding, deleting, adjusting, modifying) the state! At successful commits a new version of the object graph being modified or created is produced with a "version state", the same result that functional programs jump through many unnecessary mental hoops to achieve!.
Important Note: Idempotence as a programming technique is not owned by solely by Functional Programming as they would like you to magically believe, I used Idempotence as a key feature in "Gemstone Healer" in 6502 Assembly in the 1980's to generate the entire Dungeon Network and Room Details 100% from one 12 digit seed input!!! Two users entering the same seed get the same dungeon map as someone else does, sharing the seed value! In 1985 or in 2022!).
Smalltalk can do idepotence if one is manually very careful while ZokuTalk can do Systematic Idempotence to ensure it happens when required (all inputs accounted for and versioned, no external inputs not in the definded inputs) and Systematic Idempotence can be very important when doing massive distributed calculations across a cluster of compute servers across the Interwebs or inhouse on the available corporate computers especially when fault tollerance is important.
Oh and we don't have to confuse the matter as Functional Languages do by mixing State with Idempotence and being anti-state as a result! Lol, they have confusion at the core... by denigrating "changing state" as having no value! Changing State is how the Computational Universe operates as Stephen Wolfram has proven and it is wise to not go against his proofs!!!
Idempotence is an important technique for producing the same computational results for the same inputs! That is especially important in many (but not all) distributed processing requests across mutiple threads on one box or across a distributed cloud cluster on the interwebs. Why? if a distributed thread fails, say due to a loss of network communications, the particular thread work unit can be restarted on another server for fault tolerance recovery and completion of the distributed work flow!
{
(2) Easy distributed programming! Same process with real Native Threads! Different processes on the same box! Different distributed boxes/nodes in a compute cloud or shared across the Interwebs!...
(3) The GUI UX design brings the most advanced Visual Spaces for Work Productivity and Graphical Display of information! Bringing the best of most advanced Dynamic Interface Builders that are inherently flexible for dynamic rearrangement within a live programming GUI-UX design and live data, objects, messages, threads! Yes you can see processes and kill as needed! And bring them back to life if you need to!
...
...
...
(N) The list goes on and on, as the ZokuTalk research is very extensive with over 35+ years of research! The design of ZokkuTalk has talk a number of decades to solve certail problems to be performant and solve the safe parellel problem with millions of possible threads on a X64 bit scale CPU. I am working on implementing the ZokuTalk systems and writing about the ZokuTalk research. Suppport in form of funding is required.
I first read about Smalltalk in 1979 in an American Scientific article, followed by the Byte Magazine dedicated to Smalltalk in 1980! Wow that blew my mind! During working in 6502 Assembly Language for Gemstone Warrior, and later Gemstone Healer, video games I implemented my first Objects in 6502, yes there were only nine objects but they had some uniform characteristics, call them "map objects" for each game room. I also ported Gemstone Warrior to the Macintosh with a Motorola 32-Bit Hard Core 680000 CPU. After the games I worked in 6502 Assembly on a game system with many more objects and attempted to make a tiny Smalltalk, and failed when I realized the PC was ascendant.
In 1985 I obtained Smalltalk from Apple for the Mac Plus with 1 MiB of RAM! Wow! The next six months was warping my mind with unary, binary and keyword message sends and learning the Smalltalk Object library! It took about six months for me to feel comfortable with Smalltalk and to break out of 10+ years of procedural programming (that I started in my teens).
In 1987 I worked for Synaptec making a clone of Smalltalk for the Intel 386/486 based on ForthTalk, a variation on forth that had been objectified with Smalltalk message syntax too. I worked with Synaptec a number of times over the subsequent years as that was the era of the post 1987 Black Friday Stock Market kerfuffle.
Doing projects in Digitalk V/286 on the PC and Macintosh II I created a number of wicked apps in cad and desktop publishing! That lead to working with Condor Rebar Detailing where a civil engineer, an expert in segmental bridges, and I build the Vancouver Sky Train (it is a raised bridge above land) Bridge Extension into Surrey. I worked with Condor many times on the bridge program to extend it for vechicle bridges crossing rivers and waterways. A total of about 25 bridges where made with this software and we ported it to Digitalk V/Win where it was excellent! I also extensively worked on the Condor Rebar Detailing Program.
In 1992 I worked at JP Morgan at 60 Wall Street on Das Kapital using ParcPlace VisualWorks on the Core Technology Team and two former Parc Pllace people including one of the people who made up the original Smalltalk team!.
The reason I dive into a bit of history about my Smalltalk working experiences is to illustrate the path towards ZokuTalk has been a windy road with lots of mountains to climb from a learning and techniceal point of view with a continued research interest at making Smallktalk-80 better and better since I decided that in about 1987 after the first stint at Synaptec, my first Smalltalk-Variant Vendor. One of the issues to make better was real yet safe native-OS multithreading for Smalltalk. A thousand other aspects are affected by these Design Decisions including the ZokuTalk MOBS Extensions.}
{Building Live Programs is the Future!}
}.
{
{[1] Jack Rusher Strange Loop 2022
{[1] Alan Kay, "Burn the disk packs"
{[1] Idempotence
}
].
Contents
title: {Dead Programs Are Spooky Boo Zombies}
by: {Peter Lount}
date: {20221023, 20221025}
circa: {20220923-20220924}
version: {v0004}
tags: {#StrangeLoop. #DeadPrograms. #LivePrograms. #SpookyBoo. #BurnTheDiskPacks}.
{In the video "Stop Writing Dead Programs" [1] by Jack Rusher of Applied Science Studio who explores the insanity of dead programs that continue onward as zombies dessicated without any any life to them.}.
{
{"Most new programming languages are accidentally designed to be backwards compatible with punchcards. This talk argues that it would be better to focus on building new live programming environments that can help us solve the problems of the future. Jack Rusher's long career as a computer scientist includes time at Bell Labs/AT&T Research and a number of successful startups. His current work focuses on the deep relationship between art and technology."}.
{
{
{"... even though it's 40 years old, this Seymour Papert quote saying that we're still digging ourselves into a kind of a pit by continuing to preserve practices that have no rational basis beyond being historical." - Jack Rush qouting Seymour Papert.}.
{As a result of this ZokuTalk burns the diskpacks to quote Alan Kay.}.
{
{ZokuTalk's research has focused on bringing advanced Live Programming features to life in many ways with all kinds of different models.
For example:
(1) Going far beyond Closure's simplistic technocratic expertise required expertise for doing programming with complex "state" machinations and at the same simplifying the model and making one far more powerful that also enables wide and diversified program safety as well as Functional - when one wants it - Idempotent as appropriate and if needed.}.
ZokuTalk treats the changes to "state" of the "data/objects" as a primary aspect of the purpose of a progam, not to be avoided or feared but embraced and done in a safe atomic transactional manner with integrity and consistency isolated from other changes in a fully mulithreaded manner on N-Core-Threading processors or across distributed compute servers and being fully versioned durable on strorage as required!).
On the other hand functional languages have a helter-shelter problem with the flux of state changes in a typical enterprise application which is very strange as in real world applications most of the entire point is making correct and appropriate changes to data objects being modified aka changing (adding, deleting, adjusting, modifying) the state! At successful commits a new version of the object graph being modified or created is produced with a "version state", the same result that functional programs jump through many unnecessary mental hoops to achieve!.
Important Note: Idempotence as a programming technique is not owned by solely by Functional Programming as they would like you to magically believe, I used Idempotence as a key feature in "Gemstone Healer" in 6502 Assembly in the 1980's to generate the entire Dungeon Network and Room Details 100% from one 12 digit seed input!!! Two users entering the same seed get the same dungeon map as someone else does, sharing the seed value! In 1985 or in 2022!).
Smalltalk can do idepotence if one is manually very careful while ZokuTalk can do Systematic Idempotence to ensure it happens when required (all inputs accounted for and versioned, no external inputs not in the definded inputs) and Systematic Idempotence can be very important when doing massive distributed calculations across a cluster of compute servers across the Interwebs or inhouse on the available corporate computers especially when fault tollerance is important.
Oh and we don't have to confuse the matter as Functional Languages do by mixing State with Idempotence and being anti-state as a result! Lol, they have confusion at the core... by denigrating "changing state" as having no value! Changing State is how the Computational Universe operates as Stephen Wolfram has proven and it is wise to not go against his proofs!!!
Idempotence is an important technique for producing the same computational results for the same inputs! That is especially important in many (but not all) distributed processing requests across mutiple threads on one box or across a distributed cloud cluster on the interwebs. Why? if a distributed thread fails, say due to a loss of network communications, the particular thread work unit can be restarted on another server for fault tolerance recovery and completion of the distributed work flow!
{
(2) Easy distributed programming! Same process with real Native Threads! Different processes on the same box! Different distributed boxes/nodes in a compute cloud or shared across the Interwebs!...
(3) The GUI UX design brings the most advanced Visual Spaces for Work Productivity and Graphical Display of information! Bringing the best of most advanced Dynamic Interface Builders that are inherently flexible for dynamic rearrangement within a live programming GUI-UX design and live data, objects, messages, threads! Yes you can see processes and kill as needed! And bring them back to life if you need to!
...
...
...
(N) The list goes on and on, as the ZokuTalk research is very extensive with over 35+ years of research! The design of ZokkuTalk has talk a number of decades to solve certail problems to be performant and solve the safe parellel problem with millions of possible threads on a X64 bit scale CPU. I am working on implementing the ZokuTalk systems and writing about the ZokuTalk research. Suppport in form of funding is required.
I first read about Smalltalk in 1979 in an American Scientific article, followed by the Byte Magazine dedicated to Smalltalk in 1980! Wow that blew my mind! During working in 6502 Assembly Language for Gemstone Warrior, and later Gemstone Healer, video games I implemented my first Objects in 6502, yes there were only nine objects but they had some uniform characteristics, call them "map objects" for each game room. I also ported Gemstone Warrior to the Macintosh with a Motorola 32-Bit Hard Core 680000 CPU. After the games I worked in 6502 Assembly on a game system with many more objects and attempted to make a tiny Smalltalk, and failed when I realized the PC was ascendant.
In 1985 I obtained Smalltalk from Apple for the Mac Plus with 1 MiB of RAM! Wow! The next six months was warping my mind with unary, binary and keyword message sends and learning the Smalltalk Object library! It took about six months for me to feel comfortable with Smalltalk and to break out of 10+ years of procedural programming (that I started in my teens).
In 1987 I worked for Synaptec making a clone of Smalltalk for the Intel 386/486 based on ForthTalk, a variation on forth that had been objectified with Smalltalk message syntax too. I worked with Synaptec a number of times over the subsequent years as that was the era of the post 1987 Black Friday Stock Market kerfuffle.
Doing projects in Digitalk V/286 on the PC and Macintosh II I created a number of wicked apps in cad and desktop publishing! That lead to working with Condor Rebar Detailing where a civil engineer, an expert in segmental bridges, and I build the Vancouver Sky Train (it is a raised bridge above land) Bridge Extension into Surrey. I worked with Condor many times on the bridge program to extend it for vechicle bridges crossing rivers and waterways. A total of about 25 bridges where made with this software and we ported it to Digitalk V/Win where it was excellent! I also extensively worked on the Condor Rebar Detailing Program.
In 1992 I worked at JP Morgan at 60 Wall Street on Das Kapital using ParcPlace VisualWorks on the Core Technology Team and two former Parc Pllace people including one of the people who made up the original Smalltalk team!.
The reason I dive into a bit of history about my Smalltalk working experiences is to illustrate the path towards ZokuTalk has been a windy road with lots of mountains to climb from a learning and techniceal point of view with a continued research interest at making Smallktalk-80 better and better since I decided that in about 1987 after the first stint at Synaptec, my first Smalltalk-Variant Vendor. One of the issues to make better was real yet safe native-OS multithreading for Smalltalk. A thousand other aspects are affected by these Design Decisions including the ZokuTalk MOBS Extensions.}
{Building Live Programs is the Future!}
}.
{
{[1] Jack Rusher Strange Loop 2022
{[1] Alan Kay, "Burn the disk packs"
{[1] Idempotence
}
].
Contents
[Article
title: {Smalltalk: Getting started with the language}
by: {Bruce Badger}
date: {20221020}
circa: {20111207}
version: {v0002}
tags: {#learning. #video. #smalltalk.}
{In the video "Smalltalk: Getting started with the language" by Bruce Badger he explores getting started with Pharo Smalltalk.}.
{"How to get hold of a Smalltalk implementation (Pharo), how to start it, run some code, make a class, save the class as a file and read it back in again."}.
{
].
Contents
title: {Smalltalk: Getting started with the language}
by: {Bruce Badger}
date: {20221020}
circa: {20111207}
version: {v0002}
tags: {#learning. #video. #smalltalk.}
{In the video "Smalltalk: Getting started with the language" by Bruce Badger he explores getting started with Pharo Smalltalk.}.
{"How to get hold of a Smalltalk implementation (Pharo), how to start it, run some code, make a class, save the class as a file and read it back in again."}.
{
].
Contents
[Article
series: {BareMetal Processor Series}
title: {BareMetal | X64 | AMD Zen 4 7950X 8/16 Core Processors with AM5 Socket, X670e, PCIe5, DDR5}
by: {Peter Lount}
date: {20221012, 20221014}
circa: {20220829-20221012}
version: {v0011}
discussOn: (Discuss).
{Smalltalk has always embraced the Baremetal+App+BC-VM+No-OS of real processors! At first these "Alto" and other processors were made in house at Xerox in the early days of computing and ran Byte Code Virtual Machines with No-OSes, the application was the OS, Smalltalk-7X where X is Smalltalk 71-76 leading to Smalltalk-80 before Smalltalk was released to the world! Since then the vast majority of Smalltalk-80 and descendant systems have run on mainstream real processors! X86, ARM32, and since 64 bit systems came out X64 (from AMD and Intel) and ARM64 processors including Apple's innovative ARM64 M1 and soon M2. This series explores the very real hardware Baremetal+RAW-Processors that we can actually run real Smalltalk-80 and descendant systems on! Recently Risc-V has entered the scene with shipping processors and motherboards or FGPA open source processors for the daring.}.
With more modern Smalltalk-80 and descendant systems having moved away from relying on Byte Code VM systems performance has increased to be viable! As Smalltalk-80 has away from early Smalltalk's Alto App+BC-VM+No-OS systems (Xerox era at the start) that has been fantastic for popular usage as almost all computers have an OS! Byte Code VMs are bad things it turns out! We co-exist in the real world with OSes and Real Processor Hardware, it is shame to hobble the full power of the modern processors near magical abilities by limiting the instruction sets to a narrow set of limited byte codes!
I prefer real Baremetal+No-BC-VM applications without the limiting their full power with fake byte code virtual machines getting in the way of performance besides we know better now decades later. The original motivation of Fake Bye Code VMs was for portability unfortunately performance matters more in turns out an there are other ways to achieve portability of Smalltalk like systems!
While OS Vitualization Machine systems are popular and I might be installing them on the server hardware for their many advantages they are bascially out of the scope of the focus. Perforamce will almost certainly be better than on real machines sharing a work load with N-Vitrual-OSes!
{While there are amazing innovative efforts to make new FPGA and ASIC processor designs that are better able to deal with Smalltalk-80 Byte Codes or more efficient processors for object systems, and at some key points I'll cover them in articles. The primary focus of this Baremetal Article Series is on major shipping 32 bit and 64 bit processor architectures from AMD/Intel, ARM, Apple, and Risc-V real Bare Metal processors. Also any open sourced FPGA designs you can install a Smalltalk-80 descendant system on!
Massively Parallel New processors being developed now for Smalltalk-80 descendant systems really need to consider having many Risc-V 64 bit or 128 bit Cores or to have their Absurdly Flexible Very Wide Long Word Instructions be viable to allow other Alien Systems written in C, C++, C#, Java, Rust, Go, ... to be compiled and integrate otherwise they won't sell in mass quantities and will be predestined to fail to be viable in more than a niche market. They would also benefit from a binary translation capability to run Alien OSes from other Processor Architectures sucn as X64, ARM64, Risc-V64, etc... as Apple and other companies have used before.}.
{AMD brings out the Zen 4 Processors in the Fall 2022! The basic specs are a range of processors but the top of the line in the current released lineup is the AMD Zen 4 with 5 namometer process technology, a top of the line 7950X processor with 8/16 cores or 16/32 threads, fitting in a new AM5 socket connecting to the world with the motherboard controller X670e delivering PCIe 5.0 bus performance (double PCIe 4 and four times PCIe 3, eight times PCIe 2 speeds many of which are currently still in operation!) and utilizing very fast DDR5 memory (yeah like GPU memeory speeds).}
{
{#TechTechPotatoe says in this long detailed video "AMD Ryzen 7000 / Zen 4 Review: Live Stream Edition!" aka it is here! "Streamed live on Sep 26, 2022. It's 6am PT and I've written part of script but not had time to film. Screw it, we're doing it live!"}.
{
{"A shorter summary from August 29th. "AMD just announced Ryzen 7000 for desktop, involving Zen 4. Here's a rushed video covering the announcement."}.
{
{Reviews details: "Zen 4 and Linux with the New AM5 Hardware".}.
{
{AMD also released thei plans to continue shrinking the processor technology with Zen 4c and Zen 5 to 4-namometer and 3-nanometer sizes! Wow.}.
{
{Needless to say I am working to obtain 2 of these Zen4 system for the ZokuLab™ for building ZokuTalk™ with ZokuTalk's Safe-Multi-Threading Execution Engine (not a virtual machine as I am "Burning The Disc Packs") with all real OS processes and FULL ZokuTalk MOBS™ syntax all the way down to the #BareMetal! Counter to the rumors it is not "Turtles All The Way Down", it is "ZokuTalk MOBS (Messages, Objects+Data, Blocks (all four+ varieties) Syntax all the way daown to the Bare Metal! Heck even the Memory Garbage Collector is fully safe-multi-threading!
Yes first on X64 and then on ARM64 & Risc-V64 processors. Yes that means obtaining Apple's M2 ARM64 chip when it comes out and the Risc-V64 processors. Also interested in embedded FPGA Risc-V 32 or 64 bit processors for electronics (Iot) projects. Have to wait a bit to obtain at least 2 of the 128 thread chips with dual chip mother boards for 256 threads when these Zen4 server chips are available for the server room). Building real systems just got serious!
In the mean time I continue building ZokuTalk using Pharo (versions 6 and in the process of moving to 10 and collecting up all my code from earlier Pharo and Squeak versions) on the 10 or so X64 Intel and AMD boxes from 2012-2014 that I have in the ZokuLab and ZokuServer zones! This will be an Epic upgrade to a full safe-multi-threading distributed ZokuTalk Lisp+Smalltalk-80+ technology based systems! Oh yeah the Zen 4 will be epyc as well especially when the AMD 256 thread dual chip cpus be become real!
Unfortunately my Mac Book Pro died with a bad GPU and would need to replace the GPU on the board to fix it, decided to get an M2 ARM64 Mac and laptop when they are available.
As a side note my two favorite computer languages are Assembly and Smalltalk-80 varients and soon with ZokuTalk 1.0. X64 is a dream machine compared to the MOS6502 where I cut my assembly language skills with.}.
{Resource links:
{[1] Bare Machine}.
}
] articleTextWithNote: [
{Thanks to JM for the discussion today on the other narrow usage of "baremetal" to imply "no OS", I was not aware of that limited narrow definition! I have used my usage of baremetal for many decades to include with or without an OS present and no "byte code vitual machine"! I take Steve Jobs advice to heart and Think Different and not be constrained by others values or limited definitions! Progress doesn't respect arbitrary self imposed limits!}.
{Thanks to A.L. for his confirmation of the longstanding "Baremetal+No-BC-VM" usage as meaning NO-ByteCode-VM regardless of an OS or No-OS! for over 30 years as well."}
{
].
Contents
series: {BareMetal Processor Series}
title: {BareMetal | X64 | AMD Zen 4 7950X 8/16 Core Processors with AM5 Socket, X670e, PCIe5, DDR5}
by: {Peter Lount}
date: {20221012, 20221014}
circa: {20220829-20221012}
version: {v0011}
discussOn: (Discuss).
[Definiton
term: {#BareMetal or: {Bare Metal Processor} or: {Baremetal} or: {Practical Baremetal} or: {Baremetal Application with or without an OS}
definition: {
].definition: {
The "BareMetal Processor Series" is about the hardware the we run ZokuTalk™ and Smalltalk-80 Descentant Systems on regardless how or in what configurations of these processor systems you are using them. In this regard this article touches one or more of these various usages or definitions of "baremetal":
}
(1) The Baremetal+RAW-Processor: such as the new Zen4 7950X from AMD itself regardless of any software at all;
(2) The Baremetal-NoByteCode-NoVirtualMachine program: maximizing the native instruction set down to the #BareMetal, with or without an OS, and without Virtual Byte Code Machines (No-BC-VM) technologies of the inefficient past in the application or OS; and,
(3) Baremetal+App+ByteCode-VirtualMachine+NoOS or WithAnOS: Applications+ByteCodeVirtualMachines+No-Operating-Systems as the original Palo Alto Xerox computers that originally ran Smalltalk-80 and predessor systems! Later Smalltalk-80 descendants often generate C and Assembly Virtual Machine interpreters or compile to procedural programs in Assembly and/or C; but they still have a layered Byte Code design.
(4) Baremetal with other variations or any combinations of these or other relevant aspects to accurately and fully describt and distinguish them from the others.
(2) The Baremetal-NoByteCode-NoVirtualMachine program: maximizing the native instruction set down to the #BareMetal, with or without an OS, and without Virtual Byte Code Machines (No-BC-VM) technologies of the inefficient past in the application or OS; and,
(3) Baremetal+App+ByteCode-VirtualMachine+NoOS or WithAnOS: Applications+ByteCodeVirtualMachines+No-Operating-Systems as the original Palo Alto Xerox computers that originally ran Smalltalk-80 and predessor systems! Later Smalltalk-80 descendants often generate C and Assembly Virtual Machine interpreters or compile to procedural programs in Assembly and/or C; but they still have a layered Byte Code design.
(4) Baremetal with other variations or any combinations of these or other relevant aspects to accurately and fully describt and distinguish them from the others.
{Smalltalk has always embraced the Baremetal+App+BC-VM+No-OS of real processors! At first these "Alto" and other processors were made in house at Xerox in the early days of computing and ran Byte Code Virtual Machines with No-OSes, the application was the OS, Smalltalk-7X where X is Smalltalk 71-76 leading to Smalltalk-80 before Smalltalk was released to the world! Since then the vast majority of Smalltalk-80 and descendant systems have run on mainstream real processors! X86, ARM32, and since 64 bit systems came out X64 (from AMD and Intel) and ARM64 processors including Apple's innovative ARM64 M1 and soon M2. This series explores the very real hardware Baremetal+RAW-Processors that we can actually run real Smalltalk-80 and descendant systems on! Recently Risc-V has entered the scene with shipping processors and motherboards or FGPA open source processors for the daring.}.
With more modern Smalltalk-80 and descendant systems having moved away from relying on Byte Code VM systems performance has increased to be viable! As Smalltalk-80 has away from early Smalltalk's Alto App+BC-VM+No-OS systems (Xerox era at the start) that has been fantastic for popular usage as almost all computers have an OS! Byte Code VMs are bad things it turns out! We co-exist in the real world with OSes and Real Processor Hardware, it is shame to hobble the full power of the modern processors near magical abilities by limiting the instruction sets to a narrow set of limited byte codes!
I prefer real Baremetal+No-BC-VM applications without the limiting their full power with fake byte code virtual machines getting in the way of performance besides we know better now decades later. The original motivation of Fake Bye Code VMs was for portability unfortunately performance matters more in turns out an there are other ways to achieve portability of Smalltalk like systems!
While OS Vitualization Machine systems are popular and I might be installing them on the server hardware for their many advantages they are bascially out of the scope of the focus. Perforamce will almost certainly be better than on real machines sharing a work load with N-Vitrual-OSes!
{While there are amazing innovative efforts to make new FPGA and ASIC processor designs that are better able to deal with Smalltalk-80 Byte Codes or more efficient processors for object systems, and at some key points I'll cover them in articles. The primary focus of this Baremetal Article Series is on major shipping 32 bit and 64 bit processor architectures from AMD/Intel, ARM, Apple, and Risc-V real Bare Metal processors. Also any open sourced FPGA designs you can install a Smalltalk-80 descendant system on!
Massively Parallel New processors being developed now for Smalltalk-80 descendant systems really need to consider having many Risc-V 64 bit or 128 bit Cores or to have their Absurdly Flexible Very Wide Long Word Instructions be viable to allow other Alien Systems written in C, C++, C#, Java, Rust, Go, ... to be compiled and integrate otherwise they won't sell in mass quantities and will be predestined to fail to be viable in more than a niche market. They would also benefit from a binary translation capability to run Alien OSes from other Processor Architectures sucn as X64, ARM64, Risc-V64, etc... as Apple and other companies have used before.}.
(Definiton
term: #BareMetal
or: {Bare Metal}
or: {Baremetal}
or: {Practical Baremetal}
or: {Baremetal Application with or without an OS}
definition: {
).or: {Bare Metal}
or: {Baremetal}
or: {Practical Baremetal}
or: {Baremetal Application with or without an OS}
definition: {
This usage of general purpose practical #BareMetal means running on a real processor, any type, any technology, with or without an OS or an OS layer or OS library! The OS is orthogonal to, not relevant to the idea of the #BareMetal. OSes, if there is one, also run on the #BareMetal unless they are a virtual OS or virtual process.
The main point of Baremetal is that is real hardware not a Fake Byte Code VM or vitualization system of an OS or Virtual Machine. Ultimately it all has to bottom out at the transistors. Layers of virtual systems as if we are in Universe running on a simulated computer in some kid's computer... The notion of Bare Metal in this usage is no Byte Code Vitual Systems between you are the real hardware! No VM with fake instructions as byte codes! No VM for the OS running on a server box with 10 other OSes running! Baremetal is the base machine at the lowest level of machine instructions being compiled to directly and not through some make believe instruction no matter how simple or reduced or byte codes. Yes, X64 (like most other processors) have micro-code that presents yet another layer but if that isn't available to you as a programmer the base level of the machine code instructions are the #Baremetal!
Wikipedia's entry on "bare machine" [1] is incorrect stating that baremetal only implies "no OS", that is fine for their limited narrow scope/context area, different terms and usages in computing are the norm. Computing Science is not a precise science when it comes to the terminology, ironically enough.
The definition here is more general purpose and encompases anything written to the lowest generally available machine language using real instructions of the particular prcessor in question and not some fake byte codes of some idealized processor model.
Pratical Baremetal, in this usage means on the lowest available machine language of the processor that is available to typical low level programmers for the chip, which might mean OS level assembly/machine instructions but maybe not if it an applicated privilage process. X64 has a lower level know as their "mcirocode" but if that is not accessible to the general person programming the processors it is accademic. This is why FPGA chips and ASIC chips have become popular so that hard core techology people can make their own #BareMetal instruction sets build upon the magic of transistors and analog circuits!The ultimate is baremetal technologies I have seen are higly advanced "absurdly long very width variable length instruction sets architecutres" that are barely above the transistors themselves! More on those developments later.
} otherUsage: {The main point of Baremetal is that is real hardware not a Fake Byte Code VM or vitualization system of an OS or Virtual Machine. Ultimately it all has to bottom out at the transistors. Layers of virtual systems as if we are in Universe running on a simulated computer in some kid's computer... The notion of Bare Metal in this usage is no Byte Code Vitual Systems between you are the real hardware! No VM with fake instructions as byte codes! No VM for the OS running on a server box with 10 other OSes running! Baremetal is the base machine at the lowest level of machine instructions being compiled to directly and not through some make believe instruction no matter how simple or reduced or byte codes. Yes, X64 (like most other processors) have micro-code that presents yet another layer but if that isn't available to you as a programmer the base level of the machine code instructions are the #Baremetal!
Wikipedia's entry on "bare machine" [1] is incorrect stating that baremetal only implies "no OS", that is fine for their limited narrow scope/context area, different terms and usages in computing are the norm. Computing Science is not a precise science when it comes to the terminology, ironically enough.
The definition here is more general purpose and encompases anything written to the lowest generally available machine language using real instructions of the particular prcessor in question and not some fake byte codes of some idealized processor model.
Pratical Baremetal, in this usage means on the lowest available machine language of the processor that is available to typical low level programmers for the chip, which might mean OS level assembly/machine instructions but maybe not if it an applicated privilage process. X64 has a lower level know as their "mcirocode" but if that is not accessible to the general person programming the processors it is accademic. This is why FPGA chips and ASIC chips have become popular so that hard core techology people can make their own #BareMetal instruction sets build upon the magic of transistors and analog circuits!The ultimate is baremetal technologies I have seen are higly advanced "absurdly long very width variable length instruction sets architecutres" that are barely above the transistors themselves! More on those developments later.
Baremetal NOS, aka Baremetal Application+NOS, meaning Baremetal Application+No-Operating-System limited narrow scope definition as in Wikipedia's entry on "bare machine" [1].
}
otherUsage: {The Baremetal Processor such as the new Zen4 7950X from AMD.
}{AMD brings out the Zen 4 Processors in the Fall 2022! The basic specs are a range of processors but the top of the line in the current released lineup is the AMD Zen 4 with 5 namometer process technology, a top of the line 7950X processor with 8/16 cores or 16/32 threads, fitting in a new AM5 socket connecting to the world with the motherboard controller X670e delivering PCIe 5.0 bus performance (double PCIe 4 and four times PCIe 3, eight times PCIe 2 speeds many of which are currently still in operation!) and utilizing very fast DDR5 memory (yeah like GPU memeory speeds).}
{
{#TechTechPotatoe says in this long detailed video "AMD Ryzen 7000 / Zen 4 Review: Live Stream Edition!" aka it is here! "Streamed live on Sep 26, 2022. It's 6am PT and I've written part of script but not had time to film. Screw it, we're doing it live!"}.
{
{"A shorter summary from August 29th. "AMD just announced Ryzen 7000 for desktop, involving Zen 4. Here's a rushed video covering the announcement."}.
{
{Reviews details: "Zen 4 and Linux with the New AM5 Hardware".}.
{
{AMD also released thei plans to continue shrinking the processor technology with Zen 4c and Zen 5 to 4-namometer and 3-nanometer sizes! Wow.}.
{
{Needless to say I am working to obtain 2 of these Zen4 system for the ZokuLab™ for building ZokuTalk™ with ZokuTalk's Safe-Multi-Threading Execution Engine (not a virtual machine as I am "Burning The Disc Packs") with all real OS processes and FULL ZokuTalk MOBS™ syntax all the way down to the #BareMetal! Counter to the rumors it is not "Turtles All The Way Down", it is "ZokuTalk MOBS (Messages, Objects+Data, Blocks (all four+ varieties) Syntax all the way daown to the Bare Metal! Heck even the Memory Garbage Collector is fully safe-multi-threading!
Yes first on X64 and then on ARM64 & Risc-V64 processors. Yes that means obtaining Apple's M2 ARM64 chip when it comes out and the Risc-V64 processors. Also interested in embedded FPGA Risc-V 32 or 64 bit processors for electronics (Iot) projects. Have to wait a bit to obtain at least 2 of the 128 thread chips with dual chip mother boards for 256 threads when these Zen4 server chips are available for the server room). Building real systems just got serious!
In the mean time I continue building ZokuTalk using Pharo (versions 6 and in the process of moving to 10 and collecting up all my code from earlier Pharo and Squeak versions) on the 10 or so X64 Intel and AMD boxes from 2012-2014 that I have in the ZokuLab and ZokuServer zones! This will be an Epic upgrade to a full safe-multi-threading distributed ZokuTalk Lisp+Smalltalk-80+ technology based systems! Oh yeah the Zen 4 will be epyc as well especially when the AMD 256 thread dual chip cpus be become real!
Unfortunately my Mac Book Pro died with a bad GPU and would need to replace the GPU on the board to fix it, decided to get an M2 ARM64 Mac and laptop when they are available.
As a side note my two favorite computer languages are Assembly and Smalltalk-80 varients and soon with ZokuTalk 1.0. X64 is a dream machine compared to the MOS6502 where I cut my assembly language skills with.}.
{Resource links:
{[1] Bare Machine}.
}
] articleTextWithNote: [
{Thanks to JM for the discussion today on the other narrow usage of "baremetal" to imply "no OS", I was not aware of that limited narrow definition! I have used my usage of baremetal for many decades to include with or without an OS present and no "byte code vitual machine"! I take Steve Jobs advice to heart and Think Different and not be constrained by others values or limited definitions! Progress doesn't respect arbitrary self imposed limits!}.
{Thanks to A.L. for his confirmation of the longstanding "Baremetal+No-BC-VM" usage as meaning NO-ByteCode-VM regardless of an OS or No-OS! for over 30 years as well."}
{
].
Contents
[Article
title: {From Smalltalk to Squeak by Dan Ingalls}
by: {Peter Lount}
date: {20221011}
circa: {20011110}
version: {v0001}
discussOn: (Discuss).
{Almost 20 years ago Dan Ingalls gave a talk "From Smalltalk to Squeak" at the Computer History Museum [2] where he enumerates the many Smallktalk versions he has been involved with.}.
{
}.
{Resource links:
{[1] Yoshiki Ohshima's channel on YouTube}.
{[2] Computer History Museum}.
}
].
Contents
title: {From Smalltalk to Squeak by Dan Ingalls}
by: {Peter Lount}
date: {20221011}
circa: {20011110}
version: {v0001}
discussOn: (Discuss).
{Almost 20 years ago Dan Ingalls gave a talk "From Smalltalk to Squeak" at the Computer History Museum [2] where he enumerates the many Smallktalk versions he has been involved with.}.
{
}.
{Resource links:
{[1] Yoshiki Ohshima's channel on YouTube}.
{[2] Computer History Museum}.
}
].
Contents
[Article
title: {Fast and Dynamic}
by: {Peter Lount}
date: {20221011}
circa: {2013}
version: {v0001}
discussOn: (Discuss).
{Maxime Chevalier-Boisvert at the Universite de Montreal gives a trour how of Fast and Dynamic systems work.}.
{
{"Dynamic programming languages have long had a reputation for being slow and inefficient. The perception was that more expressive semantics necessarily require a cost in execution time. This is beginning to change as the performance gap between static and dynamic languages is visibly closing with the work being done on optimizing JIT compilers for JavaScript, Python and Lua. What does it take to make dynamic languages fast? What can we do to make them even faster? Follow me on a tour of dynamic language optimization from Smalltalk and the LISP machine to Google V8 and beyond."}.
{Resource links:
{[1] The Strange Loop Conference}.
{[2] Pointers Gone Wild | Blog by Maxime Chevalier-Boisvert}.
{[3] Love 2 Code | Twitter by Maxime Chevalier-Boisvert}.
{[4] MaximeCB | GitHub by Maxime Chevalier-Boisvert}.
}
].
Contents
title: {Fast and Dynamic}
by: {Peter Lount}
date: {20221011}
circa: {2013}
version: {v0001}
discussOn: (Discuss).
{Maxime Chevalier-Boisvert at the Universite de Montreal gives a trour how of Fast and Dynamic systems work.}.
{
{"Dynamic programming languages have long had a reputation for being slow and inefficient. The perception was that more expressive semantics necessarily require a cost in execution time. This is beginning to change as the performance gap between static and dynamic languages is visibly closing with the work being done on optimizing JIT compilers for JavaScript, Python and Lua. What does it take to make dynamic languages fast? What can we do to make them even faster? Follow me on a tour of dynamic language optimization from Smalltalk and the LISP machine to Google V8 and beyond."}.
{Resource links:
{[1] The Strange Loop Conference}.
{[2] Pointers Gone Wild | Blog by Maxime Chevalier-Boisvert}.
{[3] Love 2 Code | Twitter by Maxime Chevalier-Boisvert}.
{[4] MaximeCB | GitHub by Maxime Chevalier-Boisvert}.
}
].
Contents
On Messaging, Objects, Encapsulation, Late Binding, & Idempotence
by Peter Lount, 20190629.
Expanding on Dr. Alan Kay's often quoted statement, the most important big idea is messages being passed between objects. Objects are also key as they provide packages of related data items and code that performs operations on the data or using the data for real world computations. Encapsulation of related data items and related code methods provides protection and hiding of the "state" aka the data that relates to the state of the object. The processing details are hidden and encapsulated within code methods which also provide "Untyped Lambda Calculus" late binding of messages to methods at runtime; there is only one "type", that of Object where everything is an object that responds to messages sent to it at runtime.
It is interesting that some in the Pure Functional Langauge domain have misinterpreted Alan Kay's comment to mean that "messages alone" are the big idea and that you don't require the storing or accessing of "state" (aka data, values in variables of an object) in Objects. They make this mistake or distortion of the full Alan Kay statement so that they can preserve their notion of "functional purity" aka "referential transparency" aka "reproducable deterministic behavior" aka "idempotence" of their pure function computational model where "pure functions" only compute using the function's inputs to produce it's outputs. The notion of an object violates this "pure" model as it stores state beyond the life of the pure function or accesses stored state not passed into the pure function.
The Pure Functional Language focus is needlessly too narrowed to the scope of a single pure function as their primary approach. Referential Transparency, Reproducable Deterministic Behavior, & Idempotence can be achieved in any scope size of computation involving millions of objects and thousands of methods as long as the entire computation scope has the pure or idempotent property of only computing using the inputs to compute the outputs (and not accessing stored state that was not part of the set of inputs or writing state that was not part of the output set of objects; actually this can be relaxed in some cases such as writing a not used for input log file).
The image above is an example of the use of an idempotent reproducable deterministic computation in ZokuTalk using the wider scope within a Block that contains an Object of the Cube class that instantiates an instance and fills in the x, y, and z dimensions using the input parameters to the block and then computes the result in an idempotent manner. This example is quite simple and can be done in any Smalltalk by sending the block value or value:value:value: with the inputs. ZokuTalk takes it further by ensuring that the computation within the block is a "pure isolated transaction" by preventing it from accessing state from outside the block and raising an exception if the code attempts to do so.
One reason that idempotent computations and processing is important and useful is that if a block of code, with as many objects as you want, is referrentially transparent, has reproducable deterministic behavior and is idempotent, aka a pure block, it can safely be executed in parallel with a simple fork operation in Smalltalk type systems, or even better it can be executed in parallel using a native operating system thread of its own (as long as the language system has parallel garbage collection or can guarantee no movement of the objects in the native os forked off threads, and can guarantee isolation from other threads modifying objects in use by computation thread).
In ZokuTalk enforcing "pure isolated transactions" provides a systematic gurrantee that such parallel execution is isolated thus thread safe as long as you also heed thread synchronization such as using a Future object, parallel join or other thread synchronization techniques.
Pure functions as well as pure referentially transparent idempotent blocks of code are timeless, in that they can be computed in parallel at any time in the past and present. If the results of the computation are cached one need not recompute when the same inputs are used again and referrentially transparency is achieved; many compilers make use this technique to great effect for optimizations.
There are many benefits to the ideas from pure functional programming languages that ZokuTalk has inherited, and that even other languages can take advantage of if the programmer takes the manual care to ensure the idempotence principle. Heck, in one video game I wrote in 6502 Assembly Language the game map generator was fully idempotent across copies of the game by just typing in the same 12 hexidecimal number into other copies the game! I wrote that game back in the mid 1980's before I even new about pure functional languages showing that these techniques have been around since the dawn of time of computing.
Contents
by Peter Lount, 20190629.
Expanding on Dr. Alan Kay's often quoted statement, the most important big idea is messages being passed between objects. Objects are also key as they provide packages of related data items and code that performs operations on the data or using the data for real world computations. Encapsulation of related data items and related code methods provides protection and hiding of the "state" aka the data that relates to the state of the object. The processing details are hidden and encapsulated within code methods which also provide "Untyped Lambda Calculus" late binding of messages to methods at runtime; there is only one "type", that of Object where everything is an object that responds to messages sent to it at runtime.
It is interesting that some in the Pure Functional Langauge domain have misinterpreted Alan Kay's comment to mean that "messages alone" are the big idea and that you don't require the storing or accessing of "state" (aka data, values in variables of an object) in Objects. They make this mistake or distortion of the full Alan Kay statement so that they can preserve their notion of "functional purity" aka "referential transparency" aka "reproducable deterministic behavior" aka "idempotence" of their pure function computational model where "pure functions" only compute using the function's inputs to produce it's outputs. The notion of an object violates this "pure" model as it stores state beyond the life of the pure function or accesses stored state not passed into the pure function.
The Pure Functional Language focus is needlessly too narrowed to the scope of a single pure function as their primary approach. Referential Transparency, Reproducable Deterministic Behavior, & Idempotence can be achieved in any scope size of computation involving millions of objects and thousands of methods as long as the entire computation scope has the pure or idempotent property of only computing using the inputs to compute the outputs (and not accessing stored state that was not part of the set of inputs or writing state that was not part of the output set of objects; actually this can be relaxed in some cases such as writing a not used for input log file).
The image above is an example of the use of an idempotent reproducable deterministic computation in ZokuTalk using the wider scope within a Block that contains an Object of the Cube class that instantiates an instance and fills in the x, y, and z dimensions using the input parameters to the block and then computes the result in an idempotent manner. This example is quite simple and can be done in any Smalltalk by sending the block value or value:value:value: with the inputs. ZokuTalk takes it further by ensuring that the computation within the block is a "pure isolated transaction" by preventing it from accessing state from outside the block and raising an exception if the code attempts to do so.
One reason that idempotent computations and processing is important and useful is that if a block of code, with as many objects as you want, is referrentially transparent, has reproducable deterministic behavior and is idempotent, aka a pure block, it can safely be executed in parallel with a simple fork operation in Smalltalk type systems, or even better it can be executed in parallel using a native operating system thread of its own (as long as the language system has parallel garbage collection or can guarantee no movement of the objects in the native os forked off threads, and can guarantee isolation from other threads modifying objects in use by computation thread).
In ZokuTalk enforcing "pure isolated transactions" provides a systematic gurrantee that such parallel execution is isolated thus thread safe as long as you also heed thread synchronization such as using a Future object, parallel join or other thread synchronization techniques.
Pure functions as well as pure referentially transparent idempotent blocks of code are timeless, in that they can be computed in parallel at any time in the past and present. If the results of the computation are cached one need not recompute when the same inputs are used again and referrentially transparency is achieved; many compilers make use this technique to great effect for optimizations.
There are many benefits to the ideas from pure functional programming languages that ZokuTalk has inherited, and that even other languages can take advantage of if the programmer takes the manual care to ensure the idempotence principle. Heck, in one video game I wrote in 6502 Assembly Language the game map generator was fully idempotent across copies of the game by just typing in the same 12 hexidecimal number into other copies the game! I wrote that game back in the mid 1980's before I even new about pure functional languages showing that these techniques have been around since the dawn of time of computing.
Contents
[Article
title: {Brain Upgrade Going Well}
by: {Peter Lount}
date: {20220923}
version: {v0019}
discussOn: (Discuss).
{Steve Jobs paid for a professional Caricature Artist to draw this caricature of me at a NeXTWorld Expo in San Francisco, and I also consulted one on one with Steve Jobs the result of which improved the OpenStep Application Kit (and Apple App Kit). ... I upgraded it today to indicate my brain has been replaced by technology and science brain! Also my hair was replaced, doh! Oh well, a bonus tradeoff.}.
{
{Advancing Smalltalk-80 to a whole new dimension of capabilities is what ZokuTalk™ is all about aiming at mass adoption of hundreds of applications in an expanding set of wide diverse areas. That is the target. Will it be achieved? Action through time makes it so!}.
{
{The Smalltak.org and Zoku™ servers at the Harbor Center in Downtown Vancouver are being upgraded; the network connections have been upgraded and a few glitches that took the sitea offline have finally been resolved. ZokuTalk's extensive Language Grammar Parsers are being implemented with serious advancements to the State of The Art of Computer Science. That is the target. Will it be achieved? Action through time makes it so!}.
{ZokuTalk prioritizes Messages per Alan Kay. The syntax of messages is refined to enable vast new capabilites with a new dimensional door that open unparallelled opportunites including in Safe Parallel Message sending, receiving, futures, and distribution to many ZokuNodes™ in a coprorate #ZokuCluster™ or Free Forming Cooperative Zoku Cluster on the Interwebs. Messages are the key distinction, along with other ZokuTalk essentials make up the MOBS™ syntax improvements.}.
{It is Messages all the way down, not Turtles! Messages!}.
{ZokuTalk Objects and Data, from simple to complex forms, enable the vast form of data to be absorbed, incorporated, and supported. The goal is any kind of data that is out there! Yes even, ick, Relational Data!}.
{Blocks of all kinds shake the objective reality of representation systems. I reviewed all the Smalltalk-80 syntax a few decades ago when I was researching extending Smalltalk-80 to go beyond. Alan Kay took notice and we had a few months of email exchanges about the grammar elements. I got the impression that Alan wanted to eliminate blocks, both () and [], similar to earlier Smalltalk systems, or HyperCard, which is a very worthwhile goal. However by that time the pure unadultarated power of Square Bracket Block Closures [] had infected my Quantum Braining Unit! Our research paths diverged into parallel universes!}.
{It was very nice to briefly communicate and interact on research with one of my heroes, Alan Kay. Now we can see the Full Power of a Fully Operational Battle Star, er, Battle Star ZokuTalk System with the Full Power of Expanded MOBS Blocks, actually the Full Power of all MOBS elements that work together to vastly increase the power of what computer systems can do for people!}.
{The Blocks part of MOBS:}.
{Parentheses Blocks for (... immediate execution ...), and
Square Bracket Block Closures [... deferred execution ...] value do what they do in typical Smalltalk-80 and far beyond as both are upgraded to open new dimensions and capibilities.}.
{Additional new dimensional doors are opened with Curly Bracket Nested Alien Text {...{... immediate execution ...}...} enabling the re-presentation of #AlienGrammars to be incorporated into ZokuTalk source code, parsed and dealt with in other ways, communicated, and stored in ZokuTalk Object Data Stores!}.
{
{The most potent Blocks are doors to new dimensions created with Guillemets, sounds sort of like "gil-mets", are a pair of punctuation marks in the form of sideways double chevrons, « and », used as quotation marks, yes really, in a number of languages!}.
{ZokuTalk's «macros» enable the full first class general purpose ZokuTalk MOBS programming language, with «MOBS» syntax to be used for meta programming (as in incorporating much of the Lisp heritage)!}.
{Guillemets «macros» quote «Full First Class MOBS Syntax».}.
{No little language for «macros»!!}.
{Even the «Type system», primarily for interacting with Foreign Function Interfaces but also for Type Happy Programmers, in ZokuTalk uses the full general purpose language thus is can model far more possibilities than static type languages can with their very limited little type languages.}.
{«macros» execute at compile time!}.
{«macros» can modify the code the compiler generates, they can do compile time code construction of parts or whole systems, they can rewrite code, they are also compile time system directives, and much much more! Of course the code in the «macro» can also be executed at immediate run time as in the IDE or deployed systems as needed!}.
{Blocks open multiple dimensions that won't be disovered until ZokuTalk 1.0 Independence Day IDE in is our hands to see what you can do with it. ZokuTalk is not your granfathers Smaltalk-80 or Lisp or Erlang or 100 other languages that provided insights and direct contributions, it is radical shift in Computing Science. It took years for the full expression of the power of Smalltalk-80 blocks to be fully applied, some times new optimized compilers (as in the case of #ifNil:ifNotNil: and variants) to be implemented. Innovating take time! Knowing what to innovate takes even more time!}.
{That is the target. Will it be achieved? Action through time makes it so! If I fail at least it was attempting to Invent The Future Beyond What others Imagine The Future To Be!}.}.
{Code is Messages is Objects is Blocks is Macros is Meta is Data is Text is Code... an Infinite Loop}.
{
{Don't worry about what others are doing to invent the future but don't igore them either! Innovate beyond inventing the future! The long future awaits and needs us!}.
{If you want to help with ZokuTalk contact me and send money or provide contract work!}.
] articleTextWithNote: [
Note text: {This article is in an executable ZokuTalk source code format and will be converted to HTML automatically. A block with an Article object defines the first object is then followed by a series of {} alien text objects where the alien grammar is English and closes with this block Note instance itself. Once the ZokuTalk parser is fully an operational battle station this parsable text file to be converted to a .html.fragment for incorporation into the Smalltalk AIMS web site for presentation. All the articles herein and on other web sites and also the viable legacy articles from the old Smalltalk site of yesteryear will be converted to this standardized block data format.
ps. This article inherits capabilities from Lisp with the Article action object first and data objects to be operated upon following! A truly object-oriented flavor of Lisp (like no other, perhaps)! ZokuTalk inherits as much from Lisp as it does from Smalltalk-80! Sweet! Oh and we've not yet gone into Idempotent Functional Languages such as Erlang! Muh ha ha, far more coming, this is just the tip of the Earth Destroying Asteroid that is a Fully Operational ZokuTalk Death Star, er, Collaborative System!}
].
Contents
title: {Brain Upgrade Going Well}
by: {Peter Lount}
date: {20220923}
version: {v0019}
discussOn: (Discuss).
{Steve Jobs paid for a professional Caricature Artist to draw this caricature of me at a NeXTWorld Expo in San Francisco, and I also consulted one on one with Steve Jobs the result of which improved the OpenStep Application Kit (and Apple App Kit). ... I upgraded it today to indicate my brain has been replaced by technology and science brain! Also my hair was replaced, doh! Oh well, a bonus tradeoff.}.
{
{Advancing Smalltalk-80 to a whole new dimension of capabilities is what ZokuTalk™ is all about aiming at mass adoption of hundreds of applications in an expanding set of wide diverse areas. That is the target. Will it be achieved? Action through time makes it so!}.
{
{The Smalltak.org and Zoku™ servers at the Harbor Center in Downtown Vancouver are being upgraded; the network connections have been upgraded and a few glitches that took the sitea offline have finally been resolved. ZokuTalk's extensive Language Grammar Parsers are being implemented with serious advancements to the State of The Art of Computer Science. That is the target. Will it be achieved? Action through time makes it so!}.
{ZokuTalk prioritizes Messages per Alan Kay. The syntax of messages is refined to enable vast new capabilites with a new dimensional door that open unparallelled opportunites including in Safe Parallel Message sending, receiving, futures, and distribution to many ZokuNodes™ in a coprorate #ZokuCluster™ or Free Forming Cooperative Zoku Cluster on the Interwebs. Messages are the key distinction, along with other ZokuTalk essentials make up the MOBS™ syntax improvements.}.
{It is Messages all the way down, not Turtles! Messages!}.
{ZokuTalk Objects and Data, from simple to complex forms, enable the vast form of data to be absorbed, incorporated, and supported. The goal is any kind of data that is out there! Yes even, ick, Relational Data!}.
{Blocks of all kinds shake the objective reality of representation systems. I reviewed all the Smalltalk-80 syntax a few decades ago when I was researching extending Smalltalk-80 to go beyond. Alan Kay took notice and we had a few months of email exchanges about the grammar elements. I got the impression that Alan wanted to eliminate blocks, both () and [], similar to earlier Smalltalk systems, or HyperCard, which is a very worthwhile goal. However by that time the pure unadultarated power of Square Bracket Block Closures [] had infected my Quantum Braining Unit! Our research paths diverged into parallel universes!}.
{It was very nice to briefly communicate and interact on research with one of my heroes, Alan Kay. Now we can see the Full Power of a Fully Operational Battle Star, er, Battle Star ZokuTalk System with the Full Power of Expanded MOBS Blocks, actually the Full Power of all MOBS elements that work together to vastly increase the power of what computer systems can do for people!}.
{The Blocks part of MOBS:}.
{Parentheses Blocks for (... immediate execution ...), and
Square Bracket Block Closures [... deferred execution ...] value do what they do in typical Smalltalk-80 and far beyond as both are upgraded to open new dimensions and capibilities.}.
{Additional new dimensional doors are opened with Curly Bracket Nested Alien Text {...{... immediate execution ...}...} enabling the re-presentation of #AlienGrammars to be incorporated into ZokuTalk source code, parsed and dealt with in other ways, communicated, and stored in ZokuTalk Object Data Stores!}.
{
{The most potent Blocks are doors to new dimensions created with Guillemets, sounds sort of like "gil-mets", are a pair of punctuation marks in the form of sideways double chevrons, « and », used as quotation marks, yes really, in a number of languages!}.
{ZokuTalk's «macros» enable the full first class general purpose ZokuTalk MOBS programming language, with «MOBS» syntax to be used for meta programming (as in incorporating much of the Lisp heritage)!}.
{Guillemets «macros» quote «Full First Class MOBS Syntax».}.
{No little language for «macros»!!}.
{Even the «Type system», primarily for interacting with Foreign Function Interfaces but also for Type Happy Programmers, in ZokuTalk uses the full general purpose language thus is can model far more possibilities than static type languages can with their very limited little type languages.}.
{«macros» execute at compile time!}.
{«macros» can modify the code the compiler generates, they can do compile time code construction of parts or whole systems, they can rewrite code, they are also compile time system directives, and much much more! Of course the code in the «macro» can also be executed at immediate run time as in the IDE or deployed systems as needed!}.
{Blocks open multiple dimensions that won't be disovered until ZokuTalk 1.0 Independence Day IDE in is our hands to see what you can do with it. ZokuTalk is not your granfathers Smaltalk-80 or Lisp or Erlang or 100 other languages that provided insights and direct contributions, it is radical shift in Computing Science. It took years for the full expression of the power of Smalltalk-80 blocks to be fully applied, some times new optimized compilers (as in the case of #ifNil:ifNotNil: and variants) to be implemented. Innovating take time! Knowing what to innovate takes even more time!}.
{That is the target. Will it be achieved? Action through time makes it so! If I fail at least it was attempting to Invent The Future Beyond What others Imagine The Future To Be!}.}.
{Code is Messages is Objects is Blocks is Macros is Meta is Data is Text is Code... an Infinite Loop}.
{
{Don't worry about what others are doing to invent the future but don't igore them either! Innovate beyond inventing the future! The long future awaits and needs us!}.
{If you want to help with ZokuTalk contact me and send money or provide contract work!}.
] articleTextWithNote: [
Note text: {This article is in an executable ZokuTalk source code format and will be converted to HTML automatically. A block with an Article object defines the first object is then followed by a series of {} alien text objects where the alien grammar is English and closes with this block Note instance itself. Once the ZokuTalk parser is fully an operational battle station this parsable text file to be converted to a .html.fragment for incorporation into the Smalltalk AIMS web site for presentation. All the articles herein and on other web sites and also the viable legacy articles from the old Smalltalk site of yesteryear will be converted to this standardized block data format.
ps. This article inherits capabilities from Lisp with the Article action object first and data objects to be operated upon following! A truly object-oriented flavor of Lisp (like no other, perhaps)! ZokuTalk inherits as much from Lisp as it does from Smalltalk-80! Sweet! Oh and we've not yet gone into Idempotent Functional Languages such as Erlang! Muh ha ha, far more coming, this is just the tip of the Earth Destroying Asteroid that is a Fully Operational ZokuTalk Death Star, er, Collaborative System!}
].
Contents
[Article
title: {"Liberating the Smalltalk lurking in C and Unix"}
by: {Peter Lount}
date: {20221010, 20221013}
circa: {20140917-20140919}
version: {v0005}
discussOn: (Discuss).
{In the video "Liberating the Smalltalk lurking in C and Unix" by Stephen Kell" by at the Strange Loop Conference [1] he explores the dynamic capabilities of Smalltalk and how to add Metadata programming capabilities to C, and Unix giving more dynamic power to them.}.
{"What's the purpose of all this? Unix abstractions are fairly simple and fairly general, but they are not humane, and they invite fragmentation. By 'not humane', I mean that they are error-prone and difficult to experiment with interactively. By 'fragmentation', I mean they invite building higher-level abstractions in mutually opaque and incompatible ways (think language VMs, file formats, middlewares...). To avoid these, liballocs is a minimal extension of Unix-like abstractions broadly in the spirit of Smalltalk-style dynamism, designed to counter both of these problems."}.
{
}.
}.
{"Most programmers make a clear distinction between dynamic, interpreted languages such as Smalltalk and Ruby, and statically compiled languages such as C and C++. Dynamic languages are seen as being slow, yet easy to use, and with advantages of introspection, integrated tooling, flexibility and rapid prototyping. Compiled languages are seen as fast, yet lacking the aforementioned benefits, and requiring understanding of impenetrable binary files and esoteric tools. Interfacing the two is even worse, involving FFI "dark magic", complicated further by the fact that the infrastructures supporting one or other kind of language work quite differently. "Static" generate binaries sitting directly on the operating system, while dynamic languages exist inside interpreter-like virtual machines."
Does it have to be this way, or is there a unifying model? Can we get the best of both worlds: fast compiled binaries that nevertheless support introspection and other dynamism, and dynamic languages that integrate with compiled code without FFI magic? This talk introduces liballocs, an infrastructure which exposes the dynamism hiding in the arcane linking and debugging infrastructure of a Unix process, along with a small extension to C toolchains that enables fast dynamic access to data created by statically compiled code. Together they can be said to unleash a "hidden Smalltalk" inside the C and Unix model of programs and processes. Come prepared for a journey that takes your perceptions of the boundaries between dynamic and static languages and turns them on its head."}.
{
{"Any sufficiently complicated C or Fortran program contains an ad hoc,
informally-specified, bug-ridden,
slow implementation of half of Common Lisp." [... er, Smalltalk!]
- Philip Greenspun's Tenth Rule
}.
{
{
{"Languages should be views, not worlds"! - Stehpen R. Kell.
}.
{I concur!
ZokuTalk™ really brings languages such as Smalltalk-80 with refined MOBS (Message, Object+Data, Blocks (all four kinds) Syntax) together in a more dynamic and dramatic way. Sure it is in progress, aways off but the design is on target! Easier FFI for example with ZokuTalk becoming the fastest way to leverage Linked Libraries loaded at runtime (to respect their Alien Licenses): load and use! Other features in progress!}.
{Deep quote:
}.
{Resource links:
{[1] The Strange Loop Conference}.
{[2] liballocs on Git Hub.}.
{[3] Stephen Kell research liballocs on humprog.org.}.
}
].
Contents
title: {"Liberating the Smalltalk lurking in C and Unix"}
by: {Peter Lount}
date: {20221010, 20221013}
circa: {20140917-20140919}
version: {v0005}
discussOn: (Discuss).
{In the video "Liberating the Smalltalk lurking in C and Unix" by Stephen Kell" by at the Strange Loop Conference [1] he explores the dynamic capabilities of Smalltalk and how to add Metadata programming capabilities to C, and Unix giving more dynamic power to them.}.
{"What's the purpose of all this? Unix abstractions are fairly simple and fairly general, but they are not humane, and they invite fragmentation. By 'not humane', I mean that they are error-prone and difficult to experiment with interactively. By 'fragmentation', I mean they invite building higher-level abstractions in mutually opaque and incompatible ways (think language VMs, file formats, middlewares...). To avoid these, liballocs is a minimal extension of Unix-like abstractions broadly in the spirit of Smalltalk-style dynamism, designed to counter both of these problems."}.
{
}.
{"Most programmers make a clear distinction between dynamic, interpreted languages such as Smalltalk and Ruby, and statically compiled languages such as C and C++. Dynamic languages are seen as being slow, yet easy to use, and with advantages of introspection, integrated tooling, flexibility and rapid prototyping. Compiled languages are seen as fast, yet lacking the aforementioned benefits, and requiring understanding of impenetrable binary files and esoteric tools. Interfacing the two is even worse, involving FFI "dark magic", complicated further by the fact that the infrastructures supporting one or other kind of language work quite differently. "Static" generate binaries sitting directly on the operating system, while dynamic languages exist inside interpreter-like virtual machines."
Does it have to be this way, or is there a unifying model? Can we get the best of both worlds: fast compiled binaries that nevertheless support introspection and other dynamism, and dynamic languages that integrate with compiled code without FFI magic? This talk introduces liballocs, an infrastructure which exposes the dynamism hiding in the arcane linking and debugging infrastructure of a Unix process, along with a small extension to C toolchains that enables fast dynamic access to data created by statically compiled code. Together they can be said to unleash a "hidden Smalltalk" inside the C and Unix model of programs and processes. Come prepared for a journey that takes your perceptions of the boundaries between dynamic and static languages and turns them on its head."}.
{
{
informally-specified, bug-ridden,
slow implementation of half of Common Lisp." [... er, Smalltalk!]
- Philip Greenspun's Tenth Rule
}.
{
{
{
}.
{I concur!
ZokuTalk™ really brings languages such as Smalltalk-80 with refined MOBS (Message, Object+Data, Blocks (all four kinds) Syntax) together in a more dynamic and dramatic way. Sure it is in progress, aways off but the design is on target! Easier FFI for example with ZokuTalk becoming the fastest way to leverage Linked Libraries loaded at runtime (to respect their Alien Licenses): load and use! Other features in progress!}.
{Deep quote:
What's the purpose of all this? Unix abstractions are fairly simple and fairly general, but they are not humane, and they invite fragmentation. By 'not humane', I mean that they are error-prone and difficult to experiment with interactively. By 'fragmentation', I mean they invite building higher-level abstractions in mutually opaque and incompatible ways (think language VMs, file formats, middlewares...). To avoid these, liballocs is a minimal extension of Unix-like abstractions broadly in the spirit of Smalltalk-style dynamism, designed to counter both of these problems. These provide a foundation for features such as:
To borrow Greenspun's tenth rule, this is because each of these earlier prototypes contains an ad-hoc, bug-ridden and slow implementation of a small fraction of liballocs. The goal of liballocs is to offer a flexible, pluralist structure for growing these features on -- in a way that transparently adds thse capabilities to existing codebases, rather than requiring up-front "buy-in". It's not a framework; you don't usually write code against its API, or port your code to it. Instead, it extends the fabric which already builds and runs your code. The research programme around liballocs is working towards demonstrating the practicality of this approach, by building instances of several of the above systems/services, at modest effort and capable of co-existence.
run-time type checking in C, C++ and other unsafe languages
type-checked linking, including dynamic linking
rich debugging/tracing tools with data visibility (think: better ltrace/strace)
high-level I/O abstractions over memory-mapped data (think: realloc() part of a file)
multi-language programming without foreign function interfacing APIs
flexible "live" programming
robust and efficient dynamic software update
precise garbage collection across a whole address space
efficient and flexible checkpoint/restore
seamless debugging across native, interpreted and instrumented code
snapshotting and fast startup via allocation-graph dump/reload
easy serialization of arbitrary objects
fine-grained versioning and adaptation of binary interfaces
high-level abstractions for memory-mapped I/O
hosting multiple ABIs in one process, interoperably
reliable inter-process shared-memory data structures
simplifying linking and loading mechanisms
recompilation-based dynamic optimisation of whole processes
robust object-level copy-on-write (+ tools based on it)
robust shadow memory (+ tools based on it)
orthogonal persistence
image-based development
your idea here!
What's novel? Although the run-time facilities of liballocs are (I contend) richer than what has existed before in any Unix-like system, you might counter that many of the above goals have apparently been achieved, at least as far as proof-of-concept, by earlier research or development prototypes. This has been through heroic efforts of many people... but evidently these efforts have not "stuck" in the sense of becoming part of the fabric of a commodity distribution. When this phenomenon repeats itself, it becomes a research problem to itself -- not simply a matter of tech transfer or follow-through. Many of the resulting prototypes lack features required for real-world use -- awareness of custom memory allocators is a common lack -- and generally they are realised in mutually incompatible ways, for want of the right abstractions.type-checked linking, including dynamic linking
rich debugging/tracing tools with data visibility (think: better ltrace/strace)
high-level I/O abstractions over memory-mapped data (think: realloc() part of a file)
multi-language programming without foreign function interfacing APIs
flexible "live" programming
robust and efficient dynamic software update
precise garbage collection across a whole address space
efficient and flexible checkpoint/restore
seamless debugging across native, interpreted and instrumented code
snapshotting and fast startup via allocation-graph dump/reload
easy serialization of arbitrary objects
fine-grained versioning and adaptation of binary interfaces
high-level abstractions for memory-mapped I/O
hosting multiple ABIs in one process, interoperably
reliable inter-process shared-memory data structures
simplifying linking and loading mechanisms
recompilation-based dynamic optimisation of whole processes
robust object-level copy-on-write (+ tools based on it)
robust shadow memory (+ tools based on it)
orthogonal persistence
image-based development
your idea here!
To borrow Greenspun's tenth rule, this is because each of these earlier prototypes contains an ad-hoc, bug-ridden and slow implementation of a small fraction of liballocs. The goal of liballocs is to offer a flexible, pluralist structure for growing these features on -- in a way that transparently adds thse capabilities to existing codebases, rather than requiring up-front "buy-in". It's not a framework; you don't usually write code against its API, or port your code to it. Instead, it extends the fabric which already builds and runs your code. The research programme around liballocs is working towards demonstrating the practicality of this approach, by building instances of several of the above systems/services, at modest effort and capable of co-existence.
{Resource links:
{[1] The Strange Loop Conference}.
{[2] liballocs on Git Hub.}.
{[3] Stephen Kell research liballocs on humprog.org.}.
}
].
Contents
[Article
title: {A Canticle for Smalltalk}
by: {Peter Lount}
date: {20221006}
version: {v0001}
discussOn: (Telegram link: {t.me/MOBSBlockHeads}).
{In the video "A Canticle for Smalltalk" by Smalltalk Renaissance we explore the history of Smalltalk.}.
{
}
].
Contents
title: {A Canticle for Smalltalk}
by: {Peter Lount}
date: {20221006}
version: {v0001}
discussOn: (Telegram link: {t.me/MOBSBlockHeads}).
{In the video "A Canticle for Smalltalk" by Smalltalk Renaissance we explore the history of Smalltalk.}.
{
].
Contents
Smalltalk Systems
There are many excellent Smalltalk Systems, open source and commercial, for you to learn from, have fun with, use to build apps, deploy serious applications within companies large and small as well as on the web or phones. A number of the commercial Smalltalks also have free personal use or good development licenses, check them out.
OpenSource (License)
Pharo Smalltalk (MIT).
Squeak Smalltalk (MIT, portions Apache).
Cuis Smalltalk (MIT).
GNU Smalltalk (GPL).
Dolphin Smalltalk (MIT)
Amber Smalltalk (MIT).
Redline Smalltalk (MIT).
Essence# Smalltalk (BSD).
Susie Scripting Smalltalk (Public Domain).
Little Smalltalk (Various, Public Domain, MIT, ...).
Bee Smalltalk. (MIT), release coming soon apparently. GitHub. Bee Blog. Paper (PDF).
Newspeak Lanaguage (Apache 2.0 license, portions MIT).
Scratch Smalltalk Wiki (GPLv2 and Scratch Source Code License).
Commercial
Cincom VisualWorks Smalltalk
Instantiations VisualAge Smalltalk
GemTalkSystems Database Server Smalltalk
Smalltalk/MT
Smalltalk/X (Free to use).
Smalltalk Like
Self Language
io Language
Slate Language
Contents
There are many excellent Smalltalk Systems, open source and commercial, for you to learn from, have fun with, use to build apps, deploy serious applications within companies large and small as well as on the web or phones. A number of the commercial Smalltalks also have free personal use or good development licenses, check them out.
OpenSource (License)
Pharo Smalltalk (MIT).
Squeak Smalltalk (MIT, portions Apache).
Cuis Smalltalk (MIT).
GNU Smalltalk (GPL).
Dolphin Smalltalk (MIT)
Amber Smalltalk (MIT).
Redline Smalltalk (MIT).
Essence# Smalltalk (BSD).
Susie Scripting Smalltalk (Public Domain).
Little Smalltalk (Various, Public Domain, MIT, ...).
Bee Smalltalk. (MIT), release coming soon apparently. GitHub. Bee Blog. Paper (PDF).
Newspeak Lanaguage (Apache 2.0 license, portions MIT).
Scratch Smalltalk Wiki (GPLv2 and Scratch Source Code License).
Commercial
Cincom VisualWorks Smalltalk
Instantiations VisualAge Smalltalk
GemTalkSystems Database Server Smalltalk
Smalltalk/MT
Smalltalk/X (Free to use).
Smalltalk Like
Self Language
io Language
Slate Language
Contents
Components & Sub Systems
Usefull Smalltalk open source components and sub systems:
SeaSide web app engine (Pharo, Squeak, Gemstone/S, Cincom, etc.
Useful Smalltalk open source components from Peter W. Lount:
SortCritter for Multi Column Sorting.
ProjectManager for easy project file outs.
Contents
Usefull Smalltalk open source components and sub systems:
SeaSide web app engine (Pharo, Squeak, Gemstone/S, Cincom, etc.
Useful Smalltalk open source components from Peter W. Lount:
SortCritter for Multi Column Sorting.
ProjectManager for easy project file outs.
Contents
Legacy Smalltalk.org Articles at Archive.org
Unfortunately due to unforseen issues Smalltalk.org servers crashed, as well as life unfolding, the doh backups were unrecoverable a number of times, and recently major internet hardware upgrades at Harbour Centre server room facility where the Smalltalk.org servers upgraded all their equipment and we had difficulty finding the DNS issues; these issues are resolved with new OSes being installed shortly. In the meantime here are links to Archive.org Smalltak.org articles as I work to get them back online intime using ZokuTalk systems.
Links to Legacy Archive.org Smalltak.org articles:
List of All Legacy Smalltalk.org/articles/
Video Collections & Categories
Smalltalk: Getting The Message | The Essentials of Message-Oriented Programming with Smalltalk
2006 Smalltalk Solutions Conference
Key Smalltalk People | Alan Kay | Dan Ingalls
Learning to Talk: Introduction to Talking
ANSI Smalltalk Standard Group ANNOUNCEMENT
The Essence of Smalltalk
Bytecode-to-bytecode adaptive optimization for Smalltalk
Google's Failure
Dynamic Runtime Type-Object-Class Inference
Exploring Type Safety in Smalltalk
Dynamic Systems are where Capability Rules
Moving Forward Towards The Right Kind of More Less
Smalltalk Traits Expressing Themselves
Smalltalk Obsoletes Java
First Steps in Susie Smalltalk Scripting
Susie Smalltalk
Live Susie Smalltalk Class Hierarchy
If you're tired of drinking all that coffee, and you don't like your C flat, how 'bout some good 'ol Smalltalk to help soothe the soul?
The Boring Now leads to the Exciting Future
Shaping Evolution with Iterative Design
The Mortal Coil of Smalltalk
The Futility of Adding Types to a Dynamic Language
Extending Encapsulation For Smalltalk
Openings for the Future of Smalltalk
Achilles Heal? Tower of Babel? How about Communication?
An Introduction To Smalltalk Via "10000 factorial"
Static Typing Tunnel Vision Can Be Deadly
Some Basic F-Script Examples
The Squeak Curly Brace Extension to Smalltalk
Extending Smalltalk
The F-Script Smalltalk Extensions
Simplicity Makes the Difference that Makes the Difference
Optimizing Person-time, Not Computer-Time
Validations Are Best Done At Runtime With Full Language Symantics, Addendum 1
Dynamic Languages Permit and Benefit from Multi-Type Variables
Validations Are Best Done At Runtime With Full Language Symantics
Here's to Dynamic Freedom!
Alan Kay to deliver Turing Lecture at OOPSLA 2004!
The Cult of the Complex and Cryptic Stack Up Another Win
Inventing the Future of Collaborative Computing with Zoku
Abstract Syntax Trees Rule!
Devoted to complexity? Why?
The Case for First Class Messages
Smalltalk Shell Scripting
Indepth Interview with Cincom's Founder Thomas M. Nies
Progress on the Frontiers: Technology and Progress with Doug Engelbart and Alan Kay
User Interface Design: Avoiding the Lack of Design in Your User Interface
Donald Knuth: Rewriting the Bible in 0's and 1's
Howard Rheingold: Food for Throught
Alan Kay: The Computer "Revolution" Hasn't Happened Yet!
A Brief Introduction to Smalltalk
Why Fear, Uncertainty and Doubt?
Article Series List
MicroSeeker PIC/Smalltalk
Versions of Smalltalk
News
JP Morgan's Das Kapital Earns Profits
Applications Built Using Smalltalk
Contents
Unfortunately due to unforseen issues Smalltalk.org servers crashed, as well as life unfolding, the doh backups were unrecoverable a number of times, and recently major internet hardware upgrades at Harbour Centre server room facility where the Smalltalk.org servers upgraded all their equipment and we had difficulty finding the DNS issues; these issues are resolved with new OSes being installed shortly. In the meantime here are links to Archive.org Smalltak.org articles as I work to get them back online intime using ZokuTalk systems.
Links to Legacy Archive.org Smalltak.org articles:
List of All Legacy Smalltalk.org/articles/
Video Collections & Categories
Smalltalk: Getting The Message | The Essentials of Message-Oriented Programming with Smalltalk
2006 Smalltalk Solutions Conference
Key Smalltalk People | Alan Kay | Dan Ingalls
Learning to Talk: Introduction to Talking
ANSI Smalltalk Standard Group ANNOUNCEMENT
The Essence of Smalltalk
Bytecode-to-bytecode adaptive optimization for Smalltalk
Google's Failure
Dynamic Runtime Type-Object-Class Inference
Exploring Type Safety in Smalltalk
Dynamic Systems are where Capability Rules
Moving Forward Towards The Right Kind of More Less
Smalltalk Traits Expressing Themselves
Smalltalk Obsoletes Java
First Steps in Susie Smalltalk Scripting
Susie Smalltalk
Live Susie Smalltalk Class Hierarchy
If you're tired of drinking all that coffee, and you don't like your C flat, how 'bout some good 'ol Smalltalk to help soothe the soul?
The Boring Now leads to the Exciting Future
Shaping Evolution with Iterative Design
The Mortal Coil of Smalltalk
The Futility of Adding Types to a Dynamic Language
Extending Encapsulation For Smalltalk
Openings for the Future of Smalltalk
Achilles Heal? Tower of Babel? How about Communication?
An Introduction To Smalltalk Via "10000 factorial"
Static Typing Tunnel Vision Can Be Deadly
Some Basic F-Script Examples
The Squeak Curly Brace Extension to Smalltalk
Extending Smalltalk
The F-Script Smalltalk Extensions
Simplicity Makes the Difference that Makes the Difference
Optimizing Person-time, Not Computer-Time
Validations Are Best Done At Runtime With Full Language Symantics, Addendum 1
Dynamic Languages Permit and Benefit from Multi-Type Variables
Validations Are Best Done At Runtime With Full Language Symantics
Here's to Dynamic Freedom!
Alan Kay to deliver Turing Lecture at OOPSLA 2004!
The Cult of the Complex and Cryptic Stack Up Another Win
Inventing the Future of Collaborative Computing with Zoku
Abstract Syntax Trees Rule!
Devoted to complexity? Why?
The Case for First Class Messages
Smalltalk Shell Scripting
Indepth Interview with Cincom's Founder Thomas M. Nies
Progress on the Frontiers: Technology and Progress with Doug Engelbart and Alan Kay
User Interface Design: Avoiding the Lack of Design in Your User Interface
Donald Knuth: Rewriting the Bible in 0's and 1's
Howard Rheingold: Food for Throught
Alan Kay: The Computer "Revolution" Hasn't Happened Yet!
A Brief Introduction to Smalltalk
Why Fear, Uncertainty and Doubt?
Article Series List
MicroSeeker PIC/Smalltalk
Versions of Smalltalk
News
JP Morgan's Das Kapital Earns Profits
Applications Built Using Smalltalk
Contents