... reinvention in process ...
... rebooting ...
ZokuTalk
On Messaging, Objects, Encapsulation, Late Binding, & Idempotence
Smalltalk Systems
Components
Contribute
ZokuTalk™ Articles
ZokuTalk is an independent indevelopment reboot of Lisp, Smalltalk, Erlang, Forth, and a host of other languages; ZokuTalk inherits capabilities from these languages while avoiding, ahem, less optimal solutions from a large host of over 100+ other languages that have been scoured for compelling innovative capabilities.
At the core of ZokuTalk is the notion of MOBS, Messages being sent between Objects (as well as data) with Block lambda contexts in an uniform powerful Syntax. A minimal ZokuTalk MOBS syntax intersects with a minimal Smalltalk syntax by design. ZokuTalk's MOBS fully supports Alan Kay's big idea of messages being passed between objects in many ways not found in object systems; in addition Alan Kay recognized the important Homoiconic, same glyph, same syntax, notions from Lisp, these are infused into this core MOBS syntax: Code is Data is Objects is Code is Objects is Data is Code.
Pharo Smalltalk is currently being used as the development platform with work progressing towards independence day with a new form of direct baremetal fully object oriented execution engine not based on virtual machine designs; a new Project Manager enables ZokuTalk to emit both legacy Smalltalk source code format as well as the refined MOBS source code+object+data format. Essence# Smalltalk was the first Smalltalk to adopt a portion of ZokuTalk's MOBS syntax.
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.
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
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.
Contribute to Building the Smalltalk Community
To contribute an article, item of interest, name of a Smalltalk not listed, link to a cool component or sub system, to help rebooting the site, etc please send a an old fassioned not snail message to "c o m m u ni t y bu il d ing" at this web site name... with all the spaces removed.
All copyrights and trademarks are owned by respective owners.