Icons: Programming

icons-program-500

Advertisements

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.