Forum: Ruby Strong encapsulation, static typing and unit testing

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Nick P. (Guest)
on 2006-12-30 00:46
(Received via mailing list)
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 P.
removed_email_address@domain.invalid
M. Edward (Ed) Borasky (Guest)
on 2006-12-30 04:22
(Received via mailing list)
Nick P. wrote:
> My attention was grabbed by Jeff's response in the original thread, so
>
> particular unit - having stricter checking on interfaces would really
> impossible - esp GUIs and large web apps
> Cheers,
>
>
>
>
>
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.
Robert D. (Guest)
on 2006-12-30 10:43
(Received via mailing list)
On 12/30/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
wrote:
>
> Nick P. 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?
I have the feeling that each line of code I write change my attitude
towwards programming.
Maybe I am desperately missing to work in large scale projects :(

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. :)


As a matter of fact I did ;)

But here goes:
> 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.

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!)

--
> 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.
>
>
> Cheers
Robert


--
"The real romance is out ahead and yet to come. The computer revolution
hasn't started yet. Don't be misled by the enormous flow of money into
bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas."

- Alan Kay
M. Edward (Ed) Borasky (Guest)
on 2006-12-31 00:05
(Received via mailing list)
Robert D. wrote:
> On 12/30/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> wrote:
>>
>> Nick P. 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. :)
> 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.
> 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.
Robert D. (Guest)
on 2006-12-31 11:30
(Received via mailing list)
On 12/30/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
wrote:
> ><snip>
Nice reading  but I guess we are getting off topic

> say, a social web site, an algorithmic composition package or a queuing
> theory model.


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.

Thx for your thaughts Ed
and Happy New Year to all :)

Cheers
Robert

--
>
>
>


--
"The real romance is out ahead and yet to come. The computer revolution
hasn't started yet. Don't be misled by the enormous flow of money into
bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas."

- Alan Kay
M. Edward (Ed) Borasky (Guest)
on 2006-12-31 19:57
(Received via mailing list)
Robert D. 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.
Robert D. (Guest)
on 2007-01-01 13:01
(Received via mailing list)
On 12/31/06, M. Edward (Ed) Borasky <removed_email_address@domain.invalid> 
wrote:
> 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.


Thx for sharing and Happy New Year.
Robert

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


--
"The real romance is out ahead and yet to come. The computer revolution
hasn't started yet. Don't be misled by the enormous flow of money into
bad
defacto standards for unsophisticated buyers using poor adaptations of
incomplete ideas."

- Alan Kay
This topic is locked and can not be replied to.