Hi, Josh said, >This first one is a normal bootstrap, the exciting one will > be when Pepsi and Jolt are unified into Coke. This is > "Phase 4" in section 6.1 of "ALBERT".
Yes, it will be an "exciting instant"... Is it really the "exciting instant" what we are looking for? Reading the emails from Kjell to this email, I think we have not invested too much words trying to collaborate with his view. We are arriving to technicals details without talking about other ways of working... I said, other ways of working... (not other tools to work with). As I understood from the talk of Ian in Postdam, he is focused in writing (yes! writing the words of) the basic laws of a system that express itself when booting (a minuscule instant in the development of a system). I was interested in the goal as an anegdotic point in time, but wanted to explore if his system can be valuable for my objetives. When I saw that his system is written using the tools of the ´70s (words in a language) and he is simply writing text in C and macros with smalltalk syntax, I reflected on this and desided that his work is not valuable for my objetives because he is not using Smalltalk (he is writing, with smalltalk syntax, a system that can boot itself). His work and this list help me to understand that this is not aligned with my objetives (related with sustainable systems but not with bootable systems/languages). Kjell was susprised because the language to build bootable systems here is written with a C base, and asked if it is not convenient to doit from the Smalltalk side. I think that Ian do the best he can and use his tools (C based) to let him write the fundamental laws of booting systems. For other people it will be better to write code in Lisp or use an evolvable system of objects (e.g. one with the "syntax" defined by Alan Kay loooong time ago -not the first but, the last language for someone like me- ). The main difference is related with objetives and what we are really looking for. For someone interested in write the "correct sentence" of a booting system, he/she can use any language, and the instant of success will be granted by his work on words (and language formulation). No debugger is needed for write a fundamental law (the best way to constrain owr own future is to write/invent it). If a debugger is needed, then he/she must define the BUG class first. :-) For other people that are not happy to start from the genesis (again) and recognize that some time has gone, it is not enough an instant of excitement. What is the value of a bigbang of a system with no parent? -no family, no history- This point of view about sustainable systems has not been walked too much (at least as I know). Smalltalk systems has been sustainable from aprox. 30years ago and we, the persons, the "working hands" -not the "defining minds"- has been part of the system from the very first instance, upto the multitude of alternatives present today. For people that understand "sustainability" as the ability to continue evolving, other tools are available and better than languages. The language is not as important as the actions made on the system itself. One point of view is as valid as the other, but the activities and methods used under one path are not the same of the other (as the tools). When I understood that Ian's objetives are not my objetives and his tools are not valid to my needs, I look for other people trying to do something similar to my objetives and I has found the moebius project ( http://code.google.com/p/moebius-st/ ) they are working on Squeak Smalltalk and with the objetive to produce a Smalltalk... What? Yes! If we recognize that anything can change in a Smalltalk (also its syntax :-P ) any change we can apply to Smalltalk will make it another Smalltalk.... (the family concept constrain what is possible now) Sustainability of smalltalk is granted that way. In a language if you change a rule, you have another language; and you are under the rule of closed systems. In an open system one must work to complement the limits imposed by The Method and doing that way grants excitings instants many times in one day (instants of excitement in the privacy of the system survival when changed). We can try to define a language for all persons and a law for all systems; or... we can try to work to modify a systems that has booted +30years ago. The tools for each work can´t be the same, because the objetives and the methods are not the same. On closed systems (and writing any correct sentence) today it is important that at least one level the idea(ls) must be written in object oriented terms. It is accepted any language to specify the low level and an object design to map the basic rules. On open systems, are outside Object Oriented limits and it is not enough to write a design with objects. The problem of sustainability in open systems (natural and human controlled systems) requires the use of open instances (like smalltalk). The use of Smalltalk is convenient, but it is not related with Smalltalk syntax, and it is not related with Smalltalk "environment" (the contents). The use Smalltalk is convenient becasue it is a support to understand how to act using perception (sensing what we have done) and not using definition (saying what is there). Close vs. Open are not contraty but complementary. People working on close systems do not need to face uncertainty and need rules (good abstractions). People working on open systems need instants of excitement continuously to avoid the frustration when facing the limits of object orientation. Hope this loooong email can help to do not try to find a language/law/tool for all of us, and let us share good talk understanding that we can complement each other and it is not important to reach a conclusion at low cost or fast, it has been +30years from the first sustainable system in computer media. cheers, Ale. ----- Original Message ----- From: Joshua Gargus To: Fundamentals of New Computing Sent: Sunday, August 24, 2008 5:02 PM Subject: Re: [fonc] Coding Standards Michael FIG wrote: "Kjell Godo" <[EMAIL PROTECTED]> writes: So what you're saying is that the idc which is written in C compiles C like code into machine code? idc is written in Pepsi. You may be confused because the bootstrap .o.c files are included in the SVN checkout, at least until idc targets Coke instead of C. And then that machine code compiles Smalltalk like idst/Pepsi into machine code? No, GCC compiles the C code (until bootstrap). The idst/Pepsi compiles itself into machine code. And this bootstrapping happens over and over again and not just once or twice in a year. "The bootstrapping" is when Pepsi and Jolt are unified into Coke, and that need only happen once. Right, but there was also an initial stage in the bootstrapping where a Pepsi compiler was written in C (C++?)... this is "Phase 1" in section 6.1 of "Accessible Language-Based Environments of Recursive Theories" ("ALBERT"). This one has apparently already been discarded; now we just start from the (Pepsi-compiler-generated) files in boot/. This first one is a normal bootstrap, the exciting one will be when Pepsi and Jolt are unified into Coke. This is "Phase 4" in section 6.1 of "ALBERT". Cheers, Josh ------------------------------------------------------------------------------ _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
