First of all, it is important to be mono-paradigm in order to have a strong consistency across ISA. The major consequence of that is that everything in ISA is an Object. The Object is the base building block everywhere.
This implies that all the ISA “thing” follows the axioms of oo exposed at Step into OO paradigm.

Are there some exceptions to the “everything in ISA is an Object” rule? The only possible ones could be for a physical reason. This means where the consequence to have an Object representation of a “thing” implies an overuse of space or of time. A usage making the oo approach not reasonable in practice.

For example, any character of a character string could be an Object. Is that reasonable? In most cases no, because it is not necessary in practice to have all the features that an object provides on each characters.  Moreover, it would have an overhead on memory and processor usage. The fly weight design pattern has to be applied.

More generally, the use of primitive types directly supported by processors is a major orientation to maximize efficiency.

Let's come back to the character string subject, this means in return, that processors should support natively the String class. And also that it should support the Object notion. This point will be developed in a further post.

To conclude, this drives to have every objects like Document, Operating System, Computing Node, User, Use Case, etc. to all be Objects sharing the same axioms in the same way.

The 64 bits computers are now the standard. Even ARM and Snapdragon microprocessors are now available at this register size (nov-2016). The “credit card” computers like Raspberry Pi or Arduino are also following the 64 bits movement.

The space addressing is 1,84E+19 locations. This very very huge capability means that 64 bits architecture is here to stay for a long time.

In the rest of this blog, the 64 bits binary word is expressed as “sbyte” (for square byte) like the 8 bits binary word is expressed as byte or octet.

64 bits have also advantages in many other usages. Lets me enumerate some of them:

• It is very very improbable for a sbyte number generated randomly to collide with another one.
• A character of 64 bits do not cost so much in manipulation since it is the microprocessor work unit.
• The small entities, as primitive types like boolean and small integers, can be grouped in a single sbyte.

The uniform usage of 64 bits words (sbyte) is important to take into account when applying the oo in particular in reference implementation examples.

The simplicity, like the KISS (Keep It Simple Stupid), is a wish, a slogan. It tells nothing on how to achieve this goal.
The only thing possible it's to try to follow some principles that have proven their efficiency in practices. Here pragmaticism should be called to the rescue.

To conclude on simplicity, it is important to notice that the subject complexity cannot be avoided because things are what they are (Cf. Reference Architecture logicielle – Jacques Printz).
A State machine for instance with all its properties. Nothing is useless, at contrary, if anything is missing, then it is the state machine concept as a whole and its added value that is affected.
However, tools can come into play to deal with complexity. Auto-layouted diagrams, property editing assistant and the auto completion are examples of that.

As OO is very well experienced, its major weaknesses are also well known. ISA should provide an answer for each one.
The preferred way to do that is in using the most adapted solution. It is often coming from another paradigm. To preserve ISA consistency, it matters to confine this exo-paradigm's intrusion just to this weakness point.
For example, the Structured Query Language (SQL) is very powerful for requesting data in sets. It is a major property from the Relational paradigm. So incorporate to ISA the management of Sets is important, in particular in supporting SQL the closely as possible.
Another example is the difficulty to understand OO for business people (and for developers…). This point is usually responded thru artifacts like Use Cases (UML), User Stories (Agile), CRC cards (class Responsibilities Collaborators), BPM, Domain Model, etc. Anyway, these approaches are almost orthogonal to pure Object Orientation. So, they have to be selected and incorporated to ISA.

Being both Dynamic and Static, is one of the ISA's wishes. The principle must be diffused, sprayed everywhere in ISA.Any incorporated element in ISA must be questioned against what can be dynamic and static. What are the advantages and disadvantages? How more complex or simpler is it to have it and to use it? How much does it cost in resources?

This is also a wish for ISA. The question here is to always have a reference binary implementation proposal or an example of a chose in order to be sure that the performance is near of 100% of the hardware maximum capabilities and that the resource usage remains acceptable.
For instance, this clearly kills the option to have a bytecode running on a virtual machine, because native compiling is at least of one magnitude faster and resources-saving.

At contrary, the principles like streaming or intrinsic scalability are tracks to explore and follow.

ISA must be flexible, but not chaotic.

The major way for flexibility is achieved thru extension. That ISA must be extensible means that it is closed to modification but opened to extension. In other word, the Open/closed principle is generalized. Cf. The Open/Closed Principle.

The principle relies on the OO paradigm and in particular on interface, inheritance and polymorphism notions.

Again, as OO is very well experienced, there are major Design Patterns that have emerged from years of practices.

So, incorporate the most important return of experiences in ISA has to be done. This is preferable to the current situation where there is many applications and contexts specific implementations. This allows to provide them in a clean and uniform manner. Furthermore, they can be used in cases even not imaginable in the current real world (State DP: class life cycle management, Observer DP: transactional distributed notification, etc.).

The basic Information Technology features that are commonly found like user interface, persistence, logging, deployment, etc. have to be supported at least at a base level.

For instance, to have the serialization behavior on the base Object (at the class level to be efficient) is important. In fact this feature is mandatory in an architecture aiming to be distributed and plug and play.

Security is an ISA wish. It has to be incorporated as a cornerstone. Where an 100% sure cryptographic method is mandatory.

The safety is also important. Here it is about the software robustness. For instance, the “Schiaparelli” Mars lander would not have been a crash in 2016 november if there was an altitude class invariant having thrown an exception on negative value.
The strongly typed approaches often promote this robustness. The ADA language is the archetype. The design by contract is also an robustness factor. Here Eiffel language is the reference. However, strongly typed languages are much more difficult to manipulate (ADA) that the weakly typed ones (Basic). So the Types must be used, but not overused if there is another more simple way. Here the being both Dynamic and Static principle could help in particular for type inference.

Supporting the safety, without over complexify the system, is a goal for ISA.

The Uniform Access Principle (UAP) is an important property the OO paradigm can support to make implementation easy and runtime independant of the implementation details of features.

In a broad sense, UAP is also applicable to Object access in it self, not just to its features. This is crucial because Objects are always available if you have access rights on them. This property avoid having the silos commonly encountered. This property avoid the need for any “data centric” approach.