[ | smalltalk dot org ].
Community and industry meet inventing the future.
Simplicity Makes the Difference that Makes the Difference
written by Peter William Lount
Revision 2, 20040917 10:22am
Version 1, 20040917 2:53am

Shane King wrote:
Different kinds of complexity
[Shane King] September 14, 2004 21:13:17 EDT

While I'd agree with you that the average perl code has more lexical complexity than the average smalltalk code, I'd guess the average smalltalk code has more conceptual complexity than the average perl code.

I think lexical complexity is easier on most people than conceptual complexity. With perl, sure there's a lot to learn, but it's all pretty simple, and can be learnt by memorisation. On the other hand, while there's not as much to learn syntax wise with smalltalk, there are a number of higher level concepts you wont encounter much (if at all) in most perl code.

It's a double edged sword - higher level concepts are what makes a programming language more productive for experts, but they're also what intimidates newcomers.

It seems to me that the regular expressions of PERL have a lot of conceptual complexity that can be packed into a tiny space due to PERL's lexical complexity. Not many people will master the ins and outs of all the possible regular expression options offered. PERL has a long history of providing usefull and effective tools in the UNIX command line and web common gateway interface (cgi) contexts. It is evident that the UNIX community has fostered the development of the complexity in both PERL's lexical nature and it's conceptual capabilities. This falls in line with a "cryptic" attitude of many within the UNIX community. PERL works. It gets lots of different jobs done with elegance derived from it's design. It's also a "hack" and it's authors have recognized that it's time for a rewrite and architectural redesign from the inside out with PERL6. A general clean up and rebirth of a new syntax while supporting the older syntax of PERL5. In fact by slicing the lower levels of the PERL system off into the Parrot register based virtual machine project the new PERL will have parsers that can read PERL5 and PERL6 as well as other languages such as Phython. PHP has recently undergone a similar transformation with PHP 5.

Who knows maybe one of you reading this will spin out a version of Squeak Smalltalk by rewriting Squeak's virtual machine generator to emit parrot assembly language instructions instead of C language instructions?

The point of comparing PERL with Smalltalk is to highight the differences so that we may learn how and why the languages are designed the way they are and operate the way they do. Both languages have a rich and successful history of providing solutions.

Does PERL have a more complex lexical syntax? I think that everyone can agree that, yes, PERL's grammar is much more complex from a lexical point of view and learning standpoint than Smalltalk's grammar.

Is PERL less complex conceptually? I think it's clear that PERL has some very deep conceptual ideas that it addresses with, in some cases, a compact syntax. Does PERL have all the conceptual ideas that Smalltalk systems have? No. PERL's object nature doesn't have all the capabilities of Smalltalk by any stretch of the imagination, yet PERL has it's uses where it's an excellent choice for a tool.

The so called "conceptual complexity" of Smalltalk seems to really be learning "object oriented programming" in a "pure object" and "fully dynamic" context. While PERL and Smalltalk are both (open) dynamic languages (and there are open source versions of both available) Smalltalk systems take the dynamic and object concepts further.

The big concept of Smalltalk is message passing bewteen objects. This isn't the way that computation occurs in the vast majority of computer langauges, even many of the ones that claim some object oriented heritage.
Dan Ingall's Design Principles of Smalltalk
  • Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.
  • Good Design: A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework.
  • Purpose of Language: To provide a framework for communication.
  • Scope: The design of a language for using computers must deal with internal models, external media, and the interaction between these in both the human and the computer.
  • Objects: A computer language should support the concept of "object" and provide a uniform means for referring to the objects in its universe.
  • Storage Management: To be truly "object-oriented", a computer system must provide automatic storage management.
  • Messages: Computing should be viewed as an intrinsic capability of objects that can be uniformly invoked by sending messages.
  • Uniform Metaphor: A language should be designed around a powerful metaphor that can be uniformly applied in all areas.
  • Modularity: No component in a complex system should depend on the internal details of any other component.
  • Classification: A language must provide a means for classifying similar objects, and for adding new classes of objects on equal footing with the kernel classes of the system.
  • Polymorphism: A program should specify only the behavior of objects, not their representation.
  • Factoring: Each independent component in a system would appear in only one place.
  • Virtual Machine: A virtual machine specification establishes a framework for the application of technology.
  • Reactive Principle: Every component accessible to the user should be able to present itself in a meaningful way for observation and manipulation. [First class meta programming capabiliites.]
  • Operating System: An operating system is a collection of things that don't fit into a language. There shouldn't be one.
  • Natural Selection: Languages and systems that are of sound design will persist, to be supplanted only by better ones.
