a bit of the many i's in java programming

JonnyRadar

The Living Force
hello all,

i noticed this the other day and it seemed striking enough (and humorous) to post here.

for those of you who are not familiar with java (a programming language), one of the ways to automate something is to create a loop. though it can be whatever one wants, the variable that seems most widely used in loops is "i". ;) it works like so:

for (int i=1, i<x, i++) {
here is the function you want to repeat
}

the code runs from top to bottom, and since it recognizes that it's a loop, when it's done, it will "go back to the top" to see if it needs to run again.

so "i" starts off at one. "x" is the "cap", so to speak. it's basically the number of times you want the loop to repeat itself plus one. "i++" means that every time the loop restarts, it adds 1 to "i". as the loop progresses, "i" continuously increases by 1 until it reaches one less than "x", at which point the loop stops.

what struck me, and i hope i'm not totally alone on this (my perception of this metaphor, i mean) is that when i began doing "the work", my variable "x" was extremely high, so that the functions of my programming (societal, religious, familial, etc...) were running over and over and over. since i've begun however, i have been working on getting my variable "x", my amount of "i's", down to one, so that the functions of my programming will not run at all.

i guess this metaphor resonated with me, and i thought i'd share in case it did with anyone else as well... :P

synchronicities abound...
 
Not too sure about Java programming being a part of Work, I'd be more inclined to say it leads to illusion and delusion. Just kidding! :)

But I have to admit that this is a funny parallel for sure. i was used as short hand to indicate that the variable was an integer, and x a placeholder that represented a value from an expected set. (How many bugs in software are routinely found to be the result of expectations not meeting reality? And this in something one has consciously (?) created!)

So, fusing the values of x (integers as allegory for the little i) into a set with one member, thus breaking the loop programming is an apt analogy.

Fun to think about, but the process of reducing the set that x represents is, well, Work.

What kind of analogies could we draw from, say, functional languages, like Lisp, where the programs can become data and data can become programs?

:D
 
Yes, I really liked that one because it gives you hope of getting over"it"... at least it works that way for me:-)
 
Wouldn't there be a limit to x, (or little i's), at least according to Mouravieff, there's a max to the permutations available through different permutations of centers - positive and negative. What was that number? Argg...I loaned Gnosis out.
 
very enlightening responses, leading to areas of thought i hadn't previously explored. thanks guys!

azur, i like how you intertwined expectation into this metaphor! indeed the expectations can lead to bugs, confusion, lack of awareness, etc... and the Work certainly is fusing the values, i hadn't thought of that... i don't know much about Lisp but certainly our programming as conscious beings in this reality is MUCH more powerful than a simple java analogy, and it makes sense that in actuality it would be a symbiotic system, supporting a back and forth between the data and the program until they are in effect, creating each other in a constant stream of un-awareness. is this what you mean?

dippydog, i don't know the number of which you speak, but i'm going to try to look that up. however i was under the impression that the many i's could, at any moment, manifest out of an infinitely variable pool of i's. or perhaps i am confusing this with the quantum principle of nearly infinite possibilities at any given moment in time? or is it actual infinite possibilities?

either way i am finding that as i sift through the "data set" of my many i's, the programs are beginning to show glitches - showing through to my awareness at which point i am able to AT LEAST see them with my own "eyes". this is the first step i am on at this point, and it is rough man. rough but definitely worth it.

EDIT: i wonder if debugging could work into this at all. seems to me as though de-bugging is something constantly being done by the predator's mind, sifting through the cracks which are created by expanding awareness and attempting to seal off the holes so that the programs operate without hindrance. so that in effect what we're trying to do is actually break the program.
 
JonnyRadar said:
very enlightening responses, leading to areas of thought i hadn't previously explored. thanks guys!

azur, i like how you intertwined expectation into this metaphor! indeed the expectations can lead to bugs, confusion, lack of awareness, etc... and the Work certainly is fusing the values, i hadn't thought of that... i don't know much about Lisp but certainly our programming as conscious beings in this reality is MUCH more powerful than a simple java analogy, and it makes sense that in actuality it would be a symbiotic system, supporting a back and forth between the data and the program until they are in effect, creating each other in a constant stream of un-awareness. is this what you mean?
In effect, yes. It is symbiotic, and on further thought with what I said about data becoming programs, it is the case further on that it relates to perception freed of simple emotional, social and automatic behaviour, where the data itself is not the trigger for programs anymore, but a program might be constructed to adapt to the data. The analogy is falling apart here, obviously.

JonnyRadar said:
EDIT: i wonder if debugging could work into this at all. seems to me as though de-bugging is something constantly being done by the predator's mind, sifting through the cracks which are created by expanding awareness and attempting to seal off the holes so that the programs operate without hindrance. so that in effect what we're trying to do is actually break the program.
Following this analogy with programs, it might be better to see the programs as being part of the Operating System, as opposed to the Operating System being a facilitator to running the programs. The Operating System is the brain in its current configuration. The configuration varies, look into ligands. The hardware is changeable! So what do we have? An Operating System that re-writes it's own code when needed, i.e. the predator, in order to make sure that the bare metal (the hardware) does not change to displace it. You change the bare metal, the Operating System can't interface without changing, and this goes on until it may see that it is on track to being "surplussed". It does fight back.


The analogy with computers and lambda calculus comes really close, but the difference between a PC and the Human is that the latter can change not just the CPU microcode, but the actual circuits of the CPU. Consider the Hypervisor as an analogy for the first step in program identification. Can you see why a debugger built according to the rules and structure of the Operating System might not reveal any salient information as to the bare metal it is running on?


Cheers.

[many post edits for clarification]
 
Back
Top Bottom