Monday, January 25, 2021

Goofy Orientation

Team. Could you please help me find the right and left sides of the screen? Is the LHS and RHS, left-hand side and right-hand side, of a production in a context-free grammar inverted. In other words, what are the left and right sides of:

public static String aSimpleStringLiteral = "More backward than Aksarben."';

Could this be corrected? Or, is it the case that computing genius baffles "common sense".


When you "left-align" a paragraph in Microsoft Word or another online editor, what side of the page and screen does it align with? Are you saying, "Flush? On what side? Is that right-alignment?"

Just a reminder. Always keep this straight and remember that bolts tighten when they are turnt clockwise and loosen when they are turnt counter-clockwise. Common-sense is a nascent gift; but, it can be lost in this backwards world. Right? Or, is that Left?

And, if you think that it does not matter. Try this "natural" orientation for a year. And, see if life looks different.

Please Forgive the Rhetorical Nature of this Passage,

The Author Resolving Confusion. 

Free E-Book | A Synopsis of Programming Fundamentals

 Team. Last week the author of this weblog drafted a short book covering some the concepts in computing which he has learnt within the past three decades of learning. He has a couple of post-baccalaureates in science and engineering. One is in computer science; the other is in engineering. And, the text does contain some religious content and references from the perspective of a Protestant Christian. So, if one would not find such offensive reading while seeing another man's perspective on computing, enjoy the reading. It is a "free" (*.pdf) that you can share with your friends.


Remember Hunt, Peck, and Think. It is the "Best" Programming Approach.

Sunday, January 17, 2021

The Nature of the Controller - Idempotency - Apache CABOOSE

Team. It is the case that the term "program", of which a controller is a subclass, has many synonyms. Some of those are module, routine, operation, and function. It is the case that functions have many forms. We call one of these types idempotent. This class of function remains unchanged in behavior when it is composed with itself. For instance the identity function, f(x) = x shows idempotency when it is composed with itself. 

if f(x) = x, show f(f(x)) = x.

f(f(x)) is f(x) by substitution of f(x) = x.

f(x) is x, by the antecedent.

So, f(f(x)) is x, by transitivity.

In general, f(f(...f(x)...)) = x. So, one might compose an idempotent function with itself an arbitrary number of times, and its results will be the same.

So, if a controller is described by a relationship, C(I) = O, where I and O are vectors of zero of more inputs and outputs, respectively, one can take advantage of its idempotence. If one combines this pattern for a general-purpose controller, CABOOSE, with a traditional web-server which is a special-purpose controller, he might produce a "structured" web server. Such a primary process would interact with a bipartite model of page templates and behaviors. And, one might use representational state transfer (REST)-style resource locator for interacting with the controller. The "caboose,py" executable would be invoked implicitly and not be part of the locator string which would list the requested view followed by the input vector.

This is the power of idempotency.

 

Wednesday, January 13, 2021

The Big WORM | Write-Once Run Many

Team. With the "advent" of JAVA technology plus the modern generation of "universal" virtual-machine languages and platforms during the early-1990s, the acronym "WORM" became a common computerese "buzz-word". "WORM" is a statement of one of the most obvious principles of the modern software industry and computing. 

When a software engineering team at a Microsoft or an Oracle creates a new product, they build a logical model of a real world process. This logical model is "ephemeral"; and, it is eventually rendered in the physical form of "high" and "low" electronic signals on a secondary storage device. Yet, once person-hours are spent producing the first verified and validated instance of the software, replicating it becomes rather easy. This is the first of a pair of "bi-stable" concepts in the philosophy of WORM as used in JAVA parlance. The second is the most commonly spoken concept associated with "universal" virtual machine use. One can "write" a singular instance of a program in a modern high-level language like JAVA, compile it producing a object file, and "run" duplicates of that object on numerous computing nodes, wherever the appropriate "virtual" machine is available.

So, WORM is a notion closely and intricately linked with the language translation process, compilation and interpretation. And, in a sense it is a byproduct of the "bootstrapping" of modern compilers which occurred decades ago. One compiler was produced in a "base" language that permitted the production of new language translation tools for "new" languages from that "first" compiler produced in that "primitive" computing dialect.

And, it is unthinkable in this modern era that one should "write" a compiler each time that one is need in a software development process. Such would be costly and error-prone. The use of "well-designed", "formally-verified and -validated" compilers ensures uniformity among the object files produced and helps guarantee the reliability and robustness of these files when they are generated from a "correct" source file. In other words, a language translation tool was written once and checked for fidelity. Then, it was widely used.

Contrast this with the modern era of web-development which sprouted up in the mid-1990s. The generation of software development has yet fully blossomed. Much of the "core" functionality found in common gateway processes was frequently rewritten for each instance of a web-process needed. This counters a few fundamental principles of  programming learnt by many college freshman and high school students studying computing. That "basic" rules is this, "If one writes a module once and well, he can place it in a single place within his system and reuse it often. This promotes the concept of a singular place of modification. Which enhances testability and product maintenance tasks." 

So, why rewrite the same behavioral characteristics found within the "process" control mechanism commonly used throughout web development?

Hence, the modern era of "pre-written" controllers surfaced in the late-1990s with products like Struts and Spring for the JAVA Enterprise Edition and, in recent years, Laravel for PHP. Also, Microsoft and Oracle at a couple of large software corporation that offer a standard, reusable Model-View-Controller product.

Yet, these avatars of control are found in every software product, including those "hokey toy" examples written for introductory programming fundamental courses. They are found among the "old" text-based, menu-driven systems that were commonplace from the late-1970s, throughout the 1980s, and in the early-1990s. They are found among JAVA's Swing and FX applications plus those created with packages like Tkinter found in Python and other graphical user interface (GUI) libraries.

Although simplistic, this model of development, that uses storyboard templates which represent a description of the output views and a module of behaviors that fill-in hotspots on the "stencil" which describes the view in conjunction with a "pre-written" instance of this controller pattern, provides a WORM-like component.

It is extensible through the module of "bespoke" behaviors which supports the "general-purpose" controller and is a pattern which can be used throughout computing without the need for "recreating this wheel" each time. 

Below is our diagram of interactions found among a system which uses the CABOOSE pattern and a general-purpose controller (GPC). This diagram is from the JAVA implementation which does not "currently" include an ICEMODE global with a "IceMode.java" file produced from an "Icy,java" code generator.

In our Python instance, the directory file that contains the architectural control language (ACL) does not use an eXtensible Markup Language (XML) format. Instead, it uses a sectional comma separated values file (SCSV). And, our behaviors are not part of Python classes. They are simply "user-defined" functions. 

And, of course, overseeing it all is Boonie, our mascot!

Although one can spin his own controller in a few person-hours, it is this author's sincere hope that this pattern of development becomes as ubiquitous a modern language translation tools, compiler and interpreters.

It also supports the templating of "client-side" scripts and web components which also might hold replaceable "hotspots".



Monday, January 4, 2021

Python ICE : The Reader's Digest's Version

Team. An instance of the CABOOSE System written in Python can be found on GitHub. It should be said that the version on GitHub has an simple optimization which the code found on Google Drive does not.

Friday, December 18, 2020

Python ICE | A "Full" Python In CABOOSE Prototype [ Just Below The Surface ]



Not a ZeroC Production

Team. Hopefully, the Gang's all here. This deliverable date has long since passed by. The realization of the "fifth" phase of this multilingual project is extremely overdue. It initially was scheduled for November 15, 2020. With the completion of the final phase projected near this time or mid-January 2021. 

Seeing that this architectural software pattern will not be woven in each of the fourteen languages chosen by then, one of the "simpler" implementations was chosen as a "deliverable" concession and completed "proof of concept". The implementation language was Guido von Rossum's Python. 

Since this past year has offered the author teaching opportunities in computer programming fundamentals, in particular, Python, he knew that "finalizing" the vision of a general-purpose controller which supported dynamic invocation would be quite simple in that language. 

So, he set aside a "vacation day" before the Winter holidays in America and spun the product. Between running errands and three meetings, including an academic interview, he found time for it on a Friday. It was about 4.0 person hours (PH) worth of effort. It is nearly a (0.5) KLOC coding effort with some repeated segments of code and ample comments, not including the generated "icemode.py" file which is produced by "icy.py" and of varying length. 

It includes a "simple-minded" and "non-optimal" code-generator that renders a "hard-coded" version of the logic file with a batch file called "iceman.bat"

The primary script "caboose.py" will run using dynamic invocation for activating behaviors described in the CABOOSE logic file if the ICEMODE global in it is assigned a value of "False". If it is given a value of "True", then the script uses hard-coded logic in the "icemode.py" file generated by "iceman.bat" and ultimately "icy.py"

It goes without saying that a Python 3 hybrid-interpreter must be installed and part of your system's PATH variable before this can run from the command prompt. 

Python ICE for Windows development is available on online. This is not the product from https://zeroc.com/products/ice with a similar moniker. That product is a framework for "microservices" based upon remote procedure call (RPC) and is architected and coded much like Oracle's Ozark controller product. This is called ICE for a different bi-fold reason. Firstly, ICE is an acronym for In CaboosE

CABOOSE is a very simple pattern for a controller which one can "spin" himself using a number of languages in a day or so each. Secondly, this product uses an architectural control file (ACL) whose mapping between page concerns and those methods which satisfies them can be "iced" or "frozen" in a programmatic "switching" structure for static invocation versus the default dynamic invocation. It is more of a "template-driven" system with a model of the view in a storyboard and behaviors that render each view in a "cab.py" file. 

Unlike ZeroC's product, this product version is not object-oriented, although it could be. 

And like the JAVA in CABOOSE project which integrates well with Oracle's Ozark, this ICE product likely will mate up well with ZeroC's ICE project. But, that is intuition with the different ICEs and not experience talking. 

And, it just so happens that the JAVA in CABOOSE project was considered by Oracle's JAVA Community Process (JCP) for adoption a full-year before the development of Ozark after it was pitched as a potential JAVA Specification Request (JSR). It was determined that Oracle had enough "view technologies" with servlets and JAVA Server Pages (JSP).

So, please do not get caught up in labels. These are different types of ICE, like "nilak" and "siku" for the Inuktitut of the Alaskan coastline. Certainly there is more than one Bill Joy, James Gosling, Mary Fitzsimmons, and Tom Johnson in this world. And, it is the case that more things in this life than Irishmen come with the same name. But, if one looks closely, they can easily see the differences between the products with the same "name".

This prototype of the controller runs from the command line, but can be easily adapted for "web-use". It can be invoked from the DOS prompt with "run [view_name]". Three templated HTML views exist in the StoryBoard model: home, landing, and error.

So, for instance, if one types "run home" at the prompt, then the populated HTML template for the homepage prints on the terminal. If one types "run foobar", then the error page prints since foobar is not a registered view in the CABOOSE logic file, directory.scsv

The HTML view templates are populated by functions found in "cab.py". This Python script must be created and customized for each Python ICE (Python In CABOOSE) application which one creates. If a non-existent view is requested, then the error view is returned as was the case with "foobar".

The CABOOSE Logic file "directory.scsv" unites all of this. It drive "caboose.py" which does not need modification, outside of the ICEMODE global which might be best housed in a the "cab.py" file.

A similar, yet not fully ICE'd version for JAVA is described in JAVA in CABOOSE by Abraham Vati James found on Amazon. This only is one of the pennames under which this author has worked in past years. Take it, tweak it, turn some web gears with it. It is under a MIT License for Open Source.

Hopefully, this shows how simple spinning and weaving the tapestry of a modern general-purpose controller is. It is the author's goal that he provide implementations in the other programming dialects of this multilingual project within a few month. PHP and PERL for the LAMP stack should be an easy task such a Python. This ease of development is driven by each of their individual mechanisms for dynamic invocation. Also, the Node.js and Typescript implementations each permit use of a function for statement evaluation. 

This greatly simplifies dynamic invocation in comparison with JAVA's Reflection tools and function pointers in C/C++. And, these tasks in C#, Rust, Clojure, Groovy, and Ruby will be a "new" undertaking for the author. But, this should not be an impossible task.

Upon taking his first computer fundamentals course at Vanderbilt during the Spring of 1989, he wondered about controllers in a model-view-controller architecture and whether a general-purpose one could be built with a means of "programming it" with a secondary "architectural control language".

This is what is found in the sectioned comma separated values (*.scsv) file which holds the CABOOSE logic.

The realization of this "trivial" project arises from the culmination of many years of learning and work. And, it should be said that such a revelation was quite novel at the time when print SPOOLing was new and revolutionary. In some ways, its time has passed; in others, it has not.

This could be a means of creating the "old" text-based and menu-driven command-line interface systems from which the author first harvested the abstractions of layered and model-view-controller architectures. Based upon his training in Pascal, he wondered if he could generate the "switch-case" or "if-then-else" ladder needed for logical processing of such a controller-based system. But, he knew little about lexical analyzers, interpreters, compilers, or code generators, at the time, other than what they did. He was far from understanding parse trees and the likes of grammars. These concepts still are not his strong points, seeing that he never took a course in compiler construction. In many ways, this might be considered a "kludge".

Yet, over the years, before the advent of markup languages and eXtensible Markup Language (XML) processors, work on mainframes with "on-lines" and a bespoke in-house system called integrated scripting produced by Jack Sprouse, a knowledge of International Business Machine's Customer Information Control System (CICS), and undergraduate study suggested that such a system with a "simple-minded" code generation step driven by a architectural control language (ACL) would be worthwhile. Life's circumstances did not allow for its production until now. 

But, the author kept it simple (KIS), plus he used the bird-foraging technique (hunting, pecking, and thinking) along with copying and pasting lines of code. And, Python ICE is likely the first nearly "full" rendering of this vision. It is a extremely simple "cold fusion" of sorts, since it connects view technology standards (markup) and a popular high-level language (Python) with some elements of fourth generation languages (code generators)

It is a mezzanine generation for languages in this fifth generation, those running atop machine emulators, such as Python and JAVA. Using a mixture of declarative markup and imperative or functional languages, it is a generation 3 1/2 system when integrated with a third-generation language such as C/C++ and a 5 1/2 when combined with a modern fifth generation virtual machine dialect.

Occasionally, limitations on what one knows helps him develop simpler solutions. At times, one can "overthink" what he is doing and build a duplicate of Dr. Who's Tardis when all one needs in a Ruby Pearl Tercel DX or, better yet, a push cart.

The construction of an ICE system virtually permits for the abstraction of the C, controller, out of the MVC processing equation. So, ultimately, we now have a (model-view) MV architecture which is "best" described as (view-model) VM based upon the top-down layering

This, when run atop a virtual machine, produces a VM * VM system which experiences a magnification of its combined power and desirable engineering traits as emergent behaviors arise. And thus, one might call it a "VM-squared" or , basically s "VM^2", architecture.

The author fully knows that VM-squared or the equivalent VM-MV systems have been defined as something different in past years. Yet, it is quite true that few know where the anacronyms originated. It was in the author's college-ruled red Mead notebook which was originally purposed for his ENGL104W Prose Fiction course taught by Robert Bacon at Vanderbilt University during the Spring of 1989. 

Yet, it is oft said that “Truth is stranger than fiction, but it is because fiction is obliged to stick to possibilities; Truth isn't.” ― Mark Twain, Following the Equator: A Journey Around the World.

 And, although this misuse of personal academic notes was a violation of Vanderbilt's Honor Code, the  convolution of Flannery O'Connor's words in the phrase "everything which converges must rise." brings much comfort in this world of "360-degree" good fortune. 

"What goes around comes back around again..." - Grand Puba



Sunday, November 1, 2020

The Iceman Cometh | Summary of Project Vision - Its Ultimate Goal