When one takes a look at the Design Principles Behind Smalltalk as expressed by one of the main designers of the language, Dan Ingalls (who happens to have come up with Smalltalk-80's keyword syntax), one can see that many of these principles still hold today, over twenty three years later. A testiment to Smalltalk enduring the tests of time by rolling and adapting with the punches.
While only a few operating systems (OSes) have been written in Smalltalk and the vast majority of OSes are written in a C based language variant the rest of these principles are key "concepts" to understand when approaching Smalltalk for the first time.

In the same set of comments as Shane King's above, Vincent Foley and Isaac Gouy make the following point:
Vincent: "Why does it even matter... to a neophyte?"
It doesn't - that's the point.
It doesn't matter that "Smalltalk has 5 reserved words... and 2 operators" - all it means is that the basics they need to learn are in the libraries rather than in the language syntax.

I have to agree that to a neophyte or even someone with intermediate level Smalltalk experience and skills the fact that the language object library (rather than the lexical grammar) implements control and looping structures such as "ifTrue:, ifFalse:, ifNil:, ifNotNil:, whileTrue:, until:, to:do:, do:, etc..." makes little difference. The reason that this is so is that the vast majority of times one is simply using these control and looping structures.

I must say that when I was learning Smalltalk it was very interesting to see the source code for much of the Smalltalk system itself was available for me to browse. While at times it was overwhelming to understand all the code that could be browsed it's clear that seeing the code for operations such as "do:" or the other control and looping strucutures was going to be of major benefit, and it was. In many ways Smalltalk has been open sourced right from the beginning (although most commercial implementations keep the virtual machine closed) and that this has enabled developers and users to actually make use of the source code. Most users and developers using a system never even look at the source code (Red Hat reports that 90% of downloads don't include source code)! With Smalltalk it's all there at your figner tips, and more of it's there and adaptable since less of it is burried in the syntax and more of it is sitting in the class library where it can easliy be read and modified by novices and experts alike as they see fit. It also is easier to adapt since the changes usually take place instantly - no waiting for a build cycle to complete. While the typical person learning Smalltalk likely won't go and change system methods and objects they tend to browse through the code out of curiosity.

A significant difference and benefits begin to show up very soon with the fact that most "meta programming" capabiliites are dynamically implemented in the language object library. How so? The creation (or construction) of object instances is carried out in exactly the same way as any other object message send. There is a message, usually "new" or some variant (that you write and name appropriately) that optionally has parameters. The receiver of the message is an instnace of a Class object that represents and defines the class of object that you are wishing to instantiate. The fact that these classes are fully first class objects means that they are like anyother object in the system and that you can use them in the same ways. While a novice user simply uses and might implement "instance creation" or "constructor" methods on their classes and thus take advantage of this "dynamic first class meta programming" capability the novice isn't likely to dig deeper unless their application domain demands it. When they do they do in fact graduate into intermediate concepts of meta programming flxibility. In which case they'll find that the object messaging model of meta progamming in Smalltalk is the same thus simpilfying their journey so they can concentrate on learning the objects involved rather than any new syntax grammar.

If one has never been exposed to these concepts before they might have a learning curve and thus it might seem difficult to "learn Smalltalk" but in fact what's difficult is learning the concepts not learning Smalltalk. Many people with experience of other systems that have similar capabilities often pick up Smalltalk faster simply due to the fact that they already understand the underlying "pure object concepts". With the wide spread adoption of "object technology" in the past decade this sort of myth simply doesn't hold water. No doubt that learning Smalltalk may involve a new and unfamilar approach to software development for some who've never been introduced to the interactive development tools, for most it's a non issue and they pick up the Smalltalk technology rapidly.

Smalltalk's langauge syntax is in part based upon "keyword" and "parameter" pairs delimited by a colon character, ":", for "setting" or "passing" a paramter to an object one writes the keyword as "x: 100" or "name: 'tom'" for keywords with single parameters, and "x: 100 y: 699" for multiple keywords and multiple paramters. When "getting" a parameter value from an object one simply uses a keyword without the parameter (and colon).

This keyword syntax has been in use in the computer industry for decades before Smalltalk adopted it. I suspect that it's been used much longer in paper and pen format using natural language for a very long time before that. To say it isn't "natural" is simply to say that some isn't used to it, that's all. Once you've see it used a few times it actually is easy to read. Couple the keywords with the "clear" language syntax grammar and you have a very readable and "literate programming" language indeed.

