On Sun, Feb 17, 2008 at 4:34 PM, Rule.rule <rule.rule.rule / gmail.com> wrote:
>  But more importantly a general problem with just saying "test your code",
>  is that most real-life applications have an infinite number of
>  possible different inputs,
>  and you can only test a finite number of input-cases

And all that static typing does for this line of argument is to
restrict the number of input cases to a somewhat smaller infinity. And
not even in a way that excludes interesting defects, either.

Empirically, those who develop in dynamic languages commonly observe two things:

1. Use of static typing (at least, as implemented by current
mainstream static languages) causes accidental complexity. Complexity
== bugs.

2. Software written in Python or Ruby does not appear to be more
defect-prone in production, than software written in Java or C#.

>  -- one would like to ensure every code-line is executed at least once during every test.
> Already this goal alone, is far from a trivial task in real-life applications.

In practice, nobody should ever rely on automated tests alone, anyway.
And gunning for 100% code coverage by automated tests is waste,
because automated tests have their cost. For some parts of the
application code that cost doesn't justify the benefits.

By the way, decent code coverage is far easier to achieve with dynamic
typing and open classes. Mocking out awkward integration boundaries is
a breeze, even when those integration boundaries are third-party and
not designed for testability.

>  I think Ruby is a very interesting and fun tool to use and experiment
>  with, but might still not be the totally ideal one for every possible task
>  and application on earth,

Oh, well... show me such a tool, and I will forget about Ruby in a
heartbeat. Pending that, for a pretty wide set of applications, Ruby
sucks the least.

-- 
Alexey Verkhovsky
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]
RubyWorks [http://rubyworks.thoughtworks.com]