Team. The purpose of this project is spinning a "general-purpose" controller in fourteen different languages. This meets the goals of this "Google-based" web history, providing a modern "Rosetta Stone" describing common, widely-applicable software patterns in a myriad of languages. This project is built around four key architectural features: a "customizable" storyboard model of the view content, bundles of behaviors which populate the views of this storyboard, a file mapping between the storyboard content placeholders and these "invokable" behaviors, and dynamic invocation, which is a feature found in most "professional-grade", high-level computer programming languages. These four design decisions delineate this controller pattern from others such as Struts, Spring, and Laravel. Plus, this choice provides for its flexible, universal, and portable nature. Best of all. a single language instance of such a controller can easily be crafted and documented in forty person-hours or less by a seasoned software engineer.

So, when one builds a "web-based" system with this controller pattern at its core, he must follow the steps below. It is a "multi-cycle" process.

CYCLE A:

Front-End Developers:

  • Build a complete "static" HTML-storyboard.
  • Integrate its parts.
  • Verify it internally.
  • Validate it with the client.

Upon approval:

CYCLE B:

  • Identify any content which should be dynamic.
  • Assign each portion of content a unique user-defined placeholder, such as #E-MAIL#.

Front-End Developers:

  • Replace any content which should be dynamic with user-defined placeholders.
  • Reintegrate the annotated storyboard's parts.
  • Verify it internally.
  • Validate it with the client.

Back-End Developers:

  • Build packages of invokable methods which will replace placeholders with appropriate dynamic content. 
  • Follow a "sensible" naming convention for these methods based upon the placeholders they will replace.
  • Unit test methods.
  • Verify internally.
  • Validate with the client.

Integrator:

  • Build the mapping file based on the requirements document produced when identifying the dynamic content and defining the placeholders. This will represent an "architectural control language" (ACL) file in eXtensible Markup Language (XML) or a Segmented Comma Separated Values (SCSV) format.

[ NOTE : The front-end, back-end, and integration work for CYCLE B work can be completed in parallel. ]

CYCLE C:

  • Unite the annotated storyboard, packages of methods, and ACL file with the pre-written and reusable general-purpose controller pattern rendered in the appropriate language for the target platform and method bundles.

After this integration step:

  • Verify the system internally.
  • Validate the system with the client.

CYCLE D: ( Technically Optional )

  • "Freeze" the "liquid" nature of the dynamic invocation through the use of an integration completion engine (ICE).
  • Perform "final" verification.
  • Perform "final" validation.
An ICE is an extremely "simple-minded" code-generator that is not driven by a lexical analyzer and is not dependent upon the complexity of parse trees. In fact, a "bright" fifth grader could most likely build an ICE-machine which might be a "polyglot" code generator producing objects which differ from its native implementation language. Just ask Jeff Foxworthy.

An ICE-machine just will take a pre-written "static and templated" integration point in the target language for the "desired" platform and generate the require source code instance. Thus, it builds the appropriate logical switch for returning each view when requested. This is quite easily and naturally produced from the file mapping between the storyboard placeholders and the "invokable" methods that replace each of these with a string object. It just requires systematically building the appropriate "switching" structure for the description in the ACL file. Each "case of a view" results in the static invocation of the "associated methods" and the "appropriate string replacements". 

And, your final controller pattern could support programmatically routing its behavior through a dynamic channel or a static one which holds a flow of control "switch" built by an ICE-machine. For stability, it would be "best" if one sets the use of the dynamic or static channel before the controller's runtime cycle.

So, that is it, a more complete look at the "vision" surrounding a general-purpose controller (GPC) and a little "review" of software engineering and programming language fundamentals and their applications for those with a baccalaureate in computer science or software engineering.




Its Birth and Implausible Conception

Facts from this account has been given on-line before. During the Spring of 1989, the author of this web history was a freshman footballer at Vanderbilt University. 

He was a natural athlete just ten pounds away from the prototypical size for a professional defensive end in the National Football League at that time. He could generate a horsepower quite easily when deadlifting. And, was seventy pounds shy of the national record as a natural athlete in a large field of anabolic steroid users in his age group. He did set a state records for this group and weight class during competitions in 1987 and 1988. Plus, his overall NFL Combine score meet all of the target measurements for a defensive end, except his forty yard dash time. It was on the slow side at 4.9 seconds. The average professional at that position runs a 4.7. The "best" run a around 4.5 or 4.4. And, one tenth of a second is a lifetime at the speed of professional football. It is the difference between a completed touchdown pass and a quarterback sack. He was slated as the first defensive lineman that would enter the game lineup during what should have been his "freshman" football season in 1988-1989 and was on the first string goal-line defense, a six-man front. 




