21st Century Smalltalk

April 30, 2007

MIX07 Silverlight Announcements

Filed under: .Net Architecture, Apollo, Internet Evolution, Vista Smalltalk — pfisk @ 9:02 pm

There were some exciting announcements today at MIX07.

  • Silverlight 1.1 supports the CLR (Common Language Runtime)
  • open source Dynamic Language Runtime (DLR)
  • new language IronRuby
  • Silverlight streaming deployment service

Congratulations to Microsoft on taking some bold initiatives - I sincerely hope that this marks the beginning of a new and more exciting era of online applications. And the inclusion of “cool” languages like Ruby will likely attract a host of new developers.

For my work, two things are of importance:

  • the release of a CTP of the Silverlight CLR will finally allow me to examine its capabilities and limitations, so that I can proceed with porting Vista Smalltalk to Silverlight
  • the DLR should allow me to build a much higher performance version of Vista Smalltalk

Over the next several weeks, I will be preparing a new release of Vst/.Net to integrate with the DLR and be better synchronized with the Flash version (Vst/Flash). Hopefully, I can reach a point where scripts can be run with minimal modifications across Flash/Apollo/Silverlight/Vista.

I have tried to base my architecture on sound design principles originating in Lisp/Smalltalk and I expect that it will easily adapt to any emerging requirements in the RIA space. Some key characteristics are that my languages are totally dynamic with no dependencies on external tools (Visual Studio, FlexBuilder, etc). This should enable them to be used in embedded application scripting roles.

In any case, let the new age begin. Maybe Microsoft isn’t quite so dead after all.

Rich Network Applications – 1982

Filed under: General, Internet Evolution — pfisk @ 6:27 pm

There has recently been a lot of excitement about “Rich Internet Applications” and all of the changes that they are likely to bring. However, long before the Internet was widely used, there were other large scale networks that had similar client/server architectures.

In 1982, I was working for a financial services company in downtown Toronto that had branch offices across Canada and whose lines of business included insurance brokering, payroll services, pension administration and management consulting. We used an IBM mainframe connected via an SNA network to terminals and RJE workstations  in each of the offices.

In the corporate and larger regional offices, we also had minicomputers which were used mostly for entering sales and accounting data, and then sending validated batches of input to the central machine. At the time, the IBM PC had just been introduced but was only available with floppy disks – the minicomputers would normally have 4-6 operators on a shared machine.

Technology has advanced considerably in the last 25 years with the biggest effect being the enormous difference in cost between then and now – processing power, memory, disk storage and communications.

However, for some things, there has been surprisingly little change.

For example, the way we fill out HTML forms and then send the content to a central server for processing. This is almost exactly the same way that CICS processed data from terminals in the 1980’s. In those days, it was necessary since a computer terminal typically only had about 4kb of memory (just enough for the data) and couldn’t run programs. Today, we do the same thing on PC’s with hundreds of megabytes of memory and fast processors. Of course, AJAX and RIA’s are slowly beginning to change that.

Another similarity is the debate over central/distributed for programs/data. Regional managers used to tell me that they “wanted control over their data”. My answer was that they would have to be responsible for backups, operator training, software installation, versioning, and recovery procedures. And without exception, they decided it was easier to have the central office handle it. Today, some people “don’t trust Google (or whoever)” with their data – and then they lose their laptop at the airport with all of their company’s data. Likewise, surprisingly few private PC’s have current versions of system patches, browsers, applications, or anti-virus tools – most people don’t enjoy system administration.

Finally, languages like C# are starting to be used in both server-side and client-side (XBAP) roles. In 1982, I was deploying a subset of mainframe COBOL over the network to three different models of minicomputer with very few problems; and in fact, one of the language vendors is still doing a thriving business. Downloading runtimes to client machines has been around for quite a while.

Making applications that have both centralized and distributed components can be difficult to get right. There are no simple, universal solutions. 

The emergence of the “rich client” architecture is an exciting development in Internet evolution. But, exploiting its potential will require changes to the whole application architecture, including the server.

April 29, 2007

Microsoft’s Windows API

Filed under: General — pfisk @ 9:28 pm

Microsoft’s Windows API has been on the majority of desktop computers for most of the past two decades – in fact, many computer users have never used anything else.

About four years ago, Joel Spolksy wrote a blog post entitled “How Microsoft Lost the API War”.  It has an excellent description of what an API is (see the sidebar entitled “What is this “API” thing?”) and why it is so important. Here are some excerpts:

Remember the definition of an operating system? It’s the thing that manages a computer’s resources so that application programs can run. People don’t really care much about operating systems; they care about those application programs that the operating system makes possible….

