April 24, 2019
4:56 p.m.
Thanks all. Because of all the differences of oponion here what Object Oriented is and im still very stuck at some exercises of exercism , I have to decide to quit smalltalk. One says to not use classes , the other says use classes. im more and more confused. Maybe later I come back when I have a beter understanding what Object Oriented is and how I can use it to solve more difficult problems. Roelof Op 24-4-2019 om 18:07 schreef Ben Coman: > On Wed, 24 Apr 2019 at 16:52, Richard O'Keefe <raoknz@gmail.com> wrote: >> The one method needed to solve the problem is 18 lines. >> The test code, including all available test cases, is 27 >> lines, of which 18 lines is the test data. Tests were >> needed primarily to sort out what the problem actually *was*; >> exercism doesn't even try to provide good specifications. >> No debugging time at all was needed, precisely because the >> code was so simple and obvious. > But we do want to showcase our debugger and demonstrate how to get the > most out of it. > The way the exercises are structured is to sequentially enable one > test at a time, see how that fails and fix it, so students will be > regularly interacting with debugger. > > >> If it *had* been needed, >> viewing the result right next to the expression that yielded >> it would have given me all the context I needed, in one window. >> >> If you want to learn how to design a good set of classes, >> this is an absolutely dreadful problem. In fact ALL of the >> exercism problems are going to be dreadful for *that* >> purpose because they are provided for languages that do not >> *have* classes. > Yes, we noticed that. > Do you have any problems more suited to class creation that we might > contribute to the Exercism problem specifications? > > >> If you want to learn how to *solve problems*, >> then you need to learn to write code that is simple, clear, >> testable, and so on. You certainly need to learn how to use >> what is already there in the language (except where that is >> expressly forbidden). > My understanding of the Exercism's purpose is: > * not to teach how to solve programming problems; but > * to facilitate existing programmers to develop fluency in new > languages (although that doesn't preclude complete beginners using > it). > [ref: search "fluency" at > https://opensource.com/article/17/1/interview-katrina-owen-founder-exercism] > > >> I completely agree that designing a good set of classes is >> a very very important skill for anyone who wants to do OOP. >> I completely agree that practising this on problems you can >> hold in your head is a good idea. >> I completely agree that if *that* is your objective, >> writing minimalist code is not the best strategy. >> On Wed, 24 Apr 2019 at 16:59, Richard O'Keefe <raoknz@gmail.com> wrote: >>> TL;DR version: >>> "But if the purpose of problems is to lead students in new ways of >>> thinking about structuring OO solutions for maintainability" >>> It would be very good >>> if somebody did craft such a set of exercises, and Pharo would be a very >>> good environment for them. The exercism exercises will not do. > If the existing set of exercises is not great for this, hopefully we > can produce some to demonstrate Pharo's facility for it. > > >> The problem with exercism is that while it does have a >> criterion by which you can tell whether you have *solved the >> problem*, it provides *no* way to assess your class design. >> You don't get told "this is good, that is bloated"; there is >> no feedback about the *quality* of your code except via >> comments from those few people who can be bothered to look >> at other people's solutions and comment on them. And since >> many of them will also be beginners, their comments may not >> always help. > Hopefully we can grow participation of experienced mentors > to share the load providing *quality* feedback to distinguish the > benefits of Pharo. > >> This particular problem is very similar to a "Langton's Ant" >> problem my old department gave to students, who were expected >> to solve it in two or three hours. And ALWAYS, the thing that >> held them back was creating classes they didn't need and >> agonising over what data and methods should go where (and then >> getting it wrong, such is the nature of Java). > My immediate reaction to that is that agonizing and getting it wrong > are a useful part of the learning process, but I recognize I could > just be being contrary :) . > I'll keep your observations in mind. > >> When a problem can be solved quite directly in 18 lines of >> clean code, you are going to have a very hard time persuading >> me that even one more class pays for itself, especially in a >> system with a rich class library of stuff you don't have to write. > Not trying to persuade you personally. > Just providing an alternative viewpoint for anyone to consider. > > cheers -ben > >