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

Re: [XP] Design Agility? (was: Duplication vs Intention Revealing code)

Expand Messages
  • Ron Jeffries
    ... Interesting question. I wouldn t bias the design in anticipation of that requirement, but I d guess we might, upon receiving the next one, work like this:
    Message 1 of 17 , Jun 1, 2005
    • 0 Attachment
      On Wednesday, June 1, 2005, at 1:53:09 PM, Steve Bate wrote:

      > Let's say your customer tells you there's an additional
      > requirement. Your code must also support representing numbers
      > as German words.

      > Although this is a simpler requirement than full I18N I
      > suspect it will have a significant impact on the designs. How
      > could we measure the agility of the existing designs? For
      > example, would the percentage of statements modified be a
      > useful metric for this purpose? Could that percentage also
      > tell us whether the original design "evolved" or a new one
      > was created?

      > Which design would be the most agile given the additional
      > requirement and why?

      Interesting question. I wouldn't bias the design in anticipation of
      that requirement, but I'd guess we might, upon receiving the next
      one, work like this:

      Use what we have learned to build the German one separately; it
      wouldn't take long, since it didn't take long the first time.

      Observe the similarities and duplications; extract them, probably
      mostly into parameterized tables; perhaps somewhat into strategy
      objects or the like.

      I'd expect to get the two languages done faster that way than if I
      had tried to design a "general solution".

      But I don't know that ... I just /expect/ that.

      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.
    • Steve Bate
      ... http://www.smartphrase.com/German/ge_numbers_voc.shtml ... It wouldn t be a big problem in this case to rewrite all the code since it s a relatively small
      Message 2 of 17 , Jun 1, 2005
      • 0 Attachment
        > > Which design would be the most agile given the additional
        > > requirement and why?
        >
        > I'd have to see a representative sample of German numbers
        > to make any kind of a guess. My German is way too far
        > behind me to remember much more than ein, zewi, drei,
        > vier und zwanzig (blackbirds or some such.)

        http://www.smartphrase.com/German/ge_numbers_voc.shtml

        > Quite frankly, I wouldn't use that as any kind of a criterion
        > for agility; I'd expect to rewrite it from scratch and look at
        > the surrounding system to see how easy it would be to
        > do that without having to make massive changes elsewhere.

        It wouldn't be a big problem in this case to rewrite all the
        code since it's a relatively small function. This issue
        can also apply to larger programs when I18N is added after an
        initial implementation (rather than being specified up front).
        Rewriting a large application might not be considered an
        acceptable solution for some (many?) customers.

        Steve
      • Steve Bate
        ... Would you write the German version using the same basic technique as the English version? If so, wouldn t you effectively be rewriting the program twice
        Message 3 of 17 , Jun 1, 2005
        • 0 Attachment
          > > Which design would be the most agile given the additional
          > > requirement and why?
          >
          > Interesting question. I wouldn't bias the design in anticipation of
          > that requirement, but I'd guess we might, upon receiving the next
          > one, work like this:
          >
          > Use what we have learned to build the German one separately; it
          > wouldn't take long, since it didn't take long the first time.
          >
          > Observe the similarities and duplications; extract them, probably
          > mostly into parameterized tables; perhaps somewhat into strategy
          > objects or the like.

          Would you write the German version using the same basic technique
          as the English version? If so, wouldn't you effectively be rewriting
          the program twice (once for German and once for the merged version)?

          I like this strategy because it will work for additional languages
          (e.g., if I ask for Kanji or Swahili in the next iteration).

          > I'd expect to get the two languages done faster that way than if I
          > had tried to design a "general solution".
          >
          > But I don't know that ... I just /expect/ that.

          I understand. Can you explain what considerations or experience
          would lead you to expect that result? It does seem like there'd
          be a lot of duplicated work to implement separate solutions and
          then merge them. (Imagine this is a larger program instead of
          a relatively small function.)

          Steve
        • Ron Jeffries
          ... But rewriting an entire application in order to internationalize it seems extremely unlikely, especially if it has any reasonable design structure at all,
          Message 4 of 17 , Jun 1, 2005
          • 0 Attachment
            On Wednesday, June 1, 2005, at 5:13:36 PM, Steve Bate wrote:

            > It wouldn't be a big problem in this case to rewrite all the
            > code since it's a relatively small function. This issue
            > can also apply to larger programs when I18N is added after an
            > initial implementation (rather than being specified up front).
            > Rewriting a large application might not be considered an
            > acceptable solution for some (many?) customers.

            But rewriting an entire application in order to internationalize it
            seems extremely unlikely, especially if it has any reasonable design
            structure at all, n'est pas? Nicht wahr? Eh?

            Ron Jeffries
            www.XProgramming.com
            If it is more than you need, it is waste. -- Andy Seidl
          • Ron Jeffries
            ... Well, as I think I said, I d use what I had learned to write the second one. So I might use the same techniques ... certainly if I was happy with the way
            Message 5 of 17 , Jun 1, 2005
            • 0 Attachment
              On Wednesday, June 1, 2005, at 5:51:25 PM, Steve Bate wrote:

              >> Use what we have learned to build the German one separately; it
              >> wouldn't take long, since it didn't take long the first time.
              >>
              >> Observe the similarities and duplications; extract them, probably
              >> mostly into parameterized tables; perhaps somewhat into strategy
              >> objects or the like.

              > Would you write the German version using the same basic technique
              > as the English version? If so, wouldn't you effectively be rewriting
              > the program twice (once for German and once for the merged version)?

              Well, as I think I said, I'd use what I had learned to write the
              second one. So I might use the same techniques ... certainly if I
              was happy with the way it came out, or if I was looking to converge
              the two solutions, I would.

              I would be writing the program once again, but with more knowledge
              than last time, so I'd expect it to go even faster and better;

              I would be watching for opportunities to reuse what I already had,
              and would use those opportunities as soon as they seemed, well,
              reusable;

              I would then refactor to remove duplication, which is as unlike
              rewriting the code as reordering these three paragraphs would be
              unlike rewriting them.

              Demonstration ...

              I would be writing the program once again, but with more knowledge
              than last time, so I'd expect it to go even faster and better;

              I would then refactor to remove duplication, which is as unlike
              rewriting the code as reordering these three paragraphs would be
              unlike rewriting them.

              I would be watching for opportunities to reuse what I already had,
              and would use those opportunities as soon as they seemed, well,
              reusable;

              Drag, copy, click new location, paste, drag, cut, click new
              location, paste. Not much like rewrite at all. Let's remove more
              duplication ...

              I would ...

              be writing the program once again, but with more knowledge
              than last time, so I'd expect it to go even faster and better;

              then refactor to remove duplication, which is as unlike
              rewriting the code as reordering these three paragraphs would be
              unlike rewriting them.

              be watching for opportunities to reuse what I already had,
              and would use those opportunities as soon as they seemed, well,
              reusable;

              See? Not like rewrite at all. :)

              > I like this strategy because it will work for additional languages
              > (e.g., if I ask for Kanji or Swahili in the next iteration).

              Yes ... and I'd expect that the solution I had would become more
              general each time, and that I'd become more experienced (if not
              smarter) each time, and that pretty soon I'd be the king of numbers
              to text. Maybe. :)

              Ron Jeffries
              www.XProgramming.com
              Curiosity is more powerful than skepticism.
            • Steve Bate
              ... It depends. In this smaller application, the design structure seems reasonable but apparently didn t eliminate the need to rewrite it for the I18N
              Message 6 of 17 , Jun 1, 2005
              • 0 Attachment
                Ron wrote:
                >
                > On Wednesday, June 1, 2005, at 5:13:36 PM, Steve Bate wrote:
                > > It wouldn't be a big problem in this case to rewrite all the
                > > code since it's a relatively small function. This issue
                > > can also apply to larger programs when I18N is added after an
                > > initial implementation (rather than being specified up front).
                > > Rewriting a large application might not be considered an
                > > acceptable solution for some (many?) customers.
                >
                > But rewriting an entire application in order to internationalize it
                > seems extremely unlikely, especially if it has any reasonable design
                > structure at all, n'est pas? Nicht wahr? Eh?

                It depends. In this smaller application, the design structure
                seems reasonable but apparently didn't eliminate the need to
                rewrite it for the I18N requirement. The same could be true
                for some larger applications (and not true for many others).

                Maybe we should be careful in judging the reasonableness of
                design structure based on a need for significant rewrites after
                new requirements are identified. That's more or less why I
                mentioned the metric for design agility. I don't believe it's
                a great metric, but it's one that some people seem to use
                informally to judge other people's designs.

                Steve
              • yahoogroups@jhrothjr.com
                From: Steve Bate To: extremeprogramming@yahoogroups.com
                Message 7 of 17 , Jun 1, 2005
                • 0 Attachment
                  From: "Steve Bate" <steve.at.technoetic.com@...>
                  To: "extremeprogramming@yahoogroups.com"
                  <extremeprogramming.at.yahoogroups.com@...>
                  Sent: Wednesday, June 01, 2005 3:13 PM
                  Subject: RE: [XP] Design Agility? (was: Duplication vs Intention Revealing
                  code)


                  >> > Which design would be the most agile given the additional
                  >> > requirement and why?
                  >>
                  >> I'd have to see a representative sample of German numbers
                  >> to make any kind of a guess. My German is way too far
                  >> behind me to remember much more than ein, zewi, drei,
                  >> vier und zwanzig (blackbirds or some such.)
                  >
                  > http://www.smartphrase.com/German/ge_numbers_voc.shtml
                  >
                  >> Quite frankly, I wouldn't use that as any kind of a criterion
                  >> for agility; I'd expect to rewrite it from scratch and look at
                  >> the surrounding system to see how easy it would be to
                  >> do that without having to make massive changes elsewhere.
                  >
                  > It wouldn't be a big problem in this case to rewrite all the
                  > code since it's a relatively small function. This issue
                  > can also apply to larger programs when I18N is added after an
                  > initial implementation (rather than being specified up front).
                  > Rewriting a large application might not be considered an
                  > acceptable solution for some (many?) customers.

                  This is one of those things I consider a "scare story". The
                  fact is that an application which is very heavily oriented toward
                  text processing in English might need a complete rewrite to
                  internationalize it, but most applications that one would want
                  to internationalize after the fact aren't quite as text intensive.

                  Let's take an example I'm familiar with: PyFIT (the Python
                  port of FIT and FitLibrary.) Internationalization is a topic
                  we're probably going to be discussing in the next few months.
                  From my viewpoint, it's not going to be a difficult problem.

                  One might think that Fit does a lot of text processing, and that
                  would be true. However, most of the work revolves around
                  two issues: converting a "user friendly" name to a Python
                  identifier, and localizing error messages on the way back.

                  I've already got a leg up on the first because I support both
                  batch and FitNesse in one package, which means that I
                  already have three different algorithms to convert an external
                  name to an identifier, and the mechanism to decide which one
                  to use.

                  That mechanism is undoubtedly going to have to be extended
                  in a couple of ways (one of which I'd be doing anyway, even
                  if I wasn't thinking about internationalization), but it isn't going to
                  cause a humongous revolution in the code base.

                  The other issue is localization of error messages. As it turns
                  out, I already have a central table of error messages, indexed
                  by code and with parameters to insert. All of that mechanism
                  is embedded in one exception. The reason for that table isn't
                  looking ahead: the table has 43 messages,
                  and I've been a bad boy: there are still quite a few
                  places where I just raise Exception with a message. I'm going
                  to have to centralize those, but that's a few hours of drudgery
                  that is payback for not doing it right once I'd built the mechanism.

                  I expect there will be a few more items in the type adapters
                  having to do with locale dependent stuff, and a lot of it is
                  going to be a learning experiance, but most of it will yield
                  fairly readily.

                  John Roth






                  >
                  > Steve
                  >
                  >
                  >
                  > 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
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                • Steve Bate
                  ... I ve found that sometimes this is true and sometimes it isn t. There are going to be some subtle and not-so-subtle differences between the languages and
                  Message 8 of 17 , Jun 1, 2005
                  • 0 Attachment
                    Ron wrote:
                    >...
                    > I would ...
                    >
                    > be writing the program once again, but with more knowledge
                    > than last time, so I'd expect it to go even faster and better;

                    I've found that sometimes this is true and sometimes it isn't.
                    There are going to be some subtle and not-so-subtle differences
                    between the languages and the knowledge we gained from the first
                    program might actually be misleading for the additional languages.
                    It might take more time to undo the clever thinking that worked
                    so well for English and then reorient ourselves to both English
                    and German than it would have to consider them both in the first
                    place. Or not. It will be interesting if someone provides some
                    empirical data on this topic.

                    > then refactor to remove duplication, which is as unlike
                    > rewriting the code as reordering these three paragraphs would be
                    > unlike rewriting them.
                    >
                    > be watching for opportunities to reuse what I already had,
                    > and would use those opportunities as soon as they seemed, well,
                    > reusable;
                    >
                    > See? Not like rewrite at all. :)

                    I agree that refactoring isn't a rewrite. The third rewriting
                    is when the first two versions of the program are merged after
                    all refactoring and reuse. However, that might just be a trivial
                    if/then/else (at least for two languages) so maybe it doesn't count
                    as a rewrite. OTOH, for a larger program, the merge might not be
                    quite so simple.

                    > > I like this strategy because it will work for additional languages
                    > > (e.g., if I ask for Kanji or Swahili in the next iteration).
                    >
                    > Yes ... and I'd expect that the solution I had would become more
                    > general each time, and that I'd become more experienced (if not
                    > smarter) each time, and that pretty soon I'd be the king of numbers
                    > to text. Maybe. :)

                    I'd expect the same (even the king part). ;-) Of course, my expectation
                    of generality might just be wishful thinking. I've seen business logic
                    become very tangled and messy rather than generalized and elegant as
                    new business rules are added and little exceptional cases are added here
                    and there and then exceptions to the exceptions are added in and so on.
                    And this was with teams who were experienced developers with good
                    refactoring skills.

                    Steve
                  • Ron Jeffries
                    ... Well, first of all, it s not an app, it s a function. Second, because it is a few lines, rewriting it seems a reasonable strategy to me. I wouldn t think
                    Message 9 of 17 , Jun 1, 2005
                    • 0 Attachment
                      On Wednesday, June 1, 2005, at 6:55:06 PM, Steve Bate wrote:

                      >> On Wednesday, June 1, 2005, at 5:13:36 PM, Steve Bate wrote:
                      >> > It wouldn't be a big problem in this case to rewrite all the
                      >> > code since it's a relatively small function. This issue
                      >> > can also apply to larger programs when I18N is added after an
                      >> > initial implementation (rather than being specified up front).
                      >> > Rewriting a large application might not be considered an
                      >> > acceptable solution for some (many?) customers.
                      >>
                      >> But rewriting an entire application in order to internationalize it
                      >> seems extremely unlikely, especially if it has any reasonable design
                      >> structure at all, n'est pas? Nicht wahr? Eh?

                      > It depends. In this smaller application, the design structure
                      > seems reasonable but apparently didn't eliminate the need to
                      > rewrite it for the I18N requirement. The same could be true
                      > for some larger applications (and not true for many others).

                      Well, first of all, it's not an app, it's a function.

                      Second, because it is a few lines, rewriting it seems a reasonable
                      strategy to me. I wouldn't think rewriting an entire application
                      would seem so reasonable.

                      Third, it seems very unlikely to me that every function of the whole
                      application could even need internationalization, if it's at all
                      well-designed, so that rewriting the entire app wouldn't likely come
                      up.

                      > Maybe we should be careful in judging the reasonableness of
                      > design structure based on a need for significant rewrites after
                      > new requirements are identified. That's more or less why I
                      > mentioned the metric for design agility. I don't believe it's
                      > a great metric, but it's one that some people seem to use
                      > informally to judge other people's designs.

                      Yes, but there is a very big difference between rewriting, or
                      extending, one function, and rewriting an entire application.

                      I may be missing something, but the example seems comparable to
                      hanging a picture on the wall, and then moving it by pounding
                      another nail, and concluding that our house needs to be rebuilt if
                      someone brings in a new picture.

                      Or something like that ...

                      Ron Jeffries
                      www.XProgramming.com
                      My advice is to do it by the book, get good at the practices, then do as
                      you will. Many people want to skip to step three. How do they know?
                    • Ron Jeffries
                      ... I ve found that this is so close to true that it s well worth betting that way. I would expect the big cost in doing the German version to be the tests.
                      Message 10 of 17 , Jun 1, 2005
                      • 0 Attachment
                        On Wednesday, June 1, 2005, at 7:16:17 PM, Steve Bate wrote:

                        >> be writing the program once again, but with more knowledge
                        >> than last time, so I'd expect it to go even faster and better;

                        > I've found that sometimes this is true and sometimes it isn't.

                        I've found that this is so close to true that it's well worth
                        betting that way. I would expect the big cost in doing the German
                        version to be the tests. (Especially since I probably can't remember
                        Ein Tausend Fier und Dreisig any more.)

                        > There are going to be some subtle and not-so-subtle differences
                        > between the languages and the knowledge we gained from the first
                        > program might actually be misleading for the additional languages.

                        There might be. I don't have that expectation, because what I expect
                        to have learned are things like ...

                        good ways to handle sometimes-used conjunctions like "," and
                        "and";

                        good ways to look up words;

                        good ways to use functions, and maybe recursion, for common
                        string-related things.

                        I don't expect to have functions relating to "one" and "eleven" but
                        to things like "append 'ty'" and "append 'teen'" ... and to know
                        good ways to remove the duplication.

                        > It might take more time to undo the clever thinking that worked
                        > so well for English and then reorient ourselves to both English
                        > and German than it would have to consider them both in the first
                        > place.

                        Ah. That's why I don't do much "clever thinking". That, and the fact
                        that I'm not capable of it.

                        > Or not. It will be interesting if someone provides some
                        > empirical data on this topic.

                        It will. But I don't expect it to generalize very far. I just expect
                        it to be another example that producing generalization by
                        refactoring specialized code works well.

                        >> then refactor to remove duplication, which is as unlike
                        >> rewriting the code as reordering these three paragraphs would be
                        >> unlike rewriting them.
                        >>
                        >> be watching for opportunities to reuse what I already had,
                        >> and would use those opportunities as soon as they seemed, well,
                        >> reusable;
                        >>
                        >> See? Not like rewrite at all. :)

                        > I agree that refactoring isn't a rewrite. The third rewriting
                        > is when the first two versions of the program are merged after
                        > all refactoring and reuse. However, that might just be a trivial
                        > if/then/else (at least for two languages) so maybe it doesn't count
                        > as a rewrite. OTOH, for a larger program, the merge might not be
                        > quite so simple.

                        Why not? A larger program ought to be broken into modules about as
                        big as those in the example ... just more of them. The modules
                        ought, by the nature and definition of modularity, to be mostly
                        independent. So for most incoming changes, only a few modules should
                        be affected, and I'd expect them to be affected in ways quite like
                        the ways these methods were.

                        I wrote a whole book this way, and the same things kept happening
                        again and again. I don't think it's an accident, though I do think
                        it requires some skill.

                        >> > I like this strategy because it will work for additional languages
                        >> > (e.g., if I ask for Kanji or Swahili in the next iteration).
                        >>
                        >> Yes ... and I'd expect that the solution I had would become more
                        >> general each time, and that I'd become more experienced (if not
                        >> smarter) each time, and that pretty soon I'd be the king of numbers
                        >> to text. Maybe. :)

                        > I'd expect the same (even the king part). ;-) Of course, my expectation
                        > of generality might just be wishful thinking. I've seen business logic
                        > become very tangled and messy rather than generalized and elegant as
                        > new business rules are added and little exceptional cases are added here
                        > and there and then exceptions to the exceptions are added in and so on.
                        > And this was with teams who were experienced developers with good
                        > refactoring skills.

                        I have seen that done as well. I have never seen it done where the
                        experienced developers really used their good design and refactoring
                        skills.

                        I think that an interesting example is the one that Friedrich
                        offered a while back, with the folder / file metaphor. The
                        developers used an ArrayList whose even elements represented folders
                        and whose odd elements represented files.

                        This killed them when they needed more than one file per folder.
                        However, they were already dead, because the alternating file/folder
                        structure isn't even very good for representing a list of files in
                        folders ... it has lost information.

                        Now it is true that human rules are sometimes quite complex. I
                        recall on C3 that there were a handful of employees whose union dues
                        were different from anyone else in the company. But that didn't mean
                        that the whole application had to become bizarrely complex. In the
                        places where it did become too complex, I would say that 90 percent
                        or more of the cases were due to us, the programmers, not taking the
                        time to make a clean solution, instead just hacking a bag onto the
                        side of formerly decent code.

                        I am sure that it is theoretically possible to devise a change to
                        any given application that will cause massive changes to a large
                        number of its modules. But in practice, when a change comes in that
                        requires such changes, my experience is not that we were screwed by
                        an unexpected change, but that we had already messed up the design,
                        even without that change.

                        I think that's the way to bet, and all the work I've been doing
                        since XP started, and what I've seen from the teams I have visited,
                        seems to me to support that notion.

                        I could be entirely wrong, of course ...

                        Ron Jeffries
                        www.XProgramming.com
                        New and stirring things are belittled because if they are not belittled,
                        the humiliating question arises, "Why then are you not taking part in
                        them?" -- H. G. Wells
                      • Charlie Poole
                        Hi Ron, ... I wonder if it isn t confusing the issue to refer to this as I18N. Normally, the term refers to changes that are incidental to the overall purpose
                        Message 11 of 17 , Jun 1, 2005
                        • 0 Attachment
                          Hi Ron,

                          > > It wouldn't be a big problem in this case to rewrite all the code
                          > > since it's a relatively small function. This issue can also
                          > apply to
                          > > larger programs when I18N is added after an initial implementation
                          > > (rather than being specified up front). Rewriting a large
                          > application
                          > > might not be considered an acceptable solution for some (many?)
                          > > customers.
                          >
                          > But rewriting an entire application in order to
                          > internationalize it seems extremely unlikely, especially if
                          > it has any reasonable design structure at all, n'est pas?
                          > Nicht wahr? Eh?

                          I wonder if it isn't confusing the issue to refer to this as I18N.

                          Normally, the term refers to changes that are incidental to the overall
                          purpose of the application. This particular function has a linguistic
                          purpose
                          at it's heart: performing a limited sort of natural language generation.
                          It
                          isn't at all unreasonable to expect that we might need a different
                          algorithm
                          for different languages - ones we don't know for example.

                          In a large application, I would probably expect to deal with such a
                          function
                          through a Strategy pattern, at least for some languages. I'd implement
                          it as
                          soon as I needed to create a second function. And like you, I'd probably

                          create a second function for the second language. If we had two or three
                          langues implemented and I saw a chance to remove duplication, I'd
                          probably
                          do so, but at that point, I might keep the Strategy pattern, for the
                          time when a
                          language I don't know about came along.

                          That said, it's a fun problem. I've used it as an exercise in C++
                          classes and
                          I think it had the highest variance in terms of length of code needed to
                          solve
                          the problem of any exercise we did.

                          Charlie
                        • Ilja Preuss
                          ... test failure: expected but was ;) Regards, Ilja
                          Message 12 of 17 , Jun 3, 2005
                          • 0 Attachment
                            > I would expect the big cost in doing the
                            > German version to be the tests. (Especially since I probably
                            > can't remember Ein Tausend Fier und Dreisig any more.)

                            test failure: expected <...Vier und Dreiß...> but was <...Fier und Dreis...>

                            ;)

                            Regards, Ilja
                          • Ron Jeffries
                            ... See? I said I couldn t remember ... :) Ron Jeffries www.XProgramming.com Do we learn more through cynicism, or through some other mental posture?
                            Message 13 of 17 , Jun 3, 2005
                            • 0 Attachment
                              On Friday, June 3, 2005, at 10:28:12 AM, Ilja Preuss wrote:

                              >> I would expect the big cost in doing the
                              >> German version to be the tests. (Especially since I probably
                              >> can't remember Ein Tausend Fier und Dreisig any more.)

                              > test failure: expected <...Vier und Dreiß...> but was <...Fier und Dreis...>

                              See? I said I couldn't remember ... :)

                              Ron Jeffries
                              www.XProgramming.com
                              Do we learn more through cynicism, or through some other mental posture?
                            • Jeff Grigg
                              ... I stumbled across the Mozilla version for German: http://source.x2x2x.org/svn/x2x2x/saxon.net/trunk/Saxon.NET-B-8.4-
                              Message 14 of 17 , Jun 3, 2005
                              • 0 Attachment
                                --- Ron Jeffries <ronjeffries@X...> wrote:
                                > [....] I would expect the big cost in doing the German
                                > version to be the tests. [...]

                                I stumbled across the Mozilla version for German:
                                http://source.x2x2x.org/svn/x2x2x/saxon.net/trunk/Saxon.NET-B-8.4-
                                source/net/sf/saxon/number/Numberer_de.java
                                or
                                http://tinyurl.com/7llcr

                                It looks about like I would expect it to.
                              • Ilja Preuss
                                ... Too much duplication for my taste... Cheers, Ilja
                                Message 15 of 17 , Jun 6, 2005
                                • 0 Attachment
                                  extremeprogramming@yahoogroups.com wrote:
                                  > --- Ron Jeffries <ronjeffries@X...> wrote:
                                  >> [....] I would expect the big cost in doing the German version to be
                                  >> the tests. [...]
                                  >
                                  > I stumbled across the Mozilla version for German:
                                  > http://source.x2x2x.org/svn/x2x2x/saxon.net/trunk/Saxon.NET-B-8.4-
                                  > source/net/sf/saxon/number/Numberer_de.java
                                  > or
                                  > http://tinyurl.com/7llcr
                                  >
                                  > It looks about like I would expect it to.

                                  Too much duplication for my taste...

                                  Cheers, Ilja
                                • Jeff Grigg
                                  ... source/net/sf/saxon/number/Numberer_de.java ... True, but... I found that while German spelling is somewhat more consistent than English, (There are fewer
                                  Message 16 of 17 , Jun 6, 2005
                                  • 0 Attachment
                                    > --- Jeff Grigg wrote:
                                    >> I stumbled across the Mozilla version for German:
                                    >> http://source.x2x2x.org/svn/x2x2x/saxon.net/trunk/Saxon.NET-B-8.4-
                                    source/net/sf/saxon/number/Numberer_de.java
                                    >> or
                                    >> http://tinyurl.com/7llcr

                                    --- "Ilja Preuss" <preuss@d...> wrote:
                                    > Too much duplication for my taste...

                                    True, but...
                                    I found that while German spelling is somewhat more consistent than
                                    English, (There are fewer exceptions in the "-teen" and "-ty" ("-
                                    zehn/-zig) cases.) their use of compound words and other stylistic
                                    variations make it difficult to share the hundred, thousand and
                                    million code. When the number of exceptions exceeded the number of
                                    instances, I found my data-driven code difficult, and unrolled the
                                    loop, much as they have done.
                                  Your message has been successfully submitted and would be delivered to recipients shortly.