It is a positive feedback loop. When one operating system becomes more popular than the others, more developers will write applications for it – which, in turn, makes it become even more popular. This has been the dynamic of the Windows near-monopoly (and MSDOS before it) since the 1980’s.

Making it easy to upgrade applications accross multilple generations of MS operating systems (see my post about running four generations of applications on Vista) has taken enormous amounts of engineering resources. Joel gives us this example:

I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

So, probably somewhere deep in the Vista operating system on my computer, there is a piece of software that checks to see if I am running a 16-bit version of SimCity and will make the necessary adjustments to ensure that it works properly.

In recent years, Internet applications have been gaining market share from traditional desktop applications, and so the Windows API is losing much of its relevence. As Joel says:

Microsoft’s crown strategic jewel, the Windows API, is lost. The cornerstone of Microsoft’s monopoly power and incredibly profitable Windows and Office franchises, which account for virtually all of Microsoft’s income and covers up a huge array of unprofitable or marginally profitable product lines, the Windows API is no longer of much interest to developers. The goose that lays the golden eggs is not quite dead, but it does have a terminal disease, one that nobody noticed yet.

We are in the early stages of computers becoming as simple to use as other consumer appliances (eg radios, televisions, iPods, etc). Paul Graham states it well:

When we look back on the desktop software era, I think we’ll marvel at the inconveniences people put up with, just as we marvel now at what early car owners put up with. For the first twenty or thirty years, you had to be a car expert to own a car. But cars were such a big win that lots of people who weren’t car experts wanted to have them as well.
….
With Web-based software, most users won’t have to think about anything except the applications they use. All the messy, changing stuff will be sitting on a server somewhere, maintained by the kind of people who are good at that kind of thing. And so you won’t ordinarily need a computer, per se, to use software. All you’ll need will be something with a keyboard, a screen, and a Web browser. Maybe it will have wireless Internet access. Maybe it will also be your cell phone. Whatever it is, it will be consumer electronics: something that costs about $200, and that people choose mostly based on how the case looks. You’ll pay more for Internet services than you do for the hardware, just as you do now with telephones.

Microsoft faces a problem today that is not so much technical as it is cultural. Many (probably most) people today use computers primarily as a way of accessing the Internet and, for them the browser is more important than the desktop. What people want to do is search for information (Google, RSS), share opinions (newsgroups, blogs), be entertained (YouTube), join others in online activities (EverQuest, World of Warcraft, Second Life), or just stay in contact (email).

The Internet has a social dimension that desktop computing never had.

If Microsoft brings out products that are technically advanced but cannot be widely used, they may fail because developers will see the potential market as being too limited. But, if they follow commonly accepted standards, they won’t be able to enjoy their customary profits.

Exporting the Windows desktop monopoly to the Internet arena is likely going to prove impossible. The acronym “RIA” is commonly taken to mean “Rich Internet Application” whereas Microsoft likes to interpret it as “Rich Interactive Application” – superior user experience may be their hoped-for advantage in the emerging online applications market.

When Steve Ballmer was jumping around on stage shouting “Developers, Developers, Developers”, I think that he had it backwards. Look at how many developers there are for HTML and Javascript. Why, because these technologies are widely deployed and the market is huge. Steve should have been shouting “Deployment, Deployment, Deployment”. Put your technology on 800 million computers and you will soon have lots of developers.

Microsoft understood the desktop; I don’t think that they understand the Internet.

April 28, 2007

Building an Animation Editor

Filed under: Tools — pfisk @ 10:10 pm

animationworkspace1
Vista Smalltalk Site

Open Vista Smalltalk in your browser.

I have been working to improve the AnimationWorkspace tool (accessible from the Launcher under “Tools”).

There are currently only two kinds of items that can be added to the canvas:

  • “wheels” which can move by being rotated
  • “cars” which consist of two connected wheels

“AnimationWorkspace” is a subclass of the “DrawingWorkspace”, and I am working to combine the editing and animation capabilities of the two. Ideally, in the same canvas, you should be able to edit compond graphic objects and then test their animated behavior.

Recent improvements include:

  • creating wheels in Lisp and adding them to the canvas
  • creating TwoPointConnectors and combining them with Wheels to produce “cars”
  • the ability to clear the canvas
  • the ability to inspect the graphic elements on the canvas
  • adding a “Lisp interaction” window at the bottom of the canvas

There is still a lot more work to be done before the AnimationWorkspace will be a powerful enough tool to produce complete animated scenes. Some planned features include:

  • the ability to load MXML files (ignoring “code behind”)
  • the ability to save/load graphics from a server
  • the ability to share graphics in real time over P2P connections such as Jabber

These are all steps on the road to building a “Croquet” like system that can run on the browser or the desktop of virtually any computer using commonly available Internet communications.

April 26, 2007

A Simple Demo Application

