Another CABOOSE MVC Aside : Actionable Data Structures and Object Machines

Team. We promise simplicity, but for brevity we often omit supporting facts which will make the content of these post more accessible for new computing students and other experienced professionals who do not work with these specific concepts. As we said in an earlier post, we have very limited skills with the functional programming paradigm. This is because the use of command (imperative) lists is more common in traditional high level languages used for computing such as COBOL, FORTRAN, C, C++, JAVA, Ada, and etc. Other computing professionals learned functional programming as freshman at certain colleges. So, please search for more web-based information on the terms which seem uncommon. This is what we usually do when we meet unfamiliar terms. Once you supply this missing content, these pages will seem more sensible.

Over the last few post, we have been discussing actionable data structures. This arose from comments on our efforts at learning functional programming in JAVA 8 with its lambda expressions. We mentioned how these lambda expressions which are unnamed (anonymous) functions might be useful for implementing actionable data structures such as a map of behavior (actions). We also discussed how, for decades, data and behavior resided in the same program space but were not grouped (encapsulated) in bundles of related data and behavior. We also discussed how the creation of objects in the late 1980s was the realization of this concepts. Objects are not a final resting place, but a naif -like step toward more expressive ways of describing software modules when they model real-world entities. 

Shortly, after the development of the first object-oriented language, C++, many started discussing the notion of an object machine. Such a device would likely be purely virtual; however, instead of processing individual low-level commands such as those found in processor microcode or assembly instructions, these (non-physical) virtual processors would process streams of objects or commands which manipulated various class instances(objects) which one found stored in the virtual machine's memory.

With a dab of imagination, one can envision an actionable data structure such as a processing queue that functions as a virtual processor for such a non-physical machine. Being a queue, it would be naturally pipe-lined, and, being non-physical, it could do branch-prediction on the enqueue operation. This would alleviate pipeline stalls when a branching instruction decides that it must redirect the program's flow of control. The only constraint is that any object between the head and tail of the queue could not modify the state of the branching condition. This might restrict the length of the queue by not permitting any future enqueues until the next "object" for processing can be definitively identified. This is a stall of sorts for a processing queue, but does not require a flushing (ignoring) of instructions currently in a processor pipeline which are unusable.

All physical computer's use what one calls a Von Neumann architecture. The processing capacity and the memory exist in differing physical spaces. Since objects represent a bundling of related behavior and data, an object machine implemented with an actionable queue is a slight departure from this logically. Ultimately, the computing work is done on a Von Neumann machine, but it might be possible that one can reason about the processing differently when using an object machine. Since one inevitably is solving some sort of problem with each computing task, reasoning with more powerful, higher order paradigms might produce simpler solutions for difficult tasks.

For more information, search the web for notes on object-based virtual machines or object machines.
Please pardon the typos. This was a "fun" post as the German descendants in this area say. We did not properly implement our bird foraging procedure..Hunt.. Peck...Think..........
Enjoy your week, The CABOOSE Team.

CABOOSE Aside: Actionable Data Structures - Stacks, Queues, Maps, etc.

Team. This posting is simply a side note in the CABOOSE pages about a concept which might benefit its development. For those of us who were computing majors and studied data structures, we learned about various abstract data types such as Stacks, Queues, Trees, HashTables, and etc. It might have been a few semesters later when we discovered the dynamic invocation behavior available in most high-level languages. With this span between learning these concepts, it would be highly unlikely that one would consider combining them unless one was regularly working on projects which used both.

    Traditionally, abstract data types (ADTs) held data only and had rules for creating, reading, updating, and deleting the values within them. These ADTs were an extension of the primitive types found in high-level languages such as integers and floating-point numbers of various sizes plus characters. Being the precursor of modern objects, they represented a grouping of state and related behaviors; however, their purpose was storing state and providing methods for the creation, reading, updating, and deletion of this same state based upon the the rules of their interface. Early ADTs might store individual primitive types or a grouping of such types in a "record of data". When objects became available, they were the entities stored in these structures, such as Queues. Yet, presently, most of the implementations of these common data structures do not support the dynamic invocation of the methods contained within the objects that they store upon pop, dequeue, get, or etc. An interesting class of modern data types would be the actionable data structure. Upon the pop, dequeue, get, visit, or etc. of the object stored within the structure, the atomic action of a specified method would occur. There might also be value in associating behavior with the "insert" operations of these data structures. The dynamic behavior of these actionable data structures also might be toggle-able.  

Just a note before the sheep start flying overhead. Enjoy this upcoming week.
Hunt.... Peck... Think.....

The CABOOSE Team.

Passing Behavior and Custom JSP/JSF Elements + Behavioral Maps + Writing and Summary

Team. One of the primary goals of CABOOSE is simplicity in software development. The organization of webpage concerns and their associated rendering behaviors should be as intuitive as the use of a Task-Object-Event (TOE) chart in the development of a Visual Basic application. Also, a software engineer does not need a enormous set of knowledge, skills, or tools in his belt. He can be  effective with a few simple yet powerful paradigms.