He was lots of brown brawn, and as such, he was not viewed as very bright, even with spectacles. But, when he opens his mouth, watch out! He had consistently tested among the top "one- percent" of students in America on national standardized test, since elementary school. He had worked as an NIH Scientific Apprentice while in high school and had been published as a contributing author on a research paper in the Journal of Organic Chemistry at the age of seventeen in 1988. 

His chosen field of pursuit at the time was physics, and he had scored among the top fifty respondents on the advanced placement physics exam during the Spring of 1988. A child of the 1970s, who had lived through the energy crisis, his goal was designing more efficient engines and generators. And, he is causally-related with the innovative braking system that is found in his 2014 Toyota Prius V and the vehicle's name.  

He likely should have been on an educational grant at Vanderbilt. Which would have covered all of his academic expenses for four years without requiring working as a student-athlete. Yet, life as a student-athlete was his situation and the only option that he was given for an education at the time, despite having a Stanford acceptance letter and the offer of a four-year early-entry academic scholarship at Southern California, the President's Scholarship. Woe was him. It is a rather long sad story of misguided parental control for selfish motives and frienemies who hated him "with a passion" but smiled sweetly in his face. But, it has some bright spots. And, with a coveted educational opportunity at the Harvard of the South, few, if any, would commiserate with him or mourn a river of tears at his "plight"..  

Some of these bright spots occurred on a sunny Spring weekend after mid-terms. He had requested a "super-single" dorm room in the quadrangle on the West End near the Fuddruckers far way from the shenanigans and antics of the freshman athletic dorm. And, on a whim, simply filling up a schedule which he had planned on building around physics courses, he took a course called "Introduction in Computers and Problem-Solving". Its course call numbers might have been CSE1340. But, he might have that confused with the C++ course which he taught, as an adjunct lecturer, in Carruth Hall at Southern Methodist, Vanderbilt's pretentious little sister, in 2004. 

He did not look at the course description and assumed that it would discuss using computers for completing college research papers and performing basic business tasks with some experiential learning. It was not. 

It was a course in Pascal, a popular "first" language taught in programming fundamental courses at the time. Pascal primarily was used as an academic language, although it had many of the features of a "professional-grade" language with exception-handling, pointers, and structures like C. 

The course was "well-taught" by a graduate student whose husband was a graduate student in physics who believed that he had unraveled the mystery of "cold fusion". She might have been the author's first and likely most efficacious and inspiring college instructor, based upon life's outcomes. Yet, she also might have been in violation of the illustrious Vanderbilt Honor Code during the Spring of 1989.

While in the midst of those "sunny spots" gleaming through a tall window with a almond drape, this author drafted a few "visionary" computing concepts in his primary red Mead notebook purposed for his prose fiction class, ENGL 104W, taught by professor Robert Bacon, an adjunct. 

In retrospect, this seems appropriate seeing that ENGL 104W was a writing, W, course required for all freshman and a prerequisite for graduation. Plus, the author, a dreamer, was unknowingly penning history at the time, as his back rested against the frame of his twin bed in a super-single dorm room.

Upon completing this list of ideas, he shared them in class. As was said, watch out! The graduate student who taught the class asked if she could see the notebook. She reviewed it and the "detailed" list of ideas. This visionary concepts drafted on that weekend were:

  • programming by contract (rebranded design by contract by Dr. Bertrand Meyer)
  • object-orientation with visions for inheritance, polymorphism, encapsulation, information hiding, access modifiers, and other primitive features of this concern partitioning approach.
  • JAVA, which he code named Oak, a freely-distributed and universal virtual machine language that was object-oriented possessing product features like applets, servlets, and factories. Each of these features were implemented differently than he originally intended. Yet, it became a highly viable product. All of this was present along with an "original" tear-drop doodle titled the Duke of Earl and given the gender-neutral name of a freshman sweetheart from a "special" high school program called Horace Mann..
  • action-orientation (AO) as a meta-concern separation paradigm based upon objects. The world met AO in a form that was much different than intended lacking "actionable" data types (ADTs)
  • an action-oriented language based upon "interconnected and dynamic" object configurations called Python, since the arrangement of actionable data types in motion looked like a ball of writhing serpents in his mind's eye.
  • a vision for the concept of architecture in software, based upon principles from mature engineering fields such as construction engineering.
  • the notions of model-view-controller and layered architectures
  • an idea for patterns and frameworks in computing inspired his grandmother's Jim Walter's home in Chattahoochee, Florida. 
  • the plans for a research group called the Gang of Four.
  • and much more...