Filed under: Apollo, General — pfisk @ 4:31 pm

videostore1
Vista Smalltalk Site

Open Vista Smalltalk in your browser.

On the Launcher menu, there is now a new choice titled “VideoStoreDemo”. This is a simple demo application (right-hand window above) that displays the clients of a video rental store and the dates and details of their rentals. When you run this demo in your browser, all the data is being supplied interactively from a PHP server using HTTP requests and JSON encoding.

The client-side Lisp code for the demo is hereand the server-side PHP code is here.

In the demo, I make extensive use of Smalltalk-like concepts. For example, the client data from the server consists of an array of <name, identity-key> pairs encoded as a JSON string. Here is the code that decodes the string, stores the data locally, and updates the client list:

(@self 'clientData- (@fromJson s))
(setq names (@collect- (@asList (@self 'clientData))
                       (lambda(x)(@at- x 0))))
(@items- (@self 'clientList) names))))

“@asList” converts the receiver to a list which is then acted up by “@collect” to build a list of names – the “lambda” expression works like a Smalltalk block.

Communication to the server is asynchronous. When the user selects a client name, two requests are made to the server – one for the client detail information and a second for a list of rentals. This is how it is handled:

(setq id (@at- (@at- (@self 'clientData) index) 1))
(@callback- (@self 'server) (lambda(s) (@self 'refreshDetail- s)))
(@send- (@self 'server) (+ "cmd=clientdetail&id=" id))
(@callback- (@self 'server) (lambda(s) (@self 'refreshRentals- s)))
(@send- (@self 'server) (+ "cmd=clientrentals&id=" id))

During the next two weeks, I will begin setting up interactions with a MySQL database and I hope to demonstrate the creation of customized user interfaces through loading stored Lisp code.

It is the sort of flexibility that will be difficult to achieve with a MXML/XAML/compiled-code model.

April 24, 2007

Dynamic Languages in .Net

Filed under: .Net Architecture, Vista Smalltalk — pfisk @ 9:10 pm

Microsoft researchers have been investigating improved dynamic language support in .Net for several years now.

According to Mary Jo Foley, they may be about to finally announce a “dynamic language runtime” at next week’s MIX07 conference. If that is true, then once it is released, I should have no trouble in using it to create a high performance version of Vista Smalltalk – probably in a matter of weeks.

I am trying to understand the “big picture” of Microsoft’s strategy. On one hand, they seem to be deliberately limiting the capabilities of their Silverlight browser plug-in. On the other hand, improved dynamic language support in .Net would greatly improve its appeal as a gaming platform.

And, they appear to be putting more resources into promoting and supporting their XNA studio which can produce games for both Windows Vista and the Xbox 360 console. Also, the WCF (Windows Communication Facility) in Vista supports P2P “mesh” networking which may be a good way of linking players in highly interactive online games.

So they would like to discourage development of full-featured browser applications (which could compete with their desktop franchise) and encourage highly interactive, graphically rich applications which can best be run on Windows Vista. It would be a rational strategy for them.

MIX07 will be a very interesting event to watch.

Interaction with JSON Server Data

Filed under: Adobe, Lisp — pfisk @ 6:11 pm

httpconnect1
Vista Smalltalk Site

Open Vista Smalltalk in your browser.

Above is an image of a communications session run within a Firefox browser.

At the top left is a Lisp workspace in which there are six lines of code.

The first three lines set up the server connection:

(setq cn (@new HttpConnection))
(@url- cn “http://vistascript.net/vistascript/webserv/videostore.php“)
(@callback- cn (lambda(s)(@inspect (@fromJson s))))

And the second three lines send requests to the server:

(@send- cn “cmd=clientlist”)
(@send- cn “cmd=clientdetail&id=010018″)
(@send- cn “cmd=clientrentals&id=010018″)

There are three inspector windows which were opened when the server responses were received – one shows the client list and the others show client details (the server-side PHP code is here and here). All client-sever communications in this example use JSON encoding. Also, the requests are sent to the same server from which the application was loaded (the “site of origin”); sending requests to a different server requires a slightly different technique (such as routing through a gateway program) which I will cover in a separate post.

Having a complete programming environment available in the browser makes debugging interactions with a server a whole lot easier. As “Rich Internet Applications” start to become seriously more complex, and deal with multiple servers simultaneously, this will be a major advantage.

April 23, 2007

Application Launcher Added

Filed under: Adobe, Apollo, Lisp, Smalltalk Language — pfisk @ 6:27 pm

classbrowser3
Vista Smalltalk Site

Open Vista Smalltalk in your browser.

I have added an application launcher which appears in the Vst/Flash application window on startup. All startup actions are determined by the scripts in config.lisp, so this required simply adding a line of code.

Below is the code for the “run” method which illustrates some of the dynamic capabilities of the interpreter:

  • the @selectedItem message returns the selected tree item
  • the @property- message returns the name of the item as a string
  • the @intern message sent to the string returns a symbol
  • the @eval message returns the value of the symbol
  • the @or-, @isDemoClass, @isToolClass messages determine if the value is an appropriate class (for example, you shouldn’t try to run “Demos”)
  • if it is an appropriate class, send it the “open” message to start the demo or tool

(add-method Launcher 'run
  (lambda()
  (let ((cls)(item))
  (setq item (@selectedItem (@self 'treepane)))
  (setq cls (@eval (@intern (@property- item 'label))))
  (cond ((@and- item (@or- (@isDemoClass cls) (@isToolClass cls)))
         (@perform 'open cls))))))

The concepts in this style of programming come from Smalltalk but, for the moment, the syntax is Lisp. Once the Smalltalk-Lisp conversions are more robust, most of the “high level” application code will be done with Smalltalk syntax.

April 22, 2007

Menu Examples in Lisp and MXML

Filed under: Lisp, Xaml — pfisk @ 5:57 pm

classbrowser3
Vista Smalltalk Site

Open Vista Smalltalk in your browser.

The image above shows the new menus that I am adding to the ClassBrowser. Here is the relevent Lisp code:

(setq mb (@items-callback- MenuBar
'((File
  (("File in" fileFileIn)
   ("File out" fileFileOut)
   -
   (Close fileClose)
  )
 )
 (View
 (("Set colors" viewSetColors)
  ("Set fonts" viewSetFonts)
  -
  (Refresh viewRefresh)
  )
 )
)
(lambda(tag) (@self tag))
))

The first argument is simply a quoted list which defines the menu contents and the second argument is the “callback function” which will be called whenever the user clicks an item. In this case, the callback function simply sends a message to the menu owner – ie, if the user clicks “Set colors”, the message “viewSetColors” will be sent to the ClassBrowser instance.

Compare this to an example of how Flex/MXML sets up menus (note that the menus in the two examples are not identical). And setting up menus in WPF/XAML is very similar to Flex.

If you are using a tool like Flex Builder 2, the MXML code is automatically generated so, in practice, it is quite easy to do.

Both MXML and XAML are examples of declaring interface components statically using XML and then linking selected components to code at compile-time. For many situations, this will work well enough.

The Lisp approach is fundamentally different in that it is totally dynamic. In the Lisp example I showed above, the first list could have been read from a database or generated elsewhere in the program and it would have worked just as well.

I use Lisp because it has the structural expressiveness of XML, the power of a procedural language and the dynamic flexibility of JavaScript.

Microsoft and Adobe propose building RIA’s using three languages:

  • an XML (XAML or MXML) variant for structure
  • a Java variant (C# or ActionScript) for proceedures
  • JavaScript to add dynamic capabilities

I propose using one language, Lisp implemented identically in Flash and .Net, for all of the above.

April 21, 2007

Microsoft Hit with Patent Suit over .Net

Filed under: General — pfisk @ 3:50 pm

InfoWorld recently posted this story about a Texas company suing Microsoft:

Vertical filed suit April 18 in a U.S. District Court in Texas alleging that Microsoft has infringed on its Patent No. 6,826,744 for a “system and method for generating Web sites in an arbitrary object framework.”

The patent is for Vertical’s SiteFlash technology, which utilizes XML (Extensible Markup Language) to create a component-based structure to build and efficiently operate Web sites, according to the company’s Web site. A Vertical spokesman could not be reached for comment.

The complaint says Microsoft is still willfully infringing on the patent despite Vertical having put Microsoft on notice about it on Feb. 7. Vertical is asking for a jury trial.

As far as I can understand, this means that XAML infringes their patent. And, if the lawsuit succeeds, they will surely sue Adobe over Flex/MXML which is very similar to XAML.

I have written a number of posts about XAML. Basically, I don’t like the whole idea of mixing compiled procedural code with a declarative data structure – the “code behind” approach (the same model is used in Flex as well).

Lisp can elegantly support static data structures, embedded code, macro expansions, and selective macro expansions through “backquote macros”, which I will soon be adding to Vst/Flash. XML is fine for serializing static data and ActionScript/C# are fine for writing procedures. But, mix them together and what you have is (IMHO) a mess.

I have no idea what the outcome of this lawsuit will be – and I sincerely hope that it fails very soon.

Maybe a bright lawyer somewhere has already patented using Lisp or Smalltalk in Internet applications, or using Lisp and Smalltalk together in one application. It really wouldn’t surprise me if that were true.

Sometimes truth is stranger than fiction.

Older Posts »

Blog at WordPress.com.