John's Emails	Strip links 3
Strip links 2
To: Frank Schuurmans <frank@bio.vu.nl> Hi Frank, >> I can understand your unease with the links controlling the logic flow, >> because this is such a different approach from the structured programming >> we have all learnt. > >I have no problem with links controlling flow, i have a problem with >including them within a weblet. I think I am misunderstanding you. If links are not included within a weblet then it doesn't seem to be a weblet anymore? At least, not of the form in the diagram at:- http://brain.eu.org/weblet.htm Please clarify. >> Your idea means we will still have this sort of thing:- > >> WHILE x<10 >> IF y>4 OR p=t >> gosub random(x,y,p) >> ELSE > [etc] > >Now this is just normal programming, I want to seperate the flow controle >from operators. Perhaps a few examples would help me to understand how you do this. >> Having programmed in this way for many years in many languages I >> intuitively feel that there has to be a better way. >Off cause there is a better way (there always will be) Personally, I think that webneurons or hubs are close to the end of the story. If we can model the brain closely then there may not be much further to go. >> The brain does not operate in this fashion, it is a method devised >> without referencing the way the brain works. >I metioned before I don't want to model a brain. I don't remember. I thought the whole point was to use the principles of what has been under development for millions of years. >(when flow controle is >stripped you still can model a brain, not only this you can model many >brains!) You can model as many brains as you like with standard weblets too, because the number of webneurons and links can be countless. You can model a brain in a thousand programming ways, in many different languages. But most of these are tangled, and might take us a thousand years to get to an intelligent computer. The question is - which way has the correct and most compact building blocks for the model, so that we may achieve machine intelligence in our lifetime. >> We have to carefully think what properties a more correct programming >> method should have. >I'll start: > >- all properties of OOP Why? >- plus: a stronger seperation of data/flow controle/operators I don't really understand how (or why) you mean to separate them. >- plus: self-similarity This sounds good, but what is it? >> I can't see how you can disagree that "mappability" must be one of them. >> Structured programming is not mappable, weblets are. >I think structured or oop programs are mappable too, Impossible. To map you must be able to visit every part of the system starting from any point. If you start from a subroutine in a structured language you can only trace downwards to lower level subroutines. It is impossible to go upwards because there is no list of callers! This is why structured languages have been the most costly mistake in the history of computing (in my opinion). >but what I want is not drawing maps (the computer should do this) but draw >routes (=flow >control) on the maps. You mean like the arrows on the weblet diagram (http://brain.eu.org/weblet.htm)? In weblets (so far) the flow control is handled in the scripts within webneurons AND by the map. The FIRE command will cause other (linked) webneurons to activate. You can easily build a cascade (chain reaction) in this way. This sort of thing IS flow control. If you have a cascade of webneurons and each webneuron fires all its targets using:- FIRE ALL in the script, then the flow is almost completely controlled by the map alone. >> I really don't know what to say to convince you except what I have >> already said in previous Emails. I don't think you will be convinced >> except by trial and error on a live weblet system. By the way I have >> never had a fully live system yet, in any form. > >I think the rough idea should be clear and then it gets polished by trail >and error Yes. However, sometimes trial and error causes you even to change the original idea, often a major alteration. >One more point about mappability: >The question, 'is something mappable?' depends on the position of the >observer and the information he/she has, in other words is relative. When talking about mappability I am assuming that the observer is of the same approximate "size" as the things being mapped, and can be positioned at first on any one of those things. He/she does not have any information, just the ability to wander from one thing to another thing by following links. For example a man might explore a maze, or a car might map out a road network by driving round. In software you have to imagine yourself the size of a line of a subroutine. It will not be possible for you to wander back to any callers of the subroutine you are in, because there is no link to take you there. However, you can take any links (calls) to lower level subroutines. Therefore structured programming is downwardly mappable only. This is a restriction that severely restricts required freedom. Something is mappable if it is possible for a suitably sized observer to get to all parts of it, starting from any part. I think this is a simple and fairly absolute definition. It is incredible that many things in the world are mappable but that conventional programming languages are not! In other words, structured programming is not only unmappable, it is also not based on reality. I hate it.