The meaning of the "keyword" messages is dependent upon what the "method" or "message" does in side the object once it's been received by the object. To have a clear and precise mapping between these meanings it's important to name the messages with care, attention, consistency and approriateness. As in much of life the names that we give things makes a huge difference. This is true in a "keyword" and "named object" language and environment such as Smalltalk or in any system with a "naming space". With the careful naming of keyword mesasges it's possible to build programs that are closer to linguistic "prose" than "cryptic code".

This brings us back to the UNIX cultural concept that it's ok, and in hacker culture that it's desireable, to name things with "cryptic codes", "short cuts", and other "geekisms" of one sort or another. By adapting the language of the application domain into the keywords, objects, variables and name spaces within a Smalltalk program a "literate program" can be constructed. In fact the Smalltalk culture encourage full and meainingful names and the tools help in a number of ways to support programmers.

Smalltalk isn't perfect as implmented in the twenty plus versions that are currently listed on this site. Smalltalk isn't standing still, how could it when it has exceptional built in extensibility capabilites? Smalltalk is not only evolving it's evolving to fill many different market niches where it can provide solutions that are cost effective to implment and operate (in terms of dollars and resource utilization). In recent years there has been an explosion in both the quality and quantity of the Smalltalk systems available. A few of the commercial Smalltalk systems offer powerful suites of capabilities that have been successfully used to build very powerful ecconomic and competitive advantages for a number of the worlds leading corporations.

It's about personal mastery. In today's world programmers need to be "polyglots", or speakers, readers, and writers of many computer languages. As such it's important for professional programmers to stay competitive and knowing Smalltalk is important simply for the perspective that it provides one with. As Alan Kay is fond of saying "a new (or different) point of view is worth 80 IQ points". If all you know are the curley brace, "{ }", langauges such as C, C++, Java, C#, etc... then you are severly limiting your knowledge and capabilities by not taking advantage of the technological know how and possibilities offered by Smalltalk's unique approach to "pure object technology". Gain your competitive advantage and learn Smalltalk today.

Why am I studying PERL? I've had need to use it due to the "interoperatable" nature of today's projects. In addition the Smalltalk.org servers and many of my clients servers run various UNIX systems (FreeBSD, Linux, OpenBSD, etc...) where there are many PERL scripts (or programs). Interoperation is the name of the game in many corporate and inter-corporate environments today. In addition I'm learning PERL to ensure that the version and variant of Smalltalk that I'm authoring, the Zoku Langauge and Zoku Smalltalk, has ALL the important capabilities and advantages of PERL while attempting to reduce the "complexity" to managable and easily understandable levels. Whether or not the Zoku object syntax and objects will achieve this is left for you and time to tell.

When a company such as JPMorgan builds one of it's most important risk management systems, known as "Das Kapital", using Smalltalk ( a version of CinCom's VisualWorks Smalltalk), it seems to me that, one must take note of the fact and ask what is the advantage they gained with it that is providing the technicial leverage enabling them to generate billions of dollars of revenues with it? When an software company builds a software system tailored to the insurange industry that enables them to make significant profits year after year while remaining small how did they do it? What did Smalltalk give them? When a small construction industry comapany builds it's internal software tools using Smalltalk why did they do it and how did their system give them a major competitive advantage over the years especially when business was slow? The competitive ecconomic advantage to these companies strategic use of Smalltalk is real and significant. Many companies that are using Smalltalk do not what their competitors knowing that they are using Smalltalk. In the art of business, as in the art of war, taking advantage of every strategic capability and keeing it secret can be of significant import. While the magnitude of their financial successes vary it's clear that the "dynamic" nature of Smalltalk systems has an advantage that you can't ignore if you wish to be on the path to serious success and wealth in your career. There's no guarantee that you'll succeed, there never is in business, but why increase the risks of failure by using non-dynamic, non-pure object, non-Smalltalk systems?

In your path to success will you really let a few concepts stop you from your goals? The fact is that how fast you learn Smalltalk (or PERL for that matter) is more dependent upon you and your frame of mind, knowledge and past experience than any complexity inherent in Smalltalk. Large class libraries are going to be overwhelming no matter what language they are written in. Certainly JPMorgan's Das Kapital class library is complex, but that's because they are modeling a complex domain - financial deriviatives, risk management and other financial systems. At least large class libraries are approachable in Smalltalk using the class browser, Integrated Development Environment (IDE) tools, and significanly the "literate self documenting nature" of Smalltalk's keyword mesasge syntax. Take advantage of every possible leverage you can gain and move foward your success!

Simplicty matters, take advantage of it by producing the competitive advantage for your projects, business and career!

Copyright 1999-2010 by Smalltalk.org"!, All Rights Reserved.