Comparing Languages

January 29, 2012

Comparing programming languages sometimes evokes passionate debate, so I thought that a little perspective would be useful.

If we asked a carpenter what the “best” tool was – a hammer, a screwdriver, or a saw – he would think that this was a meaningless question. It depends upon what task you are trying to accomplish.

Here are three examples of different languages from my own career:

1) Cobol

For many years, I worked on mainframe systems that did accounting for insurance companies, pension administration, and payroll services.
In that environment, you do not want change to be “swift and agile”; you want change that is slow and can be easily verified. We had accountants whose role was to read Cobol source code to verify that it accurately reflected the legal language of pension contracts.

When you are dealing with millions of dollars in transactions per day, people take the placement of “decimal points” *very*, *very* seriously. And also, how all of the inevitable rounding errors are accounted for.

Around Christmas time, I often see credit card companies reporting the number of transactions at the busiest time of the year. This is usually in the tens of thousands of *sustained* database transactions per second. I would bet that most of these data processing systems are using Cobol/CICS.

You don’t hear about Cobol much these days, but most of the people reading this have probably used one or more Cobol transactions within the past week.

2) Fortran

A few years ago, I was talking to a recently graduated Phd student in nuclear physics. He showed me the code that he had written for his doctorate and it was all in Fortran.

One project that I worked on (over a period of 7 years) used a Smalltalk workstation to plan flight paths for aircraft collecting environmental information. The data collected was then processed on a Cray supercomputer where all of the software was written in Fortran. Fortran has huge libraries for weather forecasting, but equally important, the compilers have been optimized over decades to get the maximum performance for numerical computations.

It is like the Cobol example above — numerical modelling libraries don’t change quickly and any changes that are made have to be validated thoroughly before going into production. What matters is performance. If tomorrow’s weather forecast takes a week to compute, then it is useless.

3) C++

I worked on a telecom project for high-speed data switches that were programmed in C++. My responsibility was to merge multiple sources of code (from up to 300 programmers) into a final product build. The software was highly flexible and the team used Smalltalk workstations to build the configuration files.

In the telecom world, two things are important:
— speed – microseconds make a huge difference when you process millions of calls
— well defined interface specs – the C++ compiler will enforce 8-bit, 16-bit, 32-bit, 64-bit, 128-bit etc values. Absolutely essential in device drivers.

So, here are three examples – note that in two of the examples, Smalltalk was used in peripheral roles.

The *best* language is the one that meets the critical requirements of the application.

Financial services, weather forecasting, and programmable telecom switches all have different requirements.

And each of them has its own unique *best* language.

— Peter

Form-to-Form Communication

Form-to-Form Communication

In the image above, there are two browsers open – Safari on the left and Opera on the right.

In each of the browsers, there is a window called “Test Form” which was created with the form design tool that I have discussed in earlier posts.

At the bottom of each “Test Form” window, there are two buttons – “Send” and “Open” – and a text field with the name of a channel.

Pressing “Open” opens the communication channel; pressing “Send” sends the contents of the form to any other forms which are on the open channel.

In this test, I filled in some data in the Safari form and pressed “Send” – and the data immediately appeared in the Opera form.

Creating the test form took about 3 minutes and no knowledge of Smalltalk or JavaScript was required. Using the form is even easier – just open a channel, fill in some data, and press “Send”. And, of course, the other forms on the open channel can “Send” data back as well.

I have renamed the design tool to “QuickForms” and it will be increasingly used to build both tools and applications.

From today’s App Engine Blog:

The UK is gearing up for a very special wedding on April 29, when Prince William and Catherine Middleton will be married in Westminster Abbey in London.

Unlike many previous Royal Weddings, this event will have its own website – and we’re honoured that St. James’s Palace has chosen to use Google’s computing infrastructure to power the site.

QuickSilver Smalltalk is hosted on Google’s App Engine.

One of the reasons that I chose GAE was because of its scalability – you can scale to almost any size and you only pay for resources that you actually use. So, it is perfect for short term events that may have very large traffic spikes.

A royal wedding is this kind of event – for a few days, there may be millions of visits to the site and then traffic will dramatically decrease; and it is very hard to predict the traffic ahead of time.

The creators of the wedding site presumably have a very large budget so they could have used almost any hosting technology. And so, it is interesting that they chose to use Google’s App Engine.

Real-time Chat Window

February 19, 2011

QuickSilver Chat Window

QuickSilver Chat Window

There is now an operational Chat Window available from the desktop context menu.

To use the chat window, you must first “Open” the named channel (name is in textfield at bottom). You will then automatically receive any messages sent over that channel. To send a message, write the text in the bottom panel and press “Send”.

This is a very simple chat application that uses some new features in the Channel class.

1) when a channel is opened, it is assigned a unique ID number (from Math.random()). So, each browser will have a unique number for messages sent on the channel.

2) when messages are sent, they are packaged into an dictionary that contains the message id (above) and the message value. When messages are received, each Chat Window application checks the message id number against its own ID number. It uses this information to process only messages that were sent by other applications.

So, this chat application is sending and receiving objects. At the moment, the only data in the object is a string of text.

It is very easy to start including other info in the messages such as time, priority, classification, etc.

And the data doesn’t have to be a string – it could be a dictionary or an array for updating graphs or lists.

Chat Window provides a functional basis for a series of real-time work collaboration tools.

Object Transmission Testing

Object Transmission Testing

This is a small test to validate some ideas for a general object communication class.

There are two browsers open in the image. The test consists of sending a serialized Smalltalk object from one browser to the other and opening an inspector on the received object.

Here is the code for opening the channel:

Channel open: 'test-1'
handler: [:x | (Json decode:x) asObject inspect].

And the code for sending an object:

Channel send:
(Json encode: {{
sender: 'BROWSER ONE',
message: 'hello browser two'

You need to open the channel first on both browsers. Then you can send as many message objects as you wish. Note that both browsers will receive all messages. An object communication class would mask senders from receiving their own messages.

A few notes about the code:

  • there is a new class Json for encoding/decoding objects
  • “asObject” is a new unary message that can be sent to any JavaScript object as well as any Smalltalk object. It will encapsulate a native JavaScript object in a NativeObject Smalltalk object.
  • in sending the message, I am using a shorthand way of creating a Dictionary

This is the basic underlying Smalltalk object transmission mechanism.

Now the task is to build some protocols on top of it for more conveniently communicating with objects.

After that, we can deal with objects that contain messages.

Object-Oriented Networking

February 9, 2011

Computer languages become widely used if they are good at solving particular problems.

There have been several new or existing languages that have gained enormously in popularity over the past 15 years because they were well suited to solving problems related to the Internet:

  • Perl
  • PHP
  • Python
  • JavaScript
  • HTML
  • CSS

Perl is an *interesting* language with verbs like “die”, “croak”, “confess”, and “bless”. It is not *elegant* (like Pascal) but it certainly is *useful*.

Same thing for PHP which can mix HTML and code in very creative ways.

And Python (after “Monty Python”) with its minimal syntax and lots of time-saving shortcuts.

These three languages are hugely popular and share several things in common:

  • they were created for solving *real world* problems
  • they were originally created by single programmers, not committees
  • they are open source
  • they developed new programming styles to fit new environments
  • they weren’t afraid to experiment and evolve

Smalltalk enthusiasts want their language to become more popular.

IMHO, the secret to doing this is finding the correct problem to be solved – a problem that can be solved better by Smalltalk than any other programming language.

Consider how the Internet is evolving. Starting in 1969, solutions were developed for connecting large networks of machines (IP, TCP/IP, FTP, etc). Then, after 1989, the “World Wide Web” introduced several innovations that made the Internet usable for much larger numbers of people (DNS, URL, HTTP, HTML, CSS, etc).

Now, in 2011, the W3 “page-oriented” model is becoming outdated:

  1. users want real-time interactivity
  2. users want graphical, interactive interfaces
  3. there are new types of devices like smart-phones and iPads with different form factors
  4. many users want to share some data with friends (social networking)
  5. interfaces are becoming much more complex (work collaboration, etc)

So, I propose a new model for developing user applications which I call “Object-Oriented Networking”.

In O2N, serialized Smalltalk messages are exchanged amongst clients and servers. And we can specify standard ways to transmit and receive objects – say NetIn and NetOut (like UNIX).

The list of challenges (1-5) above are much easier to address in Smalltalk than any of the other currently available solutions.

And QuickSilver is small, fast, open source, and able to run in any of the billon+ Internet devices that support JavaScript.

New environments require new solutions – or old solutions (like Lisp and Smalltalk) that have been rediscovered.

— Peter