The essence of object orientation is that objects collaborate�� to achieve a goal.

The irony is that the code I was responding to ISN'T obviously correct.
Indeed, I found it rather puzzling.
The problem specification says that the input string may contain digits
AND SPACES.  The original message includes this:

Strings of length 1 or less are not valid. Spaces are allowed in the
input, but they should be stripped before checking. All other
non-digit characters are disallowed.

Now it isn't clear what "disallowed" means.  I took it to mean "may occur and
should simply mean the input is rejected as invalid."  Perhaps "may not occur"
was the intention.  So we shall not quibble about such characters.

But I can't for the life of me figure out how Trygve's code checks for spaces.
One reason this is an issue is that the behaviour of #digitValue is not
consistent between systems.
  Character space digitValue
    does not exist in the ANSI standard
    answers -1 in many Smalltalks (which is a pain)
    answers a positive integer that can't be mistake for a digit in my Smalltalk
    raises an exception in some Smalltalks.

This is a comment I now have in my Smalltalk library for #digitValue
      "This is in the Blue Book, but unspecified on non-digits.
       Squeak, Pharo, Dolphin, VW, VAST, and Apple Smalltalk-80
       answer -1 for characters that are not digits (or ASCII letters),
       which is unfortunate but consistent with Inside Smalltalk
       which specifies this result for non-digits.
       ST/X and GST raise an exception which is worse.
       Digitalk ST/V documentation doesn't specify the result.
       This selector is *much* easier to use safely if it
       returns a 'large' (>= 36) value for non-digits."

Let's compare three versions, the two I compared last time,
and the "version A" code I discussed before, which to my mind
is fairly readable.

"Don't add slowness": 1 (normalised time)
"Trygve's code":  6.5
"High level code": 30.6 (or 4.7 times slower than Trygve's)

Here's the "High level code".
      ^(aString allSatisfy: [:each | each isSpace or: [each isDigit]]) and: [
        |digitsReverse|
        digitsReverse := (aString select: [:each | each isDigit]) reverse.
        digitsReverse size > 1 and: [
          |evens odds evenSum oddSum|
          odds  := digitsReverse withIndexSelect: [:y :i | i odd].
          evens := digitsReverse withIndexSelect: [:x :i | i even].
          oddSum  := odds  detectSum: [:y | y digitValue].
          evenSum := evens detectSum: [:x |
                       #(0 2 4 6 8 1 3 5 7 9) at: x digitValue + 1].
          (oddSum + evenSum) \\ 10 = 0]]

This is the kind of code I was recommending that Roelof write.

As a rough guide, by counting traversals (including ones inside existing
methods), I'd expect the "high level" code to be at least 10 times slower
than the "no added slowness" code.

We are in vehement agreement that there is a time to write high level
really obvious easily testable and debuggable code, and that's most
of the time, especially with programming exercises.

I hope that we are also in agreement that factors of 30 (or even 6)
*can* be a serious problem.  I mean, if I wanted something that slow,
I'd use Ruby.

I hope we are also agreed that (with the exception of investigations
like this one) the time to hack on something to make it faster is AFTER
you have profiled it and determined that you have a problem.

But I respectfully suggest that there is a difference taking slowness OUT
and simply not going out of your way to add slowness in the first place.

I'd also like to remark that my preference for methods that traverse a
sequence exactly once has more to do with Smalltalk protocols than
with efficiency.  If the only method I perform on an object is #do:
the method will work just as well for readable streams as for
collections.  If the only method I perform on an object is #reverseDo:
the method will work just as well for Read[Write]Streams as for
SequenceReadableCollections, at least in my library.   It's just like
trying to write #mean so that it works for Durations as well as Numbers.

Oh heck, I suppose I should point out that much of the overheads in
this case could be eliminated by a Self-style compiler doing dynamic
inlining + loop fusion.    There's no reason *in principle*, given enough
people, money, and time, that the differences couldn't be greatly
reduced in Pharo.

On Tue, 5 May 2020 at 21:50, Trygve Reenskaug <trygver@ifi.uio.no> wrote: