Websela

I remember reading about Einstein. A source of his genius was how he re-evaluated criteria.

It follows that if everybody looks at the same criteria, and they look at it in the same way, and they all think the same way, then people will reach the same conclusions. And because being different in this world can be painful, most people are not only in incapable of thinking differently, they aspire not to. Einstein looked at criteria differently and found something he liked.

He decided that the speed of light was a constant. That’s it. Many things follow from that one decision. Everybody else looked at the criteria of light and saw the same thing. The conventional wisdom saw nothing new where light was concerned. In his conflict with (eval), I think Alan Kay did something similar. He took something axiomatic, unpacked new criteria, and solved the problem he faced.

Appendix II of the article The Early History Of Smalltalk describes in detail how Kay created the interpreter for Smalltalk-72. Whatever people might say about the origin of Smalltalk, those four pages demonstrate it was hugely influenced by Lisp. Colin Putney once told me that many languages are the combination of two others. “C was invented because Assembly wasn’t enough like Fortran. Smalltalk was invented because Simula wasn’t enough like Lisp”. In the Smalltalk-72 era, Kay had glommed onto Simula. But how could it be synthesized with Lisp?

The battle to be waged was against (eval). Page 92 of Land Of Lisp has:

(defparameter *foo* ‘(+ 1 2))

(eval *foo*)

The problem was that he couldn’t just use eval. As I understand it, the half page of syntax he had (as a part of a bet) left him almost without resources. He just couldn’t add eval willy-nilly. This problem led him to re-evaluate what the criteria of eval were and find a solution. He had two tools at his disposal: time, and, space.

Of course he didn’t say it that way. He said: “When I set out to win the bet, I realized that many of the details that have to be stated explicitly in McCarthy’s elegant scheme can be finessed.”

I like that. Finessed. To me that means he realized he could push the details out to the context and away from the syntax. Instead of locating all the information required in the syntax, many of the details would be ambient. They’d be around. He’d change space by changing the scope. And he’d change time by pushing the processing to late, late, late in the cycle. Dynamic binding is a choice about time and nothing else. First class objects are objects that exist at runtime. They have to be fully formed at runtime. If they were processed earlier, then they wouldn’t have to be.

He said he needed: “a protected way to access and change the relationships of the static and dynamic environment”. No problem. We will change space by confining the scope to that inside an object. Put the processing inside an object, a context object, and then you have complete control over what happens. “I extend(ed) the eval by distributing it”

If you evaluate the (eval foo) as above, then it will happen. Period. No buts. A message in Smalltalk is the location of a letter and not the actual letter. It’s a request for something to happen. And before it happens there are options: the object can ignore it, throw an exception, delegate, or do anything it likes with the request.

Appendix II also talks about the process counter (PC) in both objects and how they have to be synchronized. “Delayed receipt requires the PC counter of the receiver and the sender to be manipulated at the same time.” I’m not quite under that yet. As there is a PC counter in every context object, it shouldn’t take too long.

Interestingly, Matz didn’t have this same kind of resistance when adding eval to Ruby. Avi Bryant says that it can be used for doing Lisp-like programming in the Ruby language:

Since I often see the programming language world (at least, the small
enlightened part of it) as being divided into the LISP camp and the
Smalltalk camp, it's nice to see something like Ruby strike a decent
balance between the two.  My particular style of writing Ruby is an
interesting example of this: Ruby has the peculiarity that code inside a
class definition, but outside a method definition, is evaluated in the
context of the class object.  In other words, this code

class Foo
  def some_method(x)
    x * 2
  end

  print self
end

will print "Foo".  This means that it is possible to write class methods
that use eval to act more or less like macros, but macros that can be
overridden by subclasses, etc.

Sometimes what looks whole and incontestable is made up of smaller parts. Sometimes there are new criteria waiting to be found. Like muons.

Advertisements

stObjectModel

I took a crack at drawing the object model for Squeak. Feedback welcome.

For contrast, here are some object model diagrams of Ruby provided from Paolo Perotta’s excellent book Metaprogramming Ruby.

http://osrcon.ca/RObjectModel1.png

http://osrcon.ca/RObjectModel2.png

http://osrcon.ca/RObjectModel3.png

 

I read “Metaprogramming Ruby” asking myself why Rubyists didn’t have a debugger like we have. What was different about our object model that allowed us to have our debugger?

It’s not just a deeper object model. It’s a more rigorous implementation of the language. Ruby has a “create as needed” philosophy. Smalltalk has a “consistency of implementation” philosophy.

The difference between Smalltalk, Ruby, and JavaScript is a question of how extensively the language designers wanted to create an objective reality against which any program could be evaluated. That seems to me to be the basis of reflection. You need something against which to judge something else.

Smalltalk has a full objective reality, as a result of a deeper object model and rigorous implementation. Ruby has a partial objective reality, which is created only as you need it. JavaScript has no objective reality whatsoever. It’s a DSL makers paradise.

I don’t think there is a language called JavaScript. More, there is a galaxy of libraries and frameworks, all DSLs, that create their own reality and cannot relate to each other. Do jQuery, node.js, or Angular.js know how to play together, or are they just islands?

