Re: unification of blocks and methods (procedures).
I first saw this in EULER (Wirth and Weber ca 1966), but then saw an earlier similar notion by Landin in ISWIM and its predessors. I used the idea in my first OOP language (FLEX ca 1967-9), which also had complete static nesting of scopes, etc. But later I decided I didn't like blocks as values because they are super time bombs when passed around and completely violate encapsulation. I really wanted external objects (not internal blocks) to be passed around, and wanted a simpler way to think of contexts internally. So we left them out of the first few Smalltalks. (I still don't like them ...) Cheers, Alan At 03:11 PM 9/14/2007, Peter William Lount wrote: >Hi, > >Martin Beck wrote: >>Am Freitag, 14. September 2007 21:44:48 schrieb Peter William Lount: >> >>Hi Peter, >> >> >>>>However, you indeed change the syntax of blocks for merging block syntax >>>>with method syntax when you say >>>> >>>>[firstName: aString | firstName := aString ]. >>>> >>>>aren't you? >>>> >>>Yes, the syntax adjusts towards a unification of Blocks and Methods. >>> >>Ok, but in my opinion, it is not necessary to adjust the syntax to >>achieve this unification. I'd rather interprete a Method as a named Block. > >With the change that I suggest it can use either format. It's the >most general approach. > >>Your syntax change does early binding of a name to an implementing >>Block, which we don't want in Smalltalk... :) > >Please explain further, I didn't get your meaning. > >>The current block syntax does - as you stated, too - already >>incorporate the features needed in a method, like temps and >>arguments. So all you need, is to bind a Block to a class und a >>special method name (which has to have the same arg count). >> > >Yes, and resolve any "variable names" that need to be tied down to a >scoping context. Either at the point the block is attached to a >class (or traits node) or at the point when a block is evaluated as a block. > > >>While running the VM/compiled code, the context decides, whether >>the block is evaluated in a normal way, e.g. a home context and >>correctly interpreting the return etc., or whether it is evaluated >>in a method context. So we are at your differant evaluators again. ;) >> > >Well I'm not sure that we'd need a new evaluator for that, but >that's an interesting idea. Let me think on that some more. > >> >>>>I personally like to see a Block as a simple collection of statements. >>>> >>>Yes, that's a very powerful perspective. It's a hierarchical collection >>>of statements in the more general form. >>> >>A hierarchical collection which could be called Abstract Syntax Tree, hehe. >> > >;-) Yes. > >>Not to convince you (which is not needed ;) ), but just to add my 2 >>cents: We all know, that in a standard Smalltalk VM a Block is >>simple compiled code, which can [be] evaluated resulting in a >>single value. However, if you try to explain such lambdas, closures >>(or any other name you might think of) to Smalltalk newbies, >>especially those from C/C++/Java backgrounds, you end up in saying >>to them: "A Block is source code you can save in a variable and >>execute it later". I don't want to discuss, whether that is right >>or wrong, but I think it helps them to understand a little bit of >>what is really meant. > >I find that it's a very effective approach of explaining it to >people. At least it's a great place to get start explaining >Smalltalk blocks to them. > > >>That differs from the former statement, that it says "source code". >>And source code is a (hierarchical) collection of statements, even >>in Smalltalk - at least to some extent. >> > >Yes. > >>I think the newbie way of thinking of blocks is indeed the more >>natural one, than viewing it from the VM implementation side. >> > >Yes. It's also the way to think about them at the language level. >The VM is the implementation level and often it's job is to hide >much of the details of the inner workings from the user and the >language itself. That is why I prefer giving the language priority >in driving the design over the concerns of the virtual machine >implementation issues (if at all possible). > > >> >>>It's nice to move the discussion forward with someone who gets it for a >>>change. >>> >>Thanks. > >Your welcome. > >>If I remember correctly Ian Piumarta does (somehow) similiar things >>with his Id Smalltalk variant. > >Yes, Ian's work is really amazing. > > >>I believe, he adds blocks to classes as named methods, too. So I've >>got these ideas from him... *g* > >I did share my thoughts on the unification of Blocks and Methods >with Alan Kay and Dan Ingalls a few years back; as well I've >mentioned it at OOPSLA and in private conversations with various >people. Alan or Dan may have mentioned it to Ian or I might have >mentioned it to Ian at OOPSLA (I don't recall if I spoke with him >there). Or maybe others thought of it before. We have to ask Alan, >Dan and Ian about their coming to the idea. After telling Allen >Wirfs-Brock about it a few years back he said he'd come across that >idea before but that it seemed that no one did anything with it. So >I don't claim ownership of the idea (other than co-originating it) >but I do promote it vigorously since I see it's value. It's also not >a big leap to make as Block and Method syntax is almost the same - >the big leap is seeing it's value. > >Part of it's elegance is that it's such a minor change to make the >unification happen and that it has such a powerful new dimension >opening impact! > >If a change is required in syntax and it doesn't open a whole new >dimension of extensibility as a result then chop it out. It's like >Tilera's "kill design rule" for their N-Core chips (Tile64 or TileN) >where a N% increase in surface area of the chip must increase >performance by an equal N%! I apply a similar set of "design kill >rules" for syntax changes to Smalltalk and ZokuScript. If it's not >message based using existing syntax then I ask "how can it be made >to work with messages?" - this was the line of thinking that lead me >to see that all meta data and meta operations can be accomplished >with the existing unary, binary and keyword messaging syntax. That >was a breakthrough! It also means that almost all changes in syntax >are not needed as most changes are attempts to add meta data or >operations. The problem with new syntaxes is that they break the >notion of one uniform messaging syntax and make the world much >harder. This makes advanced topics such as code analysis and code >rewriting much more difficult and cumbersome since multiple syntax >forms are involved and they may not have bidirectional >transformations available when being converted this way and back that way. > >I see the elegance and beauty of a unified block and method syntax >for Smalltalk and ZokuScript such that I'm promoting it in the >Smalltalk community. Certainly it will end up in ZokuScript as it's >an essential building block for the future that I see for Smalltalk >like or Smalltalk inspired systems. > >If we as designers of a computer language (or other software >programs) fail to bring the principles of elegance, beauty and >simplicity to the language (or program) design and the design >process then how can we expect our products to be powerful or users >to be elegant, use beauty and simplicity in their expressions with >our languages and tools we make? > >All the best, > >peter > > > > > > |
Alan Kay wrote:
> I first saw this in EULER (Wirth and Weber ca 1966), but then saw an > earlier similar notion by Landin in ISWIM and its predessors. I used > the idea in my first OOP language (FLEX ca 1967-9), which also had > complete static nesting of scopes, etc. > > But later I decided I didn't like blocks as values because they are > super time bombs when passed around and completely violate > encapsulation. I really wanted external objects (not internal blocks) > to be passed around, and wanted a simpler way to think of contexts > internally. So we left them out of the first few Smalltalks. (I still > don't like them ...) > > Cheers, > > Alan Hi Alan, That's an interesting history lineage. Thank you. Are you saying that those systems had blocks and methods with the same syntax? I suppose you'd have to add Lisp to that list since Lisp functions and Lisp lambda's are pretty much the same thing, lists. You've mentioned that you don't like Blocks before. I've never understood why. Certainly they do violate encapsulation since they can be passed around and who knows where they'll end up (or even what they do when you get one). Is it that you don't like the use of the levels of nesting in the syntax provide by "[" and "]" that mark the block of code? What would replace them? Is it even possible for a linear one dimensional text grammar to do that I wonder? I'm glad that you added Blocks to Smalltalk-80 since they enable an amazingly huge domain of extensibility of the language flow control structures. That makes them worthwhile. It does seem that you were aiming at something else though. Have you written about that? What are your thoughts on what you're aiming for? I often find myself arguing for the creating of objects rather than using blocks (and collections and dictionaries) in many professional situations. People who get blocks sometimes rely on them way too much and it obfuscates the code - anyone can write spaghetti code. As soon as you are trying to do more than one different thing in a block or have more than one data/object value to manage it's often better for an object instead of a block. Often methods would be better off as their own independent objects for similar reasons. A nice aspect of Blocks is that they are extensible and that they have a very easy protocol, #value, #value:, etc... for working with them. Objects can even take on the block protocol at times pretending to be a Block by implmementing value. That's how my SortCriteria (aka Sort Critter) objects work within SortedCollections (http://www.smalltalk.org/components/SortCriteria.html). All the best, Peter |
In reply to this post by pwl
On Fri, 14 Sep 2007 05:58:31 -0700, Peter William Lount
<[hidden email]> wrote: > To quote Richard Dawkin's: "No, please, do not mistake passion, which > can change its mind, for fundamentalism, which never will. Passion for > passion, an evangelical Christian and I may be evenly matched. But we > are not equally fundamentalist. The true scientist, however passionately > he may “believe”, in evolution [or a certain computer language or > feature therein] for example, knows exactly what would change his mind: > evidence! The fundamentalist knows that nothing will." > http://www.timesonline.co.uk/tol/comment/columnists/guest_contributors/article1779771.ece? Everyone who believes that Dawkins is more likely to change his mind than any average fundamentalist, raise your hand. |
On 14-Sep-07, at 5:55 PM, Blake wrote: > On Fri, 14 Sep 2007 05:58:31 -0700, Peter William Lount > <[hidden email]> wrote: > >> To quote Richard Dawkin's: "No, please, do not mistake passion, >> which can change its mind, for fundamentalism, which never will. >> Passion for passion, an evangelical Christian and I may be evenly >> matched. But we are not equally fundamentalist. The true >> scientist, however passionately he may “believe”, in evolution [or >> a certain computer language or feature therein] for example, knows >> exactly what would change his mind: evidence! The fundamentalist >> knows that nothing will." >> http://www.timesonline.co.uk/tol/comment/columnists/ >> guest_contributors/article1779771.ece? > > Everyone who believes that Dawkins is more likely to change his > mind than any average fundamentalist, raise your hand. evidence found contradicting his position on evolution then he would change his mind. A fundamentalist places faith in some revealed magic above all else, facts be damned, logic ignored, reason forgotten. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: YVR: Branch to Vancouver |
In reply to this post by Blake-5
On Sep 15, 2007, at 2:55 , Blake wrote:
> On Fri, 14 Sep 2007 05:58:31 -0700, Peter William Lount > <[hidden email]> wrote: > >> To quote Richard Dawkin's: "No, please, do not mistake passion, >> which can change its mind, for fundamentalism, which never will. >> Passion for passion, an evangelical Christian and I may be evenly >> matched. But we are not equally fundamentalist. The true >> scientist, however passionately he may “believe”, in evolution [or >> a certain computer language or feature therein] for example, knows >> exactly what would change his mind: evidence! The fundamentalist >> knows that nothing will." >> http://www.timesonline.co.uk/tol/comment/columnists/ >> guest_contributors/article1779771.ece? > > Everyone who believes that Dawkins is more likely to change his > mind than any average fundamentalist, raise your hand. Folks, please. "Smalltalk" in the title of this thread refers to the programming language of that name. - Bert - |
In reply to this post by Chris Cunnington-5
On Fri, 14 Sep 2007 17:50:06 -0400, Chris Cunnington
<[hidden email]> wrote: > So, I'm interested in 6502 assembler, and I just bought Randal Hyde's "The > Art of Assembly Language" for the 80x86 set. The point of this is that I've > gotten into a large topic -- computer programming -- and I keep trying to > see it from different points of view. Assembly seems to me another great, > bottom up way to learn about this stuff. Being surrounded by people who know > so much more can be anxiety producing, so I'm climbing the learning curve, > and I favour the historical approach, thus the interest in old computers, > Commodore, and such. I started programming on a Commodore PET, in 6502 assembler. After a year or two, my parents bought me an Apple //c, which had a 65c02 (extended instruction set over the 6502). I spent many years writing a lot of 6502 assembler on that computer, and if you look through a pile of COMPUTE or Nibble magazines, you might find a couple articles with code that I had published back in the mid-80's. About 10 years ago, I got a hankering to do this kind of low level on-the-metal programming, but doing stuff on a 64 or Apple 2 just wasn't going to cut it. About that time I decided to get into robotics and embedded programming on 8-bit RISC microcontrollers, which feels a lot like programming a 6502. In 1998 I wrote a really simple compiler that translated pseudo-Smalltalk code into PIC assembler to run on a PIC. The PIC I was using at the time had 68 bytes of RAM and 1024 words of program FLASH, and I was able to control a servo, talk to an LCD, and a few other things with PIC/Smalltalk. http://www.huv.com/uSeeker/smalltalk/pic.html Anyways, the point being you can still get the same "feel" as programming on those old systems with nice new 8-bit RISC microcontrollers like the PIC or the AVR (my current favourite). Later, Jon -------------------------------------------------------------- Jon Hylands [hidden email] http://www.huv.com/jon Project: Micro Raptor (Small Biped Velociraptor Robot) http://www.huv.com/blog |
> I spent many years writing a lot of 6502
> assembler on that computer, and if you look through a pile of COMPUTE or > Nibble magazines, you might find a couple articles with code that I had > published back in the mid-80's. You wrote "Hi-Res Graphics Aid Routines" in issue #71 in April of 1986. I know people who have sets of this magazine in the original. And I'll look out for a copy at World of Commodore on Dec. 1 in Etobicoke. I'm definitely going to have to take a look at your Microseeker PIC/Smalltalk page. The PET was the first computer I ever saw and touched back in grade six. Thanks! Chris Cunnington |
In reply to this post by pwl
>>>>> "Peter" == Peter William Lount <[hidden email]> writes:
Peter> People have the right to defend their person and this right even allows Peter> them to make private communications public! Not in violation of federal law. I don't care how you feel. You don't get to violate the law no matter how you "feel". -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[hidden email]> <URL:http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! |
Randal L. Schwartz wrote:
>>>>>> "Peter" == Peter William Lount <[hidden email]> writes: >>>>>> > > Peter> People have the right to defend their person and this right even allows > Peter> them to make private communications public! > > Not in violation of federal law. I don't care how you feel. You don't get to > violate the law no matter how you "feel". > > As you know good sir I believe you are mistaken. I was well within the rights of a citizen of Canada to defend one's person. I've moved on and I think the group has as well. Thank you good sir. All the best, Peter |
In reply to this post by Chris Cunnington-5
Hello Chris,
CC> So, I'm interested in 6502 assembler, and I just bought Randal Hyde's "The CC> Art of Assembly Language" for the 80x86 set. The point of this is that I've 6502 had a nice and simple assembler so I think this is a good processor to start. You can also try 6800 Family. Imho stay a way from the 8080 Family if you can. They are much like "Is it possible to ...?" "Yes in principle but..." things. Lots and lots of special conditions to remember. Imho this unnecessarily hides the insights to be gained from programming hardware in assembly. If you plan to program on an 8 Bit system Assembly and Forth go together well. If you plan to program on a PC and run the code on the 8 bitter follow John's suggestion of Atmel microcontrollers or similar. They have a "reasonable" assembly language (think RISC vs. CISC) and a cross compiler running under Eclipse or some IDE. Cheers Herbert mailto:[hidden email] |
In reply to this post by Chris Cunnington-5
El 9/14/07 6:50 PM, "Chris Cunnington" <[hidden email]> escribió: > Thank you very much for replying. Well, I'm newish to computers and > programming. I'm surrounded at the computer clubs I attend here in Toronto > such as Unix Unanimous, The Toronto Linux Users Group, The Beach Outings > Club (my Smalltalk club) by people who have been programming forever. > > I'm also a member of the Toronto PET Users Group, which has been going since > 1979. That's PET as in Personal Electronic Transactor from 1977 and > Commodore. Next week I'll be going to TPUG to attend a discussion about Demo > programming. That's in the Demoscene, which is mainly Europeans writing > video demonstrations and SID chip music on their Commodore 64's and Amigas. > Wild, really, that they do that. > > I mentioned Jim Butterfield, because I wasn't programming in the early > 1980s, and I know he's famous amongst people here in Toronto and, obviously, > at TPUG, so I assumed you'd heard of him. A bit of a stretch, I guess. > > So, I'm interested in 6502 assembler, and I just bought Randal Hyde's "The > Art of Assembly Language" for the 80x86 set. The point of this is that I've > gotten into a large topic -- computer programming -- and I keep trying to > see it from different points of view. Assembly seems to me another great, > bottom up way to learn about this stuff. Being surrounded by people who know > so much more can be anxiety producing, so I'm climbing the learning curve, > and I favour the historical approach, thus the interest in old computers, > Commodore, and such. > > I liked playing Gemstone Warrior. Actually all my brothers and sister did. > > Commodore 64. Still Ready. > > Cheers, > > Chris Cunnington Maybe you wish know is possible to have Apple II inside Squeak, I attach the files. And I have a odd proposal to you.. What if we build a Morphic simulator of the 6502 chip ? Kind a educational project ... Could be useful to some, I think. Edgar |
In reply to this post by pwl
Hi,
Am Samstag, 15. September 2007 00:11:29 schrieb Peter William Lount: > > Your syntax change does early binding of a name to an implementing Block, > > which we don't want in Smalltalk... :) > > Please explain further, I didn't get your meaning. Okay, it was a small ironic joke: Dynamic Languages do late binding, as we all know. However, you want to assign names to a block directly, meaning early binding. ;) I think, I would get rid of the method syntax in any textual class representation like file outs. But, if needed, one can automatically visualize the block/method-source code in the "old" method syntax in the browser. Meaning, if you load a method, its underlying block is converted to method syntax and when you save it, the source code is converted back to a usual block and binded to the class. This is visual stuff which can be done by the system browsers. The compiler doesn't need to know. However, these are only some thinkings, perhaps I should get my hands back on some coding to see whether they have any value :) > [... cut ... ] Fully ACK. :) Regards, Martin |
In reply to this post by Edgar J. De Cleene
On Sat, 15 Sep 2007 02:28:09 -0700, Edgar J. De Cleene
<[hidden email]> wrote: > I miss the first mail but see the replies. > I was a 6502 and Apple II fan. Wow, so many 6502 fans. 6502 was my first assembler. Basic + ASM where needed was how I did most of my projects. Anyone remember "shape tables"? |
Blake wrote: > On Sat, 15 Sep 2007 02:28:09 -0700, Edgar J. De Cleene > <[hidden email]> wrote: > >> I miss the first mail but see the replies. >> I was a 6502 and Apple II fan. > > Wow, so many 6502 fans. 6502 was my first assembler. Basic + ASM where > needed was how I did most of my projects. My first was 6809. Close enough. I even made a computer with that CPU. Yes, with my own hands, back in year 1982, when I was in second year of secondary school. That were times! 3KB of RAM, only persistence was 512K EPROM, programming directly in machine hex codes, ... Now, back to Squeak ... Best regards Janko -- Janko Mivšek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si |
In reply to this post by Blake-5
Blake wrote:
> On Sat, 15 Sep 2007 02:28:09 -0700, Edgar J. De Cleene > <[hidden email]> wrote: > >> I miss the first mail but see the replies. >> I was a 6502 and Apple II fan. > > Wow, so many 6502 fans. 6502 was my first assembler. Basic + ASM where > needed was how I did most of my projects. > > Anyone remember "shape tables"? > > Ah yes, shape tables! Gemstone Warrior didn't use shape tables as you know them. It did have tables for it's graphics though. I was inspired by Smalltalk, which I had read about but hadn't gotten my hands onto quite yet, when I wrote Gemstone Warrior. All the objects the user could manipulate were inspired by Smalltalk's notion of objects at the UI level. While there was a Smalltalk for the Apple ][, Rosettastone Smalltalk, Gemstone Warrior was only partially objects. I was working on a object-message system for a subsequent game on the Apple ][ but by that time the IBM PC dominated the market and the Mac was coming into it's own with success. Sigh... Each of the Tile 64 Processors is thousands of more times more powerful than that old 6502 based Apple ][ system. I can imagine what Gemstone Warrior would be like on it! Fully object oriented, fully message oriented, fully 4-D (3D+Time)! If you really want a chip to play with as a hobby with potential for future success play with the Tile 64 chip! Smalltalk on the Tile 64 chip will be hot! When will it happen? Cheers, Peter |
CC'ed to the hardware list
On Sat, Sep 15, 2007 at 02:26:47PM -0700, Peter William Lount wrote: > Each of the Tile 64 Processors is thousands of more times more powerful > than that old 6502 based Apple ][ system. I can imagine what Gemstone > Warrior would be like on it! Fully object oriented, fully message > oriented, fully 4-D (3D+Time)! > > If you really want a chip to play with as a hobby with potential for > future success play with the Tile 64 chip! > > Smalltalk on the Tile 64 chip will be hot! When will it happen? Jecel Assumpcao Jr. is working on a quite similar project. He is putting Neo Smalltalk [1] on a 9-core Plurion [2] processor. He has said he will follow this up with a port of Spoon. More information can be found on his hardware Swiki [3]. I'll be working with him on this project as part of my graduate studies. [1]. Neo Smalltalk: http://www.merlintec.com:8080/software http://wiki.squeak.org/squeak/5637 [2]. A very out-of-date description of Plurion architecture: http://www.merlintec.com/download/plurion.pdf A description of the actual processor being used: http://www.merlintec.com:8080/hardware/32 [3]. Jecel's hardware Swiki: http://www.merlintec.com:8080/hardware -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808 |
In reply to this post by Blake-5
On 15-Sep-07, at 1:44 PM, Blake wrote: > On Sat, 15 Sep 2007 02:28:09 -0700, Edgar J. De Cleene > <[hidden email]> wrote: > >> I miss the first mail but see the replies. >> I was a 6502 and Apple II fan. > > Wow, so many 6502 fans. 6502 fans designed the original ARM; look what happened to that - it's everywhere. Most of us are likely to have at least 4 or 5 ARMs in our home. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful random insult:- Wise as the world is flat. |
On Sat, 15 Sep 2007 18:52:27 -0700, tim Rowledge <[hidden email]> wrote:
> > On 15-Sep-07, at 1:44 PM, Blake wrote: > >> On Sat, 15 Sep 2007 02:28:09 -0700, Edgar J. De Cleene >> <[hidden email]> wrote: >> >>> I miss the first mail but see the replies. >>> I was a 6502 and Apple II fan. >> >> Wow, so many 6502 fans. > 6502 fans designed the original ARM; look what happened to that - it's > everywhere. Most of us are likely to have at least 4 or 5 ARMs in our > home. I did not know that! http://en.wikipedia.org/wiki/ARM_architecture But it's quite int'resting. |
On 15-Sep-07, at 10:19 PM, Blake wrote: > > I did not know that! > > http://en.wikipedia.org/wiki/ARM_architecture > > But it's quite int'resting. Note the 'shipped 2.45 billion units'. In 2006. Gulp. And to think that people tried to tell us that it would never get anywhere... tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim "Wibble" said Pooh the stress beginning to show. |
In reply to this post by Alan Kay-4
On Sep 14, 2007, at 3:51 PM, Alan Kay wrote: > Re: unification of blocks and methods (procedures). > > I first saw this in EULER (Wirth and Weber ca 1966), but then saw an > earlier similar notion by Landin in ISWIM and its predessors. I used > the idea in my first OOP language (FLEX ca 1967-9), which also had > complete static nesting of scopes, etc. > > But later I decided I didn't like blocks as values because they are > super time bombs when passed around and completely violate > encapsulation. I really wanted external objects (not internal > blocks) to be passed around, and wanted a simpler way to think of > contexts internally. So we left them out of the first few > Smalltalks. (I still don't like them ...) I am glad I am not completely alone in my dislike of, or shall we say: discomfort with blocks. Of course, if you are going to have blocks, then unifying the two concepts is quite obviously a good thing (IMHO). A block is just an unattached/anonymous method body and a method just a block with a name that's attached to a class. However, with that unified view it becomes immediately obvious that there is something wrong with blocks. After all, we don't directly call methods in other cases, that's early binding and a Bad Thing. Instead we send messages to objects. How does not naming the method body make this type of early binding and leaking implementation better? On the other hand, having blocks is vastly superior to not having any useful higher order mechanism, and blocks are extremely powerful. Possibly too powerful, one of those "better old things" (lambda/ anonymous functions) that is so useful and powerful that it stops us looking for the actual "new" thing. Marcel p.s.: your message about the Internet being an OO system didn't reach me, I only just saw it on the list archives. I obviously(?) agree wholeheartedly, it is an OO system, but one that is quite different from Smalltalk. And the way to make things gel is probably not to try to "extend the image" (distributed Smalltalk, NetMorphs [as cool as they are], CORBA, SOAP), but rather to bring "the net" into "the image" in a deep way. Well, it probably wouldn't be an image as we think of it. |
Free forum by Nabble | Edit this page |