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
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 #someMessage:and: 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
On Fri, Apr 4, 2014 at 6:41 PM, Ben Coman <btc@openinworld.com> wrote:
For assignment, I would say bold both := and the variable being assigned to.
I like that a lot, especially since it draws the two critical elements of variable and assignment together. On a minor note, both := and = are currently the same color: black. That only furthers the ":= is a message" misconception. It might be worthwhile also giving := its own color, given its uniqueness.
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 #someMessage:and: c. dynamically underline only message where cursor is located.
I think you could do nested underlining in the same way that nested blocks and parentheses work. someMessage: and the second and: are underlined in black. otherMessage: and the first and: are underlined in green. That way nesting is clear. This would also be useful for code with nested conditionals, probably the most common occurrence of nested multi-part messages. I also like (c) as a minimally intrusive change that could help novices when they write code. It has the disadvantage that novices couldn't look at a piece of foreign code and get where the multi-part messages were. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
I fail to see confusion as a bad thing though. For me confusion is part of the learning process. Being successful at something is about developing the skills for it and that takes time and practice. I am no beginner or pro coder but frankly I am glad that assignment is := and comparison is =. Cant stress enough how many times I made the stupid mistake in python (the language I have most coding experience with) doing a if a=1 instead of if a==1 and its a bug that is painful to spot . Maybe I am smalltalker by birth :D but for my brain comparison is =. And though I had many arguments with my brain about it, he does not seem to want to change its mind about it. Frankly I dont think seeing that = in different color would make much of difference at least for my mistakes. But definitely would not hurt either. About command completion cant stress enough how crucial is for people like me with very bad memory. I keep forgetting names of people that have met recently, method names and class names have no chance of being remembered , when I have to deal with hundreds and thousands of them. I would love if my brain had some kind of autocompletion but it looks like my brain still runs on Windoom. Again with messages sends and multiple arguments , I love the mandatory keyword argument about Smalltalk again for someone like myself with real bad memory is just a ton of help. I just dont want to go back to unnamed arguments. Again code completion helps here. Anyway I know this is a single opinion but I am still a beginner smalltalker though not a beginner coder. Because there is like a ton of people that out there try to identify what went so bad with Smalltalk and never become truly popular , my opinion is that it has nothing to do with the language. The language is brilliantly simple and straight forward, I wish I could say the same about the libraries. Its the libraries I struggle the most when I play with pharo. At time I am afraid to look at the next method because I feel it will be the portal to spaghetti hell. I cant think a bigger nightmare for a newcomer especially when there is lack of documentation. For me thats the true dark side of Pharo. But again just an opinion. On Fri, Apr 4, 2014 at 8:26 PM, J.F. Rick <self@je77.com> wrote:
On Fri, Apr 4, 2014 at 6:41 PM, Ben Coman <btc@openinworld.com> wrote:
For assignment, I would say bold both := and the variable being assigned to.
I like that a lot, especially since it draws the two critical elements of variable and assignment together. On a minor note, both := and = are currently the same color: black. That only furthers the ":= is a message" misconception. It might be worthwhile also giving := its own color, given its uniqueness.
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 #someMessage:and: c. dynamically underline only message where cursor is located.
I think you could do nested underlining in the same way that nested blocks and parentheses work. someMessage: and the second and: are underlined in black. otherMessage: and the first and: are underlined in green. That way nesting is clear. This would also be useful for code with nested conditionals, probably the most common occurrence of nested multi-part messages. I also like (c) as a minimally intrusive change that could help novices when they write code. It has the disadvantage that novices couldn't look at a piece of foreign code and get where the multi-part messages were.
Cheers,
Jeff
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
On 04 Apr 2014, at 19:26, J.F. Rick <self@je77.com> wrote:
On Fri, Apr 4, 2014 at 6:41 PM, Ben Coman <btc@openinworld.com> wrote: For assignment, I would say bold both := and the variable being assigned to.
I like that a lot, especially since it draws the two critical elements of variable and assignment together. On a minor note, both := and = are currently the same color: black. That only furthers the ":= is a message" misconception. It might be worthwhile also giving := its own color, given its uniqueness.
yes this would be nice. And a fix for that. Did you also see that what I like is to make a distinction between a possible selector and a wrong one? because this is nice.
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 #someMessage:and: c. dynamically underline only message where cursor is located.
I think you could do nested underlining in the same way that nested blocks and parentheses work. someMessage: and the second and: are underlined in black. otherMessage: and the first and: are underlined in green. That way nesting is clear. This would also be useful for code with nested conditionals, probably the most common occurrence of nested multi-part messages. I also like (c) as a minimally intrusive change that could help novices when they write code. It has the disadvantage that novices couldn't look at a piece of foreign code and get where the multi-part messages were.
Cheers,
Jeff
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
On Fri, Apr 4, 2014 at 8:28 PM, Pharo4Stef <pharo4Stef@free.fr> wrote:
Did you also see that what I like is to make a distinction between a possible selector and a wrong one? because this is nice.
Yes, that is nice. My guess is that for beginning programmers (rather than programmers new to Pharo), it might be nice to prioritize certain messages or even limit the messages to a subset initially, especially in a Microworld environment. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
If we had a way to scope inside that micro-world subset, then we could simply use the scoping for that (and have syntax highlighting matching the scope of the browser showing the code). Then, once the user is deep enough, then he could be told how to reach the full scope. Or we let him find by himself, Hypercard-like :) Thierry ________________________________ De : Pharo-dev [pharo-dev-bounces@lists.pharo.org] de la part de J.F. Rick [self@je77.com] Envoyé : lundi 7 avril 2014 16:30 à : Pharo Development List Objet : Re: [Pharo-dev] Suggested Syntax Highlighting Features for Beginners On Fri, Apr 4, 2014 at 8:28 PM, Pharo4Stef <pharo4Stef@free.fr<mailto:pharo4Stef@free.fr>> wrote: Did you also see that what I like is to make a distinction between a possible selector and a wrong one? because this is nice. Yes, that is nice. My guess is that for beginning programmers (rather than programmers new to Pharo), it might be nice to prioritize certain messages or even limit the messages to a subset initially, especially in a Microworld environment. Cheers, Jeff -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
I went ahead and created two cases in FogBugz for the respective issues: https://pharo.fogbugz.com/f/cases/13186/Syntax-Highlighting-Distinguish-Assi... https://pharo.fogbugz.com/f/cases/13187/Syntax-Highlighting-Messages-with-2-... That way this issue won't be completely forgotten. On Fri, Apr 4, 2014 at 7:26 PM, J.F. Rick <self@je77.com> wrote:
On Fri, Apr 4, 2014 at 6:41 PM, Ben Coman <btc@openinworld.com> wrote:
For assignment, I would say bold both := and the variable being assigned to.
I like that a lot, especially since it draws the two critical elements of variable and assignment together. On a minor note, both := and = are currently the same color: black. That only furthers the ":= is a message" misconception. It might be worthwhile also giving := its own color, given its uniqueness.
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 #someMessage:and: c. dynamically underline only message where cursor is located.
I think you could do nested underlining in the same way that nested blocks and parentheses work. someMessage: and the second and: are underlined in black. otherMessage: and the first and: are underlined in green. That way nesting is clear. This would also be useful for code with nested conditionals, probably the most common occurrence of nested multi-part messages. I also like (c) as a minimally intrusive change that could help novices when they write code. It has the disadvantage that novices couldn't look at a piece of foreign code and get where the multi-part messages were.
Cheers,
Jeff
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick
participants (5)
-
Ben Coman -
GOUBIER Thierry -
J.F. Rick -
kilon alios -
Pharo4Stef