Jason Olson: Composing Programming Languages, F# and OO

Very interesting conversation. Listening to Jason talk gets me anxious to start looking into implementing my own languages. Thanks Jason.

On a side note, whoever was in the background distracting everyone needs to learn proper on-camera etiquette. I would have been a little upset had I been in Jason's shoes.

Objects, or should I say "Object Classes", originally come from the Turing award winning Ole-Johan Dahl, when he presented them at the NATO Summer School on Programming, Marktoberdorf Germany 1970.

I suggest you look at  the classic book "Structured Programming", by Dahl, Dijkstra and Hoare, where he and Dijkstra describes them clearly in the third chapter (monograph) section.

http://portal.acm.org/citation.cfm?id=SERIES11430.1243380

So let's be clear that Alan Kay came up with the phrase "Object-oriented", but not the specification of the model of using object classes, nor even the first implementation of the model.

Credit should be given where it is due.

I couldn't agree more that credit should be given where it is due. Therefore, it should be incumbent on those who believe this to actually do the work to track down just where the credit should be given. I did this when I was asked to write "The Early History of Smalltalk" for the ACM History of Programming Languages" (HOPL II, which is available online and as a book chapter).

As I mentioned in that history, parts of the object idea had been around for quite a while (and the class and instance idea could be traced back to Plato's "Ideals"). As far as I could tell, this idea was used in a recognizable but somewhat weak way on the US Air Force Burroughs 220 file system for Air Training Command as early as 1960 or 1961, and much more powerfully in the Burroughs 5000 of Bob Barton, and first described publicly at the WJCC in 1961 (paper is online), and in Ivan Sutherland's Sketchpad system done in 1962 (which like the B5000 also introduced several more deeply seminal ideas).

These ideas predated the first Simula ca 1965, and the first paper in English (1966) which did not reference any of the above, and also predated the next Simula (67), which had a stronger notion of "class".

Also, it is important to realize that the two Simula guys were completely different personalities with completely different attitudes about "objects". Dahl was very conservative and didn't like the idea of objects (he prefered data structures and his use of Simula classes was primarily to make what are now called Abstract Data Types). Nygaard on the other hand was a wonderful infinite horizon creative thinker and not only loved the idea of objects, but was the most enthusiastic person we ever demoed Smalltalk to later in the 70s.

As I mentioned in the history, my epiphany came in Nov 1966 after encountering Sketchpad and Simula in my first week of grad school. This combusted with my background in mathematics and biology, and with ARPA's plans to make a distributed ARPAnet, to provide a glimmer of a universal structuring idea that was simply to recapitulate and recur on the idea of "computer" itself.

Our contributions to this already years old research field were to generalize and scale and liberate: everything could and should be an object (so classes should be objects, elementary entities should be objects, objects should be more biological, the Internet that was being worked on should be completely made from encapsulated entities, the underlying object system should be made from objects, all should be late-bound like the Internet was going to be, and so forth).

And this allowed bad old ideas like operating systems, applications, and even programming languages to be dispensed with. This worked very powerfully and compactly at Xerox PARC, but is not a style that has been adopted in the commercialization of the Xerox PARC ideas since 1980.

Best wishes,

Alan Kay

Alan,

First thank you very much for your very nice reply!

I did read your paper and I do agree with you that most modern languages using objects do look more like what Dahl was talking about i.e. hierarchical data types to resolve their members.

I just wonder what your take on this OO question is, i.e. regarding languages like C#, Python, Ruby, etc that don't explicitly use messages for dispatch. Do you think they are OO?

Best Regards,

Anthony

Good question. I'm not a big fan of any of them, including the ones I've designed.

I think we (the programming language field) has yet to get to a sweet spot that matches up with the scales, aspirations, and life cycles we want to deal with.

That sweet spot yet to come will certainly have a very strong and dynamic notion of modules, and one part of the notion will almost certainly involve both protection and intermodule communication. But I don't think we need to be religious about the past (even the parts of the past that were done better than today).

My main complaint about most language use today (including the languages you mentioned) is that the very weak "data structure and procedure" style is retained (via getters and setters, etc.), and (b) the CPU is used to set the notion of "time passing" so that bad synchronization schemes have to be employed. This leads to fragile, very large, inscrutable, and intractable systems.

It was known in the 70s how to eliminate both these problems. (But not all the problems involved with scaling and very high level expression.)

So, to me, the issue is much more "how should we design and program systems that must live in an ever growing "ecology" of ongoing systems?"

Besides using the good 70s solutions to the two problems alluded to above, we could also think about the idea of protected modules which don't send explict messages but use some form of efficient and general publish and subscribe.

Imagine that each module in "a space" exhibits two kinds of "bulletin boards": one that tells the space what the module needs as resources to do its job, and (b) one that exhibits what the module has produced. A "super-Linda" kind of matcher can be used to automatically do the brokering. This is more late bound and has more possibilities for graceful scaling (because objects are not dealing with targets but with needs).

Similar mechanisms can be used to completely separate "meanings" from "optimizations" so that semantic debugging, testing and validation can be done independently of attempts to make things go faster.

One of the mottos from Xerox PARC was "Math Wins!", and I think this is still the case. By "math" I mean mathematical thinking and making up new mathematics when it will help problem solving. It is possible to make meta systems in which the new maths can be turned into programming systems and run. This is somewhat equivalent to "escaping from bricks to inventing arches" when things start to get too complex. This is one of the most powerful properties of computers, but it is rarely used to the extent needed and possible in most of today's systems.

And so on. It's not that this stuff is easy or solved, it's that too many people in the field are simply trying to *cope*, where what we need are lots of people trying to make *real progress*!

Cheers,

Alan

the sound in this one is a little wierd for me, stereo separation is of the wall and its also out of sync..

anyhow
very interesting talk one thing i'd really like more info  on is how to write extension methods (for c#/vb) in f#.. that would be such a great way to integrate and compose old sk00l c# code with funky new f# code

@complexity in syntax or in implementation 
it seems the fact that more syntactily rich languages like java or c# have "won" over "lighter" languages like erlang or smalltalk is mostly attributed to luck or marketing i dont think its either.. as jason says, programmers love syntax. we need to express the compexity, it matters less if its in the syntax or in the framework. in my oppinion richer syntax makes for more human readable and machine toolable code.

i also think its an illusion that the "lighter" languages are easier to learn, that might technically be true but in order to write something interesting you'll still need to learn how to control flow and stuff like that.. but instead you have to learn an api, not syntax.. you still need to learn the same stuff.

small syntax languages seem easier to create and they may be pretty in some sense, but are they easier to work with? im not so sure.. and isnt the goal of a language to make the programmer, not the language designer, more productive? its all good though, im not saying anyone should stop doing anything rich (but not too rich ) syntax is just my personal preference

i was straming the wmv high version, but i noticed this on other videos as well. it might be lagg caused by my puny work laptop.. didnt notice this before installing the win7 rc though.. i dont think its channel9s fault anyway

Excellent discussion. Jason, keep up th good work. You motivation is inspirational. heheh.

I'm sure you guys are extremely busy and have a ton of stuff on your plate as far as show ideas and priorities...but I think this topic would make a great series.  I'd love to see Olson and Meijer talk, I'd love to follow the progress that Olson makes as far as creating different languages with unique feature sets and constructs.

These topics are VERY interesting and exciting, but all of us don't have the time/opportunity to pursue them, it would be fun to "learn vicariously" through Jason.

Just a thought....great show.

I did like the conversation. I made my own .NET language called dylan.NET. For who wants to give it a look go to http://borgdylan.web.officelive.com/dylandotnet.aspx . It is free of charge and new releses come out often.