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

1423Re: [scrumdevelopment] Re: IEEE SWEBOK Is Looking for Reviewers--They Don't Even Mention XP, Agile, etc.

Expand Messages
  • Mike Beedle
    Jun 5, 2003
    • 0 Attachment
      --- Fabian Ritzmann <usefri@...> wrote:
      Mike Cohn wrote:
      >> Hmm, when you write HaskellUnit for us, I'll
      >> give it a try! :)
      > http://hunit.sourceforge.net/

      It is a mind warping experience....

      Whether you program in Haskell later or not or for
      how long is irrelevant -- it will definitely change
      the metric of how you evaluate "goodness" or
      "fitness" for you programs and it will somewhat
      change your programming _habits_ -- at least that's
      what it did for me.

      After learning functional programming, or worse
      after learning functional-logical programming
      i.e. Curry, Clips, etc.. one tends to develop
      systems that are logical and/or functional even
      when you are using imperative programming
      languages i.e. Java, C++, etc. -- kind of like
      writing OO programs in C.

      We in fact use a layered architecture for our
      servlet-based J2EE apps that tries to emulate
      a logical-functional paradigm.

      The result? We think a simpler, more elegant, higher
      performance (through memoization) -- and
      definitely more reliable system. But we are a little
      biased ;-), of course.

      > That's why the first programming course for CS
      > students at my former university has been based
      > on a functional programming language for more
      > than 10 years already. Best to teach it as early as
      > possible.

      Yep, early mind warp in that direction is highly

      > You are testing quality with unit tests? Mine
      > are entirely functional. They still improve quality

      > but that's not what is tested. System quality
      > is usually tested by integration and system tests.

      So you never run into a null pointer exception, or
      unmanaged memory, or uncovered branches, or ugly
      side effects in a test for an imperative program? :-)

      Yes, I confess -- I use unit tests for both, system
      and functional tests. But I agree, a _strong_ aspect
      of units tests is also their mini acceptance test role
      for the features of a component.

      self wrote:
      > What the world needs to accept is that declarative
      > programming paradigms lead to a much higher
      > quality to begin with because they avoid system
      > errors and in many cases guarantee provability:
      > Haskell, Clips, Prolog, Erlang, etc., etc.

      Fabian wrote:
      > I thought about that, too, when I read Michael
      > Feathers' opinion that one should teach test driven
      > development right from the beginning. I had
      > been taught functional programming in the beginning.

      The combination is very powerful:

      * test as _specification_ from Test-First, and
      * program as executable _specification_ from
      functional programming

      Both strategies drive development more into the
      quantifiable _what_ space, much more than worthless
      "exhaustive requirements documents" or "models".

      Perhaps, this is what we need to concentrate in
      software architecture -- in patterns that tell us
      _what_ to program and that are executable,

      - Mike
    • Show all 37 messages in this topic