It was hours of "intellectual" fun and a welcome respite from the weight room, agility drills, and that "hateful" Louisianan drawl and smokeless tobacco breath of his position coach, Greg Mantooth. 

The graduate teaching assistant likely had very little problem understanding these notes on the surface. The author often was called "simple" by his high-school sweetheart during his junior year, a tall-petite freckle-faced gal with stormy grey eyes and bushy burnt orange ringlets draping her neck. It was not that he was a dunce, think-headed, or could not comprehend academic material; she said that, when he explained the concepts in the physics lecture which they shared as juniors, the lessons that he weaved were super clear and easily understood. 

Although, in his mind, she was quite an enigma that only Alan Turing's genius likely could unravel. 

Yet, the graduate teaching assistant could not read between the lines of his writings. The most "powerful" concepts in those pages were "hidden" in his notes. They were personal engrams which only he can invoke upon remembering the contents of those "conceptually-rich"  pages with "interconnected" ideas. 

One of these is this approach for developing software systems. As a freshman, he sensed that certain behavioral abstractions were "archetypal" and "primitive" when constructing software. The controller is one. Mostly, an "underappreciated and hidden" step in the software development process, the controllers play a role as vital as compilers or  interpreters. In fact, in ways, they "interpret" the "desires of the end users" and "encode" these as "logical and salient responses" that it returns. And, in a very simplistic and primordial way they perform the system's "thinking".

He recognized the presence of these abstractions in the simple and elementary "menu-driven" systems which he built around a command-line interface on the IBM model 20 Personal System in his dorm room. It was while studying the general behaviors of a Pascal program written as an assessment for that course that he saw the fundamental features of the model, view, and controller architecture.

In fact, such systems would more naturally and logically be termed a view-controller-model architecture. This is based upon the innate organization of its layers. But, these terms were circularly permuted for a reason.

This was another of the "hidden" ideas in his notes which were misinterpreted by those who have "inherited" those visions. Hence, history and the world of computing have a "bastardized" rendering of this concept.

Thinking of languages, like JAVA, as a future generation of computing dialects built around virtual machine platforms in conjunction with the model-view-controller architectures which seemingly surround the core of every system's logic, he drafted the following acronym based upon algebraic reasoning.

VM * MVC  //Virtual Machines Running Systems with Model-View-Controller Architectures

VM * VCM //Re-Arrangement of Terms

VM * VM   //The C Represents Unity Since It Can Be Written Once and Run In Many Instances
                    // as a General-Purpose Controller ( GPC = 1 )

MV * VM  //An "Obfuscation" Step that has become a modern computing paradigm,
                   //Model-View - View-Model

(VM)^2      //This was the true vision for a "VM-Squared" Architecture. A System With A 
                    //View-Model Architecture Running Atop a Virtual-Machine
                   //A new generation of languages and paradigm for development built around the concept
                   //of WORM-driven General-Purpose Controller.

It be should mentioned that the "well-known" acronym WORM was birthed in those notes and had bi-fold meaning. Firstly, it reflected the universality found among a widely adopted virtual machine. Secondly, the dynamic "serpent-ballish" configurations envisioned as "his" Python programs, supporting innate concurrency, were the structural equivalent as a clump of interwound worms. This might have resulted in the concept of a WORM-architecture, seeing that the interconnected objects in an action-oriented configuration would be a cascade of activity after an "initial" method is invoked, much like an array of dominoes. And, it might be the case that a "vision" for a server based upon such action-oriented structures was born that day. In short, the phrase "domino server" might have been in those few pages of notes. 

