Loading ...
Sorry, an error occurred while loading the content.

New Articles on XProgramming.com

Expand Messages
  • Ron Jeffries
    Bowling Vectors Ron Jeffries 04/26/2006 June Kim posted a J Language version of bowling that is very vector-oriented. As an experiment, I coded up a
    Message 1 of 20 , Apr 28 7:23 AM
    • 0 Attachment
      Bowling Vectors
      Ron Jeffries
      04/26/2006

      June Kim posted a J Language version of bowling that is very
      vector-oriented. As an experiment, I coded up a vector-style
      version in Ruby, TDD of course. It turned out to be kind of
      interesting.

      http://www.xprogramming.com/xpmag/dbcBowlingVector.htm

      Grotesque Hackery in XSL
      Ron Jeffries
      04/22/2006

      Between the new book review page and a few other things, I just
      spent a few days in a painful, test-free update of my web site
      scripts. Here, a report on how much it hurt. Lessons learned?
      We'll have to see what I do. Like lots of folks I know, I haven't
      figured out how to do what I know I should.

      http://www.xprogramming.com/xpmag/jatGrotesqueHackery.htm

      Ron Jeffries
      www.XProgramming.com
      We cannot solve our problems with the same thinking we used when we created them.
      -- Albert Einstein
    • Stefan Schmiedl
      ... errrmmm... The inject is stolen from Smalltalk, and since Ruby doesn t have it -- silly girl -- we have to implement it stefan@g64 ~ $ irb ... = 6 Maybe
      Message 2 of 20 , Apr 28 2:54 PM
      • 0 Attachment
        Ron Jeffries (28.04. 10:23):

        > Bowling Vectors
        > Ron Jeffries
        > 04/26/2006
        >
        > June Kim posted a J Language version of bowling that is very
        > vector-oriented. As an experiment, I coded up a vector-style
        > version in Ruby, TDD of course. It turned out to be kind of
        > interesting.
        >
        > http://www.xprogramming.com/xpmag/dbcBowlingVector.htm

        errrmmm...

        "The inject is stolen from Smalltalk, and since Ruby doesn't have it
        -- silly girl -- we have to implement it"

        stefan@g64 ~ $ irb
        >> [1,2,3].inject(0) { | sum, each | sum + each }
        => 6

        Maybe she didn't at the age of 1.6, but now at a beautiful 1.8,
        she sure does :-)

        s.
      • Stefan Schmiedl
        ... Note to self: Read at least another half page before posting. Note to Ron: Thanks for making some pieces fall into place with this J/Ruby article. s.
        Message 3 of 20 , Apr 28 3:06 PM
        • 0 Attachment
          Stefan Schmiedl (28.04. 23:54):

          > Maybe she didn't at the age of 1.6, but now at a beautiful 1.8,
          > she sure does :-)

          Note to self: Read at least another half page before posting.

          Note to Ron: Thanks for making some pieces fall into place with
          this J/Ruby article.

          s.
        • Ron Jeffries
          ... So I was rapidly, not to say rabidly, informed by some Ruby experts. I ve updated the article to reflect my new learning. ;- Ron Jeffries
          Message 4 of 20 , Apr 28 4:12 PM
          • 0 Attachment
            On Friday, April 28, 2006, at 5:54:55 PM, Stefan Schmiedl wrote:

            > Maybe she didn't at the age of 1.6, but now at a beautiful 1.8,
            > she sure does :-)

            So I was rapidly, not to say rabidly, informed by some Ruby experts.
            I've updated the article to reflect my new learning. ;->

            Ron Jeffries
            www.XProgramming.com
            It is better to attempt something great and fail that attempt,
            than to attempt to do nothing and succeed.
            --Cookie, Garden Court Chinese Restaurant, Hamburg, MI
          • Ron Jeffries
            ... You re welcome. I enjoyed the exercise myself. It s a very different implementation, and I suspect it echoes the smaller J one fairly well. Though I still
            Message 5 of 20 , Apr 28 4:14 PM
            • 0 Attachment
              On Friday, April 28, 2006, at 6:06:18 PM, Stefan Schmiedl wrote:

              > Note to Ron: Thanks for making some pieces fall into place with
              > this J/Ruby article.

              You're welcome. I enjoyed the exercise myself. It's a very different
              implementation, and I suspect it echoes the smaller J one fairly
              well. Though I still have to learn what :{*&%^#$ means before I can
              be sure.

              Ron Jeffries
              www.XProgramming.com
              Questioner: How do I sell my executive team on doing this stuff?
              Jim Highsmith: Don't. Just do it. They don't know what you're doing anyway.
            • Stefan Schmiedl
              ... APL programmer cursing ASCII-terminals for not supporting the characters he needs... s.
              Message 6 of 20 , Apr 29 7:07 AM
              • 0 Attachment
                Ron Jeffries (28.04. 19:14):

                > Though I still have to learn what :{*&%^#$ means before I can
                > be sure.

                APL programmer cursing ASCII-terminals for not supporting the
                characters he needs...

                s.
              • June Kim
                ... Thank you for the interesting article. As much as I enjoyed reading it, I wanted to add some comments. ... Actually, it isn t. I think the biggest
                Message 7 of 20 , Apr 30 2:56 AM
                • 0 Attachment
                  On 4/28/06, Ron Jeffries <ronjeffries@...> wrote:
                  > Bowling Vectors
                  > Ron Jeffries
                  > 04/26/2006
                  >
                  > June Kim posted a J Language version of bowling that is very
                  > vector-oriented. As an experiment, I coded up a vector-style
                  > version in Ruby, TDD of course. It turned out to be kind of
                  > interesting.
                  >
                  > http://www.xprogramming.com/xpmag/dbcBowlingVector.htm
                  >

                  Thank you for the interesting article. As much as I enjoyed reading
                  it, I wanted to add some comments.

                  >
                  > NB. Pick the balls that actually start frames & add em up
                  > Then this, I assume, means to use the first array to index into the
                  > second array, and add up the results.

                  Actually, it isn't. I think the biggest difference between the J
                  version and your Ruby version is this.

                  framex and scoreifframe are all names to verbs, not any references to
                  arrays. So, gamescore could be interpreted in other languages as:

                  gamescore = cap(sum, fork(framex, take, scoreifframe))

                  (originally gamescore =: [: +/ framex { scoreifframe )

                  cap and fork are higher-order functions that take functions as
                  arguments and returns new functions as result. cap(f,g) is a new
                  function that does f(g(y)). fork(f,g,h) is a new function that does
                  g(f(x,y),h(x,y)).

                  So the J version doesn't really pass around any half-way complete
                  arrays. Actually they do all the things at once without any
                  variables(at least when not considering the internal workings). No
                  reference to any data, hence it's called tacit programming, and it is
                  extremely easy to refactor. I mean really easy. Of course, this style
                  of programming(tacit) allows easier modification and specialization of
                  codes compared to data-passing-around-way.

                  >
                  > That's what
                  >
                  > framex { scoreifframe
                  >
                  > means: take the array framex and index it into the array scoreifframe,
                  > returning those values and dropping the others. In other words,
                  > something like 2 4 {. 10 20 30 40 50 will equal 30 50.

                  Actually, no.

                  2 4 {. 10 20 30 40 50
                  |length error
                  | 2 4 {.10 20 30 40 50

                  {. is take and is different from {, which is called "from". {. takes x
                  elements from the start of the vector.

                  2 {. 10 20 30 40 50
                  10 20

                  In the upper case, where the x was 2 4, the rank(dimension) doesn't
                  match right, so you get the length error.

                  > In J, that operation is called "take". Let's call
                  > it that.

                  It's called "from". take is a different one, and you can see it used
                  in the definition of framex, where it is used to take just 10 indexes
                  of frame starts. (10 {. y)

                  > 90 expected, got zero. Let's see what has to happen to make
                  > it work. The frame_start indexes are ust fine. The scores for each
                  > roll, assuming it's the first roll of a frame, aren't.

                  Minor typo here: ust fine ==> just fine


                  I think in programming languages like Io(http://iolanguage.com), which
                  is greatly malleable, you can easily and closely mimic array-oriented
                  languages like APL and J. As I remember there have been many attempts
                  to hybrid OOPL and array-oriented programming languages. One approach
                  was to embed AOP on top of generic OOPL, like Java and smalltalk(I
                  remember having seen some papers from ACM digital library), the other
                  one was to build OOP facility on top of AOPLs(J and APL have OOP
                  features).

                  I find your ruby approach was quite similar to the J version except
                  the way frame start index is extracted and each frame score is
                  calculated.

                  framex does a very interesting way. It builds an index of "the start
                  index of next frame" and then loops over({~^:a:) the index to get the
                  all start indexes of all frames. This is a powerful idea(as Alan Kay
                  and Seymour Papert says).

                  scoreifframe does always cut each frame as three rolls compared to
                  yours, but adds conditionally.

                  3 <\ 1 2 3 4 5
                  +-----+-----+-----+
                  |1 2 3|2 3 4|3 4 5|
                  +-----+-----+-----+

                  3 +/\ 1 2 3 4 5
                  6 9 12

                  \ is called infix, and < is a verb for boxing, +/ is, as you know
                  already, summing. \ runs through the vector and for each x elements do
                  the verb. \'s part of speech is conjunction.

                  Finally, I see some difference in your style of TDDing from me. I try
                  to remove duplications in tests and try to cut the cases as "aspects".
                  My analogy is "rice rolled in dried laver", as we call it in Korea
                  Kimbab. http://images.google.co.kr/images?q=kimbab&sa=N&tab=wi You
                  can slice a Kimbab roll into pieces with varying sizes but every piece
                  has rice, carrot, spinach, dried seaweed and all the same ingridients.
                  If you disassemble the roll instead, you can get all of the
                  ingridients separate. In the test cases of open, spare, and perfect,
                  each one is testing separating frames, scoring each frame, summing
                  frames, and etc. The problem is that when there is any need to change
                  the code, due to the permeated aspects across many test cases, the
                  tests could be fragile and you are forced to change many of them at
                  once. (Of course those tests are valuable as integration tests.) I
                  think many uniformal test cases are a smell. When test cases are
                  written in ingrideints tests(disassembly), those cases reads like the
                  rules(declarative) described in the original requirements.

                  However, as you have written in your article, you seemed to have
                  chosen that way intentionally. And you have test cases like
                  test_frame_start_strike. So you do have both of ingridient tests and
                  slice tests.

                  BTW, I really respect your honesty and humbleness shown in the
                  article. I always learn a lot reading what you have wrote, not only on
                  technical sides but also on personality and attitude sides.

                  June
                • Ron Jeffries
                  ... Thanks ... I appreciate the feedback. ... As I mentioned, I was interpreting the comments and don t understand the code. Suspect I need even more help than
                  Message 8 of 20 , Apr 30 10:23 AM
                  • 0 Attachment
                    On Sunday, April 30, 2006, at 5:56:10 AM, June Kim wrote:

                    > Thank you for the interesting article. As much as I enjoyed reading
                    > it, I wanted to add some comments.

                    Thanks ... I appreciate the feedback.

                    >> NB. Pick the balls that actually start frames & add em up
                    >> Then this, I assume, means to use the first array to index into the
                    >> second array, and add up the results.

                    > Actually, it isn't. I think the biggest difference between the J
                    > version and your Ruby version is this.

                    As I mentioned, I was interpreting the comments and don't understand
                    the code. Suspect I need even more help than what's below ... we'll
                    see.

                    (Your text reordered below ...)

                    > So the J version doesn't really pass around any half-way complete
                    > arrays. Actually they do all the things at once without any
                    > variables(at least when not considering the internal workings). No
                    > reference to any data, hence it's called tacit programming, and it is
                    > extremely easy to refactor. I mean really easy. Of course, this style
                    > of programming(tacit) allows easier modification and specialization of
                    > codes compared to data-passing-around-way.

                    I'm happy to accept that as written, supported by my brief
                    experience with APL on my IBM PC/AT. But I don't, as yet, understand
                    just what that line of code does ...

                    I'd like to understand better just what J does with the case in
                    hand. Let me try to decode what you're saying ...

                    > framex and scoreifframe are all names to verbs, not any references to
                    > arrays.

                    Is it fair to think of a verb as a function? When you write / apply
                    a verb, do you think of the verb, or of its result on the data it'll
                    be applied to? When I was doing APL, I was always thinking about the
                    resulting /data/, since it was, after all, the answer that I was
                    interested in.

                    > So, gamescore could be interpreted in other languages as:

                    > gamescore = cap(sum, fork(framex, take, scoreifframe))

                    > (originally gamescore =: [: +/ framex { scoreifframe )

                    > cap and fork are higher-order functions that take functions as
                    > arguments and returns new functions as result. cap(f,g) is a new
                    > function that does f(g(y)). fork(f,g,h) is a new function that does
                    > g(f(x,y),h(x,y)).

                    I'm not clear on what this means, in this case. In particular I
                    don't see where the x and y are coming from in the line above, which
                    is the last line of the program.

                    I'll start from the inside. Following your words above, it sounds
                    like fork(framex, take, scoreiffframe) (fork(f,g,h)) is a new
                    function applying to x,y that does

                    take(framex(x,y), scoreiffframe(x,y))

                    The framex call produces the indexes of the balls that start the
                    frames; the scoreifframe scores that frame. (I'm still not sure what
                    x and y are here, but it may not matter.)

                    I assume that since take knows its arguments are functions (verbs)
                    that it may (must?) evaluate the second function, scoreifframe, only
                    where framex has an index).

                    In the ruby code, this would be as if we called our frame_score
                    method somehow after running the frame_starts method, so that we
                    don't evaluate the rolls that do not start a frame. I'm not sure
                    whether it would be possible to write that in Ruby so that it felt
                    as much like a vector operation as the current code does to me,
                    but I'd guess we could do much the same thing by passing in a
                    block. Might be worth a try, if I can come to understand more
                    clearly what the J code does.

                    I don't expect it to feel entirely the same, of course, since J is
                    manipulating functions (verbs), and Ruby is manipulating data.
                    Interesting to try, though ...

                    Suppose we built a method take, that instead of simply processing
                    two arrays, took two blocks, and iterated the first one, calling
                    yield on the other ... I bet I could do it ...

                    Does the above stream of consciousness sound like I might
                    understand, as well as an earthling might, what the take part of the
                    code is doing? If not, please try again to smarten me up.

                    Now for the cap part.

                    > cap(f,g) is a new function that does f(g(y)).

                    In our case, we have sum, and this function that is (as I envision
                    it) returning the vector of frame-starting frame scores.

                    So that means sum(the appropriate frame scorse), right? But what I
                    don't understand is what the cap was good for.

                    I thought that +/ (1 2 3) already meant 1 + 2 + 3. So what was it
                    that made it necessary or desirable to put the cap in there?

                    >> That's what
                    >>
                    >> framex { scoreifframe
                    >>
                    >> means: take the array framex and index it into the array scoreifframe,
                    >> returning those values and dropping the others. In other words,
                    >> something like 2 4 {. 10 20 30 40 50 will equal 30 50.

                    > Actually, no.

                    > 2 4 {. 10 20 30 40 50
                    > |length error
                    > | 2 4 {.10 20 30 40 50

                    > {. is take and is different from {, which is called "from". {. takes x
                    > elements from the start of the vector.

                    > 2 {. 10 20 30 40 50
                    > 10 20

                    > In the upper case, where the x was 2 4, the rank(dimension) doesn't
                    > match right, so you get the length error.

                    I'm not sure whether this comment is a red herring or not, in light
                    of the cap/fork discussion. What would

                    framex { scoreifframe

                    do, all on its own? I suppose I should download J and find out.
                    After I download Rake and REXML and ... <sigh/>

                    >> In J, that operation is called "take". Let's call
                    >> it that.

                    > It's called "from". take is a different one, and you can see it used
                    > in the definition of framex, where it is used to take just 10 indexes
                    > of frame starts. (10 {. y)

                    OK ...

                    >> 90 expected, got zero. Let's see what has to happen to make
                    >> it work. The frame_start indexes are ust fine. The scores for each
                    >> roll, assuming it's the first roll of a frame, aren't.

                    > Minor typo here: ust fine ==> just fine

                    Thanks ... I'm fixing that as we "speak", in another thread.

                    > I think in programming languages like Io(http://iolanguage.com), which
                    > is greatly malleable, you can easily and closely mimic array-oriented
                    > languages like APL and J. As I remember there have been many attempts
                    > to hybrid OOPL and array-oriented programming languages. One approach
                    > was to embed AOP on top of generic OOPL, like Java and smalltalk(I
                    > remember having seen some papers from ACM digital library), the other
                    > one was to build OOP facility on top of AOPLs(J and APL have OOP
                    > features).

                    Yes ... I've played with similar ideas in my Extended Set Theory
                    days, and also when I was reading /Recursive Programming
                    Techniques/, by Burge, and fiddling with APL. The hybrid approaches
                    that I've tried haven't gone together very well, but I haven't
                    looked at Io or J. Perhaps I should ...

                    > I find your ruby approach was quite similar to the J version except
                    > the way frame start index is extracted and each frame score is
                    > calculated.

                    Yes ... I think I see that part of that is that the frame score is
                    calculated only for appropriate frames in the J approach, and for
                    all frames in mine. That was due to my not knowing what cap/fork
                    stuff is about. (And I still don't, I regret to say.)

                    (The typo is fixed now, that thread reports ...)

                    > framex does a very interesting way. It builds an index of "the start
                    > index of next frame" and then loops over({~^:a:) the index to get the
                    > all start indexes of all frames. This is a powerful idea(as Alan Kay
                    > and Seymour Papert says).

                    Isn't that analogous to what the Ruby program does with the inject?
                    I can't read the little bit of code there to be sure ...

                    > scoreifframe does always cut each frame as three rolls compared to
                    > yours, but adds conditionally.

                    > 3 <\ 1 2 3 4 5
                    > +-----+-----+-----+
                    > |1 2 3|2 3 4|3 4 5|
                    > +-----+-----+-----+

                    > 3 +/\ 1 2 3 4 5
                    > 6 9 12

                    > \ is called infix, and < is a verb for boxing, +/ is, as you know
                    > already, summing. \ runs through the vector and for each x elements do
                    > the verb. \'s part of speech is conjunction.

                    Yes, I think I understood that bit ... maybe. ;->

                    > Finally, I see some difference in your style of TDDing from me. I try
                    > to remove duplications in tests and try to cut the cases as "aspects".
                    > My analogy is "rice rolled in dried laver", as we call it in Korea
                    > Kimbab. http://images.google.co.kr/images?q=kimbab&sa=N&tab=wi You
                    > can slice a Kimbab roll into pieces with varying sizes but every piece
                    > has rice, carrot, spinach, dried seaweed and all the same ingridients.
                    > If you disassemble the roll instead, you can get all of the
                    > ingridients separate. In the test cases of open, spare, and perfect,
                    > each one is testing separating frames, scoring each frame, summing
                    > frames, and etc. The problem is that when there is any need to change
                    > the code, due to the permeated aspects across many test cases, the
                    > tests could be fragile and you are forced to change many of them at
                    > once. (Of course those tests are valuable as integration tests.) I
                    > think many uniformal test cases are a smell. When test cases are
                    > written in ingrideints tests(disassembly), those cases reads like the
                    > rules(declarative) described in the original requirements.

                    I would be delighted to see an example of that style of TDD, in a
                    language I can understand such as Ruby, Java, C#. From the
                    description, I'm not quite getting it.

                    > However, as you have written in your article, you seemed to have
                    > chosen that way intentionally. And you have test cases like
                    > test_frame_start_strike. So you do have both of ingridient tests and
                    > slice tests.

                    > BTW, I really respect your honesty and humbleness shown in the
                    > article. I always learn a lot reading what you have wrote, not only on
                    > technical sides but also on personality and attitude sides.

                    Thanks. I try to combine a willingness to try things, a fascination
                    with odd ways of solving problems, a confidence that everything will
                    be all right, and a smiling recognition of how fallible I am (and
                    most of us are).

                    Ron Jeffries
                    www.XProgramming.com
                    Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
                  • June Kim
                    ... I guessed so and was quite surprised how much you could skillfully achieve from only following the comments! ... Yes, it is. ... When I write a verb, I
                    Message 9 of 20 , Apr 30 6:34 PM
                    • 0 Attachment
                      On 5/1/06, Ron Jeffries <ronjeffries@...> wrote:
                      > On Sunday, April 30, 2006, at 5:56:10 AM, June Kim wrote:
                      >
                      > > Thank you for the interesting article. As much as I enjoyed reading
                      > > it, I wanted to add some comments.
                      >
                      > Thanks ... I appreciate the feedback.
                      >
                      > >> NB. Pick the balls that actually start frames & add em up
                      > >> Then this, I assume, means to use the first array to index into the
                      > >> second array, and add up the results.
                      >
                      > > Actually, it isn't. I think the biggest difference between the J
                      > > version and your Ruby version is this.
                      >
                      > As I mentioned, I was interpreting the comments and don't understand
                      > the code. Suspect I need even more help than what's below ... we'll
                      > see.

                      I guessed so and was quite surprised how much you could skillfully
                      achieve from only following the comments!

                      >
                      > (Your text reordered below ...)
                      >
                      > > So the J version doesn't really pass around any half-way complete
                      > > arrays. Actually they do all the things at once without any
                      > > variables(at least when not considering the internal workings). No
                      > > reference to any data, hence it's called tacit programming, and it is
                      > > extremely easy to refactor. I mean really easy. Of course, this style
                      > > of programming(tacit) allows easier modification and specialization of
                      > > codes compared to data-passing-around-way.
                      >
                      > I'm happy to accept that as written, supported by my brief
                      > experience with APL on my IBM PC/AT. But I don't, as yet, understand
                      > just what that line of code does ...
                      >
                      > I'd like to understand better just what J does with the case in
                      > hand. Let me try to decode what you're saying ...
                      >
                      > > framex and scoreifframe are all names to verbs, not any references to
                      > > arrays.
                      >
                      > Is it fair to think of a verb as a function?

                      Yes, it is.

                      > When you write / apply
                      > a verb, do you think of the verb, or of its result on the data it'll
                      > be applied to?

                      When I write a verb, I think about what I want to achieve, or the
                      problem statement.

                      For example, when I want a verb for arithmetic average, I think about
                      a problem statement, "sum divided by number" and write as in the
                      order, avg=: +/ % # (+/ is sum, % is divide, # is number).

                      When I apply a verb I think about what that would result in(not the
                      detailed process).

                      > When I was doing APL, I was always thinking about the
                      > resulting /data/, since it was, after all, the answer that I was
                      > interested in.

                      Yes, I think more or less that way when writing verbs composed of
                      smaller verbs. I treat verbs as if they were data, and that's the
                      power of tacit programming, and natural language. When we are talking
                      about "average" we are actually treating verbs like nouns : "sum
                      divided by number", where sum, divided by, and number are all
                      functions(verbs) but treated here like nouns(result data).


                      >
                      > > So, gamescore could be interpreted in other languages as:
                      >
                      > > gamescore = cap(sum, fork(framex, take, scoreifframe))
                      >
                      > > (originally gamescore =: [: +/ framex { scoreifframe )
                      >
                      > > cap and fork are higher-order functions that take functions as
                      > > arguments and returns new functions as result. cap(f,g) is a new
                      > > function that does f(g(y)). fork(f,g,h) is a new function that does
                      > > g(f(x,y),h(x,y)).
                      >
                      > I'm not clear on what this means, in this case. In particular I
                      > don't see where the x and y are coming from in the line above, which
                      > is the last line of the program.

                      Sorry for not being elaborate on that. J's verb(function) can have one
                      or two arguments. When there are one argument, its default name is y,
                      and when two, they are x and y from left to right, respectively.

                      * is a verb, and when it has two arguments it's called "times", which
                      is just multiplication.
                      3 * 4 is 12. When it has one argument, it's called "signum", of which
                      result can be 1, 0, or -1 depending on the sign of the number. * 5 is
                      1, since 5 is a positive number. Here, 3 and 4 are traditionally
                      called x and y, respectively and 5 is called y. x is on the left side
                      of the verb and y is on the right side.

                      The confusion comes from mixing J's way and other languages way to
                      explain the idea.

                      I will use pythonic syntax to describe this again:
                      gamescore= cap(sum, fork(framex, take, scoreifframe))

                      Now I can use gamescore as:
                      gamescore([2,3, 4,5, 0,0, ...])

                      Then it is proceeded(or expanded) as:

                      sum(take(framex([2,3,4,5,...]), scoreifframe([2,3,4,5,...])))

                      In this case only one argument is given and fork(f,g,h)(y) works as
                      g(f(y),h(y))

                      When two arguments are given as fork(f,g,h)(x,y), it works as g(f(x,y),h(x,y))

                      Now in J context,
                      frk1=: f g h NB. when three verbs are in a row(called train), they
                      automatically become a fork
                      foobar=: 1 2 3
                      frk1 foobar NB. this is equivalent to (f foobar) g (h foobar)

                      >
                      > I'll start from the inside. Following your words above, it sounds
                      > like fork(framex, take, scoreiffframe) (fork(f,g,h)) is a new
                      > function applying to x,y that does
                      >
                      > take(framex(x,y), scoreiffframe(x,y))
                      >

                      Almost correct. In this case only one argument is given, and
                      take(framex(y), scoreifframe(y)) is supposed. (BTW, every verbs can be
                      monadic or dyadic when applying, if they have respective definition
                      already; here framex and scoreifframe are monadic and take is dyadic)

                      > The framex call produces the indexes of the balls that start the
                      > frames; the scoreifframe scores that frame. (I'm still not sure what
                      > x and y are here, but it may not matter.)
                      >
                      > I assume that since take knows its arguments are functions (verbs)
                      > that it may (must?) evaluate the second function, scoreifframe, only
                      > where framex has an index).

                      No. Three verbs in a row is such a useful and frequently used concept,
                      they are automatically transformed into a new verb. Take doesn't need
                      to know whether its arguments are functions or nouns.

                      More over the definition for a fork is quite mathematical and you
                      don't need to, and shouldn't worry about the sequence of processing
                      inside the fork.

                      Calculating the element only where framex has an index and use it
                      appropriately to get score of the frame is feasible in J but it
                      doesn't do that as default. It's because we can't generally guess
                      there are one-to-one sequential mapping between the rolls argument and
                      the result of scoreifframe.

                      >
                      > In the ruby code, this would be as if we called our frame_score
                      > method somehow after running the frame_starts method, so that we
                      > don't evaluate the rolls that do not start a frame.

                      As I wrote above, J calculates all frame starts and all frame scores
                      and then take between them. However, in this specific problem and
                      solution, the way you described can be easily implemented in J.

                      > I'm not sure
                      > whether it would be possible to write that in Ruby so that it felt
                      > as much like a vector operation as the current code does to me,
                      > but I'd guess we could do much the same thing by passing in a
                      > block. Might be worth a try, if I can come to understand more
                      > clearly what the J code does.
                      >
                      > I don't expect it to feel entirely the same, of course, since J is
                      > manipulating functions (verbs), and Ruby is manipulating data.
                      > Interesting to try, though ...
                      >
                      > Suppose we built a method take, that instead of simply processing
                      > two arrays, took two blocks, and iterated the first one, calling
                      > yield on the other ... I bet I could do it ...
                      >

                      I think you should instead build a higher order function, say fork,
                      first. and then...

                      fork(framex, take, scoreifframe)

                      which returns a new function.

                      > Does the above stream of consciousness sound like I might
                      > understand, as well as an earthling might, what the take part of the
                      > code is doing? If not, please try again to smarten me up.
                      >
                      > Now for the cap part.
                      >
                      > > cap(f,g) is a new function that does f(g(y)).
                      >
                      > In our case, we have sum, and this function that is (as I envision
                      > it) returning the vector of frame-starting frame scores.
                      >
                      > So that means sum(the appropriate frame scorse), right? But what I
                      > don't understand is what the cap was good for.
                      >
                      > I thought that +/ (1 2 3) already meant 1 + 2 + 3. So what was it
                      > that made it necessary or desirable to put the cap in there?

                      Suppose, also in pythonic syntax, you have two functions, each named
                      closeEyes and openEyes, which take aPerson as an argument.

                      Now you want to make a new function named wink.

                      wink=cap(closeEyes, openEyes)

                      You can use wink as: wink(aPerson)

                      Now, you might wonder what happens when two verbs are put in a row in J?

                      plus=:+
                      sqr=:*:
                      foo=:plus sqr

                      Here foo is a new verb, or function and it isn't same as [: plus sqr,
                      which is plus(sqr y).

                      Two verbs in a row is automatically transformed into a new verb and
                      it's called a hook. What foo does is, "add(plus) square". So, foo 4 is
                      20(4+ 4^2).

                      >
                      > >> That's what
                      > >>
                      > >> framex { scoreifframe
                      > >>
                      > >> means: take the array framex and index it into the array scoreifframe,
                      > >> returning those values and dropping the others. In other words,
                      > >> something like 2 4 {. 10 20 30 40 50 will equal 30 50.
                      >
                      > > Actually, no.
                      >
                      > > 2 4 {. 10 20 30 40 50
                      > > |length error
                      > > | 2 4 {.10 20 30 40 50
                      >
                      > > {. is take and is different from {, which is called "from". {. takes x
                      > > elements from the start of the vector.
                      >
                      > > 2 {. 10 20 30 40 50
                      > > 10 20
                      >
                      > > In the upper case, where the x was 2 4, the rank(dimension) doesn't
                      > > match right, so you get the length error.
                      >
                      > I'm not sure whether this comment is a red herring or not, in light
                      > of the cap/fork discussion. What would
                      >
                      > framex { scoreifframe
                      >
                      > do, all on its own?

                      They don't do anything. When typed in in the interpreter, the
                      interpreter shows the parsed result of the newly created verb.

                      framex { scoreifframe
                      framex { scoreifframe
                      +------+-+------------+
                      |framex|{|scoreifframe|
                      +------+-+------------+

                      This shows that framex { scoreifframe is a fork.

                      > I suppose I should download J and find out.
                      > After I download Rake and REXML and ... <sigh/>
                      >

                      You should try Studio > Labs, which is an interactive tutor system.

                      > >> In J, that operation is called "take". Let's call
                      > >> it that.
                      >
                      > > It's called "from". take is a different one, and you can see it used
                      > > in the definition of framex, where it is used to take just 10 indexes
                      > > of frame starts. (10 {. y)
                      >
                      > OK ...
                      >
                      > >> 90 expected, got zero. Let's see what has to happen to make
                      > >> it work. The frame_start indexes are ust fine. The scores for each
                      > >> roll, assuming it's the first roll of a frame, aren't.
                      >
                      > > Minor typo here: ust fine ==> just fine
                      >
                      > Thanks ... I'm fixing that as we "speak", in another thread.
                      >
                      > > I think in programming languages like Io(http://iolanguage.com), which
                      > > is greatly malleable, you can easily and closely mimic array-oriented
                      > > languages like APL and J. As I remember there have been many attempts
                      > > to hybrid OOPL and array-oriented programming languages. One approach
                      > > was to embed AOP on top of generic OOPL, like Java and smalltalk(I
                      > > remember having seen some papers from ACM digital library), the other
                      > > one was to build OOP facility on top of AOPLs(J and APL have OOP
                      > > features).
                      >
                      > Yes ... I've played with similar ideas in my Extended Set Theory
                      > days, and also when I was reading /Recursive Programming
                      > Techniques/, by Burge, and fiddling with APL. The hybrid approaches
                      > that I've tried haven't gone together very well, but I haven't
                      > looked at Io or J. Perhaps I should ...
                      >
                      > > I find your ruby approach was quite similar to the J version except
                      > > the way frame start index is extracted and each frame score is
                      > > calculated.
                      >
                      > Yes ... I think I see that part of that is that the frame score is
                      > calculated only for appropriate frames in the J approach,

                      No, it isn't. But it's very easy to modify into that approach.

                      gamescore=: [: +/ framex { scoreifframe

                      should be changed into

                      gamescore=: [: +/ framex onlyfrom scoreifframe

                      It's all done when onlyfrom is defined. Here onlyfrom is a
                      conjunction. Conjunction is a binary operator(can be user-defined),
                      which takes two verbs(left and right) as its arguments. What onlyfrom
                      does is calculate left verb first and only pass the indexed arguments
                      to the right verb.


                      > and for
                      > all frames in mine. That was due to my not knowing what cap/fork
                      > stuff is about. (And I still don't, I regret to say.)
                      >
                      > (The typo is fixed now, that thread reports ...)
                      >
                      > > framex does a very interesting way. It builds an index of "the start
                      > > index of next frame" and then loops over({~^:a:) the index to get the
                      > > all start indexes of all frames. This is a powerful idea(as Alan Kay
                      > > and Seymour Papert says).
                      >
                      > Isn't that analogous to what the Ruby program does with the inject?
                      > I can't read the little bit of code there to be sure ...
                      >

                      It's different. I'll show you.

                      You can refactor framex into several pieces:

                      f2=:{~^:a:~
                      f3=:_1 _1 ,~ i.@# >:@:+ 10&~:
                      f1=:0 f2 f3
                      framex =: 10 {. f1

                      How do I know where to cut? As I wrote above already, when you just
                      type in the name of a verb(or the verb itself), the interpreter shows
                      how it is parsed(you can choose the display mode as tree or
                      parathesized version as well).

                      What does f3 do here?
                      r=: 10 0 10 1 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0
                      f3 r
                      1 3 3 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 _1 _1

                      _1 _1 is for end sentinel.

                      Look at the result of f3 r. Start from index 0. The index for the
                      index of next frame start is 1(the start of second frame). Now read
                      index 1 of f3 r. It's 3(start of third frame). Now read index 3 of f3
                      r. It's 5(the start of fourth frame). And so on...

                      fii=:f3 r
                      0{ fii
                      1
                      1{fii
                      3
                      3{fii
                      5
                      5{fii
                      7
                      7{fii
                      9

                      The start index of frame for the roll r is 0, 1, 3, 5, 7, 9 , ...

                      This sequence of "from"ing is what f2 does. Until when? Until there is
                      a convergence(remember there are _1 _1 at the end). What f1 does is
                      let f2 sequence start from index 0(first frame) and repeatedly apply
                      the result of f3, which is constant now, as an argument of from({).

                      Finally framex takes only 10 frame starts.

                      > > scoreifframe does always cut each frame as three rolls compared to
                      > > yours, but adds conditionally.
                      >
                      > > 3 <\ 1 2 3 4 5
                      > > +-----+-----+-----+
                      > > |1 2 3|2 3 4|3 4 5|
                      > > +-----+-----+-----+
                      >
                      > > 3 +/\ 1 2 3 4 5
                      > > 6 9 12
                      >
                      > > \ is called infix, and < is a verb for boxing, +/ is, as you know
                      > > already, summing. \ runs through the vector and for each x elements do
                      > > the verb. \'s part of speech is conjunction.
                      >
                      > Yes, I think I understood that bit ... maybe. ;->
                      >
                      > > Finally, I see some difference in your style of TDDing from me. I try
                      > > to remove duplications in tests and try to cut the cases as "aspects".
                      > > My analogy is "rice rolled in dried laver", as we call it in Korea
                      > > Kimbab. http://images.google.co.kr/images?q=kimbab&sa=N&tab=wi You
                      > > can slice a Kimbab roll into pieces with varying sizes but every piece
                      > > has rice, carrot, spinach, dried seaweed and all the same ingridients.
                      > > If you disassemble the roll instead, you can get all of the
                      > > ingridients separate. In the test cases of open, spare, and perfect,
                      > > each one is testing separating frames, scoring each frame, summing
                      > > frames, and etc. The problem is that when there is any need to change
                      > > the code, due to the permeated aspects across many test cases, the
                      > > tests could be fragile and you are forced to change many of them at
                      > > once. (Of course those tests are valuable as integration tests.) I
                      > > think many uniformal test cases are a smell. When test cases are
                      > > written in ingrideints tests(disassembly), those cases reads like the
                      > > rules(declarative) described in the original requirements.
                      >
                      > I would be delighted to see an example of that style of TDD, in a
                      > language I can understand such as Ruby, Java, C#. From the
                      > description, I'm not quite getting it.

                      Sorry for not being clear.

                      When you are tdding a fibonacci sequence generator, you could follow
                      the steps of:

                      assert fibo(0) == 1
                      assert fibo(1) == 1
                      assert fibo(2) == 2
                      assert fibo(3) == 3
                      assert fibo(4) == 5
                      assert fibo(5) == 8

                      each being its own test case. You could feel confident enough just
                      doing those sequences.

                      What I prefer is, following the original problem statement:

                      Fibonacci sequence is a sequence that starts from 1 1 and then add the
                      last two numbers to get next.

                      Now I would compose todo list as:
                      fibo starts from 1 1
                      add last two numbers
                      fibo expands with the result above
                      and etc

                      The former example(fibo(n) == m) is showing uniformal test cases and I
                      think there is a bad smell. For each test case, you see add last two
                      and expand the sequence and the start is 1 1, all intermingled.

                      >
                      > > However, as you have written in your article, you seemed to have
                      > > chosen that way intentionally. And you have test cases like
                      > > test_frame_start_strike. So you do have both of ingridient tests and
                      > > slice tests.
                      >
                      > > BTW, I really respect your honesty and humbleness shown in the
                      > > article. I always learn a lot reading what you have wrote, not only on
                      > > technical sides but also on personality and attitude sides.
                      >
                      > Thanks.

                      My pleasure. I learned TDD and a lot more about programming from
                      you(including Kent and Ward, from reading c2.com) I can't thank you
                      enough.

                      > I try to combine a willingness to try things, a fascination
                      > with odd ways of solving problems, a confidence that everything will
                      > be all right, and a smiling recognition of how fallible I am (and
                      > most of us are).
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > Accept your conditions, but not your fate. -- Rod Walsh & Dan Carrison
                      >
                    • Ron Jeffries
                      ... Interesting ... I guess I d like to see an example worked out, especially where the algorithm isn t entirely known in advance. For example I wonder how
                      Message 10 of 20 , May 1, 2006
                      • 0 Attachment
                        On Sunday, April 30, 2006, at 9:34:29 PM, June Kim wrote:

                        >> > Finally, I see some difference in your style of TDDing from me. I try
                        >> > to remove duplications in tests and try to cut the cases as "aspects".
                        >> > My analogy is "rice rolled in dried laver", as we call it in Korea
                        >> > Kimbab. http://images.google.co.kr/images?q=kimbab&sa=N&tab=wi You
                        >> > can slice a Kimbab roll into pieces with varying sizes but every piece
                        >> > has rice, carrot, spinach, dried seaweed and all the same ingridients.
                        >> > If you disassemble the roll instead, you can get all of the
                        >> > ingridients separate. In the test cases of open, spare, and perfect,
                        >> > each one is testing separating frames, scoring each frame, summing
                        >> > frames, and etc. The problem is that when there is any need to change
                        >> > the code, due to the permeated aspects across many test cases, the
                        >> > tests could be fragile and you are forced to change many of them at
                        >> > once. (Of course those tests are valuable as integration tests.) I
                        >> > think many uniformal test cases are a smell. When test cases are
                        >> > written in ingrideints tests(disassembly), those cases reads like the
                        >> > rules(declarative) described in the original requirements.
                        >>
                        >> I would be delighted to see an example of that style of TDD, in a
                        >> language I can understand such as Ruby, Java, C#. From the
                        >> description, I'm not quite getting it.

                        > Sorry for not being clear.

                        > When you are tdding a fibonacci sequence generator, you could follow
                        > the steps of:

                        > assert fibo(0) == 1
                        > assert fibo(1) == 1
                        > assert fibo(2) == 2
                        > assert fibo(3) == 3
                        > assert fibo(4) == 5
                        > assert fibo(5) == 8

                        > each being its own test case. You could feel confident enough just
                        > doing those sequences.

                        > What I prefer is, following the original problem statement:

                        > Fibonacci sequence is a sequence that starts from 1 1 and then add the
                        > last two numbers to get next.

                        > Now I would compose todo list as:
                        > fibo starts from 1 1
                        > add last two numbers
                        > fibo expands with the result above
                        > and etc

                        > The former example(fibo(n) == m) is showing uniformal test cases and I
                        > think there is a bad smell. For each test case, you see add last two
                        > and expand the sequence and the start is 1 1, all intermingled.

                        Interesting ... I guess I'd like to see an example worked out,
                        especially where the algorithm isn't entirely known in advance. For
                        example I wonder how you'd use your style in TDDing bowling in a
                        conventional language ...

                        Thanks for the conversation and the help with J. Very interesting!

                        Ron Jeffries
                        www.XProgramming.com
                        A man hears what he wants to hear, and disregards the rest. -- Paul Simon
                      • Anthony Williams
                        ... I ve posted a C++ version to my blog: http://www.justsoftwaresolutions.co.uk/cplusplus/vector_bowling.html At 75 lines vs 72, it s not much different to
                        Message 11 of 20 , May 2, 2006
                        • 0 Attachment
                          Ron Jeffries <ronjeffries@...> writes:

                          > Bowling Vectors
                          > Ron Jeffries
                          > 04/26/2006
                          >
                          > June Kim posted a J Language version of bowling that is very
                          > vector-oriented. As an experiment, I coded up a vector-style
                          > version in Ruby, TDD of course. It turned out to be kind of
                          > interesting.
                          >
                          > http://www.xprogramming.com/xpmag/dbcBowlingVector.htm

                          I've posted a C++ version to my blog:

                          http://www.justsoftwaresolutions.co.uk/cplusplus/vector_bowling.html

                          At 75 lines vs 72, it's not much different to Ron's Ruby version in length,
                          and just as clear, in my opinion.

                          Anthony
                          --
                          Anthony Williams
                          Software Developer
                          Just Software Solutions Ltd
                          http://www.justsoftwaresolutions.co.uk
                        • Ian Collins
                          ... Interesting solution. One thing you could mention is all of the one line functions will probably be optimised away - it would be interesting to see the
                          Message 12 of 20 , May 2, 2006
                          • 0 Attachment
                            Anthony Williams wrote:

                            >Ron Jeffries <ronjeffries@...> writes:
                            >
                            >
                            >
                            >>Bowling Vectors
                            >>Ron Jeffries
                            >>04/26/2006
                            >>
                            >> June Kim posted a J Language version of bowling that is very
                            >> vector-oriented. As an experiment, I coded up a vector-style
                            >> version in Ruby, TDD of course. It turned out to be kind of
                            >> interesting.
                            >>
                            >> http://www.xprogramming.com/xpmag/dbcBowlingVector.htm
                            >>
                            >>
                            >
                            >I've posted a C++ version to my blog:
                            >
                            >http://www.justsoftwaresolutions.co.uk/cplusplus/vector_bowling.html
                            >
                            >At 75 lines vs 72, it's not much different to Ron's Ruby version in length,
                            >and just as clear, in my opinion.
                            >
                            >
                            >
                            Interesting solution.

                            One thing you could mention is all of the one line functions will
                            probably be optimised away - it would be interesting to see the
                            resulting assembler :)

                            Ian
                          • Ron Jeffries
                            ... It s certainly similar, and I imagine that to a person who was used to seeing C++ s rather excessive use of :: an , it s pretty clear. After a while one
                            Message 13 of 20 , May 3, 2006
                            • 0 Attachment
                              On Tuesday, May 2, 2006, at 9:55:48 AM, Anthony Williams wrote:

                              >>
                              >> June Kim posted a J Language version of bowling that is very
                              >> vector-oriented. As an experiment, I coded up a vector-style
                              >> version in Ruby, TDD of course. It turned out to be kind of
                              >> interesting.
                              >>
                              >> http://www.xprogramming.com/xpmag/dbcBowlingVector.htm

                              > I've posted a C++ version to my blog:

                              > http://www.justsoftwaresolutions.co.uk/cplusplus/vector_bowling.html

                              > At 75 lines vs 72, it's not much different to Ron's Ruby version in length,
                              > and just as clear, in my opinion.

                              It's certainly similar, and I imagine that to a person who was used
                              to seeing C++'s rather excessive use of :: an <>, it's pretty clear.
                              After a while one reads right past the noise characters.

                              However, I've been looking at a fair amount of actual C++ code
                              lately and I've never seen a one-line function. I've seen lots of
                              twenty, forty, even hundred-line functions.

                              Your example shows that it is /possible/ to write C++ in that style
                              ... but would you, and would a typical on-the-ground C++ programmer
                              really write that way?

                              (On the other hand, would a typical on-the-ground Ruby or C#
                              programmer write the way I do? I have my doubts about that, too.)

                              Ron Jeffries
                              www.XProgramming.com
                              Replacing an on-site customer with some use cases is about as effective
                              as replacing a hug from your Mom with a friendly note.
                            • Tim Dugan
                              Regarding this.. [...] been looking at a fair amount of actual C++ code lately and I ve never seen a one-line function. I ve seen lots of twenty, forty, even
                              Message 14 of 20 , May 3, 2006
                              • 0 Attachment
                                Regarding this..

                                "[...] been looking at a fair amount of actual C++ code lately and I've
                                never seen a one-line function. I've seen lots of twenty, forty, even
                                hundred-line functions."

                                Perhaps a lot of programmers have weak programming style? :)

                                Previously when I did C++ and now, with Java, I definitely write a
                                significant number of 1-line methods--and not just "accessors" and
                                "setters". I suspect most programmers don't write one-line methods
                                because they view a method as a unit of work to be coded, not as an
                                abstraction of how an object works.

                                One of the developers I was working with recently said he prefers long
                                methods over multiple short ones because it's easier to tell where you
                                are in the debugger.

                                Tim Dugan, Technical Lead - O&D/RTDP
                                PROS Revenue Management
                                (713)335-7942, tdugan@...

                                -----Original Message-----
                                From: extremeprogramming@yahoogroups.com
                                [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Ron Jeffries
                                Sent: Wednesday, May 03, 2006 6:29 AM
                                To: extremeprogramming@yahoogroups.com
                                Subject: Re: [XP] Re: New Articles on XProgramming.com

                                On Tuesday, May 2, 2006, at 9:55:48 AM, Anthony Williams wrote:

                                >>
                                >> June Kim posted a J Language version of bowling that is very
                                >> vector-oriented. As an experiment, I coded up a vector-style
                                >> version in Ruby, TDD of course. It turned out to be kind of
                                >> interesting.
                                >>
                                >> http://www.xprogramming.com/xpmag/dbcBowlingVector.htm

                                > I've posted a C++ version to my blog:

                                > http://www.justsoftwaresolutions.co.uk/cplusplus/vector_bowling.html

                                > At 75 lines vs 72, it's not much different to Ron's Ruby version in
                                length,
                                > and just as clear, in my opinion.

                                It's certainly similar, and I imagine that to a person who was used
                                to seeing C++'s rather excessive use of :: an <>, it's pretty clear.
                                After a while one reads right past the noise characters.

                                However, I've been looking at a fair amount of actual C++ code
                                lately and I've never seen a one-line function. I've seen lots of
                                twenty, forty, even hundred-line functions.

                                Your example shows that it is /possible/ to write C++ in that style
                                ... but would you, and would a typical on-the-ground C++ programmer
                                really write that way?

                                (On the other hand, would a typical on-the-ground Ruby or C#
                                programmer write the way I do? I have my doubts about that, too.)

                                Ron Jeffries
                                www.XProgramming.com
                                Replacing an on-site customer with some use cases is about as effective
                                as replacing a hug from your Mom with a friendly note.



                                To Post a message, send it to: extremeprogramming@...

                                To Unsubscribe, send a blank message to:
                                extremeprogramming-unsubscribe@...

                                ad-free courtesy of objectmentor.com
                                Yahoo! Groups Links









                                The information contained in this email may be confidential and/or legally privileged. It has been sent for the sole use of the intended recipient(s). If the reader of this message is not an intended recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. If you have received this communication in error, please contact the sender by reply email and destroy all copies of the original message. Thank you
                              • Anthony Williams
                                ... ... There s a lot of badly structured C++ out there, much of it written by quite competent programmers. I ve inherited code with thousand-line
                                Message 15 of 20 , May 3, 2006
                                • 0 Attachment
                                  Ron Jeffries <ronjeffries@...> writes:

                                  > On Tuesday, May 2, 2006, at 9:55:48 AM, Anthony Williams wrote:
                                  >
                                  >>>
                                  >>> June Kim posted a J Language version of bowling that is very
                                  >>> vector-oriented. As an experiment, I coded up a vector-style
                                  >>> version in Ruby, TDD of course. It turned out to be kind of
                                  >>> interesting.
                                  >>>
                                  >>> http://www.xprogramming.com/xpmag/dbcBowlingVector.htm
                                  >
                                  >> I've posted a C++ version to my blog:
                                  >
                                  >> http://www.justsoftwaresolutions.co.uk/cplusplus/vector_bowling.html
                                  >
                                  >> At 75 lines vs 72, it's not much different to Ron's Ruby version in length,
                                  >> and just as clear, in my opinion.
                                  >
                                  > It's certainly similar, and I imagine that to a person who was used
                                  > to seeing C++'s rather excessive use of :: an <>, it's pretty clear.
                                  > After a while one reads right past the noise characters.

                                  <G>

                                  > However, I've been looking at a fair amount of actual C++ code
                                  > lately and I've never seen a one-line function. I've seen lots of
                                  > twenty, forty, even hundred-line functions.

                                  There's a lot of badly structured C++ out there, much of it written by quite
                                  competent programmers. I've inherited code with thousand-line functions
                                  before, but that doesn't make it good C++ style.

                                  > Your example shows that it is /possible/ to write C++ in that style
                                  > ... but would you, and would a typical on-the-ground C++ programmer
                                  > really write that way?

                                  I'm most definitely an "on-the-ground C++ programmer", since I do most of my
                                  work using C++. I'm fairly sure I'm not typical, though --- I use TDD, for
                                  starters, even on GUI stuff.

                                  I refactor my code until it's clear. Sometimes that means one line functions,
                                  sometimes not. Bowling actually seems quite conducive to short functions.

                                  SourceMonitor tells me that my average on a recent 30k-line project is 3.1
                                  lines/function for non-test code. Even so, many of the functions are more
                                  complex than I'd like; I just haven't devoted the time to make them shorter.

                                  > (On the other hand, would a typical on-the-ground Ruby or C#
                                  > programmer write the way I do? I have my doubts about that, too.)

                                  ;-)

                                  Anthony
                                  --
                                  Anthony Williams
                                  Software Developer
                                  Just Software Solutions Ltd
                                  http://www.justsoftwaresolutions.co.uk
                                • Ron Jeffries
                                  ... There are a lot that don t follow the same style guidelines as I do, anyway ... ... Don t know. I really don t understand what folks are doing. ... I
                                  Message 16 of 20 , May 3, 2006
                                  • 0 Attachment
                                    On Wednesday, May 3, 2006, at 8:33:08 AM, Tim Dugan wrote:

                                    > Regarding this..

                                    > "[...] been looking at a fair amount of actual C++ code lately and I've
                                    > never seen a one-line function. I've seen lots of twenty, forty, even
                                    > hundred-line functions."

                                    > Perhaps a lot of programmers have weak programming style? :)

                                    There are a lot that don't follow the same style guidelines as I do,
                                    anyway ...

                                    > Previously when I did C++ and now, with Java, I definitely write a
                                    > significant number of 1-line methods--and not just "accessors" and
                                    > "setters". I suspect most programmers don't write one-line methods
                                    > because they view a method as a unit of work to be coded, not as an
                                    > abstraction of how an object works.

                                    Don't know. I really don't understand what folks are doing.

                                    > One of the developers I was working with recently said he prefers long
                                    > methods over multiple short ones because it's easier to tell where you
                                    > are in the debugger.

                                    I laugh, I cry.

                                    On Wednesday, May 3, 2006, at 8:43:07 AM, Anthony Williams wrote:

                                    > I'm most definitely an "on-the-ground C++ programmer", since I do most of my
                                    > work using C++. I'm fairly sure I'm not typical, though --- I use TDD, for
                                    > starters, even on GUI stuff.

                                    > I refactor my code until it's clear. Sometimes that means one line functions,
                                    > sometimes not. Bowling actually seems quite conducive to short functions.

                                    > SourceMonitor tells me that my average on a recent 30k-line project is 3.1
                                    > lines/function for non-test code. Even so, many of the functions are more
                                    > complex than I'd like; I just haven't devoted the time to make them shorter.

                                    Yes ... that average is way lower than what I see, even among C++
                                    folks who are allegedly very good. I think there may be a thing in
                                    more, um, mature programmers who accept longer code, though I am
                                    old, if not mature, and I wrote tiny routines in C. Even assembler.

                                    I just don't get it, sometimes ... some people's kids ...

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Fear is the mindkiller. --Bene Gesserit Litany Against Fear
                                  • Keith Ray
                                    I ve seen Java code just with just as many large methods and large classes as C++. The mozilla project has some c++ methods that are several 1000 s of lines
                                    Message 17 of 20 , May 3, 2006
                                    • 0 Attachment
                                      I've seen Java code just with just as many large methods and large
                                      classes as C++.

                                      The mozilla project has some c++ methods that are several 1000's of
                                      lines long -- a very fertile source for writing about code smells and
                                      refactoring. ;-)

                                      On 5/3/06, Ron Jeffries <ronjeffries@...> wrote:
                                      > On Wednesday, May 3, 2006, at 8:33:08 AM, Tim Dugan wrote:
                                      >
                                      > > Regarding this..
                                      >
                                      > > "[...] been looking at a fair amount of actual C++ code lately and I've
                                      > > never seen a one-line function. I've seen lots of twenty, forty, even
                                      > > hundred-line functions."
                                      >
                                      > > Perhaps a lot of programmers have weak programming style? :)
                                      >
                                      > There are a lot that don't follow the same style guidelines as I do,
                                      > anyway ...
                                      >
                                      > > Previously when I did C++ and now, with Java, I definitely write a
                                      > > significant number of 1-line methods--and not just "accessors" and
                                      > > "setters". I suspect most programmers don't write one-line methods
                                      > > because they view a method as a unit of work to be coded, not as an
                                      > > abstraction of how an object works.
                                      >
                                      > Don't know. I really don't understand what folks are doing.
                                      >
                                      > > One of the developers I was working with recently said he prefers long
                                      > > methods over multiple short ones because it's easier to tell where you
                                      > > are in the debugger.
                                      >
                                      > I laugh, I cry.
                                      >
                                      > On Wednesday, May 3, 2006, at 8:43:07 AM, Anthony Williams wrote:
                                      >
                                      > > I'm most definitely an "on-the-ground C++ programmer", since I do most of my
                                      > > work using C++. I'm fairly sure I'm not typical, though --- I use TDD, for
                                      > > starters, even on GUI stuff.
                                      >
                                      > > I refactor my code until it's clear. Sometimes that means one line functions,
                                      > > sometimes not. Bowling actually seems quite conducive to short functions.
                                      >
                                      > > SourceMonitor tells me that my average on a recent 30k-line project is 3.1
                                      > > lines/function for non-test code. Even so, many of the functions are more
                                      > > complex than I'd like; I just haven't devoted the time to make them shorter.
                                      >
                                      > Yes ... that average is way lower than what I see, even among C++
                                      > folks who are allegedly very good. I think there may be a thing in
                                      > more, um, mature programmers who accept longer code, though I am
                                      > old, if not mature, and I wrote tiny routines in C. Even assembler.
                                      >
                                      > I just don't get it, sometimes ... some people's kids ...
                                      >
                                      > Ron Jeffries
                                      > www.XProgramming.com
                                      > Fear is the mindkiller. --Bene Gesserit Litany Against Fear
                                      >
                                      >
                                      >
                                      > To Post a message, send it to: extremeprogramming@...
                                      >
                                      > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                      >
                                      > ad-free courtesy of objectmentor.com
                                      > Yahoo! Groups Links
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >


                                      --

                                      C. Keith Ray
                                      <http://homepage.mac.com/keithray/blog/index.html>
                                      <http://homepage.mac.com/keithray/xpminifaq.html>
                                      <http://homepage.mac.com/keithray/resume2.html>
                                    • Ron Jeffries
                                      ... Yes, I ve seen the same. I think that the C++ I see is worse than the Java / C# by a small margin. It might just be older. Or the programmers might ... but
                                      Message 18 of 20 , May 3, 2006
                                      • 0 Attachment
                                        On Wednesday, May 3, 2006, at 10:44:06 AM, Keith Ray wrote:

                                        > I've seen Java code just with just as many large methods and large
                                        > classes as C++.

                                        > The mozilla project has some c++ methods that are several 1000's of
                                        > lines long -- a very fertile source for writing about code smells and
                                        > refactoring. ;-)

                                        Yes, I've seen the same. I think that the C++ I see is worse than
                                        the Java / C# by a small margin. It might just be older. Or the
                                        programmers might ... but I'm generally older than any two of them,
                                        and my code doesn't seem to be coming in larger methods lately ...

                                        Ron Jeffries
                                        www.XProgramming.com
                                        Learn from yesterday, live for today, hope for tomorrow.
                                        The important thing is to not stop questioning. --Albert Einstein
                                      • Ian Collins
                                        ... Yes, as others have said there is a lot of legacy C++ with stupidly long functions out there. But that code wasn t written test first. My code has lots of
                                        Message 19 of 20 , May 3, 2006
                                        • 0 Attachment
                                          Ron Jeffries wrote:

                                          >
                                          >Your example shows that it is /possible/ to write C++ in that style
                                          >... but would you, and would a typical on-the-ground C++ programmer
                                          >really write that way?
                                          >
                                          >
                                          >
                                          Yes, as others have said there is a lot of legacy C++ with stupidly long
                                          functions out there. But that code wasn't written test first.

                                          My code has lots of very short functions, a practice that is actively
                                          encouraged in Stroustrup's "The C++ Programming Language".

                                          Sort functions are very efficient in C++ as they tend to by inlined away
                                          by the compiler, a fact many programmers tend to overlook.

                                          Ian
                                        • Ron Jeffries
                                          Two articles this time, one on estimating the Shotgun Pattern project, and one showing some more of our spike code. Readers have been chiming in with estimates
                                          Message 20 of 20 , Dec 3, 2006
                                          • 0 Attachment
                                            Two articles this time, one on estimating the Shotgun Pattern
                                            project, and one showing some more of our spike code.

                                            Readers have been chiming in with estimates and sorting us out on
                                            how to use the Internet to find useful Java image code.

                                            Shooting for Estimates
                                            Ron Jeffries
                                            12/03/2006

                                            Input from a few readers, and our initial estimates for the
                                            shooting project.

                                            http://www.xprogramming.com/xpmag/dbcShootingForEstimates.htm

                                            Darker Before the Dawn
                                            Ron Jeffries
                                            12/03/2006

                                            Our first spike took a bit longer than we had hoped, but we
                                            successfully interpreted a BMP file. We worked to improve our
                                            code, while people wrote to us to tell us how ignorant we are. Fun
                                            all around.

                                            http://www.xprogramming.com/xpmag/dbcDarkerBeforeTheDawn.htm

                                            Ron Jeffries
                                            www.XProgramming.com
                                            Agility is not an inescapable law of purity
                                            but a pragmatic principle of effectiveness. -- Marc Hamann
                                          Your message has been successfully submitted and would be delivered to recipients shortly.