how to model this a better way

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: how to model this a better way

Ben Coman
On Wed, 24 Apr 2019 at 16:52, Richard O'Keefe <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: how to model this a better way

Roelof
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 <[hidden email]> 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 <[hidden email]> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: how to model this a better way

Richard O'Keefe
Please don't quit Smalltalk.
I never said not to use classes.
That would be insane.
I said that *this specific exercise* is one
where *extra classes do not pay off.
This is in no way whatsoever a debate about
Pharo or Smalltalk.
We'd be having exactly the same discussion
in a list devoted to Java, Python, Ruby, or
any other OO programming language.
Please read
It's a short page about learning.

If you want to learn about OOP, the problem is not
Pharo or Smalltalk or even me.  It's that exercism
is not designed to do that.  It's designed to give
people who already know what they are doing in one
or more other languages practice in a new one.

Do a web search for something like "How to learn OO design".
You will find little things like
<quote>

Here's the OOP model:

A program can be modelled as a set of communicating black-box objects, with their own state.

The idea is to separate concerns, abstracting away implementation behind well-defined interfaces, which can in turn be implemented by other objects to cleanly replace parts of the application.

The rest of OO is pretty much just understanding Design Patterns (a set of names for common interactions between objects, and methods for setting these interactions up), grokking inheritance, and the difference between inheritance and composition, and grasping how to design a good OO system (how thickly to layer your classes, how much abstraction and what sorts, etc.)

The best languages for learning OO are Ruby and Smalltalk.

</quote>

in https://news.ycombinator.com/item?id=12495117

You will find articles like

https://medium.com/@richardeng/the-consequences-of-learning-oop-the-wrong-way-3659bdf0b996

You will find courses.

And look at the Pharo web site again: Stephan Ducasse has put up free copies of several books about Smalltalk.  I think he now has every one I've heard of.  Here's one link to get to them:

http://stephane.ducasse.free.fr/FreeBooks.html


Smalltalk and Object Orientation: an Introduction,

may be particularly helpful.



On Thu, 25 Apr 2019 at 04:56, Roelof Wobben <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: how to model this a better way

