Dan Ingalls and Allen Wirfs-Brock: On Smalltalk, Lively Kernel, Javascript and Programming the Inter
- Posted: Feb 07, 2008 at 11:37 AM
- 11,654 Views
- 7 Comments
Download
How do I download the videos?
- To download, right click the file type you would like and pick “Save target as…” or “Save link as…”
Why should I download videos from Channel9?
- It's an easy way to save the videos you like locally.
- You can save the videos in order to watch them offline.
- If all you want is to hear the audio, you can download the MP3!
Which version should I choose?
- If you want to view the video on your PC, Xbox or Media Center, download the High Quality WMV file (this is the highest quality version we have available).
- If you'd like a lower bitrate version, to reduce the download time or cost, then choose the Medium Quality WMV file.
- If you have a Zune, WP7, iPhone, iPad, or iPod device, choose the low or medium MP4 file.
- If you just want to hear the audio of the video, choose the MP3 file.
Right click “Save as…”
- Mid Quality WMV (Lo-band, Mobile)
- MP3 (Audio only)
- WMV (WMV Video)
I recently attended Lang.NET 2008 and, as expected, learned a great deal from some of the industry's finest language and compiler minds.
Here, we meet Dan Ingalls and Allen Wirfs-Brock, two legendary Smalltalkers (contributors to the language). Dan Ingalls is well known for his work at Xerox PARC and his contributions along with Alan Kay to Smalltalk. Dan is also very passionate about Javascript. So much so, that he's gone and created a very interesting Javascript-only project named Lively Kernel. And you can thank Dan for Bit blit.
Allen Wirfs-Brock is currently working on some very interesting language enhancements that he can't talk about publicly
Join us as we discuss a whole range of very interesting topics.
Enjoy!
Low res file for bandwidth challenged.
Here, we meet Dan Ingalls and Allen Wirfs-Brock, two legendary Smalltalkers (contributors to the language). Dan Ingalls is well known for his work at Xerox PARC and his contributions along with Alan Kay to Smalltalk. Dan is also very passionate about Javascript. So much so, that he's gone and created a very interesting Javascript-only project named Lively Kernel. And you can thank Dan for Bit blit.
Allen Wirfs-Brock is currently working on some very interesting language enhancements that he can't talk about publicly
Join us as we discuss a whole range of very interesting topics.
Enjoy!
Low res file for bandwidth challenged.
Comments Closed
Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums,
or
Contact Us and let us know.
Follow the Discussion
edit: found low resolution copy. Thanks C.
Great discussion. Having assimilated the recent group of language discussions with people like Dan, Allen, Erik, Giland and others; it seems a natural commonality has appeared. All the pieces exist that we need, but we just need a good chef to mix the cake.
It seems the problem domain is:
1) Many core, threads, and locking problem.
2) Shared state problem.
3) Local/remote message passing arch.
It seems to follow that the "ingredients" of next lang arch need to be:
1) Read-only message based arch at core.
2) Message loop as primary in/out of all classes (e.g Erlang).
3) Local model same as remote model so distributed apps are same (i.e. Volta like).
4) A dedication to above in keeping the rules and not allowing leakage.
Thought experiment:
1) All objects, and messages, are read-only external to the owner. So if I pass "this" (class1) as a message to class2, a copy of class1 is made (by the system) and passed to the class2 in-queue (by the system). Class2 can not set state in original class1 as it has only a local copy. All this is enforced by the runtime. class2 is the only class that can get this message. Multicast is handled with multiple copies of class1 sent to many classes. Class1 now becomes local state of class2 as long as it wants to keep it. The only way to change state is local - by handling messages.
2) Each class message loop is single-threaded. So locks are mostly gone. Classes can be created on separate threads for concurrency. Coordination is done via message passing and/or some root controller/state class.
3) All In-Messages are handled by a message loop in the class (ala windows message loop). Something like CCR and/or Linq message popping is used to handle messages processed by type or some predicate using lambda functions. Something like setting properties just become a message handled by the class, but publicly looks like a simple property setter.
4) Remote access becomes same pattern as local access - no surface difference. The arch handled all the comm goo below (ala Volta).
Features:
1) All objects become services handling messages.
2) Remoting is as simple as local in-proc.
3) Shared state is mostly solved.
4) Very parallel by design.
5) Async streaming and pipelining become very natural.
6) Very dynamic in nature. Objects can be removed and replaced in the system at runtime because of the loose message passing and queue model.
7) Events are replaced because not needed. Same behavior is handled by async messages.
-
W
Or you can play with it live here.
Lets see where this all goes in to future...
Learn't most important thing from video was use :-http://www.live.com
Thx, for all the cool stuff...
Remove this comment
Remove this thread
close