The rantings of a beautiful mind

On life, society, and computer technology.

My Photo
Name:
Location: Toronto, Ontario, Canada

I live in the Fortress of Solitude. I drive the Silver Beast. My obsession is justice. I used to be a Windows software developer. I retired in 2000 when my stock options helped me achieve financial security.

Tuesday, October 31, 2006

Nice, though dated, article

Here's a nice, though dated, article: New Tricks for an Old Dog.

One interesting practical application that uses embedded Smalltalk is an 8-line PBX (private branch exchange) telephone system with integral voice mail... Most amazing, perhaps, is the time scale needed to develop the application: It took four engineers just nine months to bring the product to field testing, and a further three months to go to market.

-----

Smalltalk's fast development times and small development teams are corroborated by numerous practical examples. EDS estimates that development time in Smalltalk is about one-fifth that of development in C++. And a European bank that recently rewrote its client management software using OTI's Smalltalk cut the size of its development team from about 1,000 (COBOL) to fewer than 100 (Smalltalk) programmers, who now write more complex systems in the bargain.

-----

Clohessy claims that only 10% of a typical application is speed-critical, and these speed-critical parts are the only ones that need to be written in C (or assembler).

Or Fortran!

Monday, October 30, 2006

Smalltalk and Fortran!!

http://www.artima.com/forums/flat.jsp?forum=155&thread=116721

This would be my dream job: writing software in both Smalltalk and Fortran! God, I miss Fortran. What a great language!

[My very first programming language was FORTRAN (in the early 1980’s, I was a bona fide FORTRAN guru). I have a very special place in my heart for Fortran (these days, the name is no longer all capitalized).]

Saturday, October 28, 2006

Smalltalk, Objects, and Design

I really like “Smalltalk, Objects and Design,” by Chamond Liu. This book is well-written, eminently readable, and quite informative. While it is not a deep survey of the Smalltalk language, it is an excellent guide. The book goes well beyond Smalltalk to discuss object-oriented design and software development processes in general.

It is also very well-balanced, giving an honest and upfront view of software development. For example,

The Smalltalk language is easy to learn because it is so small. But the language by itself doesn’t do much. It is powerful only in conjunction with the hundreds of foundation classes and thousands of supporting classes that are part of today’s Smalltalk products. You will have to learn many of these classes before you can write clean Smalltalk code. This takes time and practice.

It also takes time to become proficient in applying the ideas in this book — designing with containers, polymorphism, patterns, and so on. Everyone has an innate ability to understand and talk about objects, but not everyone will work long and hard enough with them to become a good designer. Look at it this way: object-oriented development increases our toolkit of techniques, which gives us more ways than ever to make a mess. Without the maturity that comes with experience, it is harder than ever to pinpoint desirable solutions in this enlarged universe of possibilities.


An object-oriented project is no more likely to succeed than any other project. Out-of-touch leadership, misplaced optimism, complacency, the wrong tools, and all the rest are just as likely to afflict an object-oriented project as any other. Successful projects need business acumen coupled with technological knowhow, and you can find these qualities in conventional projects as well as in object-oriented ones.


GUI builders alleviate tedium. They are a pleasurable addition to our bag of software tools. But they don’t make model-view separations automatic and they divert us from the profoundly challenging task — design.


There’s a good chapter on “Design patterns,” too. Hardly a replacement for the “Gang of Four” classic, but I’m too lazy to read a lot, so I really appreciate this chapter.

I highly recommend the book. If you’re at all interested in Smalltalk or object-oriented design (and you want an easy read), this is THE book to get!

Wednesday, October 25, 2006

Smalltalk Debate

I’ve observed that all hard-core C++ programmers have one thing in common: they are performance-obsessed. (This probably spills over in their bedrooms, as well.)

Ted hit the nail squarely on the head: To C++ programmers, “good enough” performance is never good enough. The hacker mentality is that they must write the most terse and efficient code possible in order to impress the heck out of each other. It’s a glorified pissing contest. “My dick is bigger than your dick.”

Since Ajith has studied economics, I am astonished that he doesn’t understand the application of economics in software development. Given the state of today’s hardware, native code applications are no longer the necessity that they used to be; interpreted code is now an acceptable alternative in most application domains.

Why interpreted code? In two words: programmer productivity. It comes down to economics... Hardware costs are no longer a big deal, but labour costs — i.e., programmer labour — are absolutely critical in most software development organizations. Why the f*ck do you think everybody is trying to outsource software development to f*cking India???

If I can hire a Smalltalk developer to do THREE or FOUR times the amount of work that a C++ programmer can do, I’d be f*cking nuts not to go that route! The alternative is to hire THREE or FOUR C++ programmers. At a salary of $80,000 per year, that’s a big, f*cking chunk of your IT budget!

Ajith didn’t answer my question — what application domain is he working in that is so performance-sensitive? Maybe he’s one of the exceptions that must work in C++. If so, I feel sorry for him.

But for the rest of us, we would be wise to look at Smalltalk or Ruby or Python or even Lisp!


Ajith, do you have the gonads to prove that you’re anywhere near as productive as a Smalltalk developer??

R


On 10/25/06 12:21 PM, "Edward (Ted) Doig" wrote:

WTF? Did I personally offend you or something?

Performance is not the Be All and End All of every fucking programming task. Of course you can write it all in a compiled language and it will run with blinding speed and work in a MILSPEC environment and mana will rain down from Heaven and you can go off and write your Turing Award acceptance speech etc. etc. etc.

Yes, I'll be the first to admit that "good enough" ain't necessarily "performance optimal". My point is that what amount of efficiency is appropriate to the task at hand? While you're busy writing your oh-so-efficient STL/C++ program that is gonna run circles around me, I'll have already rattled off my one line of script, got my answer, and have gone out for a beer already. ;-)

I did not, nor did I ever imply, that writing everything in shell script is a panacea, but for certain problem domains, it is more efficient for me overall. So a dedicated C program will run 5x faster. So what? So I get my response back in 25 milliseconds rather than 5 milliseconds. Big deal. I'll learn to live with it.

Your initial argument was based on lines of code, and I provided a counter-argument. You then mention performance, and I assert that it simply doesn't matter in this case. You'd better be careful, Ajith, you're starting to sound even more curmudgeonly than Richard! :-)

Thx - Ted



From: rengranting On Behalf Of Ajith Shanmuganathan
Sent: Tuesday, October 24, 2006 10:59 PM
Subject: RE: [rengranting] Studying Smalltalk


Ted,

Come on, no one believes the crap you write.

I've written shells from scratch, I know how inefficient they can be.

I've also seen scripts from hell, so I know script programming is not for novice programmers. If you want write maintainable, fast, robust software in a production environment, you wouldn't choose shell scripts.

Ever heard of process overhead? Your little shell script will be at least 5 times slower than a dedicated C program. Measure the performance, you will be surprised how slow your code is.

I've heard the lame arguments for using PERL and other scripting languages. In reality, these languages suck for just about everything otther very simple tasks.

My STL and GNU library code is definitely orders of magnitude faster than any shell script. So don't be stupid.

- Ajith

Tuesday, October 24, 2006

Smalltalk Testimonial

Here’s a nice story about how a C++ game console developer became converted to Smalltalk...

http://smalltalk.org/articles/article_20060919_a1_LearningToTalk_v1.html

As a learning exercise, he wrote a DirectX game entirely in Smalltalk!

Monday, October 23, 2006

Croquet

Some while back, my friend Norm mentioned Croquet. Well, because I’m immersed in Smalltalk now, I’m looking at all things Smalltalk. So I’m reviewing Croquet in earnest...

http://www.itwales.com/999105.htm#4

http://www.opencroquet.org/about_croquet/index.html

This is exciting! Croquet is the future of operating systems!


There are a number of reasons why we need something like Croquet today. First, the personal computer user interface was cast in amber 20 years ago. This was for various reasons:

* The desktop GUI originally developed by Alan Kay and his colleagues was an extremely successful approach to interacting with the personal computer.

* The emergence of software monopolies removed any encouragement to innovate on the platform. Compare a modern PC of 2004 to the first Macintosh shipping in 1984 and the major difference you will see is color.

* The fact that these dominant systems were created in early bound languages made it impossible to easily modify the foundations of the system either by the developers or by third parties.


