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
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)
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
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
"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
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..." --
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...