R
Roger Alsing
The type checking in the popular strongly typed languages like Java
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?
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)
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)
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)
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.
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
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.