Croquet was built to answer a simple question. "If we were to create a new operating system and user interface knowing what we know today, how far could we go?" Further, what kinds of decisions would we make that we might have been unable to even consider 20 or 30 years ago, when the current operating systems were first created? We decided that it was time for an existence proof that innovation could still continue and succeed on the personal computer. We felt that the very definition of the personal computer and its role needed to be shifted from a single-user closed system to a next generation broadband communication device.


Here’s an excellent explanation why I’ve never been able to get into any (C-based) Open Source project...

Most open source work is done in C or C++, often using tools developed decades ago. It's too difficult for most people to download the source and build an open source project and those that could do it often don't feel they have the time or patience to do it. In the Squeak environment, there is no build process, and no long waits for recompilation, nor do you have difficulty jumping into a running system to find out what is happening. Programming happens at a much higher level of abstraction in Squeak Smalltalk. Due to difficulties with C and C++ most people see open source programming as a badge of hacker machismo. Old Smalltalkers, and the new breed of Squeakers can be forgiven for asking, "Why do you people keep torturing yourselves when there's a better way?"

Thursday, October 19, 2006

Programming Language Benchmarks

Here’s a great website for comparing programming language performance:

http://shootout.alioth.debian.org/gp4/

It’s truly enlightening. For example, you will find that Cincom VisualWorks is generally much, much faster than Ruby, but Ruby is much more memory-efficient.

No surprise but C++ is much faster and much more memory-efficient than Java.

C# is generally much faster than Python. Both languages are roughly similar in terms of memory consumption.

BASIC is hands down much faster and leaner than Python or Ruby.

You can spend hours comparing every language pairing. It’s fun!!!

A couple of caveats:

These are benchmark comparisons of specific language implementations. You can’t draw final conclusions about the languages themselves. However, they are good indicators of relative performance and should be used appropriately in decision-making.

Also, just because Language A is much faster than Language B does not mean that Language B is inadequate to the task of running your application. For example, C++ is clearly faster and leaner than Java, but Java runs well for many applications.

At least for me, this website has convinced me that VisualWorks is better than Ruby (I don’t really care that Ruby uses less memory). If Smalltalk is a little sluggish on my iMac, imagine how slow Ruby must be!!

Wednesday, October 18, 2006

An Ode to Smalltalk

I found this post on the Internet. I thought it was very elegant and insightful, so I just had to show it to you guys. When you read it, keep in mind how you do things in C# or Java...


Smalltalk may very well be the one true language of civilization and progress (and yes, I need medical help).

