Hi guys - I���ve been hammering on the exercism project to get pharo shining over there��� its been a good side distraction (there is lots of energy in that community to) and its made me really push my use of Iceberg & git as well as learn some fo the newish file reference stuff (still getting good at that - but like the approach),

Anyway - I���ve got an Alpha working, and users can pull down a zero conf pharo image and eval a little script that will get them up and running (which is pretty slick).

So the story then goes - Exercism is trying to simulate TDD and help you learn a new language (aka Pharo or Go or Python etc). To this end, they���ve got an active community building up little test exercises with suites of tests that new users can run to help them learn the syntax/essence of the language track they���ve signed up to. You run the tests, develop your solution and then submit it to a community to get feedback and then progress.

Pretty standard - we can play in this pond too - and it turns out that Tonel actually makes it pretty easy to submit readable solutions that will fit on their website. YAY.

The trouble is - when you pull down a new exercise - I use the TonelReader to pull the code into your image - and I thought it would be cute to just pull in the TestCase so that users can simulate the full TDD cycle - where you can create things in the debugger��� this is where it all began right?

So you hit a clanger when you do this - and in a way its a bit of a legacy thing we���ve carried around (and possibly should fix better). When Tonel reads in the TesCase, it normally will reference a class this isn���t there (I���ve deliberately left the solution out). It does the right thing and put a nil placeholder in the code so that it can read it in.

HOWEVER - when you run your test and hit that nil class placeholder we do a very bad job of dealing with this in the debugger. And if you think about it - we also do a bad job when typing in code too - we essentially insist that declare a class then and there - unlike a selector which can happily be late bound.

So back to my TDD example - user gets a debugger with a nil class error - the create button is actually not helpful for you as it only creates methods. So our ���live in the debugger��� mantra is a bit less obvious here. What you had to do is make a change to the source (like a space) so that you can reserve the method - which then causes you to get the ���create class prompt���. So we have the ability - just don���t expose it very well - however now you have a missing method - but again its not so obvious that you have to resume your debugger (it hasn���t resumed when you created the class) - and then you will get another error for the missing method that the create button will now resolve.

This feels very clunky to me - and makes me feel like I���m mis-selling smalltalk where we have a bullet point about ���Amazing for debugging������.

This feels fixable though right? I���m wondering about thoughts though before jumping in���

Tim

p.s. - we���re building some exercises for exercism and getting that process streamlined so hopefully many more people can help - and maybe we can augment the great learning courses/videos/books that we already have.