This "MVC with a GPC on a VM" is not what has been recorded historically as a "VM-Squared" architecture. Why? Honor Code violations at Vanderbilt University. Do not get me started on "intended" projects name "Jovial" and "Jocund". These most likely are the only vocabulary terms distinctly remembered from lessons learnt while in grammar school. The author's six grade teacher suggested that her students learn a word per day. She said that doing so would enhance scores on college entrance exams. "Jovial" and "Jocund" were terms that she gave on one of her weekly vocabulary quizzes. These projects were intended in honor of her. Their original visions were never realized and simply are "misty" water-colored memories (in the key of Barbara Streisand).

In defense of this graduate teaching assistant, the author sent extended family members who were on the executive leadership team at Sun Microsystems these notes in the early-1990s. In fact, the phrase "Share with Gerald at Sun" was in those pages. The author was told that the computing corporation already had been pitched this JAVA idea; and, had he not sent the original writings on notebook paper, JAVA might have never been produced. His "family" members knew that a college student should not have a copy of a proprietary idea which was the property of Sun scribbled on notebook paper. So, the development of the project might have been reconsidered since they then knew that it originated with the author. This resulted in the proliferation of these ideas.

Not caring for the revelry of the football life, he left Vanderbilt after that Spring.

It was the case while an undergraduate at Grinnell College in 1991-1992, he took a course taught in Niklaus Wirth's Modula-II which used the notion of objects, imports, exports, and access modifiers. He does not know the "officially" recorded history of Modula. its objects, and origination; but it likely is "intentionally" pre-dated before the Spring of 1989. And, weeks after sharing his notebook with the graduate student at Vanderbilt, he heard a couple of academics, likely professors, enthusiastically discussing the potential for object-orientation and the concepts he had crafted in his notebook while walking the corridors of the hall were he attended his Pascal lectures. So, it seemed prudent that he share these visions with the intended recipients at Sun after attending Grinnell. Time was short.

Although, an "estimated error tolerance" exists in all of these historical dates. For those who were "well-versed" in the established practice in software development circa 1988 and might have attended a conference on Systems, Programming, Languages, and Applications (SPLASH) which spun-off OOPSLA or the first Software Architecture conference hosted by the ACM, you might see threads of plausibility in this account.

For those who know recently recorded computing history, this might seem far-fetched. But, for those who are in academics, understand the pettiness of the politics and grandiose egos, plus are familiar with the treacherous nature of corporate espionage, this account might seem somewhat reasonable. 

For one, successful "visionaries" in computing, such a Bill Gates, often say that one must separate the innovator from the vision early in the product development process. Many have been documented as saying that innovators are highly intelligent, chock full of ideas, and prolific; but, they do not understand business, which is ruthless. Innovators like dreaming up new and novel ideas. Businessmen enjoy making money primarily for themselves.

Innovators are nice guys. They are proverbially that "last guy in the line" at a chili feed. Why? They simply let the woman, children, and elderly go ahead of them. And, they do not fight with the aggressive males that push past them. What do they invariably get for their reward? A few cold beans, in oily, over-spiced tomato paste, that have been burnt and charred from the bottom of the pot plus unsatisfied hunger pains. Mmmmm! 

As a rule of thumb, businessmen are "type-A" personalities.

Enough about the author. He is simply thanks the Author and Finisher of his Faith, seeing that an athlete, an offensive lineman (S. Bishop) wearing #73, was driven by Vanderbilt's coaching staff until he perished in 1987 from heart failure. The author who wore this same number when he was on the team is simply thankful that he survived his hospital stay when the football staff, led by the strength and conditioning coach Brad Bates, drove him past his limits. Only experiencing mild heatstroke at the time, he has lived and seen his visions realized, although he has not been credited with them. One of his teammates whom he might have known during the 1988-1989 year was not as fortunate. The Lord and His Mercies are paramount. It is his prayer that his predecessor who wore #73 rests in eternal peace.

- Jamie Guertes' Husband (Forever In Love)