JAVA Server Pages (JSP) and JAVA Server Faces (JSF) support the development of custom tags for rendering page content. We have suggested the creation of a general purpose tag which might  be useful in accelerating web application development depending upon a manager's development resources. Using the Reflection features of JAVA, it could dynamically invoke methods of any class. Also, with the advent of simplified lambda expressions in JAVA 8, behavior might also be made available which supplies page content.

Support for such a custom element might be available in the first release of CABOOSE. We must learn more about programming with lambda expression which are just anonymous functions provided through a Functional Interface with a single abstract method. We are not aware of any limitations which might possibly prevent realizing this goal. Also, we must decide whether we supply support through the functional paradigm only or also supply a general purpose tag which supports reflection.

Weaving the source which provides the custom page content and storing it in a package or library might be much easier using a general purpose tag which invokes behavior written with mundane JAVA methods or lambda expression than crafting custom tags. It would definitely lessen the learning curve for an engineer who has not created custom tags before.

Finally, it seems that a great place for all of this behavior is in a map. Such keyed behavior could be invoked with a constant time complexity provided that the number of behaviors in the maps is small. Also, when these behaviors represent a well-designed instruction set with a given command format, one can provide a set of registers for holding the parts of the imperative. This combined this the behavioral map would provide a simple and intuitive processor in an interpreter architecture when creating a command shell or meta-VM.

ASIDE: A similar behavioral data structure is possible in PERL, PHP, and Python and other UNIX-like scripting languages. Such an Abstract Data Type (ADT), the behavioral map, is viable in most modern high-level imperative languages.

We freed up some extra time this weekend so we will redraft the summary of the end of the second chapter of the Ozark MVC 1.0 specification. It should be online before the end of next week.

Also, CABOOSE might seem like vaporware if you had difficulty compiling the source which we included in-line with these post (See January-March 2015). We have simply adjusted our delivery date after we discovered that Oracle was producing Ozark. We are hoping that we can ride that "Razorback" as it is adopted within the development community. Our tentative delivery date is one hundred and eighty days after the availability of the first production-grade release of Ozark.

Pardon the long message and enjoy this upcoming weekend.

The CABOOSE Team. 

Still Searching for Early Draft Notes for the Second Chapter | Oracle's Lamba Expressions MOOC

Team. It has been a couple of weeks since the last posted comments. The summary notes from Oracle's Early Draft of Ozark, MVC 1.0 or JSR 371, are still missing. We will continue looking. If all else fails, we will simply regenerate them soon. With our current work schedule, we have only found time in the past week for participating in Oracle's Massive Open Online Course covering Lambda Expressions in JAVA Development Kit (JDK) 8.

Oracle broadcast the lessons with a YouTube viewer so they are likely available for public consumption at youtube.com. Being that functional programming is not in our skill-set. This course is quite interesting and informative. We are aware that functional programming became a viable part of JAVA before JDK 8. We are also knowledgeable of the fact that JAVA is supporting other programming paradigms than that of the imperative one in its efforts of become the first truly "universal" language. With declarative and functional features, it lets one choose the most effective paradigm for the programming task at hand.

The lambda expressions in JDK8 are a concise representation of previous functional programming features in JAVA with its support of functional interfaces. These contained large amounts of "boiler-plate" code which the Oracle engineers have subtracted from the syntax used with lambda expressions.

Upon completing the first lesson of this MOOC, we realized that it might supply a means of supporting the dynamic invocation of behavior found in the CABOOSE model, since one can pass lambda expressions as arguments. These expression are ultimately anonymous functions in the form of a functional interface. We use this term, function, in the computer science sense, because it might have void inputs or return values which are not found in the traditional functions in the field of mathematics.

But, passing behavior as an argument is quite an intriguing concept. We are only novices at the use of lambda expressions, but wonder if we can get around their "anonymous" nature by placing these functional interfaces in a HashMap, requesting them as needed with a key, and placing them in a method's argument list.

In terms of CABOOSE, we could associate each page concern with a lambda expression which handles rendering that concern.  As compact as these expression are, this would enhance the readability and maintainability of a CABOOSE project; however, it would require that a manager have development resources who are comfortable with the functional paradigm.

One feature of functional programming is that it is "stateless". We have not fully grasped how this is in that lambda expressions might modify state in the surrounding scope. Yet, it does not modify state in a certain context of the program's execution.

We apologize for the lack of activity on this weblog for the past few weeks. Things should pick up soon.

Happy Coding. The CABOOSE Team.

MVC 1.0 Early Draft - Second Chapter Summary of Final Sections Missing | Very Busy

Team. Although we have been rather busy, we completed the summary of the rest of the second chapter last week but could not find a convenient time for placing it online. In the meantime, the electronic files containing the summary have been misplaced. We must spend some time searching our various USB drives. We apologize for the lack of post over the last four weeks. Our work week has included 60+ hours of activities since 06.01.2015. We are hoping that we can free up twelve or more hours after 09.01.2015. Please, check back periodically.

The CABOOSE Team. Hunt. Peck. Think. And Keep Singing. La-La.