ExtJs 4.0 Class Hierarchy Browser
February 4, 2012
ExtJs 4.0 Class Hierarchy Browser
http://ec2-50-19-46-70.compute-1.amazonaws.com/apps/demo2
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…
New Blog – SIMPL/PHP
January 20, 2012
Hello again,
I have started a new blog at http://simplphp.wordpress.com.
SIMPL/PHP is a complete “Smalltalk-like” online environment for developing Internet applications.
And I will keep this blog alive as well for discussing Smalltalk…
Development Update – May 5
May 5, 2011
My last post on March 11 talked about the upcoming release of Sencha’s ExtJs 4.0 libraries.
Finally, ExtJs 4.0 was released last week and this will now allow development of the QuickSilver libraries to resume.
I plan to move the QuickSilver blog from WordPress to one of my own sites probably in early June. This will allow both discussion and interaction with the tools to occur in a common environment.
The goal is to create a Smalltalk-like environment for rapid development of Internet-based applications.
I will be posting more details in a couple of weeks.
Comments on Current QuickSilver Status
March 11, 2011
Update to ExtJs 4.0
ExtJs 4.0 was scheduled to be released Feb 28, but the beta is still not available as of today (March 11). Instead, there are a number of pre-releases (currently pre-release 3) that are only available in full debug configuration. This is about a 2.8 MB download, so the loading will be slow until the beta is available.
Once the beta is ready, I will use the dynamic loading capability which should improve startup times dramatically.
ExtJs 4.0 is a major refactoring of the product, so I decided to proceed with the upgrade rather than extending the ExtJs 3.3 tools.
QuickSilver Smalltalk Compiler
The compiler is working well with only a few bugs that I am aware of.
Debugger
A debugger can be implemented by some additions to the code generator that will insert extra statements to store the current state and exit the current process. I don’t see any major problems implementing a debugger.
Smalltalk vs JavaScript Syntax
The QuickSilver compiler could be extended to handle either Smalltalk or JavaScript syntax. In any case, the compiler will have to be reworked to support a debugging environment.
Currently, the compiler takes Smalltalk code from which it generates JavaScript code for compilation. The inverse should also be possible – that is, take JavaScript code and convert it to Smalltalk syntax.
ExtJs 4.0 supports SVG graphics which means that it is probably not too difficult to build an “MIT Scratch” type visual programming interface for end users.
QuickSilver is now about 86kb in size. Adding JavaScript syntax support could add another 30-50kb (guess?). Supporting Scratch really doesn’t add much to the compiler – it receives a graph structure from the graphical interface and uses it to generate code – this just uses the generator that is already in the compiler.
Dynamic Environment
One change that I am currently implementing is to load as much as possible (HTML, CSS, JavaScript) from dynamic sources – Memcache or Database. This will allow many applications to share common components.
It also means that applications can be dynamically created from existing components on the site. The “Lego” building-block approach to creating applications.
Smalltalk Tools in JavaScript for ExtJs 4.0
March 10, 2011
ExtJs 4.0 Class Browser
http://www.silversmalltalk.com/
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.
‘The Browser Is The Platform Of The Future’
March 10, 2011
An article from a game developer publication:
http://www.gamasutra.com/view/news/33406/Hawkins_The_Browser_Is_The_Platform_Of_The_Future.php
At the Game Developers Conference last week, Electronic Arts and now Digital Chocolate (Millionaire City) founder Trip Hawkins worried that evolutions in the multiplatform space would pose major challenges for developers trying to earn money in emerging spaces.
The explosion of browsers onto mobile devices and the rise of cloud-based gaming can take much of the credit for why Hawkins, who was also Apple’s director of marketing prior to founding EA, believes that it’ll end up the game industry’s most central platform.
“The browser has taken over 2 billion PCs–it’s going to be taking over a billion tablets over the next few years, billions of mobile devices,” he says.
And it’ll even enter new areas: “It will end up in my opinion very strong on the television. The browser is the platform of the future,” Hawkins adds.
Cloud-based rendering is increasingly enabling consumers to access content from a number of devices whether or not they own that content, thus “there is going to be enormous growth there,” he says.
Consumers will be able to integrate that content more persistently in their daily lives and want to remain engaged with it, versus traditionally when content was segregated to the living room or to a single computer.
He is saying what I have repeated several times in this blog – the application platform has moved from the desktop to the browser/tablet/phone connected to the Internet. And this trend will continue and accelerate.
QuickSilver runs in any JavaScript environment and is deployed from a cloud infrastructure (Google’s App Engine).
Apple Rejects Squeak Smalltalk
March 10, 2011
Here is a news item from “Wired” that was published last year but which I have just become aware of.
http://www.wired.com/gadgetlab/2010/04/apple-scratch-app/
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.
Updating Libraries to ExtJs 4.0
March 8, 2011
I am currently updating the QuickSilver libraries to ExtJs 4.0.
The site will be back to normal in a few days.
QuickSilver Smalltalk 