[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

Strong encapsulation, static typing and unit testing

Nick Pavey

12/29/2006 10:44:00 PM

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@skatingloons.com
3 Answers

M. Edward (Ed) Borasky

12/30/2006 2:21:00 AM

0

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
> nick@skatingloons.com
>
>
>
>
>
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.blo...

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

M. Edward (Ed) Borasky

12/30/2006 10:04:00 PM

0

Robert Dober wrote:
> On 12/30/06, M. Edward (Ed) Borasky <znmeb@cesmail.net> 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.blo...

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.

M. Edward (Ed) Borasky

12/31/2006 5:56:00 PM

0

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.blo...

If God had meant for carrots to be eaten cooked, He would have given rabbits fire.