|
Purpose By changing your style of programming to remove
internal dependencies will reduce your total project effort by 50%,
produce unbreakable code, and have code that can be changed at any time.
This is simply what software development is.
I build yoyo's does not mean I'm an expert yoyo'er. I have spent 3
years trying to learn how to remove internal decencies, it is not as
easy as it sounds. You will want to fall back on what you've done in the
past. I did this on 1 line of code that took me 3 weeks to resolve.
A Linker
In my last newsletter, I talked about the JavaScript
compiler as a part of "Jane". The compiler will run in emulation mode,
and produce executable code. To produce an executable, as a part of the
software, a linker was required. It took me two days, just to read
an object library to extract object code to be placed into the resultant
executable. This is the same amount of time it took me 30 years
ago to do the same thing.
The point is, our basic static structures separated from logic is no
better, and might even be worse, today because of the number of
versions, variations, and vendors of the same structure. If I were to do
all the different formats and logic for all these different structures,
it might take six months of work.
One of "Jane's" primary goals is to manage all information. So access
to known information structures will take seconds not man months of
work, with far greater reliability.
"The Holy Grail"
Mr. Crockford, is right for Software Engineering, as a science it
would be great. In eighty years we have yet to produce one line that
meets the code reuse criteria.
I directed my efforts to software development, which is the practical
application of creating software. So if I know that in 80 years and
billions of man-years of effort has yet produce one line of re-usable
code, maybe something is wrong.
Code reuse It like searching for and wasting time on anti-gravity, when a more
practical approach, airplanes, might hold a better solution. We can
assume that anti-gravity and code reuse could exist. I do not waste my
time on either one.
Quotes:
"Code reuse is the Holy Grail of Software Engineering." --
Douglas Crockford
"There are no true synonyms" -- my fifth grade teacher
"Behind every great man is a woman rolling her eyes." -- Jim
Carrey
"Progress might have been alright once, but it has gone on too
long." -- Ogden Nash
"The best time to plant a tree was 20 years ago. The second best
time is now." -- Chinese Proverb
|
|
Removing Internal Dependencies:
The two reasons for software failures are internal and external
dependencies. An external dependency is software that you did not write,
software that you have no control over. An Internal dependency is
software you did write and used it for more than one purpose. Getting
rid of external dependencies is easy, re-write everything yourself.
Getting rid of internal dependencies is a little more difficult.
The reason for removing external dependencies should be obvious; any
external change will break your system. The reason to remove internal
dependencies, may not be so obvious, it will improve your software in
four way: First is it makes software code unbreakable. Second it will reduce
the time to develop software. Third it will speed up the execution of the
program. Fourth it will make software changeable.
My initial thinking was to reduce the number of internal dependencies on any
piece of code to a manageable number of permutations. Three uses of a
piece of code has six permutation. So if each piece takes 1 hour to
implement, this is 6 hours. It seemed a reasonable assumption. This
assumption is wrong, we have based all of our software development on this assumption for the last 80 years. We have been spending more time designing
software for reuse without any real or practical benefits.
I now promote zero reuse of code. Whether it's one line or a million
lines, code should only be used for one purpose. This means building a
system that only has a linear forward progressive logic.
Instead of trying to collapse code to reduce size, we actually expand
code to reduce size. We also expand code to drastically reduce
development time by as much as 80%.
As an Example:
A and B both call C, this requires A and B to agree on a
calling convention and balance the logic to suit both. This can take
man years to develop properly. Future changes have risk, and there is no
accountability.
A calls C1, B calls C2, now A and C1 are independent
from B and C2. This I can do in under 30 seconds.
Accountability is 100%. The size and complexity of C1 and C2 are
reduced. I can change C1 and C2 with 100% confidence.
In forty years of development, I have never seen a function called
from 2 parts of any system that had identical purposes. The few cases
that you might think are identical, is not worth the 30 seconds it takes to
isolate your code.
I can place C1 and C2 right next to where they are being called. This
gives me the ability to visualize and alter the logic at will.
Words that make no since:
Object * Abstract * Virtual * Polymorphism * Inheritance * Cloud *
Big Data * Instance * Encapsulation * Refractor * Namespace
These terms were used to describe application specific logic. The
terms are too vague and do not describe logic, rather hide 2 or 3 lines
of coded logic. I would prefer words like: Place-holder instead of
abstract, Replaceable instead of Virtual, Fix instead of Refractor, and
so on...
|
|
|
Intelligent Data Structures I can probably count on my fingers
and toes all the data structures that I need access to.
- Font Files
- Images
- Videos
- Vector Graphics
- Object Code
- Database Tables
Maybe 10 or 20 more. "Jane" is to build and manage data structures as an
integral part of the system. So the code to create, manage and
access them is immediate. No more days or weeks of coding just to access
something already known.
Compiler Update:
The JavaScript compiler now has access to object libraries, so I can
write C++ system routines to finish the compiled version of the
JavaScript compiler.
This means the compiler will run in all the current browsers to
produce a 64 bit windows and ARM executables.
I have also extended JavaScript to know the difference between
integer, whole, and real numbers.
Diagramming Source Code Designing and writing software is an
illusion of logic. As a part of designing Jane I diagrammed source
code, how was it written, what percentage does what part, and what
percentage is actually logic.
It turns out that logic only makes up 3% of the code. The remaining
97% is gaining access to information so the logic can be applied, and
then doing something with the production of the logic. For example "draw
a character on the screen" the logic is 60 lines, the lines of code to
get to the logic is 2,000 lines.
The production of logic is done in a very small time frame. Writing
the 60 lines of logic of the draw character example might take 30
minutes; In this 30 minutes I have complete understanding of the system,
where the data came from, where its going, what I should do, and how to
best test the logic that I am now implementing. It is also true that I
am the only person that knows this information. Once I am finished, I no
longer know this information as well as I did during the 30 minutes of
writing the code. Over time I may not even remember that I even wrote
the code. With this information, I designed Jane to manage the data
structures, the logic, testing and every piece of knowledge when the
logic was written. |