ExtJs 4.0 Class Hierarchy Browser

ExtJs 4.0 Class Hierarchy Browser


Above is a screenshot of an online class hierarchy browser for the ExtJs 4.0 JavaScript library.

It was built in about three hours using Sencha’s new Designer 2.0 GUI builder.

There are only a limited number of “good” fundamental ideas in computer programming and the same ideas keep get “rediscovered” and coming back into fashion.

This seems to have happened with Clojure Lisp – a 54 year-old language got some new syntax and some new VM’s (CLR,JVM) – and now is enjoying a surge in popularity. Code-as-data or “Homoiconicity” is a “good idea” for many types of programming tasks.

In a previous post, I commented on how much Ruby resembles Smalltalk with its “everything is an object” philosophy.

The newest JavaScript libraries are also borrowing heavily from the Smalltalk legacy.

In particular, the ExtJs 4.x libraries are structured in much the same way as Smalltalk libraries:
— the library is based upon classes
— classes are arranged in a hierarchy with method inheritance
— there are “static” methods and properties, similar to Smalltalk’s “class” methods
— parent classes are referred to by a “superclass” variable
— there are “self” and “super” functions for method calls

Browser interfaces for RIA (buzzword – Rich Internet Applications) applications are becoming as complex as desktop GUI’s.

As a result, JavaScript libraries are becoming larger and more capable as well.

And the best way to structure an extensive widget library is to organize it with classes as was pioneered by Smalltalk.

Another paradigm seeing resurgence is the Model-View-Controller pattern (again from Smalltalk).

The ExtJs 4.x libraries have Model, View, Controller classes and the ExtJs Designer 2.0 project tool automatically sets up this pattern by default.

MVC is gaining popularity on the server side as well. The online browser example that I linked above uses the CodeIgniter PHP library on the server – and CodeIgniter is also organized in a Model-View-Controller pattern.

So, in this example, both the browser JavaScript library and the server PHP library are using the MVC pattern.

As a language, Smalltalk’s popularity has decined over the years. But many of the ideas that Smalltalk was based upon are very much alive and well:

— windowed GUI interface => MS Windows, Apple Macintosh, etc
— bytecode interpreters => Perl, PHP, Java, C#, Python, Ruby, etc
— Object-Oriented programming => Java, C++, C#, Ruby, Python, etc
— Integrated Development Environments (IDE’s) => Eclipse, Visual Studio, etc
— MVC => many libraries

And, as Internet applications become more complex, I expect that we will see more of Smalltalk legacy being “rediscovered”.

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

Ruby is the New Smalltalk

January 28, 2012

Over the past few months, I have had the opportunity to use the Ruby language on a small project.

Ruby was designed by Yukihiro “Matz” Matsumoto as an fully object-oriented, dynamically typed, interpreted language. Its design was influenced by Perl, Smalltalk, and Python.

What surprised me was the degree to which the language reminded me of Smalltalk – everything is an object and there are many familiar Smalltalk methods such as “select” and “collect” for collections.

All of the consulting work that I have done over the past decade has been for Internet applications with an emphasis on RIA (rich Internet application) architectures (ie with large amounts of JavaScript).

