[Pharo-dev] Suggested Syntax Highlighting Features for Beginners

Ben Coman btc at openInWorld.com
Fri Apr 4 12:41:25 EDT 2014

J.F. Rick wrote:
> Smalltalk is a pretty great language, but its syntax is unusual. I've 
> taught introductory programming in Pharo three times and, in my 
> experience, there are two places where novices get repeatedly confused 
> with syntax.
> First, there is the differences between assignment := and comparison = 
> . Obviously, Smalltalk is not the only language where that is a 
> problem. Java is even more confusing, with assignment = and comparison 
> == . In Squeak, there was the attempt to address this problem head on 
> with using _ instead of := and having it show up as an arrow pointing 
> left; while that nicely addressed that problem, it proved awkward for 
> many reasons (e.g., it only appeared as an arrow in Squeak, it wasn't 
> compatible with other Smalltalks). In addition, comparison is a simple 
> message send, where assignment is the most critical language element 
> that is not an object or a message. In other words, there is a huge 
> difference in meaning between the two and a really minor syntactical 
> one. That's confusing to novices. Even after covering it repeatedly in 
> class I still find novices making that mistake. As their debugging 
> skills are minimal, this can be a real obstacle.
> Second, there is the problem of keyword messages with more than one 
> argument. In Java, "this.someMessage( arg1, arg2)" is pretty 
> comprehensible to a novice. In Smalltalk, "self someMessage: arg1 and: 
> arg2" seems like two message sends (i.e., 
> "this.someMessage(arg1).and(arg2)"). While novices won't see 
> multi-argument messages very often, they do come up (e.g., 
> ifTrue:ifFalse:). I have my class do regular quizzes on identifying 
> messages and this still tricks them up even if they've already seen in 
> 10 times.
> Now, I'm not advocating changing the Smalltalk syntax; that's just 
> unlikely to happen. But, perhaps syntax highlighting could be employed 
> to good use. For instance, it is extremely helpful that blocks and 
> parentheses show by color which ( [ go with which ] ). Perhaps 
> something similar could be done for messages with more than 1 
> argument. For instance, the message could be underlined in different 
> colors. That way I could easily see which ifFalse: went with which 
> ifTrue:. It would also give a visual indicator: (for novices) Be 
> careful, this message is one of those weird ones that's longer than it 
> first appears. For assignment vs comparison, you similarly need a 
> powerful visual cue that assignment is an usual thing, where 
> comparison is a pretty ordinary thing. Perhaps an arrow decoration 
> could appear behind the :=.
> These may seem like trivial issues. For experts, they are. I don't 
> need any of it. I don't find syntax highlighting and command 
> completion that useful in my programming. But, I'm proficient with a 
> debugger. Should I occasionally make such a trivial mistake (e.g., 
> forgetting to type : in :=), I immediately find it while debugging and 
> easily fix it. For novices, using a debugger is not an option. 
> Remember, they don't understand what a stack is. Syntax highlighting 
> is the best debugging feature that they understand. And these are two 
> real common mistakes that they make that could be addressed by 
> improvements to syntax highlighting.
> Just a suggestion,
> Jeff
> -- 
> Jochen "Jeff" Rick, Ph.D.
> http://www.je77.com/
> Skype ID: jochenrick

For assignment, I would say bold both := and the variable being assigned to.
Underlining sounds interesting, but there are a few choices:
a. nested underlining - self someMessage: (self otherMessage: arg 1 and: 
arg2) and: arg3
b. non-nested underlining - only underline #otherMessage:and: and not 
c. dynamically underline only message where cursor is located.

I prefer (c.).  This would be least annoying to the experts, and maybe 
not even need a Preference.  Students don't have it as a continual 
crutch - but they can easily check whenever needed with a tight feedback 
loop most productive for learning.

cheers, Ben

More information about the Pharo-dev mailing list