It is not, however, the language of the future. :( It's more of a half-forgotten treasure, alight with the lost wisdom of the ancients (also see Symbolics, Lisp Machines, Eiffel, or Project Orion).

There are those that sit and lament the decline of a superior, more enlightened technology, lost to the barbarian hordes of the latter days (more like to the lack of management and advertising competence by its owners). (Don't even think about starting on the VHS vs. Betamax thing, tho. This is different).

There are those that ask, "Why is it that we do not yet hold in our hot little consumer hands, computer technology that was developed decades ago?"

That way lies certain doom! Instead, keep the light of knowledge alive, all ye true believers! Teach your children, educate your co-workers, and scribe the legends of a long-forgotten age so that one day the technology can be resurrected. Rejoice in seeing the wisdom of the old ways run in the veins of its offsprings (Objective-C, Java, Ruby, Python,...).

Its time shall come again!

[Note: This is not to imply that Smalltalk is dead. Saying that would certainly be news to the vibrant Smalltalk community, or to the various Smalltalk vendors such as Instantiations (VA Smalltalk) or Cincom (VisualWorks, ObjectStudio), and certainly to the many companies who use Smalltalk as their primary development environment that are doing quite well. However, Smalltalk's place in the industry today is a far cry from the Xerox PARC's Project Dynabook days and the dreams of its inventor.]

Ahem. I suppose that, among all of this ranting, I have not mentioned what Smalltalk is at its heart, nor explained its uniqueness.

Smalltalk, as others have mentioned, is an Object-Oriented Programming Language. That fact alone is not enough for me to waste electrons on -- there are several things one has to understand about Smalltalk.

Purity and Simplicity of Syntax
Each line of Smalltalk code is like a string of pearls -- object message, object message message. That's it, that's all there is to the language. When I code, I can almost picture the objects as small orbs on the mindscape, with messages as pulses of light traveling between the orbs in a vast, delicate network. I can't make any claims of productivity gains solely due to the Smalltalk syntax. I can say, however, that it's a simple, intuitive joy to code in this language.

Smalltalk is the IDE
This may seem strange to many C++ or Java coders who are used to the command-line compiler, and regard an IDE as little more than a souped-up text editor for the lazy. Those who swear by, and cannot live without, their MS Visual Studio or JBuilder environments can start to appreciate the importance of a good IDE to a language; however, the symbiosis between Smalltalk, the language, and its IDE goes even beyond that.

For one, a class browser in a typical Smalltalk IDE is a feat of informational organization. A single screen lists all the known objects, their methods (either instance or class methods by the flick of a switch), the variables used by that class, and finally the source code for a particular selected method. This setup allows the programmer to traverse the complex informational space of a large software project with amazing speed. For instance, if you click on a variable, all the methods that refer to that variable show up. More importantly, for a given method, you can see all its senders (other methods that call this one), as well as its implementers (for a commonly named method, think Java's toString(), a list of objects who implement that method). Thus, following the execution path/crumb trail of (somebody else's) code, across dozens of objects becomes almost effortless. Finally, there's the...

Live Brain Surgery Effect
Smalltalk's virtual machine is its greatest strength; the fact that it's a byte-code based interpreted language enables a programmer to delve right into the code of a program while it's running. Like a doctor performing a brain surgery without anaesthetic, with the patient awake and coherent and able to answer questions, a Smalltalk programmer can look and probe at a living, running program at any moment, and examine the contents of every variable in every method on the callstack. So say your program gets an error. Instead of deciphering the cryptic error messages, hunting for the mistake through the source code, recompiling and restarting the program... a window pops up. The window puts you directly into the call stack at the moment of the error, and you can examine the living guts (suspended in time) of the program -- the values of all the variables in the methods on the stack; you can even execute code on the objects in those methods. And when you track down the error and change code in a method, only the code in that method is recompiled, while the program is still running! At that point, you can close the error window, and continue with the (still uninterrupted) program, but now with the correct code.


Sweet F*cking Jesus!!! Isn’t that amazing??? Why the hell aren’t we all programming in Smalltalk...?

Monday, October 16, 2006

Studying Smalltalk

This weekend, I began studying Smalltalk in earnest. Because I’m using Cincom’s VisualWorks (basically, this is the original Smalltalk from ParcPlace/Xerox PARC), I’m focusing on materials that deal directly with VisualWorks. So, for example, I’m starting with the following tutorials:

Cincom VisualWorks Tutorials

I’m also looking at the following books:

Smalltalk by Example: The Developer’s Guide (Featuring VisualWorks), by Alec Sharp, McGraw Hill, 1997.

Smalltalk: An Introduction to Application Development using VisualWorks, by Trevor Hopkins and Bernard Horan, Pearson Education, 1995.

I don’t know how good these books are. I’ll let you know in a couple of months. (BTW, they’re FREE from http://www.iam.unibe.ch/~ducasse/FreeBooks.html )


I’m having fun! I’m starting to get into it, actually moving away from television!

Sunday, October 01, 2006

An Inspirational Story

From another blog...


David Buck's Story


I started programming in 1978 on my own home-brewed computer. I evolved from machine language through to assembler, BASIC, and Pascal and C when I started my university degree at Carleton University. I remember the BYTE magazine article in 1981 and the idea of Smalltalk intrigued me.

In 1984, Carleton University received Smalltalk-80 on tape and they installed it on a Sun workstation. Unfortunately, the Sun only had 1 Meg of memory and it needed 2 Megs for Smalltalk, so for the first little while the system was horribly slow.

After the memory upgrade, I decided to do a Smalltalk project in Artificial Intelligence for the AI course taught by Wilf Lalonde. I managed to write a natural language parser that could read sentences and tell where the main verb was, what words were nouns, etc. It worked quite well.

After I finished my bachelor's degree, I obtained the source code for the Smalltalk virtual machine and ported it to the Amiga so I could use it at home. It was quite a blast having Smalltalk on my home computer.

I did a Master's thesis in Smalltalk (again under Wilf Lalonde) writing a 3D graphics renderer for B-Spline surfaces and a physically-based modeling package for it. This work is now evolving into a commercial product called ElastoLab. ElastoLab has a VisualWorks UI and a C++ physics engine.

I've been working full-time in Smalltalk since 1993 consulting to various companies and helping them on their projects. People tell me that Smalltalk is dying, but I'm seeing a resurgence. I'll stick it out. I can't give up on the world's most productive and expressive language. I love Smalltalk and I plan to continue using it.


Yes, I love Smalltalk too and I plan to wholly dedicate myself to this wonderful tool.

In Praise of Smalltalk

From a blog...

C# or Java?
Over the last few years at work I've been coding in ASP/Javascript, then C#, and eventually Java. The previous year I was using Websphere/Java, but I switched departments recently and am now back to coding in Visual Studio/C#. I'm not overly partisan regarding either platform. I really don't feel a strong preference for one over the other.

Java has an immense library, and some good free IDEs, with my favorite (at home) IDE being Eclipse with the MyEclipseIDE add-on. (MyEclipse conveniently packages tons of great additional functionality for Eclipse. You could hunt down and install most of what they provide for free, but if nothing else they save you a lot of effort.)

But, I also enjoy working with C#. Visual Studio is very easy to develop in, and, like Java, there's an abundance of support and resources available for either one.

Since my focus is going to be graphics and game creation, I considered C++ too, but didn't want to worry about pointers, garbage collection, etc. etc.. That just doesn't sound appealing. They may not match C++ for speed, but I'm not looking to create the next Half-Life 2 or Doom 3, so I don't think that'll matter.

But, thinking about that reminded me of one of my key goals: not to necessarily pick the most 'efficient', the 'best' language, but to pick something that I would find fun to code in. I won't pretend that my decision is in any way based on careful research or a well-reasoned consideration of all various factors. It's going to be very subjective.

So, time to actually decide...



And the language of choice is....Smalltalk!
When we're going out to a restaurant, Russ is amused by my inability to decide exactly what I'll order until the waiter is hovering over us. Sometimes, after having been saying I'll order either A or B, B or A, I'll blurt out a third thing at the last minute. I just did it again: "Let's see, C# or Java? Which one......oh, how about Smalltalk!" Okay, it wasn't quite that impromptu, but it definitely was a come-from-behind decision to pick Smalltalk.

I know most people would find that decision downright ridiculous, but there's a (form of) reasoning behind my madness. I've always found Smalltalk interesting from the perspective of language development history, and had dabbled in various free versions of it over the last few years. (Squeak and Cincom VisualWorks in particular). While I wasn't initially blown away by it (for reasons I'll detail in some later post) I was intrigued.

As I mentioned in a previous post, having fun and enjoying the development process itself was of key importance. In thinking about this I remembered one of the best times I ever had: writing in Forth on my Commodore 64 back in the mid-eighties. What really appealed to me about it was the way code was naturally segregated into smaller parts, and you could incrementally build up your functionality and slowly let it 'grow' one piece at a time. (One could object that this is true of any language, but some facilitate this more than others...) Similarly, Smalltalk provides a very interactive experience that lets you fluidly move between design, coding, and testing. It's also rigorously object-oriented (some may say to the detriment of the language, but I love it), and I enjoy using a Class Hierarchy Browser for not only reference but as a place to code in. It makes looking up information feel like a smoothly integral part of the development process rather than an interruption to my coding while I hunt for what I need to know.

So, a major theme of this blog will be about my experiences and such as I go about developing a small game in Smalltalk. There are some wonderful sites with lots of information on Smalltalk, especially insofar as the language itself. BUT, there's not a whole lot of information out there (at least easily available) on developing games in Smalltalk, so I'm hoping to pass along whatever interesting/helpful info bits I find or discover as I do this. At the time of this post, my sidebar links are a miscellaneous mix of stuff, but over time I'll put a separate section of smalltalk-related links that I find especially helpful or interesting.

Next up: I'll review the various Smalltalk implementations, and make a choice for which one to concentrate on for my initial efforts.


This fellow shares my sentiments about Smalltalk. It's about having fun and exploring a delightfully different way to develop software.