Could the author of this page please sign his/her creation?
Hmmm. Probably lost in outer picospace. ;-)
This is written in the poetic style of Kjell Godo (squeaklist@gmail.com)
Is a long long long term project on the 10 year plan.
The idea is to make an OpenSource platform for Smalltalk, Lisp, Prolog oriented people to be able to program in. As opposed to programming in C, C++, Delphi, Basic, or Java. Yet still to inhabit all those worlds that the C, C++, Delphi, Basic, and Java programmers inhabit. It's supposed to take the best ideas of everything that I know about up to this point and put them all into a single idea right where the rubber meets the road. It is to be both OpenSource yet commercial at the same time.
That's not the whole thing in a nutshell though. The main objective of this project is a kind of circularity. The quickest way to explain it is to get on the loop somewhere and start going around.
The idea is to make a triad of languages based on the Little Smalltalk idea.
The three languages are-:
PicoSmalltalk
PicoLARC
PicoProLARC
I would like to shoe horn several of the ideas and code in Squeak to be able to create these three new language systems. Because Squeak's Smalltalk to C translation idea is better than what I had originally thought of doing.
The whole PicoVerse is kind of circular so maybe the best thing to do is just to start somewhere on the loop and start going around. I will update this page in the future.
The main idea ( there is only one? ) is to make a system that is completely adjustable in every sense of the word. Both in size and in shape and in style. The sense of modularity will be increased to the farthest extent that I can manage. And there will be a better BAZAR style development system.
The other main idea is to have broad highly automated pathways outwards into the rest of the worlds of C, C++, Basic, Delphi, Java, etc., All the other languages/platforms/applications in existance. Including MSWord, MSExcel, ( .:shudder:..:cringe:. ).
The other main idea is to be highly installable and uninstallable and not leave any garbage lying around.
First of all what about the LARC part of the two names. L stands for Lisp. ARC is for Xerox PARC.
Now for something about each language-:
PicoSmalltalk is a suped up version of Little Smalltalk( if that is possible. At
least it will have a bigger mission. bigger? )
PicoLARC is a combination of the simplicity and recursivity of the parenthesis lambda syntax of Lisp and the ( anObject message ) self documenting message send ordering including keywords of Smalltalk. It will have the class hierarchy of Ansii Smalltalk.
PicoProLARC will be PicoLARC but with a Prolog bent. The main idea of this language will be Prologishness. But it will have the same syntax as PicoLARC.
Now we get to the Pico in the names. Pico is a souped up version of the Little in Little Smalltalk. The source code for Little Smalltalk takes up 50K of gcc.
The PicoLanguages will each start with a minimal core. A single line of text perhaps, just to drive home the spirit of the whole idea. Then from there will be modules, highly automated modules. The system will be able to browse and edit all other languages in the same way that Smalltalk browses and edits itself. Simple textual source code files are OUT. Except that you will be able to output the entire system to make file + source + databases + image files etc. if you want to. These modules will probably start out as Squeak or Smalltalk/Express Objects.
The Main idea of the PicoLanguages is that every single part of them is in a module. From top knotch to toe nail. Which is suppose will involve the Squeak idea of Smalltalk to C translation. ( I'm still adjusting to this idea. It seems destined to change several of my initial foundational ideas. )
And these modules, KEGModules are not just any old modules but they will be extremely plug and play modules. Slide the old one Out and Slide the new one In will be their motto. Whatever has to be done, designed, structured in order to carry this goal out WILL BE DONE.!!! make no bones about that.
The main goal of this modularity will be for a dumb spoke from off the street to be able to learn Smalltalk or PicoLARC in a few weeks and then use that to look up and down the system and be able to tweak it all as easily and as well as subclassing and overriding a method in Smalltalk initially was when one first tried it. And I do mean THE WHOLE SYSTEM. !!! All of it. Every dot and every q and every interface to Java every bit of attatched Delphi, every jot of DLL C code will ALL BE IN —–>MODULES——.
period.
case closed.
you better believe it.
yes sir.
you betcha.
And the documentation system. Will be second to none. Documentation will be the PicoVerse's middle name. You aint seen nothin yet. Well you may have, but if you have, I haven't. But from what I have seen. You ain't seen nothin yet. And I am just anal enough to do it too.
Okay, back to the plug and play. You will be able to slide out and slide in various different memory managers, etc. There will be multiple versions of every module in the system and an highly automated database driven subsystem for manipulating all these things so that one module can be slid out and another slide back in in 10 seconds. If it takes any longer than that then you need a new CPU brother. And that is a FIRM specification criterion. Everything in the system needs to be able slide out and slide in in under 10 seconds. ( not that 10 seconds is any magic number but it drives home the idea of the whole thing. ) For instance you will be able to have completely different memory managers that each have the same module interface that can be exchanged for each other within 10 seconds and a single click. But the system is not limited to a single memory module interface. There can be seperate different infrastructures that take different memory module interfaces. So that each memory module is not restricted to a single interface with the rest of the world that was promulgated by whacked out programmer X way back in the stone ages. There will be memory modules A which all have the A interface to the rest of the world. These will only work on A type infrastructures. Then there will be the B memory modules which will have the B interface to the rest of the world. These will only work on B type infrastructures. etc.
okay if I still haven't got it right I will just have to come back later.
These modules will exist in a cloud. A big cloud around that first initial symbolic line of text. The starting point. And all the modules will have dependencies going in and coming out. If any module M is dependent on any other module S then that dependecy will be saved inside that module M. M will point to S as one of its dependentOnModules( I need a better name for this ). S will point to M as one of its dependents. Okay I may have gotten the details of this mixed up right now but I'll just continue, this can be fixed up latter.
Any way there will be an automated subsystem whereby you can trace pathways up trough the module cloud following dependencies and push a button and cause a new version of whatever to be generated instantly to your specifications. For instance-: a small little itty bitty smalltalk that has not GUI and can fit on the head of a pin( like Little Smalltalk ), or a big hugemongouse monster like VisualWorks, and everything in between.
I'll just list off a few of the other main ideas and come back later and fill them out-:
Each PicoLanguage will have the exact same internal byte level Object structure. C level Object structure.
Each pointer to an object in any PicoLanguage will be able to be local( within this process ), aroundTown( on the same machine ), longdistance( a URL of some kind ). I don't know exactly how this will be done but it should be small whatever it is so it's not too much overhead.
And there will be shared memory spaces where the different PicoLanguages can do stuff to each other's innards.
These three PicoLanguages will generate PicoOperatingSystems. Or PicOSes. Each PicOS will be a single Object that points out to other resource and server Objects. And every Object will have its place either in the image or in a database.
Each PicoLanguage will be able to spew out binary or text or encrypted text executables and shared libraries that can be thrown across the net and executed on the other end in a range of security modes.
These PicoLanguages/PicOSes will have piggyback in their middle name. They will piggyback on every other OS and language.
The PicoLanguages will not require a GUI coded directly in them. The first GUIs for the PicoLanguages will be coded up in some other language like Java or Delphi or VBasic or some Linux GUI like tK or whatever, could even be a Smalltalk GUI like the one for Squeak. By this I mean that PicoSmalltalk will have a pathway into Squeak and will use Squeak's GUI without actually being in the Squeak image, it will be in a seperate PicoSmalltalk process. The PicoLanguages will switch in and out different GUIs along with all the linkages within 10 seconds at the touch of a button. The system may have to recompile stuff etc but it will be that easy.
There will be wide highly automated avenues outwards to CORBA, DCOM, COM, etc.
And ALL of it. All of it will be in modules. Highly automated modules saved into databases.
So the main idea is to bring the entire world to the fingertips of the Smalltalk Lisp Prolog programmer in the most flexible way. This flexible way may take longer to implement initially than a hacked out version made in the common way of slap something together and stick it to the maintainers, but will in the long run win out. I know because I have implemented something like this on top of Smalltalk/V 2.0 and have been using it and adding to it for the last 9 years.
And when we flew down from Seattle and Adele Goldberg said to us in her 1 week industrial class at Stanford that it may take 3 years for you to build up that framework, I said Amen reverend mother Adele, and set to it. I may have been the only one. And it did take 3 years. But at the end the system just stopped growing. The image size which I had been chewing my nails over, just stopped. And has sat where it was for the last 3 years or so even though I keep adding functionality at a somewhat slower but still regular pace. And I have the book A Little Smalltalk to thank partly for that.
But I didn't fully use the Modules I made and so now I'm stuck in Smalltalk/V. That mistake will not happen in the PicoVerse. And I know whither I speak. What I am proposing is the apex of 9 years of thinking and working on this. Because I am tired, of having to put up with something less. And I want to make something or spark something into existance that will put the C, C++, Java, Delphi, Basic world to shame. Just absolutely to shame. Absolutely and unequivocabley. I want every damned one of their reservations and equivocations and little hates, to be answered. And answered hands down.
And then it would be nice if the whole thing got promoted. And I'm not above the Microsoft tactics of PHB zapping to do it. I'm not above including sex and religion and or whatever it takes to do it either. I'm not above grabbing them by the balls. Just like a dad blamed marketing man selling dog food on the TV.
( ( no slander or slight on any or all religions or faiths is intended. ) )
I suppose all of this stems out of my long suffering angst at watching the commerical Smalltalk vendors shooting themselves in the foot. Thinking small. The Amiga. OS/2. PHBs all. Small potatoes PHBs. From the backwaters. Their people make something good and then they don't run with it. –>They- even may make something good and then don't run with it. And the result is that as a result all the programmers who were depending on them to keep this line of work open and growing so that lots of new jobs for it are in an abundance and can easily be got in any town in the nation are let down. Maybe they will have to go and eat their heads off and learn to mouth Java. ( shudder, cringe ).
Now the PicoVerse could set this to rights. It may never come into existance. But I hope so. If not then perhaps Linux will do it anyway. Or some other thing. I myself don't really care anymore because I am not dependent on any PHBs. But it would be nice. So when I get the time. I'm going to try. If anyone wants to run with the idea go ahead. I may use what you've made to make my own version if yours is not what I want or maybe it will be and I will be saved a lot of work. Either way, okay.
Well, okay, I'll come back later and see if I still agree with any of this stuff.
