Icons: Programming

icons-program-500

Databases: 50 years of stupidity

stupidity

Database conventions are not best practices.  Database naming conventions are based on random ontological concepts.  Ideas about what constitutes an entity are misdirected.  Programmers know nothing about what a class or an object is or how to name them.  Hierarchical, Relational and Network databases have maintained a persistent and ignorant set of practices that the information technology intelligencia have followed mindlessly.  What we have after 50 years is a brute force patchwork of bad design practices and mediocre engineering that continues to work within the same set of assumptions.  It’s a product of the inertia of intellectual lethargy that dominates not just the technological world, but the world that uses technology in general.  Workers are too busy being inefficient and ineffective to improve their business practices.  They jump at silver bullet solutions that promise results without change.

Database people have never understood data.  Programmers have never understood data.  They have instead tried to please everybody’s ontological misconceptions with grotesque architecture and then shoehorn it all into a physical processor that is about as progressive and efficient as the internal combustion engine.  Eco-nut technologists like to use buzzwords like “organic” to describe the chaotic crap they are producing on the web.  It isn’t organic, its a massive slum composed of any piece of detritus the occupants can build with surrounding a district of monolithic towers of gross excess and shameless waste.  Google’s motto is “Don’t be evil.”  Has any company ever considered having the motto, “Be good”?  The more I work with corporations the more I recognize that goodness is discouraged and evil is whatever the corporation says it is.  If you work for anyone you are part of a Milgram experiment and you are delivering those electric shocks everyday under the direction of psychopaths.  The merit you get promoted for is based on your willingness to flip those switches more than anyone else.  Having a conscience is deemed unprofessional and grounds for termination.

This is the environment within which real innovation has to work.

Hungarian Backwords Notation, a naming convention by Charles Simonyi, has been abused and bastardized by programmers and database administrators with no understanding of semantics, which is most of them.  Consequently, it has been rejected by a large portion of the IT community.  Not even Microsoft knew what it had.  I fought with Simonyi’s concept for years and applied it in several working applications successfully against massive resistance.  The more I worked with it the more I realized that Object Oriented Programming was based on a completely false ontology.  The metaphors were completely wrong.  And the Unified Modeling Language entrenched the misconceptions even further.  Information technology is spawning increasing complexity without any appreciation for underlying order.  The order was datatypes.  There are only a handful of Classes and they are datatypes. The English are backwards, not the Hungarians.

If the world was looked at as a collection of datatype classes the entire philosophy of data and programming and systems would have to change.  Objects do not have properties, properties have objects.  And there are only a handful of properties.  I’ve realized this and it has changed my perspective of data design forever.  Throw away your OOP and your Data Model textbooks.  They’re crap.  Google, Apple and Microsoft are not the future.  Einstein had a better grip on reality than Turing ever did.  The typical mind, including the IT mind, still thinks elephants are bigger than the moon.

Related Links:

Icons: Systema Iconic Language: Part I

In this series of posts I will be exploring the concept of an iconic language built upon the vocabulary I have been incrementally creating as part of the Systema Framework.

Abstract Relationships

enterpriserelateabstract

Concrete Relationships

enterpriserelateconcrete1

I have worked with icons before and this is a revisit of some of those ideas as well as modifications.

Apport Icon Set

The Apport icon set defines the entities that can exist in a system:

iconscreate2

Accord Icon Set

The Accord Icon set defines the relationships that can exist in a system:

iconsrelate2

Below is a cross product of the Apport and Accord Icon sets:

enterpriserelateicons2

Record Icon Set

I am sure that the icon set below is familiar if you have followed my blog.

iconsrecord1

Note that the cross product below is only for the entities themselves and not for their relationships.

enterpriserecordicons

Properly utilized, an iconic language would allow you to build sentences out of the individual icons interactively.

I plan to continue to think about this subject further and will update as I go along.

Below are links to web pages and pdf documents I have read so far on the topic:

Programming: A Great Seed Idea

I just came across a new blog, SysFunk by blackjack87, where a fledgling idea is taking shape:

Abstract

Entitys are essentially living, growing, software programs. They have urges, a nature, skills, an environment, and relationships; they are bound by their nature, environments and urges. They are governed holistically by an anthropological philosophy by means of adopting such familiar natural survival characteristics as adaption, and regeneration.

