[Article
title: {Brain Upgrade Going Well}
by: {Peter Lount}
date: {20220923}
version: {v0019}.
{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!}. ]
Smalltalk Blocks and Closures
by Peter Lount, 20201016.
In the video "Smalltalk blocks and closures origin and evolution" by Juan Escalada we explore the history and evolution
of the humble yet super powerful block.
"Even though there probably isn't a Smalltalk developer who doesn't use Block on a daily basis,
it's not common knowledge that they are based on the idea of Anonymous Functions,
nor that their Closures' origins can be traced back to Scheme.
The idea of this talk is to analyze the origin of this tool that defined Smalltalk, it's evolution until it became the full closure that we know today, and have a better idea of the potential advantages it provides." - Juan Escalada
Nor is it known that many of the blocks used in the base classes and users applications are actually technically Functional Programming based upon the age old principle of "idempotent" functions and computations where the input data (and objects) alone are used to computer the results of the block with no other external inputs the results will be the same everytime. If the idempotence property is present this means that the block of code is purely functional and will always produce the same results given the same imputs. However this isn't enforced in Smalltalk, it's easy for a block of code to access an external source of information, such as the system time, that can then change the computational results. In many functional languages idempotence is enforced.
In the ZokuTalk variant of Smalltalk a block may be configured with a message to enforce an idempotent or pure functional computation; for example, "aList doIdempotently: [:each| each doSomeComputationWithInput: anObject]" makes sure that "anObject" and it's connected graph is the only external piece of data to the block that is accessed in the example.
Many existing methods are functional in every Smalltalk system, for example, the classes True and False implement #ifTrue:, #ifFalse:, #ifTrue:ifFalse:, & #ifFalse:ifTrue:. These four utterly essential methods in Smalltalk and ZokuTalk are pure functional blocks of code! They are idempotent as well based upon the receiver and their input parameter blocks, keep everything the same (idempotence principle) and they will be fully pure and deterministic, and thus functionally pure. Of course the true and false parameter input blocks are not necessarily an idempotent computation and usually due to the state changes within the objects changed by computations in the block are decidely not idempotent (the non-functional state change approach to computational systems that produce real world results).
The history of the Smalltalk block goes deep into the Church and Turing theories of computation. "Annoymous Functions" are merely at one level "functions with no name" which is what blocks are. It should be noted that Smalltalk's blocks track back to Alonzo Church's "untyped lambda theory" without the OCD (Obsessive Compulsive Distorder) use of excessive "static type specification" of every receiver of a message, of every parameter, of every return value from a method or a block. ZokuTalk of course carries forward this Smalltalk lineage of the extremely more powerfull untyped approach while enabling "type" (really class) "conversions" and "data validation and verification rules" using the full power of the ZokuTalk MOBS (Messages between Objects within code Blocks Syntax) language, no overly simplistic "type specifications" that (1) lie about the types permitted, "int * foo" lies in C & C++ for instance because "null" isn't listed as a valid type on the pointer to an integer variable foo; really in C it should be "int,null * foo" to be a proper type specitication language.
In ZokuTalk you can use the VerificationAndValidation library of objects to filter and convert objects based upon their class (aka type) or any other attribute at all or both! You can't tell C that you only want that pointer to foo to have the integer values 0 to 100. In ZokuTalk the Validation and Verification object library enables you to construct the most powerful validation and conversion rules because it lets you do so in the exact same MOBS language that you write all your other code in!
The main places where data valiation, verification, converstion, filtering and other similar rules are appropriate are parameters to "system primitives", "foreign functions", "between inter application interfaces" (for integrity and security), data input 101, and "transaction consistency" reasons.
It's decidedly and certainly not appropriate to put type specifications on every variable, every method parameter, every method return value; to do so is bordering on an Obsessive Compulsive Disorder (OCD) in the computer industry; it's no wonder it's accepted though given the often extreme pedantic and savant nature of some to many programmers. Don't kill the messenger please, just reporting observations from decades of working with a lot of programmers. Thanks.
The power of Blocks can't be understated especially with the natural and easy syntax of blocks used in Smalltalk and ZokuTalk language syntax. The humble uncluttered block, [...], that computes something, "...", is at it's core very clean and simple syntax yet provides extreme powers to the developer. This is taken even further in ZokuTalk where blocks obtain superpower status and are extended and useful in so many more ways!
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.
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 "p e t e r . l o u n t at g m a i l d ot c o m" at this web site name... with all the spaces removed.
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.
