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.
No comments:
Post a Comment