+1 On Tue, 7 Aug 2018 at 09:02 Tim Mackinnon <[email protected]> wrote:
> 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. > > > > -- Sent from the past
