Edit Rename Upload Download Back to Top

new code syntax

It is often argued that Smalltalk syntax is much easier to learn than 'curly brackets' languages like Java, C and C++, if you come to it fresh; that the appearance of difficulty some programmers complain of is strictly an artefact of their being 'corrupted' by programming languages that have an ill-chosen 'nerdy' syntax. Those curly-bracket programmers who have difficulty with Smalltalk syntax when they first see it sometimes aren't eager to accept this argument. The following is an attempt to put it in the easy-to-understand form of a little story.

Our story concerns an experienced programmer, Bob, and newbie, Alice. Bob has spent years in C and C++ and currently writes Java. Alice is a former admin person who wants to transfer to programming; she's had OO explained to her at a high-level but has no experience with any programming language.

(For the purposes of my story, Bob is a bit of a nerd. I do not imply that all Java programmers are down at his level. However I could quote posts from comp.lang.java.advocacy / comp.lang.smalltalk.advocacy cross-threads to prove that some are.)

Their boss, Jennifer, decides to send Alice and Bob on a one-day Smalltalk-reading course (so they can study and reuse ideas from a Smalltalk goodie that has impressed her and is relevant to their business). She sends Bob the following memo, copied to Alice.

    Memo
	to: Bob
	from: Jennifer
	re: Smalltalk course.

    Bob,
	please attend this course;
	bring Alice.

Bob sees it's a memo, knows memos are written in English, so his mind uses its English-reading lexical analyser to read it, and has no problems understanding it perfectly. The first sentence is the standard memo header for Bob�s firm with the 'to', 'from' and 're' parameters filled in, and ending, like all English sentences, with a full-stop ('full-stop' = 'period' for American readers). The second sentence contains two clauses separated by a semi-colon, not a full-stop, because they share grammatical elements (in this case, they share the same subject, i.e. 'Bob'), and ends with full-stop; no problems, there. (Alice also has no difficulty understanding the memo.)

Once they are seated in the course, it's a different story. Bob knows this is a course on programming so his mind loads its code-reading lexical analyser and this puts its English-reading lexical analyser out of scope whenever the instructor shows a line of code, even though it comes instantly back into scope to read English explanatory text above and below said code lines. Thus Bob finds it hard to parse.

	Memo to: bob from: jennifer re: smalltalkCourse.

though he would instantly understand its Java equivalent

	new Memo(bob,jennifer,smalltalk_course);

The Smalltalk uses white space to separate the words in the expression, just as English does, whereas Bob knows that programming languages use punctuation to separate words in an expression. Worse, what is that dot at the end of the line doing? Bob knows that dots connect words in expressions; he's looking for a connection to stuff on the next line and wondering why it's formatted in that funny way. As for the colons, it's like no use of a colon in any language he knows. Alice by contrast, finds it easy to map this syntax onto the high-level, 'an object is sent a method with parameter values', OO overview she was given because it is so like English syntax.

The next line is even worse for Bob.

    bob
	attend: course;
	bring: alice.

has him baffled. The semi-colon looks like an end of statement to him, preventing him from parsing the final method. Abetting his confusion is the fact that there is no equivalent one-statement Java construct. In Java, it would have to be two statements:

    bob.attend(course);
    bob.bring(alice);

Alice, by contrast, can understand the Smalltalk easily and would find the Java harder.

As the morning goes on, one of two things happens to Bob.

1) A sudden, 'Aha!', process in his mind may let him realise that if he kept his English-reading lexical analyser in scope while reading the code then he'd get on a lot better. He can still use some of his code-reading lexical analyser but he musn't let the latter block the former. (Plus, of course, he can use all his OO knowledge. He just has to abstract it a little from the code syntax assumptions it was previously identified with in his mind and attach it instead to English-syntax assumptions he well knows.)

2) However if Bob has that combination of arrogance and fear of looking stupid that adds up to one meaning of the word 'nerd' then his annoyance may block this 'Aha!' from ever happening. In that case, by lunchtime, he's telling everyone that Smalltalk is a really stupid language and he can't think what Alice sees in it; maybe she should give up her plan to switch from admin to programmer if she can't see that it's just silly. Since Bob is the experienced programmer and Alice is not, Jennifer may listen to him. And if understanding how the goodie written in Smalltalk does its stuff was an important opportunity for the company, then it will be lost.

(Some other points about the logic behind Smalltalk syntax are described here. I find them useful in mastering and remembering it. The rest of the notation used in the examples on the following pages is briefly summarised here.)

Another source of unhappiness for Bob about Smalltalk syntax is the way it handles control flow.


Bob's ability to accept Smalltalk syntax may also be indirectly hampered by the fact that he may simultaneously be feeling uneasy about:

(Written by Niall Ross as part of Smalltalk for Java Programmers.)


Edit Rename Upload Download Back to Top