Teensey Elf Executables

Teensey Elf Executables are explained here at this link.

Boogles my mind!

Size is Everything! 

Is this an example of reduction to the lowest possible granular level, in this case Linux programming code, that serves greater efficiency by focus on what a thing (code) "is" by design to produce a result of what it does by virtue of what it is?  By what it does by virtue of the attributes baked into the thing to accomplish its action to produce a result.

Is this the dominance of the object oriented approach and its design elegance and efficiency over the an alternate old school functional oriented approach to get the job done?  The fundamental approach that I apply to solve the Money Problem by designing what it is as a lowest level granular discrete object encapsulating meaning and methods and messages to implement them?

What is that?

Create a thing to do something at the lowest possible granular level appropriate to the problem domain.  Give it the attributes to do it and the methods to apply its attributes then it will do what it was designed to do in relationship to all other entity objects in the problem domain from the lowest level to the highest level of entity relationship of integration to solve the problem.

Complex but I see a structure.  Well written.  I can follow it for two pages but I can see where it is going and why.

Reduce complexity to simplicity.

Was this taken from the link my Ah-ha, I get it moment????

"What went wrong is that we treated _start as if it were a C function, and tried to return from it. In reality, it's not a function at all. It's just a symbol in the object file which the linker uses to locate the program's entry point." 

I like that.

This is the first line on the link:

"If you're a programmer who's become fed up with software bloat, then may you find herein the perfect antidote."

Is the bloat in software a functional programming bloat?  Functions to be removed to background by use of objects to implement them with the object entity attributes, methods and messages also in the background.  I think that one of the rules is that any one thing can and will do more than one action.  A system is a few things and a multitude of actions.  Manage all the actions directly in functional programming?  Manage fewer things that do built in actions by design.  That of course requires front end investment in object design.

If Objects are more persistent in system life span and functions change faster than objects then a more efficient and controllable system is built on front end object oriented design at a higher level of abstraction that focus on more direct functional design at the lower level.

Old school programming was programming functions.  Programming what a thing does.

Newer school, using newer more efficient tools is programming things.  Like creating robots with inherent ability as objects to do things they are taught to do by investing them in the programming design structures with the means to do them in response to messages to perform them. 

Money is that kind of robot.  The current monetary system is product of what money does as a singular functional thing, not what it is enabled to do as an object with the built in attributes and methods to do it.  Its primary attribute must be a matter of accounting.  That has been extracted from Money by stripping it of owning an accounting method function and placing that function in an object called Account.  It is the most important attribute of Money but owned by an Entity that is not Money.  Owned by Account.  Bankers own Account Entities.  Money is a function of account. 

The solution to the Problem Domain called Money is to take the fundamental  accounting attribute from Account and invest it as an attribute of Money.  The specific attribute and associated methods and messages that make Money account for itself and its own creation independent of debt at both the micro and macro level.

Restructuring of ownership of fundamental attributes in of two Super Class object entities one being Money the other being Account is required and demanded in order to produce a better conceptual system vital to management of our affairs:

Money must have accounting attributes necessary for its designed role as an independent Super Class entity.  Account has different accounting attributes necessary for its designed role.

The problem with the current system is the Money does not own and operate its own account for itself attributes.  They are misplaced and incorporated in the Account system based on balance sheet accounting that puts money a child of the Object Entity: Accounting Class.  A child created by the Accounting Class, inheriting some attributes of its Parent Class:Accounting.

Banks own Accounting.  They do not own Money created as a child of Accounting function.  Literally that child Money is a Liability of the Bank to account for as well as an Asset.

The key to the restructure and appropriate assignment of Entity Attributes is:

1. Assign Money its own Object Class attributes necessary to define itself as a Super Class object independent of Account but with methods to account for itself as a class inherited by all object children of its class to the lowest granular instance of the Class:Money

 2, Assign Account its own Object Class attributes to define itself as a and account entirely for itself as a Super Class object with methods to account for itself as a class inherited by all children of its Object Class to the lowest granular level of the Class:Account

The purpose of Money and its relationship to Account is to be a system for a purpose of serving the allocation of resources.  A social purpose accomplished in different ways around the world but the universal tool in accomplishing whatever those may be.

Money and Account are the two big things used for social purposes but are also the best metrics in terms of what they are and what they do to evaluate how well they work to serve us.

They do not serve well because of failure in design.  It can be corrected and these are my ideas for doing it.  In many ways the nature of information systems that we are designing for so many applications are pointing the way for how to design new systems to serve us and restructure old systems to serve us better.  This general trend will apply itself to our Monetary System or even save us when it collapses and collapses the associated functions its serves us.

There is a need to get ahead of the problem that is written on the wall by correcting the most obvious relationship flaw between Money and Account at the root of the problem. 

Essential attributes of Money must be extracted from the banking domain of Accounts and management of Money as an Object independent of Accounts that it may relate to assigned to a different agency.

Account structure creates and manages money values in a balance sheet system of debits and credits.

The extraction of Money as a child of the Account system sets up a higher level balancing relationship between Money and Account.  All money, currency of 12 trillion dollars or whatever in base money equals all 12 trillion dollars total of all Accounts. 

All currency money in all accounts serve all of us.  We all use money. 

The first step by mandate , or last step if progressively applied, is that all entities, all citizens and all other non-citizen entities that use Money be registered at the Bank Account level to transact business among account.  Their assigned primary identification number, and every user entity of the Monetary Account system must have one to pay or receive money is the same as their Bank Account number or related child of that number if money is held in different account managing institutions. 

Sure a long ways from Teensey Executables but that is how things get built.  From the smallest things structured to make bigger things.  Simplicity reduces complexity.

Size matters.