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.
