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

Re: [XP] Place for rarified skills?

Expand Messages
  • david.abrahams@rcn.com
    ... Wow, I never expected to encounter such blatant language bias here. I thought XP was largely about pragmatism. The problem is not specific to C++ at all,
    Message 1 of 20 , Oct 1, 2001
    • 0 Attachment
      --- In extremeprogramming@y..., cg@c... wrote:
      > >As much as I wish it were otherwise, generic programming
      > >and template metaprogramming are hardly "lingua franca"
      > >among C++ programmers. Those skills are best applied in
      > >environments where flexibility and maximum performance are
      > >both required. Also, I enjoy solving difficult problems --
      > >often arriving at a solution requires exploiting concepts
      > >and techniques outside the knowledge of mainstream programmers.
      > >
      > That's a problem that is I think quite specific to C++, which
      > is so baroque that indeed there are corners of the language that
      > are only accessible to specialists. The best solution, of course,
      > is to avoid the language like the plague.

      Wow, I never expected to encounter such blatant language bias here. I
      thought XP was largely about pragmatism. The problem is not specific
      to C++ at all, though C++ admits a wider variety of techniques and
      approaches than many languages. Part of what I'm referring to here has
      nothing to do with languages: it's simply the application of good old
      Computer Science. If I have to use the NFA-to-DFA construction, or
      dijkstra's algorithm, I'm already speaking a language that the average
      programmer doesn't seem to grasp.

      > I have programmed the last 3 months mostly in Smalltalk.
      > Before that, almost a year mainly Python. Before that, around
      > 5 years in Java. These are all very accessible languages where
      > there are hardly any dark corners.

      It's very interesting that you'd say so. My experience with Python in
      particular (and I love Python for its many merits) has been that it's
      full of dark corners, mostly due to incomplete documentation. I can
      read the source code to find out what happens, but one shouldn't have
      to. I can't speak for Java or Smalltalk, and would encourage you not
      to knock C++ until you've learned to use it with as much authority as
      the other languages you know.

      In any case, none of these languages are capable of the combination of
      flexibility and high performance that can be acheived with advanced
      techniques in C++. As I've said, I wouldn't use an advanced technique
      where a simpler one would do - sometimes the problem just demands it.

      > The best expression of intelligence and creativity is to
      > make solutions look so obvious that any moron thinks he
      > could have come up with it. As a side effect, it means
      > you run less risk of having to maintain your own hacks...

      No argument there. Why do I get the sense that you don't think I value
      simplicity and re
    • david.abrahams@rcn.com
      ... Actually, I can say this about Java (once again, it s an issue of documentation): The Java libraries documentation goes to great lengths to tell you about
      Message 2 of 20 , Oct 1, 2001
      • 0 Attachment
        --- In extremeprogramming@y..., david.abrahams@r... wrote:

        > I can't speak for Java or Smalltalk

        Actually, I can say this about Java (once again, it's an issue of
        documentation): The Java libraries documentation goes to great lengths
        to tell you about exactly /which/ exceptions may be thrown from any
        function, but leaves a much more important corner completely dark. It
        consistently omits any mention of what the program state is in case of
        an exception. If you don't know what has happened to the objects
        you're operating on, writing error recovery code is next to
        impossible. If you're operating on some critical persistent piece of
        program state when the error occurs, all you can do is cross your
        fingers and hope for the best. I would think that would make writing
        reliable software very difficult.

        Every language has its dark corners. Those in C++ are different from
        those in other languages and in some ways more capricious, but at
        least if you're curious and industrious, light can be found in the
        Sta
      • wecaputo@thoughtworks.com
        ... It is, don t let the incessant off-topic holy war mongers here get to you ; -) It helps if you think of such troll-like comments as people trying to say
        Message 3 of 20 , Oct 1, 2001
        • 0 Attachment
          David Abrahams:
          >I thought XP was largely about pragmatism.

          It is, don't let the incessant off-topic holy war mongers here get to you ;
          -) It helps if you think of such troll-like comments as people trying to
          say something along the lines of "XP is easier to apply in some languages,
          than in others." I would agree with that statement.

          However, it isn't a very interesting or practical discussion topic (IMHO)
          as the reality of many organizations, and individuals, is that they aren't
          only using the "easier to do XP" languages. And before anyone goes asking
          which ones they are, I suggest they look at the archives, there's only
          about 215 threads on the topic.

          >Part of what I'm referring to here has
          >nothing to do with languages: it's simply the application of good old
          >Computer Science. If I have to use the NFA-to-DFA construction, or
          >dijkstra's algorithm, I'm already speaking a language that the average
          >programmer doesn't seem to grasp.

          This is the more interesting question IMO, and the answer (to summarize the
          thread) is:

          1) In XP we strive for simplicity[1] and clarity. So the first response one
          gets here is a question: "Can the task be completed without putting on the
          star and moon hat?"
          2) If the answer is no, then the second response is: "Use spikes to explore
          the concepts further and find TSTTCPW[2] (we still want this, even if the
          answer is outside the experience of the average programmer)
          3) Then the response moves along to: "We are still responsible to the team
          for communicating the rationale behind the decision. Whether the spike was
          done alone or as a pair, the implementation of the solution (still
          scheduled as a task to a story) should be paired. Regular interest,
          communication, Unit testing, and refactoring rules still apply."
          4) The next part of the response is: "Having such expertise on an XP
          project is very important, but not at the expense of team, and learning
          values." -- IOW knowledge bigots need not apply.
          5) The final part is: "One person's wizardry is another's "Good old CS".
          Good design is emergent in XP, not eliminated. Every technique has its
          place. We are encouraged to oversimplify in the hopes that we can get away
          with it but, as always let the code, the requirements, and the team tell
          you what is "simplest".

          [1] The rules for simplicty (lots of threads here and at the wiki
          discussing this too):
          http://www.c2.com/cgi/wiki?XpSimplicityRules

          [2] The Simplest Thing That Can Possibly Work

          Best,
          Bill
        • peter.sommerlad@itopia.ch
          ... I ... specific ... and in contrast to Java, you might not need to consider the more advanced stuff in your coding, because C++ is carefully designed to the
          Message 4 of 20 , Oct 1, 2001
          • 0 Attachment
            --- In extremeprogramming@y..., david.abrahams@r... wrote:
            > --- In extremeprogramming@y..., cg@c... wrote:
            ...some points about the advanced and bad things about C++

            > > That's a problem that is I think quite specific to C++, which
            > > is so baroque that indeed there are corners of the language that
            > > are only accessible to specialists. The best solution, of course,
            > > is to avoid the language like the plague.
            >
            > Wow, I never expected to encounter such blatant language bias here.
            I
            > thought XP was largely about pragmatism. The problem is not
            specific
            > to C++ at all, though C++ admits a wider variety of techniques and
            > approaches than many languages.
            and in contrast to Java, you might not need to consider the more
            advanced stuff in your coding, because C++ is carefully designed
            to the principle that you pay only for what you use.
            For example, grasping multi-threading is hard and using locks can
            heavily drain performance of a system, both hurt even the average
            Java
            programmer without she being able to ignore them or get rid of.
            ...
            > In any case, none of these languages are capable of the combination
            of
            > flexibility and high performance that can be acheived with advanced
            > techniques in C++. As I've said, I wouldn't use an advanced
            technique
            > where a simpler one would do - sometimes the problem just demands
            it.

            I write C++ code happily using the features available before 1990
            and only occasionally the "more advanced" features. Nevertheless,
            C++ provides me much better means of abstraction (OO) as C and
            can still be easily read if I take care. An additional benefit
            refraining from the use of exceptions and templates is that it
            is highly portable, even to platforms where the C++ compilers
            are nascent (like TPF - regards to my former colleague Paul Trunz).

            I do not say that templates and exceptions do not have their
            applicability, but as they used to confuse compilers they still
            tend to confuse developers, but that is a story true about many
            languages. So it is not so much a language deficit but a matter of
            the Idioms and style you are using. And here David is right: "less is
            more".

            Yours
            Peter.
            --
            Peter Sommerlad

            itopia - corporate information technology
            technoparkstrasse 1
            ch-8005 z├╝rich
            tel +41 1 355 56 27
            fax +41 1 355 56 01
            mobile +41 79 432 23 32
            mailto:peter.sommerlad@...
            http://www.itopia.ch
          • Ron Jeffries
            ... I don t think it is bias to call things the way they are. C++ has language features far more arcane than any other language I ve ever used and I ve used a
            Message 5 of 20 , Oct 1, 2001
            • 0 Attachment
              Around Monday, October 01, 2001, 7:22:35 AM, david.abrahams@... wrote:

              > Wow, I never expected to encounter such blatant language bias here.

              I don't think it is bias to call things the way they are. C++ has
              language features far more arcane than any other language I've ever
              used and I've used a lot. I think Cees called it accurately.

              > I
              > thought XP was largely about pragmatism. The problem is not specific
              > to C++ at all, though C++ admits a wider variety of techniques and
              > approaches than many languages.

              C++ prosecution rests. ;->

              > Part of what I'm referring to here has
              > nothing to do with languages: it's simply the application of good old
              > Computer Science. If I have to use the NFA-to-DFA construction, or
              > dijkstra's algorithm, I'm already speaking a language that the average
              > programmer doesn't seem to grasp.

              Well, it's good to be above average, like all the children in Lake
              Wobegon. But perhaps I digress. Further below, you ask:

              > Why do I get the sense that you don't think I value
              > simplicity and readability?

              I'm going to pretend that's actually a question, hoping that it is,
              and I'm going to answer it.

              You started the conversation by remarking that

              > I've been thinking about where I'd fit into an XP environment, or how agile
              > processes could fit into the kind of work I do. The quote above really
              > struck me personally, since
              > a. It rings true
              > b. Any job which really exploits my abilities is likely to result in at
              > least some rarified code.
              >
              > As much as I wish it were otherwise, generic programming and template
              > metaprogramming are hardly "lingua franca" among C++ programmers. Those
              > skills are best applied in environments where flexibility and maximum
              > performance are both required. Also, I enjoy solving difficult problems --
              > often arriving at a solution requires exploiting concepts and techniques
              > outside the knowledge of mainstream programmers.

              In subsequent replies, you've said

              > If I have to use the NFA-to-DFA construction, or
              > dijkstra's algorithm, I'm already speaking a language that the average
              > programmer doesn't seem to grasp.

              and

              > I would never apply a
              > "rarified technique" where something simpler would do. When designing
              > reusable libraries, the rarified technique is often exactly what's needed to
              > make life simpler for the library's users.

              and

              > not just because finding an answer is made harder by having
              > to bring the less knowledgeable up to speed "all at once", but because they
              > become frustrated during these processes because they don't feel they're
              > contributing and they could be doing "real work" (meaning work within their
              > current grasp).

              So what I read here comes across as the words of someone who is highly
              skilled and enjoys exercising his skills to the utmost. I can dig
              that; certainly if I had any skills I imagine I'd enjoy exercising
              them.

              Yet your message comes across as "sometimes we must accept complexity
              so as to solve the problem".

              Certainly in some sense that's true: we've all had to solve a problem
              and had to use or create a complex solution. To me, the question is:

              Looking upon this hard problem solved with something from deep in
              our bag of tricks, is our feeling just one of satisfaction?

              On the one hand, the problem was hard, probably no one else around
              could have solved it at all.

              On the other hand, the solution isn't -- by your own statement --
              simple. When that happens to me, I always feel a little sadness
              in the satisfaction, because I've had to do something that the
              average Joe behind me (no offense, Joe) will have trouble with.

              It's that bit of sadness that I didn't hear in your presentation.
              That's why I kept pushing on the subject. But I think I'm through now,
              unless you want to go on. You can solve hard problems, you care about
              simplicity. One could want no more.

              "Thank you sir, may I have another?" ;->

              Ronald E Jeffries
              www.XProgramming.com
              Wisdom begins when we discover the difference between
              "That makes no sense" and "I don't understand". --Mary Doria Russell
            • Matthew Davis
              ... needed to ... Would you accept that a rarified technique may turn out to be a good way to remove duplication? Here s my example: In a legacy project we
              Message 6 of 20 , Oct 1, 2001
              • 0 Attachment
                --- In extremeprogramming@y..., Ron Jeffries <ronjeffries@a...> wrote:
                > Around Sunday, September 30, 2001, 9:03:10 PM, David Abrahams wrote:
                >
                > > When designing
                > > reusable libraries, the rarified technique is often exactly what's
                needed to
                > > make life simpler for the library's users.
                >
                > For example?

                Would you accept that a rarified technique may turn out to be a good
                way to remove duplication? Here's my example:

                In a legacy project we have (ugh) a struct.h/cpp set of files. The
                header defines a bunch of structures - purely data - and
                prototypes for InitializeXxx() functions for each of them. The .cpp
                has implementations for each of those structures, which used to each
                set all the struct members to zero, but had at some point been
                refactored to memset() the struct to all zeroes.

                Ignoring for a moment the other 8 gazillion things wrong with this
                code, I sought to eliminate the massive duplication of 40 functions
                that all simply call memset, using the parameter type as the size to
                set to 0's.

                The most obvious solution to me was a templatized function, which I
                implemented. It's really pretty simple - but since relatively few C++
                developers are intimate with writing templates (heck, even I had to
                look up the syntax to be able to write this function), it's possible
                that by doing this I've created a barrier to someone else
                understanding the code.

                I reconcile this with the thought that the best solution is the best
                solution, and knowing the language is the responsibility of any future
                developer working on the code. When I consider using a rarified
                technique, I think carefully about whether there is a better, less
                rarified technique. But if less rarified techniques are not as good,
                then the rarified technique has to win.

                Besides, this lets me show by example just what is a good use of a
                rarified technique. :-)

                (Now to do something about the fact that the InitializeXxx() functions
                took references rather than pointers, or that the only thing relating
                the structures to each other is that they are structures, or that the
                data they contain would probably be better maintained by actual
                objects...)

                -Matthew
              • Keith Nicholas
                ... I don t think this is the real issue....I think wrapping complexity up in a way that it can be used simply makes it way more useable for the average Joe.
                Message 7 of 20 , Oct 1, 2001
                • 0 Attachment
                  > On the other hand, the solution isn't -- by your own statement --
                  > simple. When that happens to me, I always feel a little sadness
                  > in the satisfaction, because I've had to do something that the
                  > average Joe behind me (no offense, Joe) will have trouble with.
                  >
                  > It's that bit of sadness that I didn't hear in your
                  > presentation. That's why I kept pushing on the subject. But I
                  > think I'm through now, unless you want to go on. You can
                  > solve hard problems, you care about simplicity. One could
                  > want no more.
                  >

                  I don't think this is the real issue....I think wrapping complexity up
                  in a way that it can be used simply makes it way more useable for the
                  average Joe.

                  Java, smalltalk etc all do the same thing, they wrap complexity up into
                  something more simple and accessible to the average Joe. Good example
                  is garbage collection, as a developer, you don't even think about this
                  too much, but it is a complex piece of software that someone had to
                  write.

                  This is what is being discussed in terms Davids discussion. The
                  creation of elements of software which simplify development when you
                  have those elements, but the cost of getting those elements in the first
                  place might be quite high and involve quite a bit of complexity.

                  Also maintaining those elements requires someone who can understand the
                  complexity and advanced techniques that have been used.

                  In terms of XP, the decision to make "library software elements" that
                  simplify the overall development is a business decision if they are
                  going to require a significant amount of effort. However, I think
                  possibly that these kinds of things really do need to be open source
                  like boost as it is very hard for one business to get the skills
                  required to be able to maintain these more advanced software elements
                  (hard enough to find people with good basic understanding of C++!).

                  We had a little talk here at our company about Mr Alexandrescus
                  techniques and decided it would be too hard to get developers who would
                  be able to work with the code even though the techniques are very
                  powerful and can be much quicker to write software with.

                  Keith


                  > "Thank you sir, may I have another?" ;->
                  >
                  > Ronald E Jeffries
                  > www.XProgramming.com
                  > Wisdom begins when we discover the difference between
                  > "That makes no sense" and "I don't understand". --Mary Doria Russell
                  >
                  >
                  > To Post a message, send it to: extremeprogramming@...
                  >
                  > To Unsubscribe, send a blank message to:
                  > extremeprogramming-unsubscribe@...
                  >
                  > ad-free courtesy of objectmentor.com
                  >
                  > Your use of Yahoo! Groups is subject to
                  > http://docs.yahoo.com/info/terms/
                  >
                  >
                  >
                • David Abrahams
                  ... From: Brian C. Robinson ... Even using STL is not neccessarily generic programming. STL is an example of generic programming,
                  Message 8 of 20 , Oct 2, 2001
                  • 0 Attachment
                    ----- Original Message -----
                    From: "Brian C. Robinson" <brian.c.robinson@...>

                    > At 04:05 PM 9/30/01, you wrote:
                    > >As much as I wish it were otherwise, generic programming and template
                    > >metaprogramming are hardly "lingua franca" among C++ programmers.
                    >
                    > That's why you pair with them. And get them to read some books (Meyers'
                    > Effective STL and Josuttis' The C++ Standard Library are my
                    > favorites). Pretty soon everyone in your group will be at least competent
                    > in the area of generic programming. This is exactly what I did.

                    Even using STL is not neccessarily generic programming. STL is an example of
                    generic programming, but most people are using it directly for concrete
                    jobs, rather than writing new generic components. Not to devalue concrete
                    jobs (ultimately, they're everything!), but I want to distinguish library
                    component design/construction from library use.

                    > >Also, I enjoy solving difficult problems --
                    > >often arriving at a solution requires exploiting concepts and techniques
                    > >outside the knowledge of mainstream programmers.
                    >
                    > Ah, so "clever" programming.

                    Emphatically not! I always prefer the straightforward to the clever. I'm
                    talking for example, about exploiting concepts from "the literature", like
                    graph theory, parsing technology, linear algebra, pattern matching, etc.,
                    etc. These concepts and theories are capable of wrapping up a whole lot of
                    complex thought into simpler packages. Often, seeing a problem in these
                    terms is what's required in order to make it simple enough to be manageable.

                    > Are your solutions simple? If so, you should
                    > easily be able to explain them to your pair.

                    It depends whether the pair is willing to accept a quick-and-simplified
                    explanation of the theory or not.

                    -Dave
                  • Ron Jeffries
                    ... I think most people are willing to learn. Honestly, and with the deepest love and respect, it still sounds to me as if the problem is closer to you than it
                    Message 9 of 20 , Oct 2, 2001
                    • 0 Attachment
                      Around Tuesday, October 02, 2001, 12:55:59 PM, David Abrahams wrote:

                      >> Are your solutions simple? If so, you should
                      >> easily be able to explain them to your pair.

                      > It depends whether the pair is willing to accept a quick-and-simplified
                      > explanation of the theory or not.

                      I think most people are willing to learn. Honestly, and with the
                      deepest love and respect, it still sounds to me as if the problem is
                      closer to you than it is to these other guys.

                      Ronald E Jeffries
                      www.XProgramming.com
                      Accroches-toi a ton reve. --ELO
                    • David Abrahams
                      ... From: Ron Jeffries ... That s my experience, too. They may not have the patience to go through the deep explanation, though.
                      Message 10 of 20 , Oct 2, 2001
                      • 0 Attachment
                        ----- Original Message -----
                        From: "Ron Jeffries" <ronjeffries@...>


                        > Around Tuesday, October 02, 2001, 12:55:59 PM, David Abrahams wrote:
                        >
                        > >> Are your solutions simple? If so, you should
                        > >> easily be able to explain them to your pair.
                        >
                        > > It depends whether the pair is willing to accept a quick-and-simplified
                        > > explanation of the theory or not.
                        >
                        > I think most people are willing to learn.

                        That's my experience, too. They may not have the patience to go through the
                        deep explanation, though. Frankly, we may not have the time. Maybe I need to
                        work on my explanation skills.

                        > Honestly, and with the
                        > deepest love and respect, it still sounds to me as if the problem is
                        > closer to you than it is to these other guys.

                        I'm not sure there is a problem at all. If there is one, I'd be willing to
                        accept that it's me; I certainly never imagined that "these other guys" had
                        a problem. What problem do you perceive?

                        I'm just interested in finding a place in an XP environment where I can
                        contribute, and feel like I'm fully used. Since it might be up to me to
                        create that environment, I'm asking about the experiences of others.

                        -Dave
                      • Ron Jeffries
                        ... Good approach. I think my answer is something like this: You re smart. You know a lot. Therefore you re called on to solve hard problems. Solve them in
                        Message 11 of 20 , Oct 2, 2001
                        • 0 Attachment
                          Around Tuesday, October 02, 2001, 2:09:00 PM, David Abrahams wrote:

                          > I'm not sure there is a problem at all. If there is one, I'd be willing to
                          > accept that it's me; I certainly never imagined that "these other guys" had
                          > a problem. What problem do you perceive?

                          > I'm just interested in finding a place in an XP environment where I can
                          > contribute, and feel like I'm fully used. Since it might be up to me to
                          > create that environment, I'm asking about the experiences of others.

                          Good approach. I think my answer is something like this:

                          You're smart. You know a lot. Therefore you're called on to solve
                          hard problems. Solve them in such a way that you never need to
                          work on that code again. That is, leave behind you not just
                          working code, but working, clear code, and at least one other
                          team member who can do any necessary maintenance.

                          Details, of course, are left to you. I'm sure you're up to it.

                          Is that helpful? Or harmful? ;->

                          Ronald E Jeffries
                          www.XProgramming.com
                          Discontinue reading if rash, irritation, redness, or swelling develops.
                          Especially irritation.
                        • Keith Nicholas
                          I don t think this is so much a question about XP but more a more general question of any team based development. It s more a matter of finding a team of
                          Message 12 of 20 , Oct 2, 2001
                          • 0 Attachment
                            I don't think this is so much a question about XP but more a more
                            general question of any team based development. It's more a matter of
                            finding a team of developers who you can fit into. Of course one of
                            your best bets is to create your own XP environment with the types of
                            developers that you want to work with. The cool thing about an XP type
                            environment (though not unique to) is that it actively encourages
                            communication and cooperation with all the team which is a great
                            opportunity to share knowledge and skills.

                            The other thing that may be worth thinking about is a catalog of
                            refactorings specific to generic/template C++ programming. Perhaps
                            things such as "Replace class with template", "Replace Memory Management
                            with smart pointer" etc...but perhaps that's better discussed on the
                            refactoring email list :)

                            Keith

                            > -----Original Message-----
                            > From: David Abrahams [mailto:david.abrahams@...]
                            > Sent: Wednesday, October 03, 2001 6:09 AM
                            > To: extremeprogramming@yahoogroups.com
                            > Subject: Re: [XP] Place for rarified skills?
                            >
                            >
                            >
                            > ----- Original Message -----
                            > From: "Ron Jeffries" <ronjeffries@...>
                            >
                            >
                            > > Around Tuesday, October 02, 2001, 12:55:59 PM, David Abrahams wrote:
                            > >
                            > > >> Are your solutions simple? If so, you should
                            > > >> easily be able to explain them to your pair.
                            > >
                            > > > It depends whether the pair is willing to accept a
                            > > > quick-and-simplified explanation of the theory or not.
                            > >
                            > > I think most people are willing to learn.
                            >
                            > That's my experience, too. They may not have the patience to
                            > go through the deep explanation, though. Frankly, we may not
                            > have the time. Maybe I need to work on my explanation skills.
                            >
                            > > Honestly, and with the
                            > > deepest love and respect, it still sounds to me as if the
                            > problem is
                            > > closer to you than it is to these other guys.
                            >
                            > I'm not sure there is a problem at all. If there is one, I'd
                            > be willing to accept that it's me; I certainly never imagined
                            > that "these other guys" had a problem. What problem do you perceive?
                            >
                            > I'm just interested in finding a place in an XP environment
                            > where I can contribute, and feel like I'm fully used. Since
                            > it might be up to me to create that environment, I'm asking
                            > about the experiences of others.
                            >
                            > -Dave
                            >
                            >
                            >
                            >
                            > To Post a message, send it to: extremeprogramming@...
                            >
                            > To Unsubscribe, send a blank message to:
                            > extremeprogramming-unsubscribe@...
                            >
                            > ad-free courtesy of objectmentor.com
                            >
                            > Your use of Yahoo! Groups is subject to
                            > http://docs.yahoo.com/info/terms/
                            >
                            >
                            >
                          Your message has been successfully submitted and would be delivered to recipients shortly.