This is not a novel idea, even Turing experimented with artificial life, however it is novel for social networks and bioinformatics.  Entities in social networks have characteristics very similar to what this abstract describes and the reason why I believe organisms are a product of natural laws in network behavior.  There is a great deal of unexplored territory.  Blackjack87 has some work cut out for him, but if he pursues it, I will follow with interest and help where I can.

Link:

SysFunk

Criticism of UML

I came across this interesting criticism of UML today: Why UML fails to add value to the design and development process.

I agree with the author that UML’s lack of integration into automated lifecycle process at both the domain end and the technology end tends to make the documentation a one time island of work.  However, I do not agree that domain specific products have to be developed.  We do not understand sytems well enough yet to make such a conclusion.

The criticism of UML’s lack of ability to generate code is one of the reasons I am in favor of the Associative Model of Data and the Sentences ADBMS at LazySoft.  The schema, form design, query design and results are all built into a single user interface that can be updated in real time and issues such as normalization and denormalization that plagues relational database integrity and performance do not exist.

Icons: Systema

I finally put together a broad range of icons for the System Elements. Remember Causus (Why), Ductus (Who), Modus (How), Datus (What), Eventus (When), Locus (Where):

Systema

Tonight I broke out the dictionary and began examining my Latin roots. Spurred on by the term “datum” I decided to go all the way and produce an internally consistent set of terminology for a system:

I have a confession to make.  I abused the Latin a bit.

I recently learned that to enable philosophers of all languages to exchange their work Latin is used as the standard. In working to refine my understanding of system concepts I can see the rationale behind using a language with a thoroughly refined vocabulary and grammar. Dead languages do have utility.

Design: Attacking Convention

It’s wrong. The way we think about managing files in applications is wrong. And it is wrong for one reason. It lacks conceptual abstraction, simplicity and consistency.

“Wait!” you may say, “the icons are the same in all the applications! We’ve got the sheet of paper for ‘New’, the opening folder for ‘Open’ and the diskette for ‘Save’. We’ve even got a cute magnifying glass for ‘Search’.”

Frak the magnifying glass!

That’s part of the problem. The “New”, “Open” and “Save” icons should be sacrificed on the alter and replaced. New is relatively acceptable, but when we open it is not file we open but a folder. When we save we are not saving to a diskette. And we shouldn’t even be using the term “File” for anything. We are managing “Email”, “Documents”, “Worksheets”, “Presentations”, “Databases”, “Calendars”, “Projects”, “Drawings”, “Contacts” and “Browsers” people! If our applications are single function so should be what we are editing.

When you “Open” you could be uploading or downloading into your computer’s memory. When you “Save” a document, you could be uploading it to a hard drive on the web or downloading it to your hard drive; it could be burning it to a CD-ROM or good heavens even writing to a diskette. I’m not going to draw little hard drives. I’m going to abstract the concepts completely.

I always hated the clipboard metaphor. I just decided to call it a “content block”. You either delete it from your document, copy it from your document, update your document with it or select it in your document.

This is not my final version in the least. But I wanted to put some food for thought on the tabula rasa.

Implicity and Explicity

Nothing can be so amusingly arrogant
as a young man who has just discovered an old idea
and thinks it is his own.
Sidney J. Harris

By now I think I have established the legitimacy of the Six Hats, Six Coats Framework and I am presenting it here in what I am going to consider its final form:

zachmanframeworkabstract03.jpg

Every notational technique is a combination of two or more of the Six Coats. What we are working toward ultimately is a language to interrelate all Six Hats and Six Coats at once.

In this post I want to think about the terms “implicit” and “explicit” and how they relate to the Six Hats, Six Coats Framework. For the purpose of this framework implicit is defined as unchanging and invisible; explicit is defined as changing and visible.

Every entity, relationship, attribute, constraint, definition and manipulation has an implicit and explicit name. As well, every motive, locale, object, method, person and event has an implicit and explicit name. An implicit name is unique and once assigned cannot be changed. An explicit name is unique, but it can be changed. The implicit name is not visible to the user. The explicit name is visible to the user.

An entity which contains its own primary key is an implicit entity. An entity which contains a key from another entity in its primary key is an explicit entity.

A relationship that connects one entity’s primary key as part of the attributes of another entity is an implicit relationship. A relationship that connects one entity’s primary key as part of another entity’s primary key is an explicit relationship.

If the primary key is never made visible to the user and cannot be changed it is an implicit primary key. If the primary key is visible and can be changed as long as it is unique it is an explicit primary key.

Attributes that are foreign keys are implicit attributes. Attributes that are non-key are explicit attributes.

