How G15 PMN's FCM differs from object-oriented programming and is a viable alternative

by S.R. Weber


Location of this paper on G15 PMN FCM:
intraplates.com/g15-pmn-fcm
G15 PMN FCM programs: norskesites.org/fic3/fic3inf3.htm



BACKGROUND
  It's an objective historical fact that, when Bjarne Stroestrup developed C++ as an object- and class-oriented language, with objects, he was--as he has indeed acknowledged--borrowing concepts from the Simula-67 language developed and completed in Oslo, Norway, in 1967, by Ole-Johan Dahl and Kristen Nygaard at Regnecentralen, Oslo. In Simula67, as an extension of Algol (an earlier language, a bit like a primitive form of Pascal), there is the whole set of concepts--class, objects, inheritance. My own father worked with Simula, a language they developed prior to Simula67, which had processes rather than objects, and in some senses had a less hierarchical feel.
  When Kristen Nygaard, during one of my meetings with him over a cup of coffee in Rosenkrantzgate, at his favourite "journalist-free place", as he called it (his fame in Norway considerable, this was around year 2000)--said that only a structure that is not rich, is a structure, it was in defense of hierarchies. I had argued that the processes of the nonlocal as indicated by works of such as David Bohm on quantum physics, and who I had the opportunity to meet a number of times, suggest something more of a network, less of a hierarchy, with a "richer type of structure than hierarchy".
  So we didn't agreed, but I felt it nevertheless was a moment of some depth for me, to be able to formulate what I had felt all the way as for object-oriented languages to one of the two people who, as far as computer science history goes, originated the whole shebang.
  I let it go, and we proceeded to discuss quantum theory and how computer modelling might have a role in it; at times he would speak about his newest ideas on computing and on language development (including his new pet language projects, made in colloboration with others, called "Beta"); and we would speak about the University, about education, and the conflict between what he called "pioneers" and "all the rest".

FCM AS A NEW WAY TO DO PROGRAMMING
  My starting-point for thinking beyond objects initially connected to how the notion of warps--as I called them--or "pointers", as they more lamely are called, in languages such as Forth and C, could be harnessed in a more standard way if thought clearly about. For the mechanism allowing objects to exist, floating about in an imaginary data space with algorithms attached to their data elements, is of course just this thing--the warp, the "pointer" that allows a program with somewhat prespecified input/output properties to be called from a dataarea rather than having to be named specifically in the program entertaining a reference to this special dataarea.
  So G15 was built up, as a machine language or assembly language, in which the notion of the 32-bit number was embraced as the most psychologically meaningful type of number to operate with in computing, and a mechanism by which virtually everything else can be implemented. For one of the reasons warps were complicated to work with in both Forth and C was, after all, that these languages didn't quite define these as part of themselves, but rather merely 'allowed' their existence, manuals asserting their hardware-dependence. (One of the things that made C. Moore, author of the first Forth, break with the proposed Ansi-standard of Forth was that the Ansi proposal commitee wanted to introduce words like 'cell' to make a second-hand wrapping mechanism around the pointers that Moore had used to his delight, in creating a language that allowed interactivity during the motor control of such as telescopes.)
  Then, it was clear that G15 required a layer on top of itself for ease of use. I wanted something that learned everything of the the text-stack language I had made earlier (part of the socalled "Firth platform" and the extensions I made for it under the name Lisa GJ2 Fic3), which made stack handling--an essential ingredient of languages that has the interactivity and first-hand feel that Moore wanted with Forth--far more easy than in Forth. I wanted to go back to numbers in stacks, but have a language that was integrated with its own font and its own card concept for a more vertical coding approach that would remind the mind of the programmer to think in terms of stacks, rather meditatively if you wish, while doing the coding--and which also would high-light the important features without this high-lighting having to be done by the notorious rows of *'s and such that fills up just about every object-oriented program of some size on the planet.
  One of the most misleading features of the verbose programming languages in the class of object oriented programming languages is that names of variables and names of functions and objects may be so suggestive that the attention is distracted away from looking at the code. The overall tendency, also, in object-oriented languages to use pompous words (cfr the "import" statement that starts every Java program, for instance, or the "self" word in Python, or the "bless" word in object-oriented parts of Perl--as some examples)--further clouds the mind of the programmer and all in all contributes to a second-hand approach to data and programs. In seeking a first-hand relationship to data and programs and how they are weaved together, we are making a statement of seeing computer programming as a form of science, not just as a form of consumer electronics production and shaping; and of seeing computers and robots as something that not only initially, by at absolutely all stages are completely overseen by understanding human minds and not something created by sloppy, inattentive, second-hand processes and then invested with fierce motors and potentially damaging equipment of various sorts. In short, first-hand programming involves a dimension both of ethics and philosophy, but it is also hugely practical--it means making programming much more fun.
  So these considerations created the particular structure of the G15 PMN programming approach, where one takes to G15 to do things that require optimalisation, but use PMN whenever the speed of PMN, as half-compiled and half-interpreted (we might say), is adequate. PMN will then deliever, due to its very strict syntax but its complete openness as to the handling of warps, or "pointers", in its nearness to 32-bit numbers throughout, functions and data definitions and matrix definitions also, --including matrices with functions--a naturally understandable series of programs, naturally first-hand, naturally esthetical.

