> The type checking in the popular strongly typed languages like Java
> and C++ are actually quite weak in uncovering incorrect code.

Yes absolutely, static typed languages have a problem finding logical 
flaws at compiletime.
But so does Ruby since it doesnt even have compiletime.
So thats a non argument.

If C# cant find logical problems at compile time and
Ruby cant fint logical flaws at compile time either (due to lack of 
such)

And you will find the problem at runtime in C#, and likewise in Ruby.

How does that make C# worse than Ruby in that aspect?

> They are really about imposing constraints so that code isn't run
> against the wrong data at run-time.  Such constraints are necessary in
> languages whose implementations determine which method  to run by a
> type determined at compile time, rather than by using self-describing
> runtime information to do method dispatching.

I will still argue that a method name alone is not self-describing.
It will only describe signature but not semantics.
(while I do argue that interfaces carry semantics with them, and that 
you have to willingly break that semantics if you implement an interface 
method incorrectly)

> Many errors aren't found at compile time in these languages, for
> example, array bounds errors.  It's very hard to design a static type
> system which detects the error in
> 
> function foo(array a, int i)
>     array[i]
> end
> 
> ary = new Array(10)
> foo(ary, 12)
> 
> There are certainly less popular languages which attempt this, but
> they aren't widely used.  Some consider arrays with different bounds
> to be of different types, but this makes it hard to write lots of
> things.  Others do type inferencing, but these tend to be hard for
> mere mortals to understand, at least the ones I've seen so far.
> 
> So languages like Java, despite being statically typed, defer array
> bounds checking to run-time.

Yes, and Ruby still does runtime checks for everything, so it is still a 
non argument.

You are comparing the compile time checks of static languages alone to 
the runtime checks of Ruby.
Thats not how it works, static languages have compile time AND runtime 
checks.

(And I'm confident that you know that there are list types in other 
languages if we need expansion)


> As for run-away errors being hard to debug, that's true, but from
> practical experience these tend to be much worse in statically typed
> languages where the compiler got fooled by a typecast, or a pointer
> alias bug, and branched through a non-existent or wrong virtual
> function table, or did a fetch or store outside of the bounds of the
> object because it got the type wrong.

Well that's a bit of a stretch.
You are taking the worst of c and c++ and making it look like its a 
major problem in all static typed languages.
(Yes C# have pointers if you like, but they are used once in a lifetime 
for most people there)


> If your concern is correctness, which it should be, then it's best to
> use best practices for writing in dynamic languages, such as TDD/BDD
> rather than attempting to mimic techniques from statically typed
> languages which are really there to cover the class of errors caused
> by a statically typed implementation.

So you are saying that just because you do TDD you do not apply argument 
validation in your API?

Argument validation have nothing to do with static typing, it has to do 
with good practice and preventing the consumers of your API from 
screwing up badly.

I do practice TDD, but that doesnt make me assume that every consumer of 
my code will also do TDD.

-- 
Posted via http://www.ruby-forum.com/.