Constraints are implicit when they are data listed in a foreign entity. Constraints are explicit when they are a datatype.

Definitions are implicit when they protect explicit child tables. Definitions are explicit when they cascade manipulations.

Implicit manipulations maintain an audit trail. Explicit manipulations do not maintain an audit trail.

So, what is the purpose of implicity and explicity? Primarily it is strength and flexibility. Implicit design results in rigid, but more integral systems. Explicit design results in flexible, but less complete systems. For example, in an office you have work to rule, which is implicit, and work to allow, which is explicit. Ultimately, in dealing with implicity and explicity it is best to strike a balance. No system is fully normalized or fully exceptionalized. It is necessary to allow for both normality and exceptions as no system is fully closed or fully open.

Implicity and Explicity

Six Hats, Six Coats and Sun Tzu

suntzu.jpg

From Sun Tzu on the The Art of War

I. LAYING PLANS

1. Sun Tzu said: The art of war is of vital importance to the State.

2. It is a matter of life and death, a road either to safety or to ruin. Hence it is a subject of inquiry which can on no account be neglected.

3. The art of war, then, is governed by five constant factors, to be taken into account in one’s deliberations, when seeking to determine the conditions obtaining in the field.

4. These are: (1) The Moral Law; (2) Heaven; (3) Earth; (4) The Commander; (5) Method and discipline.

5,6. The Moral Law causes the people to be in complete accord with their ruler, so that they will follow him regardless of their lives, undismayed by any danger.

7. Heaven signifies night and day, cold and heat, times and seasons.

8. Earth comprises distances, great and small; danger and security; open ground and narrow passes; the chances of life and death.

9. The Commander stands for the virtues of wisdom, sincerely, benevolence, courage and strictness.

10. By method and discipline are to be understood the marshaling of the army in its proper subdivisions, the graduations of rank among the officers, the maintenance of roads by which supplies may reach the army, and the control of military expenditure.

11. These five heads should be familiar to every general: he who knows them will be victorious; he who knows them
not will fail.

12. Therefore, in your deliberations, when seeking to determine the military conditions, let them be made the basis of a comparison, in this wise:–

13. (1) Which of the two sovereigns is imbued with the Moral law?
(2) Which of the two generals has most ability?
(3) With whom lie the advantages derived from Heaven and Earth?
(4) On which side is discipline most rigorously enforced?
(5) Which army is stronger?
(6) On which side are officers and men more highly trained?
(7) In which army is there the greater constancy both in reward and punishment?

14. By means of these seven considerations I can forecast victory or defeat.

15. The general that hearkens to my counsel and acts upon it, will conquer: let such a one be retained in command! The general that hearkens not to my counsel nor acts upon it, will suffer defeat:–let such a one be dismissed!

16. While heading the profit of my counsel, avail yourself also of any helpful circumstances over and beyond the ordinary rules.

17. According as circumstances are favorable, one should modify one’s plans.

18. All warfare is based on deception.

19. Hence, when able to attack, we must seem unable; when using our forces, we must seem inactive; when we are near, we must make the enemy believe we are far away; when far away, we must make him believe we are near.

20. Hold out baits to entice the enemy. Feign disorder, and crush him.

21. If he is secure at all points, be prepared for him. If he is in superior strength, evade him.

22. If your opponent is of choleric temper, seek to irritate him. Pretend to be weak, that he may grow arrogant.

23. If he is taking his ease, give him no rest. If his forces are united, separate them.

24. Attack him where he is unprepared, appear where you are not expected.

25. These military devices, leading to victory, must not be divulged beforehand.

26. Now the general who wins a battle makes many calculations in his temple ere the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat: how much more no calculation at all! It is by attention to this point that I can foresee who is likely to win or lose.

Sun Tzu truly was one of the greatest minds in human history. He knew that a war was a collision between two systems. He had a firm grasp of the military as a system and had reduced it to its fundamental components.

  1. MOTIVE: Moral Law. Vision and Mission.
  2. LOCALE: Earth. Terrain.
  3. OBJECT: Discipline. Integrity.
  4. METHOD: Method. Training.
  5. PERSON: Commander. Organization.
  6. MOMENT: Heaven. Climate.

The correlation between the Six Coats and the Five Fundamental Factors is complete. Let’s take a look at Sun Tzu using the Six Hats, Six Coats Framework:

suntzuperspectives02.jpg

A nice fit.

Six Hats, Six Coats and Sun Tzu