Then enter FCM, the name coming from considerations as to what a more mature computer science ought to call the type of mind-inspired programs that go into robots and such-- first-hand computerised mentality.
  We have elsewhere given arguments against the AI concept and this will not be repeated here.
  The approach of FCM is however not exclusively an alternative to AI, it is also a furthering of what we can, as a broad category, call a level-network process oriented form of programming.
  In FCM, then, instead of objects floating around in an imaginary data space created through calls on a hierarchy of classes of them by a main program, we have a network, with level numbers assigned to various parts of the network so as to indicate sequence of performance, of nodes, including nodes with one or more algorithms attached to them. In contrast to object oriented languages, the data space is not imaginary, it isn't kept rather in the clouds or hidden from the programmer. Here, in FCM as implemented in G15 PMN, the indexed matrix of nodes is entirely concrete and available and indeed every reference to it is by means of numbers in the 32-bit domain, numbers, that is, within the range of about a billion or two (plus, minus), so that we aren't speaking of numbers as long as a line of text. Learning to work with and even to some extent love numbers is learning to work with order, order as such, we might say, or one way of presenting order and symmetry to the mind. This requires that fancy names don't cover it all up. We must have access to the numbers, see and check what's going on, not just when we are correcting programs but also to experience more clearly in the mind the order there shaped as plays itself out on our computers, our, indeed, Personal computers. The PC concept indicates this first-handedness and part of the PC concept is a keyboard, which facilitates thought more than dictates to some type of voice recognition algorithm, and the large screen which also faciliates thinking by clear presentation, whether of text, image or symbol; as well as the mouse pointer device, called on as supplement to the keys on the keyboard but not needlessly much.
  The PC running G15 PMN FCM, then, has in it a level of nodes, so that these nodes may act on each other, to activate and deactivate one another (we might say), and give and borrow data from one another, and all this in a way that involves a loop that spins through, again and again, all the nodes in what we call FCM loops. Neither the structure of the nodes nor the loop is hidden from the programmer but in contrast neat little definitions that are highly accessible and not even precompiled, but run through and compiled during each startup of the FCM, through the standard 'Third Foundation' app that is the G15 PMN in its peak.
  There's a lot more to be said about these structures,-- but I'll give Nygaard right in one point, they are good structures, these FCM nodes, or 'foundries' as they are called inside G15 PMN FCM (for they are creating other things as ovens that melt and shape metals), also,--in part--because they aren't "too rich". They have been defined with some stringency, so that the programmer, while organising his or her thoughts in relation to a particular application to be made in FCM ways, will know what the contraints are, know the boundaries, as it were, of the stage.
  Indeed, during the last conversation with the late Nygaard, we spoke about programming in terms of metaphors: "the theatre", he said, "is an execellent metaphor of programming."

***** FINIS


Document written in G15 PMN's B9edit editor this date: 2016:12:23
and prepared for net by this G15 PMN app# 3829321.


COPYRIGHT: You are permitted to redistribute this text in respectful contexts when whole, nothing added and nothing removed from it, including author, date and with proper reference to the website indicated above where it was first published.