Andres Valloud-4
Perhaps what's been unsaid in this thread is that sometimes exercises
put some solution above all others (because it's presented as "the" answer).

On the one hand, maybe the messages here make it seem like there's no
single answer, as if the language was at fault.  On the other hand, one
learns more from exploring multiple avenues to solve a problem.  I
suspect that, after a while, one takes the latter attitude for granted.

So, to be explicit, the cookbook way to programming will only get one so
far.  It's much better to consider multiple avenues, then weigh pros and
cons.

On 4/24/19 16:19 , Richard O'Keefe wrote:

> Please don't quit Smalltalk.
> I never said not to use classes.
> That would be insane.
> I said that *this specific exercise* is one
> where *extra classes do not pay off.
> This is in no way whatsoever a debate about
> Pharo or Smalltalk.
> We'd be having exactly the same discussion
> in a list devoted to Java, Python, Ruby, or
> any other OO programming language.
> Please read
> http://www.cs.otago.ac.nz/cosc345/bickerton.htm
> It's a short page about learning.
>
> If you want to learn about OOP, the problem is not
> Pharo or Smalltalk or even me.  It's that exercism
> is not designed to do that.  It's designed to give
> people who already know what they are doing in one
> or more other languages practice in a new one.
>
> Do a web search for something like "How to learn OO design".
> You will find little things like
> <quote>
>
> qwertyuiop924 <https://news.ycombinator.com/user?id=qwertyuiop924> on
> Sept 14, 2016 <https://news.ycombinator.com/item?id=12495808> [-]
>
> Here's the OOP model:
>
> A program can be modelled as a set of communicating black-box objects,
> with their own state.
>
> The idea is to separate concerns, abstracting away implementation behind
> well-defined interfaces, which can in turn be implemented by other
> objects to cleanly replace parts of the application.
>
> The rest of OO is pretty much just understanding Design Patterns (a set
> of names for common interactions between objects, and methods for
> setting these interactions up), grokking inheritance, and the difference
> between inheritance and composition, and grasping how to design a good
> OO system (how thickly to layer your classes, how much abstraction and
> what sorts, etc.)
>
> The best languages for learning OO are Ruby and Smalltalk.
>
> </quote>
>
> in https://news.ycombinator.com/item?id=12495117
>
> You will find articles like
>
> https://medium.com/@richardeng/the-consequences-of-learning-oop-the-wrong-way-3659bdf0b996
>
> You will find courses.
>
> And look at the Pharo web site again: Stephan Ducasse has put up free
> copies of several books about Smalltalk.  I think he now has every one
> I've heard of.  Here's one link to get to them:
>
> http://stephane.ducasse.free.fr/FreeBooks.html
>
>
>
>
> Smalltalk and Object Orientation: an Introduction
> <http://sdmeta.gforge.inria.fr/FreeBooks/STandOO/Smalltalk-and-OO.pdf>,
>
> may be particularly helpful.
>
>
>
> On Thu, 25 Apr 2019 at 04:56, Roelof Wobben <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     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 <[hidden email]
>     <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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
>     >
>     >
>
>
Reply | Threaded
Open this post in threaded view
|

Re: how to model this a better way

Richard O'Keefe
In reply to this post by Roelof
PS: in this thread nobody has disagreed about what OO programming is.
The disagreement was about *how to apply it*.
There actually seems to be quite a lot of agreement that the
answer depends on what your underlying goal is:
 - is this throw-away code for a specific problem?
 - is this code to be included in a useful program?
 - is this just for practice in an unfamiliar language
   where you already understand all the concepts?
 - is this for learning about radically new concepts?
And everyone agrees that test cases are good for all of these.

You might find it useful to join another exercism thread and
solve some of these problems in a language that you are
comfortable with, then solve them in Smalltalk (or Ruby).
This will help to separate "how do I solve this problem?"
from "how do I express this solution in language X?"
Another thing you might find useful, having solved a
problem, is to try to solve it a different way.

For example, in a functional language, you might solve a
problem first in a C-like way using mutable objects freely.
Then you might solve it again using immutable values.
And then you might solve it again using higher-order functions.
And then you might solve it again using point-free style as
much as you can.

For another example, in R, or Fortran 90, or Matlab, you
might solve a problem first in an element-at-a-time way,
and then you might try it again using vectorisation to
eliminate as many loops as you can.

And in *this* example, don't suppose that there is One Right
Way To Do It.  Get ONE solution going.  ANY solution.  I would
suggest my approach, because (a) of course I would, and (b) it
really is a struggle with exercism to find out what the problem
actually is, and you want to get to SOME solution quickly.  But
it doesn't matter so much, because the point is to try it MORE
ways than one.  This is one way to learn design.  Try more than
one approach and discover which ones work out better.

I started out using Point.  Then I tried again just using bare
coordinates.  I started with position and velocity as instance
variables.  Then I tried again with them as method temporaries.
I eliminated one thing after another until I was left with
obviously correct code, and I felt no shame in using
#caseOf: to classify characters, even though there are books
that will tell you that using "if" and "case" is anti-OO.
I could do it again eliminating #caseOf: in terms of "if" if
I saw any value in doing so.

In this particular exercise, you are simulating
ONE instance (the robot) of ONE kind of thing (Robots).
That strongly suggests that your solution might have
ONE class: Robot, or perhaps TWO: Robot and RobotTest.
That's the one active thing.

This thing has properties: where it is and which way it
is going.  Now from the point of view of differential
geometry, points and directions are different things and
live in different abstract spaces, so I would have a lot
of sympathy for having two classes: Place (x,y) and
Direction (dx,dy) with #turnLeft and #turnRight as
operations on Direction and
place plus: distance in: direction
as an operation on Place returning a new Place.
But a good programmer is a lazy programmer, and
looks for existing code to use.  And the classic
Point class in Smalltalk combines Place and Direction
in one "two-dimensional vector" concept, originally
designed for 2D computer graphics rather than
geometry.  It's good enough, and Smalltalk programmers
can be expected to know that Point exists (just as Java
programmers can be expected to know about Java's point
classes), so I'd use it.

So now, from one mind, we have designs with
1  Robot
2  Robot, RobotTest
3  Robot, RobotTest, Point
4  Robot, RobotTest, Place, Direction
classes.  ANY of them could be defended as a good design,
depending on what the ultimate aim is.


Reply | Threaded
Open this post in threaded view
|

Re: how to model this a better way

Roelof
Hello Ricard O'  Keefe

For my exercism is a way of practising smalltalk and get familair with the concepts.
So sometimes for me totally new concepts like Double Dispatch.  so in your questions some of the thirth and fourth question. And I try to solve the challenges like there are real world problems.

Because Tim like to push me further then sometimes the challenges needed so I learn new concepts or practice things I already learned.

I agree totally with you that I always look if existing classes can do the job before I write my own objects.

The problem that I faced is that I not always see which objects I need and what the responsibility is.

Right now my thoughts are this :

RobotTests  they contain all the tests.
Robot . Responsibility for keeping track of what the position is and which direction it faces.
Direction. Responsibility for calculating a new position or a new direction the robot faces.

Thanks for you suggestion to solve it first in a language that im familiar with but I not so familiair with a langugae I can solve "all"  the problems.  Because smalltalk is OO  I sometimes look at ruby code to see how they solve things.

Roelof





Op 25-4-2019 om 06:23 schreef Richard O'Keefe:
PS: in this thread nobody has disagreed about what OO programming is.
The disagreement was about *how to apply it*.
There actually seems to be quite a lot of agreement that the
answer depends on what your underlying goal is:
 - is this throw-away code for a specific problem?
 - is this code to be included in a useful program?
 - is this just for practice in an unfamiliar language
   where you already understand all the concepts?
 - is this for learning about radically new concepts?
And everyone agrees that test cases are good for all of these.

You might find it useful to join another exercism thread and
solve some of these problems in a language that you are
comfortable with, then solve them in Smalltalk (or Ruby).
This will help to separate "how do I solve this problem?"
from "how do I express this solution in language X?"
Another thing you might find useful, having solved a
problem, is to try to solve it a different way.

For example, in a functional language, you might solve a
problem first in a C-like way using mutable objects freely.
Then you might solve it again using immutable values.
And then you might solve it again using higher-order functions.
And then you might solve it again using point-free style as
much as you can.

For another example, in R, or Fortran 90, or Matlab, you
might solve a problem first in an element-at-a-time way,
and then you might try it again using vectorisation to
eliminate as many loops as you can.

And in *this* example, don't suppose that there is One Right
Way To Do It.  Get ONE solution going.  ANY solution.  I would
suggest my approach, because (a) of course I would, and (b) it
really is a struggle with exercism to find out what the problem
actually is, and you want to get to SOME solution quickly.  But
it doesn't matter so much, because the point is to try it MORE
ways than one.  This is one way to learn design.  Try more than
one approach and discover which ones work out better.

I started out using Point.  Then I tried again just using bare
coordinates.  I started with position and velocity as instance
variables.  Then I tried again with them as method temporaries.
I eliminated one thing after another until I was left with
obviously correct code, and I felt no shame in using
#caseOf: to classify characters, even though there are books
that will tell you that using "if" and "case" is anti-OO.
I could do it again eliminating #caseOf: in terms of "if" if
I saw any value in doing so.

In this particular exercise, you are simulating
ONE instance (the robot) of ONE kind of thing (Robots).
That strongly suggests that your solution might have
ONE class: Robot, or perhaps TWO: Robot and RobotTest.
That's the one active thing.

This thing has properties: where it is and which way it
is going.  Now from the point of view of differential
geometry, points and directions are different things and
live in different abstract spaces, so I would have a lot
of sympathy for having two classes: Place (x,y) and
Direction (dx,dy) with #turnLeft and #turnRight as
operations on Direction and
place plus: distance in: direction
as an operation on Place returning a new Place.
But a good programmer is a lazy programmer, and
looks for existing code to use.  And the classic
Point class in Smalltalk combines Place and Direction
in one "two-dimensional vector" concept, originally
designed for 2D computer graphics rather than
geometry.  It's good enough, and Smalltalk programmers
can be expected to know that Point exists (just as Java
programmers can be expected to know about Java's point
classes), so I'd use it.

So now, from one mind, we have designs with
1  Robot
2  Robot, RobotTest
3  Robot, RobotTest, Point
4  Robot, RobotTest, Place, Direction
classes.  ANY of them could be defended as a good design,
depending on what the ultimate aim is.



Reply | Threaded
Open this post in threaded view
|

Re: how to model this a better way

Offray Vladimir Luna Cárdenas-2
In reply to this post by Richard O'Keefe

Roelof,

I second Richard on that. Maybe Exercism is important, but I don't know if is important enough to consider quitting Smalltalk because of the experience solving a problem there.

Maybe sharing some of our personal experiences learning Smalltalk, the struggles and joys on that could put Exercism in perspective.

In my case I started with Smalltalk via Etoys and Squeak in 2006 and 2007, but I left it as I can not "get it" all, despite of seeing the potence behind ideas like Dynabook and having rewarding experience in educational context with freshmen students. We used Etoys, Bots Inc and Scratch. The last was easier to get, but the others offered a better continuum to go from tile based programming to coding, so we combined all of them. But when I try to build more... "practical" things like OS scripting or data stories/visuals I struggle a lot with the Smalltalk environment, the paradigm switch and its purity, the absence of modern books and local communities and the kind of childish UI. It was like if I was growing in my needs, but the Squeak environment was so tailor suited for education with children that can not grow with me in more professional day to day tasks.

Seven years later I found Pharo, so Smalltalk and I were changed enough for this meeting again experience. I have struggles again, particularly getting support with some issues related the GT, but the community was welcoming (as always), the books where more mature, the mailing list more active, and the level of fluency I get this time to express my old and new ideas in code was nothing I have experienced before in any computer language/environment. I chose a "real" world project as my learning experience this time (called Grafoscopio[1]) and despite it has a lot to improve and there is still newbie code here and there, any time I have the chance to working in it again, I'm really grateful of sticking around and keeping with the Smalltalk communities and the technology.

[1] https://mutabit.com/grafoscopio/index.en.html

So, my advice is don't let the Exercism experience let you down on Smalltalk. You could try with other approaches to learn, you could try with different books, or given yourself some distance, rest a little bit and be back here again. I know nothing about double dispatch, I'm learning design patters, I do not do TDD as common wise advices. I'm learning this by myself, following my own exploration and learning needs as they arrive, with the help of this community. And I know I'm getting better when I compare with myself years ago. So I expect to be here for the years to come and get even better and to showcase that in the code I write and share with this community. Would be nice to have around too.

Cheers,

Offray


On 24/04/19 6:19 p. m., Richard O'Keefe wrote:
Please don't quit Smalltalk.
I never said not to use classes.
That would be insane.
I said that *this specific exercise* is one
where *extra classes do not pay off.
This is in no way whatsoever a debate about
Pharo or Smalltalk.
We'd be having exactly the same discussion
in a list devoted to Java, Python, Ruby, or
any other OO programming language.
Please read
It's a short page about learning.

If you want to learn about OOP, the problem is not
Pharo or Smalltalk or even me.  It's that exercism
is not designed to do that.  It's designed to give
people who already know what they are doing in one
or more other languages practice in a new one.

Do a web search for something like "How to learn OO design".
You will find little things like
<quote>

Here's the OOP model:

A program can be modelled as a set of communicating black-box objects, with their own state.

The idea is to separate concerns, abstracting away implementation behind well-defined interfaces, which can in turn be implemented by other objects to cleanly replace parts of the application.

The rest of OO is pretty much just understanding Design Patterns (a set of names for common interactions between objects, and methods for setting these interactions up), grokking inheritance, and the difference between inheritance and composition, and grasping how to design a good OO system (how thickly to layer your classes, how much abstraction and what sorts, etc.)

The best languages for learning OO are Ruby and Smalltalk.

</quote>

in https://news.ycombinator.com/item?id=12495117

You will find articles like

https://medium.com/@richardeng/the-consequences-of-learning-oop-the-wrong-way-3659bdf0b996

You will find courses.

And look at the Pharo web site again: Stephan Ducasse has put up free copies of several books about Smalltalk.  I think he now has every one I've heard of.  Here's one link to get to them:

http://stephane.ducasse.free.fr/FreeBooks.html


Smalltalk and Object Orientation: an Introduction,

may be particularly helpful.



On Thu, 25 Apr 2019 at 04:56, Roelof Wobben <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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
>
>


Reply | Threaded
Open this post in threaded view
|

Re: how to model this a better way

Richard O'Keefe
In reply to this post by Roelof
For what it is worth, I have now completed two thirds of the Exercism tasks for Pharo.
That's about 24 of them, maybe 1 or 2 more.
ONE of them warranted the creation of another class (the Tournament exercise deserves
a Team class).
MOST of them were no-data classes with just one method.
A couple of them required multiple methods, which in turn required state in the
class, but not many.
In each exercise the framework forces you to have at least two classes:
Solution  -- defined by you
SolutionTests -- provided
and you have to glean the interface from the SolutionTests class.
Your suggestion for a Direction class is perfectly reasonable, and would be
the right thing to do if Point did not exist or if you made a conscious decision
to avoid it for practice reasons.

I suppose the idea is that you push the testing button beside the SolutionTests
class, and when an undefined class or undefined message is encountered, use the
debugger to begin creating it.  I found it helpful NOT to do that, but to survey
*all* the tests first to find out what methods were required and from that to
work out what state had to be maintained.

On Thu, 25 Apr 2019 at 17:22, Roelof Wobben <[hidden email]> wrote:
Hello Ricard O'  Keefe

For my exercism is a way of practising smalltalk and get familair with the concepts.
So sometimes for me totally new concepts like Double Dispatch.  so in your questions some of the thirth and fourth question. And I try to solve the challenges like there are real world problems.

Because Tim like to push me further then sometimes the challenges needed so I learn new concepts or practice things I already learned.

I agree totally with you that I always look if existing classes can do the job before I write my own objects.

The problem that I faced is that I not always see which objects I need and what the responsibility is.

Right now my thoughts are this :

RobotTests  they contain all the tests.
Robot . Responsibility for keeping track of what the position is and which direction it faces.
Direction. Responsibility for calculating a new position or a new direction the robot faces.

Thanks for you suggestion to solve it first in a language that im familiar with but I not so familiair with a langugae I can solve "all"  the problems.  Because smalltalk is OO  I sometimes look at ruby code to see how they solve things.

Roelof





Op 25-4-2019 om 06:23 schreef Richard O'Keefe:
PS: in this thread nobody has disagreed about what OO programming is.
The disagreement was about *how to apply it*.
There actually seems to be quite a lot of agreement that the
answer depends on what your underlying goal is:
 - is this throw-away code for a specific problem?
 - is this code to be included in a useful program?
 - is this just for practice in an unfamiliar language
   where you already understand all the concepts?
 - is this for learning about radically new concepts?
And everyone agrees that test cases are good for all of these.

You might find it useful to join another exercism thread and
solve some of these problems in a language that you are
comfortable with, then solve them in Smalltalk (or Ruby).
This will help to separate "how do I solve this problem?"
from "how do I express this solution in language X?"
Another thing you might find useful, having solved a
problem, is to try to solve it a different way.

For example, in a functional language, you might solve a
problem first in a C-like way using mutable objects freely.
Then you might solve it again using immutable values.
And then you might solve it again using higher-order functions.
And then you might solve it again using point-free style as
much as you can.

For another example, in R, or Fortran 90, or Matlab, you
might solve a problem first in an element-at-a-time way,
and then you might try it again using vectorisation to
eliminate as many loops as you can.

And in *this* example, don't suppose that there is One Right
Way To Do It.  Get ONE solution going.  ANY solution.  I would
suggest my approach, because (a) of course I would, and (b) it
really is a struggle with exercism to find out what the problem
actually is, and you want to get to SOME solution quickly.  But
it doesn't matter so much, because the point is to try it MORE
ways than one.  This is one way to learn design.  Try more than
one approach and discover which ones work out better.

I started out using Point.  Then I tried again just using bare
coordinates.  I started with position and velocity as instance
variables.  Then I tried again with them as method temporaries.
I eliminated one thing after another until I was left with
obviously correct code, and I felt no shame in using
#caseOf: to classify characters, even though there are books
that will tell you that using "if" and "case" is anti-OO.
I could do it again eliminating #caseOf: in terms of "if" if
I saw any value in doing so.

In this particular exercise, you are simulating
ONE instance (the robot) of ONE kind of thing (Robots).
That strongly suggests that your solution might have
ONE class: Robot, or perhaps TWO: Robot and RobotTest.
That's the one active thing.

This thing has properties: where it is and which way it
is going.  Now from the point of view of differential
geometry, points and directions are different things and
live in different abstract spaces, so I would have a lot
of sympathy for having two classes: Place (x,y) and
Direction (dx,dy) with #turnLeft and #turnRight as
operations on Direction and
place plus: distance in: direction
as an operation on Place returning a new Place.
But a good programmer is a lazy programmer, and
looks for existing code to use.  And the classic
Point class in Smalltalk combines Place and Direction
in one "two-dimensional vector" concept, originally
designed for 2D computer graphics rather than
geometry.  It's good enough, and Smalltalk programmers
can be expected to know that Point exists (just as Java
programmers can be expected to know about Java's point
classes), so I'd use it.

So now, from one mind, we have designs with
1  Robot
2  Robot, RobotTest
3  Robot, RobotTest, Point
4  Robot, RobotTest, Place, Direction
classes.  ANY of them could be defended as a good design,
depending on what the ultimate aim is.



12