Jan 2016
Issue

Mar 2016
Issue
GO TO Statement is Good:

The Go To Statement is needed. I just read the paper "Go To Statement Considered Harmful" by Edsger W. Dijkstra. I consider this paper is a lot of words about nothing.

In very simple software development situations we can get away with never using an unconditional branch (i.e. the GO TO Statement).  Just because one person does not see a reason for something does not make it universally unnecessary.

I did come across a situation that "could" not be accomplished without a Go To statement. It took me 6 hours to emulate the Go To statement in JavaScript. Actually JavaScript does have a limited Go To statements in the form of loop labels.  Without these, it would still would have been possible to emulate, but with confusing code and more time.

We only have 5 basic hardware instructions, with "Branch" being one of them. So you want to restrict access the unconditional branch statement only to the compiler. Hiding instructions is not what is needed. We need more access to the hardware not less. I believe that getting rid of the Go To Statement is one of the stupidest things done by compiler writers. (others are, case sensitivity, and the use of keywords)


Development Status:

I know I am very late in getting an evaluation system published. I had to redesign the complete system to overcome all existing technologies. I am building my own database systems, compilers, and operating system. This might seem a little overkill just for an evaluation system, but this is vital to prove my claims for the end of software development.

I promise to have a release by the end of February 2016. If I can manage at least one line of code then I can manage trillions.


“See things as you would have them be instead of as they are.”  -- Robert Collier

"Visualize this thing that you want, see it, feel it, believe in it. Make your mental blue print, and begin to build." -- Robert Collier

"The first step toward creating an improved future is developing the ability to envision it."  -- Unknown

"I never guess. It is a capital mistake to theorize before one has data. Insensibly one begins to twist facts to suit theories, instead of theories to suit facts." -- Sherlock Holmes

Visualization of code:

I have been working the last two years on developing a coding style that permits software development at a line by line basis. What this means is that for every line of code I will know with 100% certainty what will happen.

Currently in software development there is no visualization of what will happen. I live in the realm of "Hello World"s with never enough time to research all logic possibilities for every line of code.

We start with the verbalization of action. For example "C = A + B" , words that I want transformed into an action. I have maybe 90% confidence in visualizing this statement. Even this very simple example it is not universal: what compiler, what version, what vendor, a large number of factors I am required to account for in the development of software.

The objective of my development is for the accountability for billions of lines of code. This will never happen with current software development methodologies. Windows 10 has 50 million lines of code, a very small number of lines, yet difficult to manage, and impossible to change.  So if you gave me these 50 million lines of code, they would be worthless. I might find 20 lines of code of any value, that is, code that can be visualized.  I am sure I could wrap all the code and place it in a form I could use, but to what end? So we are back at the point of having to rewrite code, just to make it self aware. I am not belittling their work, far from that, I believe they did great work, they just had no place to but it so that it can be used to its full extent. All I want to do is build a place to put things so great work can be better appreciated and used the way the original developers envisioned. I am but an ant in the land of giants.

The benefits for visualization of code, is for code that never fails, can be easily and quickly changed, can be thoroughly tested, code that does exactly what it is asked to do, and finally an infinite amount of code can be managed by a single individual.

The work here is to eliminate any knowledge I am required to know that is not shown in the code. This means that all code must be transparent, and entered by professionals.  Coding is now done by amateurs. What I mean by this, is that, if we give the same task to eight people, we will get eight very different results. We need to get the same result from eight professionals, and that all eight results should, for the next 1000 years, be useful.


Organization of a billion lines of code:

This should be easy with proper design. I believe we can jump this up to trillions of lines of code, with little or no effort. "stupid humans will no longer be necessary"

Software Design Patterns are bad:

I am again faced with a vague terminology without technology "a design pattern is a general reusable solution..." -- Wikipedia

There are no true synonyms, and there are no true reuse of code. A reuse of code is bad, there is no benefit in building libraries, macros or APIs. These are assumed  benefits in reusing code. In fact what is happening is the addition of complexity, and  dependencies, both of which are costly and will fail over time.

What we need is verbalization for action. To know without a doubt what will happen when we use code. We have very few tasks that we can request that fall into this category. Computers only work with numbers, so we can ask for addition, subtraction..., etc.. and a very limited set of tasks for strings, which are system dependent, and really should be excluded from this list. The reuse of code has not been proven to work in 80 years of software development.


Management of Tasks:

Just as each line of code can be visualized, so must each task. This is the management of tasks, which are the actions that we what to call upon.

In billions of lines of code there must be a way to organize it, so it can be: added to, changed, and removed. We want to be able to accomplish this with 100% certainty of success.

We tie the verbalization to actions, and then have the system manage and maintain itself so nothing can fail from modification. I have used natural language, nouns, verb, adjectives and other parts of speech to determine action. This means that the system will know for any action what code is used, and how it can be adjusted.

I have renamed my system to Adam.

"Adam for the command "print invoice" let me edit the code that formats the invoice, please!"

And so we begin...

Author: Clif Collins
http://CollinsSoftware.com
Houston, Texas

February 1, 2016

email: c2@CollinsSoftware.com