Getting double semi as sequencer harvested.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
244 messages Options
1 ... 8910111213
Reply | Threaded
Open this post in threaded view
|

Re: Fear and loathing of the "perification" of Smalltalk

Alan Kay-4
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
>
>
>
>
>
>


pwl
Reply | Threaded
Open this post in threaded view
|

Re: Fear and loathing of the "perification" of Smalltalk

pwl
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








Reply | Threaded
Open this post in threaded view
|

Re: Fear and loathing of the "perification" of Smalltalk

Blake-5
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.


Reply | Threaded
Open this post in threaded view
|

Re: Fear and loathing of the "perification" of Smalltalk

timrowledge

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.
Me. Dawkins is a serious scientist. If there is any plausible  
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



Reply | Threaded
Open this post in threaded view
|

Re: Fear and loathing of the "perification" of Smalltalk

Bert Freudenberg
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 -



Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

Jon Hylands
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

Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

Chris Cunnington-5
> 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



Reply | Threaded
Open this post in threaded view
|

Re: responding to ad hominem person attacks

Randal L. Schwartz
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!

pwl
Reply | Threaded
Open this post in threaded view
|

Re: responding to ad hominem person attacks

pwl
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".
>
>  
Hi Mr. Schwartz,

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


Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

Herbert König
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]


Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

Edgar J. De Cleene
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
I miss the first mail but see the replies.
I was a 6502 and Apple II fan.
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




A2Emulator.cs.gz (15K) Download Attachment
rom6502 (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fear and loathing of the "perification" of Smalltalk

Martin Beck-3
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

Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

Blake-5
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"?

Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

Janko Mivšek


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

pwl
Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

pwl
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"?
>
>
Hi,

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


Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

Tapple Gao
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

Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

timrowledge
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.



Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

Blake-5
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.

Reply | Threaded
Open this post in threaded view
|

Re: Assembly Language

timrowledge

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.



Reply | Threaded
Open this post in threaded view
|

Blocks (Re: Fear and loathing of the "perification" of Smalltalk)

Marcel Weiher
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.


1 ... 8910111213