Strong encapsulation, static typing and unit testing

Discussion in 'Ruby' started by Nick Pavey, Dec 29, 2006.

  1. Nick Pavey

    Nick Pavey Guest

    Hi Everyone,

    I've been following the discussion on strong encapsulation with
    interest... It's a really interesting topic.

    Reading through the posts and some of the Ruby books and
    documentation, I've come across the idea that Ruby's lack of strong
    typing is less important because there is some support for a unit
    testing framework.

    My attention was grabbed by Jeff's response in the original thread,
    so instead of hijacking it, I thought it might be interesting to
    start a new discussion. I thought I'd kick things off with these
    points, sort of in order of priority:

    Software engineering
    o In our experience, putting well defined layers into the code has
    always helped clarify the system
    o You can never tell what your users are going to do with your
    code! More protection is usually better :)
    o Clarity and reliability are almost always more important than speed

    Testing in the real world
    o Very often, only superficial testing is done, and this only
    catches the trivial stuff
    o It's easy to catch the easy errors. To catch the hard ones takes
    a *lot* of work
    o The late-breaking bugs are the ones that hurt - especially if
    it's a silly typo that could have been caught statically

    Unit testing
    o Often the problems crop up in integration rather than within a
    particular unit - having stricter checking on interfaces would really
    help
    o It's hard to push a unit into all corners of it's functionality
    without reasonably fully fledged supporting functionality
    o If the testbench suffers from the same limitations as the
    language it's testing, how do you know where the error's being
    generated?

    Testing methodology
    o There's a difference between syntax checking and verification of
    functional correctness
    o Rigorous testing of software is often extremely hard to do, if
    not impossible - esp GUIs and large web apps
    o Strict type checking can really help with the readability and
    maintainability of code

    Just so you know where I'm coming from, I work verifying functional
    correctness of CPUs and designing the supporting tool flows. I have a
    strong disposition towards strong encapsulation, typing and testing,
    and even then I never do enough testing!

    What do you all think?

    Cheers,


    Nick



    --

    Nick Pavey
    Nick Pavey, Dec 29, 2006
    #1
    1. Advertising

  2. Nick Pavey wrote:
    > Hi Everyone,
    >
    > I've been following the discussion on strong encapsulation with
    > interest... It's a really interesting topic.
    >
    > Reading through the posts and some of the Ruby books and
    > documentation, I've come across the idea that Ruby's lack of strong
    > typing is less important because there is some support for a unit
    > testing framework.
    >
    > My attention was grabbed by Jeff's response in the original thread, so
    > instead of hijacking it, I thought it might be interesting to start a
    > new discussion. I thought I'd kick things off with these points, sort
    > of in order of priority:
    >
    > Software engineering
    > o In our experience, putting well defined layers into the code has
    > always helped clarify the system
    > o You can never tell what your users are going to do with your code!
    > More protection is usually better :)
    > o Clarity and reliability are almost always more important than speed
    >
    > Testing in the real world
    > o Very often, only superficial testing is done, and this only
    > catches the trivial stuff
    > o It's easy to catch the easy errors. To catch the hard ones takes a
    > *lot* of work
    > o The late-breaking bugs are the ones that hurt - especially if it's
    > a silly typo that could have been caught statically
    >
    > Unit testing
    > o Often the problems crop up in integration rather than within a
    > particular unit - having stricter checking on interfaces would really
    > help
    > o It's hard to push a unit into all corners of it's functionality
    > without reasonably fully fledged supporting functionality
    > o If the testbench suffers from the same limitations as the language
    > it's testing, how do you know where the error's being generated?
    >
    > Testing methodology
    > o There's a difference between syntax checking and verification of
    > functional correctness
    > o Rigorous testing of software is often extremely hard to do, if not
    > impossible - esp GUIs and large web apps
    > o Strict type checking can really help with the readability and
    > maintainability of code
    >
    > Just so you know where I'm coming from, I work verifying functional
    > correctness of CPUs and designing the supporting tool flows. I have a
    > strong disposition towards strong encapsulation, typing and testing,
    > and even then I never do enough testing!
    >
    > What do you all think?
    >
    > Cheers,
    >
    >
    > Nick
    >
    >
    >
    > --
    >
    > Nick Pavey
    >
    >
    >
    >
    >
    >

    Well ... this discussion comes up often enough on this list that most
    peoples' opinions are well known, and usually repeat discussions that
    have been going on since the dawn of time -- I can imagine Euclid and
    Pythagoras, at least, discussing their branches of mathematical
    reasoning with their colleagues in similar fashion. :)

    But here goes:

    1. One thing I *haven't* seen in any of these discussions is the "gas
    law models" of large software engineering projects. I can't seem to find
    any references on the web, but the books of Lawrence Putnam are a good
    place to start.

    2. As I (and IIRC others) have mentioned in these discussions, the one
    language that was deliberately designed to facilitate development and
    maintenance of large software projects -- Ada -- seems to be a well-kept
    secret. It's still very much a live language -- GNU has a compiler, for
    example -- but, given that it was specifically designed to facilitate
    large efforts, how come the large efforts are being done in Java for the
    most part?

    3. The practices and processes of software engineering in most cases
    need to be *subordinate* to the business model, even (especially) when
    the business is a software development business! In many cases, that
    means you have to ship something that's "good enough" rather than
    something that's provably correct and has no transactions with
    unacceptable response times.



    --
    M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
    http://borasky-research.blogspot.com/

    If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
    M. Edward (Ed) Borasky, Dec 30, 2006
    #2
    1. Advertising

  3. Robert Dober wrote:
    > On 12/30/06, M. Edward (Ed) Borasky <> wrote:
    >>
    >> Nick Pavey wrote:
    >> <snip>
    >> Well ... this discussion comes up often enough on this list that most
    >> peoples' opinions are well known,

    >
    >
    > I do hope they change, do you not?

    Of course ... times change, people change, the only constant is change,
    etc. But there are evolutions and revolutions, steady growth as well as
    bubbles and crashes, and lots of other phenomena in complex adaptive
    systems. I don't view Ruby as a revolution, for example -- certainly
    FORTRAN, COBOL, Lisp and Smalltalk were revolutions and possibly even Perl.
    > I have the feeling that each line of code I write change my attitude
    > towwards programming.

    Ah, to be young again! :) The last time I had that feeling was when I
    got my first Lisp program to run successfully. :)
    > Maybe I am desperately missing to work in large scale projects :(

    It's an acquired taste, for sure. :)
    >>
    >> 2. As I (and IIRC others) have mentioned in these discussions, the one
    >> language that was deliberately designed to facilitate development and
    >> maintenance of large software projects -- Ada -- seems to be a well-kept
    >> secret. It's still very much a live language -- GNU has a compiler, for
    >> example -- but, given that it was specifically designed to facilitate
    >> large efforts, how come the large efforts are being done in Java for the
    >> most part?

    >
    >
    > If I only knew? we lost our Ada83 project in 89 and I never could find an
    > Ada job anymore, I do not even know Ada95 save for a most superficial
    > layer.

    Well, in terms of complex adaptive systems, Ada got forced into a niche
    somehow. A while back, when VAXes ruled the world, Intel actually
    designed a 32-bit chip (IIRC their first 32-bit chip) specifically for
    Ada. Just as today's programmers prefer the freedom of
    Perl/Python/PHP/Ruby over Java and C++, the programmers back then
    preferred the freedom of Fortran and C.

    There are still Ada jobs, I think. Somebody must at least be maintaining
    all the Ada code that got written when it was mandated as the
    implementation language for defense projects. And I think there are even
    a few open source projects written in Ada.
    >
    > 3. The practices and processes of software engineering in most cases
    >> need to be *subordinate* to the business model, even (especially) when
    >> the business is a software development business! In many cases, that
    >> means you have to ship something that's "good enough" rather than
    >> something that's provably correct and has no transactions with
    >> unacceptable response times.

    >
    >
    > Could you elaborate? Would that pragmatical approach not allow to
    > implement using *your* technique? Please note I am out off business
    > since
    > 89, have to earn my bread with IP/DB/OS (baaad!)

    Well ... I can elaborate at great length, but I suspect I'd simply be
    repeating what other people have said and said more eloquently. This
    particular discussion is centered on language features and software
    engineering practices, and the original poster was very explicit about
    at least the business *context* of his post, if not the actual business
    model. In short, what works for him might not work for someone building,
    say, a social web site, an algorithmic composition package or a queuing
    theory model.

    --
    M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
    http://borasky-research.blogspot.com/

    If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
    M. Edward (Ed) Borasky, Dec 30, 2006
    #3
  4. Robert Dober wrote:
    > What I meant is the following, Is it possible to hide the choice of the
    > implementation language from the customer, can an abstraction be made to
    > "get the job done".
    > But this still might be OT, do not mind too much about it.

    Now *that* is an interesting philosophical question. Not "is it wise to
    hide the choice of the implementation language from the customer", but
    is it *possible*?

    On an "agile" project, probably it is neither wise nor possible, given
    that the customer is probably in the loop and even in the room while the
    programming is going on. But on a huge project, unless the language is
    mandated, like Ada for certain types of defense projects, it's not only
    possible but probably a good idea. I have, for example, absolutely no
    idea what the implementation language is for any of the major Microsoft
    projects -- Office, the Windows kernel, or IE. I can guess it's C++, or
    I could Google for it, I suppose, and given the age of the products I
    can rule out Java. But there's nothing in any of these complex products
    that is customer-visible that rules out implementation in any
    sufficiently-capable language.

    --
    M. Edward (Ed) Borasky, FBG, AB, PTA, PGS, MS, MNLP, NST, ACMC(P)
    http://borasky-research.blogspot.com/

    If God had meant for carrots to be eaten cooked, He would have given rabbits fire.
    M. Edward (Ed) Borasky, Dec 31, 2006
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?Unlhbg==?=

    Strong typing for user controls

    =?Utf-8?B?Unlhbg==?=, Jan 13, 2006, in forum: ASP .Net
    Replies:
    5
    Views:
    2,324
    =?Utf-8?B?Unlhbg==?=
    Jan 16, 2006
  2. Digital Puer
    Replies:
    27
    Views:
    5,082
    James Rogers
    Sep 13, 2003
  3. Gabriel Zachmann

    strong/weak typing and pointers

    Gabriel Zachmann, Oct 28, 2004, in forum: Python
    Replies:
    102
    Views:
    1,779
    Carl Banks
    Nov 13, 2004
  4. namekuseijin

    Re: "Strong typing vs. strong testing"

    namekuseijin, Sep 27, 2010, in forum: C Programming
    Replies:
    214
    Views:
    3,341
    Nick Keighley
    Oct 17, 2010
  5. namekuseijin

    Re: "Strong typing vs. strong testing"

    namekuseijin, Sep 27, 2010, in forum: Python
    Replies:
    229
    Views:
    3,438
    Gregory Ewing
    Oct 29, 2010
Loading...

Share This Page