The things that stand out to me about Ruby are instance variables and eigenclasses. Chapter 5 of the Bluebook says metaclasses were created to give classes customizable initialization. That appears to me to be what Ruby doesn’t have – constructor methods. It has :new and :new() (OK, ActiveRecord has :create for automatic generation of setters and getters). You cannot initialize an object and set the values of instance variables in one message.

If I read this rightly, you need to initialize instance variables. i.e.:

        
             class MyClass
                def my_method
                    @v = 1
                end
             end 

             obj = MyClass new 
             obj.my_method

On page 35 of “Metaprogramming Ruby” it says:

“If Bill, hadn’t called obj.my_method(), then obj would have no instance variable at all.”

Initialization for ivars. That’s interesting.

Constructor methods in Smalltalk are class side methods. You can add class side methods in Ruby. Each time you do so, an object called an eigenclass is created. This follows the “create as needed” philosophy that I see as Matz’s attitude to language design. As opposed to the “consistency of implementation” that I see as Kay’s.

And that’s why we have a debugger as we do an nobody else does. We have a deep – perhaps four tier deep – object model that is quite rigorously implemented. These two things seem to me to provide a greater objective reality against which a specific program can be judged. I think that is a definition of reflection. A layer of abstraction provides a basis of comparison.

Ungar’s paper “SELF: The Power of Simplicity” describes the SELF language from which JavaScript gets its prototypal inheritance. In the paper he compares SELF to Smalltalk-80. He suggests that an advantage of SELF is that it eliminates meta-regress (i.e. class of class of class):

“No object in a class-based system can be self sufficient; another object (its class) is needed to express its structure and behaviour. This leads to a conceptually infinite meta-regress: a point is an instance of class Point, which is an instance of metaclass Point, which is an instance of metametaclass Point, ad infinitum. On the other hand, in prototype-based systems an object can include its own behaviour; no other object is needed to breathe life into it. Prototypes eliminate meta-regress.” (page 5)

It’s an interesting point. It sounds so reasonable. And I’ve resented the Smalltalk object model for years, as an oppressive Mobius strip. But now that I understand it, I think it provides an objective, underlying reality that I find quite reassuring. To have a similarly reassuring substructure in JavaScript, you need to invent it yourself. And that’s what the ever expanding galaxy of JavaScript frameworks is doing, ad infinitum.

I’ve always wondered about that question. I’ve been involved with Smalltalk for years and from time to time the pioneers all show up at an event or on a mailing list. I’ve never seen Adele Goldberg in conjunction with anything.

Then I was looking at some old episodes of Bits & Bytes, a TVO show from thirty years ago explaining how to use a personal computer. And there was Adele Goldberg explaining what a window was. Naturally, I decided to steal the clip.

I haven’t made any videos for a few years. I have 142 on YouTube totalling seven hours. I’m at it again to make some for Websela. I’ve got a new one here.  It has two versions of Adele Goldberg. One of her as herself. And, one as depicted by HBO in a movie called Pirates Of Silicon Valley (1999).

If it doesn’t run in your browser, let me know.

Another image here. 

Here is a web application using Colin Putney’s Altitude framework. It’s a mockup for a possible squeak.org website. The site uses Bootstrap to make the site with Altitude, as the underlying framework. If you open it with Cog, execute the first line in the Workspace, you’ll see the site at localhost:8624. If your computer is connected to the internet, it’ll pull down related files and present the site. I have to say that Colin intended a more sophisticated use of what he created. Some shortcuts were taken by me to make it have conventional RESTful-looking urls.

David Graham ported Andreas Raab’s WebClient web server to Cuis on GitHub, as is shown here. I created a simple web framework a while ago by welding the canvas of Seaside to Goran Krampe’s HttpView2 chassis. The result is called GreenNeon, which I’ve ported to Cuis. You can download the image here.  Zipped it comes in at 5M. Start it wit Cog and you can go to localhost:9221 and it’ll say Hello World!. The Websela homepage uses GreenNeon and Bootstrap. I’m unfamiliar with GitHub and the .pck file format Cuis developers use in lieu of Monticello .mcz files, so I’ve just provided an image.

The Squeak wiki can be a reference for you on your desktop. Download this image. Open the image and execute the two commands in the Workspace one at a time. Then go to localhost:8666. You’ll have the Squeak wiki in a browser on your desktop.

You may want to leave a few seconds after the first command, as the image has to suck in ten thousand files. I removed a few things to make the download smaller. It is ~50M and expands to ~350M. There is no Croquet book or Swiki book (i.e. the Swiki wiki). There are no images. Getting it out of the server was 3G.

If you want to take a new Squeak 4.4 and load in the ComSwiki, you can find the source on the Gemstone SqueakSource here. You’ll need to install Comanche. (I recommend the near latest, but not the latest version of Kom.)

The only real change I made to make the ComSwiki work in 4.4 was to copy #readOnlyFileNamed: into UnixFileDirectory. ComSwiki wants StandardFileStream in XmlSwikiStorage. UnixFileDirectory readOnlyFileNamed: ‘1.xml’ needs to produce a StandardFileStream and not MultiByteFileStream, which is what FileDirectory readOnlyFileNamed: will provide.

There are no tests for the ComSwiki. If it explodes on your desktop, perhaps you could say where.