response 36 of 45:

Feb 5 13:27 UTC 2007

Re #32 re #31:  I wouldn't presume to defend my one-liner on grounds of 
readability or maintainability, of course.  For that, I'd recast it the 
way it was done in #30, or live a little more on the edge and do:

    i = 0;
    p = s[0];
    while (*p)
        if (isspace(*p))
            ++p;
        else if ((++i) < m)
            p = s[i];
        else
            break;
  /* If i < m, we have the first all-blank row, else there isn't one */
  /* Look Ma, no curly braces! */

But they're all the same solution, really -- except for some language-
specific tweaking -- in that they use the same two variables 
initialized, updated, and tested in exactly the same ways.  The 
predicate-logic based approach to algorithm developement pioneered by 
Dijkstra does tend to lead to economical, maintainable solutions, I've 
found.  Once you have such a solution, *then* you can concern yourself 
with expressing it in a style appropriate to the programming language at 
hand.  As David Gries put it, you should program *into* a language, not 
*in* a language.

response 38 of 45:

Feb 7 22:30 UTC 2007

Of course #32 was a joke.  I even laughed.  But the question you raise 
in #37 is interesting.  I haven't thought about it all that much, but I 
imagine that if the language departs significantly from the "Von Neumann 
machine" model - e.g. a functional programming language - it probably 
would.

However, doesn't programming in most of today's widely-used languages 
ultimately come down to manipulating variables with loops, conditionals, 
etc?  I'm thinking of languages like Java, JavaScript, Perl, Python, 
Ruby.  For those, I'd think the predicate-logic approach would be pretty 
much the same.

I'll pose the following exercise:

    foreach language in (Perl, Java, JavaScript, Ruby, Python, etc)
    {
        Rephrase the "first all-blank string" problem in a form
        sensible for that language;

        Solve it;
    }

(Rephrasing is necessary since different languages have different
representations and operators for strings.)

response 40 of 45:

Feb 11 21:14 UTC 2007

Okay, no one has responded in the last five days, so here are my solutions
to Remmers's puzzle for Ruby, Python and Perl.  Critique away.

# -+=Ruby=+-
def find1stblank(strings)
    strings.detect { |str| str =~ /^\s+$/ }
end

strings = [ "this", " is ", "a", "   ", "string" ]
p find1stblank(strings)
strings = [ "this", " is ", "a", "string" ]
p find1stblank(strings)

# -+=Python=+-
def find1stblank(strings):
    for i in range(1, len(strings)):
        if strings[i].isspace():
            return i
    return -1

strings = [ 'This is a test', '   ', 'hi there' ]
print(find1stblank(strings))
strings = [ 'This ', 'is ', 'another ', 'test', ' ' ]
print(find1stblank(strings))
strings = [ 'This ', 'is ', 'another ', 'test' ]
print(find1stblank(strings))

# -+=Perl=+-
use warnings;
use strict;

sub find1stblank
{
        for (my $i = 0; $i < @_; $i++) {
                return $i if $_[$i] =~ /^\s+$/;
        }
        return -1;
}

my @lines = ("This", "is ", "    ", "a", "test");
print find1stblank(@lines), "\n";
@lines = ("This", "is ", "another   ", "test", " ");
print find1stblank(@lines), "\n";
@lines = ("This", "is ", " not   ", "a", "test");
print find1stblank(@lines), "\n";

Note that for the Ruby code, I take a more Ruby-ish approach, returning a
reference to the row in question instead of just an index.

Note also that these solutions take advantage of facilities of the language
that are beyond that of our more primitive examples (e.g., in Ruby and Perl,
we have regular expressions as a basic idea, whereas in Python we can ask the
string whether it's blank).

Two related questions: is taking advantage of these language features too much
of, ``programming in a language'' instead of ``programming into a language''?
That is, can we legitimately frame the question in terms of regular
expressions and objects at a very high level, or is that ``cheating''?  The
second question, even if it *is* cheating, do we care?  Should we?

response 42 of 45:

Apr 8 11:31 UTC 2007

Responses #40 and #41 illustrate the effect of language primitives (in 
this case, regular expressions) on the shape of a solution.

(Aside:  This item has showed up as a shared bookmark on del.icio.us.  
Have a look at http://del.icio.us/tag/grex/  and
http://del.icio.us/url/93a9640a15e68aef7b1d7837f006cc01 ...)

response 44 of 45:

Dec 3 13:51 UTC 2007

I've never liked "come from" because it can really confuse you when
you're debugging something. Like, you'll be wondering why a certain line
was never executed only to find out later that it was because the line
before it was associated with a "come from" much later on in the program.