This usually involves considerable manipulation of data structures such as dictionaries and lists. And Ruby is very powerful in this area with an easy syntax for declaring literal structures ([…] for lists and {…} for dictionaries.

The Ruby environment that I use is on the Heroku cloud platform. Heroku, recently hired “Matz”, the inventor of Ruby, as a full-time member of their staff.

Twenty years ago, I used to build Smalltalk applications for Unix desktop workstations. There were many flavors of workstation popular at the time and Smalltalk offered a single solution to run on all platforms. With the current dominance of Windows and MacIntosh, the requirement for multi-platform desktop apps has mostly disappeared.

Today’s application environment is increasing becoming Internet based where standard protocols (HTTP,HTML,CSS,JavaScript,etc) mostly hide the specifics of client devices.

The client-side application language seems to be standardizing on JavaScript. So, our language choices come down to what works best on the server.

And, as I said earlier, Ruby is a descendant of Smalltalk which has excellent server-side implementations. My sense of Ruby is that it is about 80% influenced by Smalltalk, and perhaps 10% each by Python and Perl.

So, I think that one of the main reasons that we have not seen, and IMHO may never see, a Smalltalk revival is that its “ecological niche” is now occupied by Ruby.

The development environment so beloved by Smalltalkers (with browsers, inspectors, debuggers, etc) really had very little to do with the Smalltalk language itself but had more to do with the single-user desktop platform which Smalltalk was designed for.

On a desktop platform, you can halt a process to inspect its internal state. Internet applications running on a shared server hundreds or thousands of kilometers away are a totally different situation.

“Smalltalk-like” tools can probably be developed for many of the popular modern languages such as Python, Ruby, Clojure, Scala, or Groovy.

And maybe even for PHP…

ExtJs 4.0 Class Browser

ExtJs 4.0 Class Browser


ExtJs 4.0 is an advanced JavaScript library that I have chosen as the basis for rendering QuickSilver widgets across multiple browsers and mobile devices. It support SVG graphics, flexible data models, and dynamic component loading.

Currently, I am porting QuickSilver from ExtJs 3.3 to ExtJs 4.0. There has been a complete rewrite of much of the library and this has resulted in a great deal of work in migrating the Smalltalk widget libraries.

ExtJs 4.0 has a new class system which is more similar to the Smalltalk class system.

As an exercise, I tried building (in JavaScript) a Smalltalk-style class browser for the native ExtJs classes and the tool works quite well. In fact, it is very similar to tools currently being built by Dan Ingalls (who created both Squeak and the original Smalltalk-72 and Smalltalk-80).


Smalltalk has long had the reputation for being a highly productive language. I keep wondering whether the productivity has been due to the simple language syntax or to the powerful tools available in the environment. It seems that Dan Ingalls has built a complete Smalltalk development environment
using JavaScript as the only language.

Smalltalk tools for JavaScript? I would be glad to hear your thoughts.

Here is a news item from “Wired” that was published last year but which I have just become aware of.


About 40 years ago, tech legend Alan Kay invented the idea of a lightweight tablet computer that children could use to learn programming.

Apple’s iPad delivers on the tablet part of that vision — but the company has blocked a kid-friendly programming language based on Kay’s work from getting onto the iPad.

Apple removed an app called Scratch from its iPhone and iPad App Store last week. The Scratch app displayed stories, games and animations made by children using MIT’s Scratch platform, which was built on top of Kay’s programming language Squeak, according to MIT.

Steve Jobs took a tour of Xerox PARC in 1979, and some might even say that his visit is still unfolding with the release of the iPad tablet, which resembles Kay’s description of the Dynabook (illustrated at right).

Jobs this month personally mailed an iPad to Kay, who praised Apple’s tablet as “fantastically good” for drawing, painting and typing. But Kay declined to give his full evaluation of the iPad to Wired.com until his question of whether Scratch or Etoys — another educational programming language Kay developed for kids — would be usable on the device.

With the removal of Scratch from the App Store, for now the answer to Kay’s question would appear to be “No.”

“If you follow the chain of where Scratch came from, yes it is a Dynabook app, sadly not an iPad app,” McIntosh wrote in Apple’s developer forums.

McIntosh said that Apple removed the app because it allegedly violated a rule in the iPhone developer agreement — clause 3.3.2, which states iPhone apps may not contain code interpreters other than Apple’s. The clause reads:

An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).

Daring Fireball blogger John Gruber, who first reported the removal of Scratch, explained that Apple’s intention with the “no interpreters” rule is to block meta-platforms such as Adobe Flash.

AFAICT, Apples clause 3.3.2 is still in force.

iPad is pretty much what Alan Kay described as the “Dynabook” concept. And, now that it is reality (in large part due to the influence of Smalltalk), Squeak Smalltalk won’t be allowed to run on it.

QuickSilver runs in the JavaScript environment and doesn’t require the installation of a separate VM. So, QuickSilver should be ok for the iPad, iPhone, Android, or any other device that supports JavaScript.

Sencha’s ExtJs 4.0 will be released in the next few weeks.

It has a number of things that will be very useful in QuickSilver:

  • SVG graohics implemented in JavaScript/CSS
  • dynamic loading resulting in faster startups
  • better client-server integration (Ext Direct)
  • constructors organized as classes

I have been reading the documentation for ExtJs 4.0 and it seems that the library structure has moved closer to Smalltalk. In particular, they have added Ext.Class and Ext.ClassManager.

There is now explicit support for calling parent methods like Smalltalk’s “super” (Ext.Base.callParent) and calling class methods (Ext.define({static: …})).

In the QuickSilver compiler, I wrote a number of library functions to support this type of Smalltalk behavior in JavaScript. Once ExtJs 4.0 is released, many of these might be replaced by the equivalent Ext functions.

Also, it means that it may be possible for the QuickSilver compiler to produce pure ExtJs 4.0 code.

Develop and prototype in Smalltalk and automatically generate JavaScript for deployment.

New Smalltalk Methods in QuickSilver

New Smalltalk Methods in QuickSilver


I have added several standard Smalltalk methods to QuickSilver and a few new ones:

Array class





<Number> range works like “range” in Python – it produces an array filled with numbers.
<Array> list is a convenience method – it lists an array to the Transcript.

Here is an example of how to list the squares of odd numbers between 1 and 100 in reverse order.

((100 range
select:[:x | x odd])
collect: [:x | x squared])
reverse list.

QuickSilver is real Smalltalk:
— smaller footprint then jQuery
— faster than Squeak
— compiles to JavaScript
— MIT license
— targets browsers, iPhones, iPads, Androids, etc

The project is now only 17 days old – it is just getting started…