[ruby-talk:9417] Re: 101 Misconceptions About Dynamic Languages

Nathaniel Talbott wrote:

# [but neglected to cite who he quoted]

# > On the pro-C++ side, I still draw comfort from a
# > clean compile. I don't think I would ever feel
# > safe in Ruby without a suite of unit tests
# > exercising all the things that can go wrong in my
# > code at run-time.

Maybe so, but many others seem to feel safer with increased experience. 
This may also be a function of what sorts of applications you and others 
are doing. But I would like to see the compiler do other types of checking 
(yes, pun intended); see below.

There are some major applications that I (and millions of other people) 
use (and even like) that are unfortunately semi-notorious for their run 
time errors, and it is my understanding that these are mostly written in 
C++. 

Too many people have drawn comfort from clean Java compiles, only for 
others of us to have later on encountered "NullPointerException"s rather 
more often then we would have liked. (This in a language once promoted as 
having no pointers.) 

IMHO, Donald Knunth is the only person on earth that could *realistically* 
draw comfort from clean compiles with respect to things that can go wrong 
at run time. :-)

# Hmmm...
# 
#                "Ruby - the language that makes you feel like unit
#                testing"
# 
# Sounds like an advantage, not disadvantage :-) While I see pros for
# going to byte-code compilation, none of them have anything to do
# with error-checking.  It seems to me the compiler is a tempting
# crutch to lean on instead of properly testing your code. Just my
# $0.02.

Hmmm.... That's also a good reason for removing Ruby's -w flag, which is 
just another tempting crutch. Indeed, syntax error messages should be 
removed too, since they are just crutches for those slothful holdouts that 
don't properly test after each newly added statement. :-)

Actually, I think it would be nice if Ruby's -w flag were as powerful as 
Perl's and if there was something comparable to Perl's "use diagnostics;". 
These features do a fairly remarkable job of warning about and of 
explaining about probable/actual programming errors at compile time 
(although Perl is so big and complex that these features still miss lots 
of problems).

Over the last year, the expressed consensus of the long term expert Ruby 
users seems to have been that they very rarely encounter the sorts of 
problems where strong static type checking would be useful--indeed, so 
rarely so that strong static type checking would actually be 
counterproductive in terms of overall productivity at the same level of 
quality. (I haven't seen a satisfying theoretical explanation of why this 
is the case, but I think that part of the reason is that off by one errors 
and dirty data cause many more problems in practice than dirty syntax 
((type-wise))--and compilers are oblivious to these things.)

Given this situation, about the only practically effective way to argue 
for adding some additional form of static type checking to Ruby is to base 
such arguments on actual experience with Ruby programs. Only on the basis 
of such (and much!) *actual* *Ruby* *experience* would you then have a 
reasonable clue about what sorts of things were actually needed, why they 
were needed, and where they were needed. I strongly suspect that some 
optional Ruby Way (tm) of static type-checking will eventually be 
developed, but I doubt that C++ will be the language that Ruby will borrow 
from.

Conrad Schneiker
(This note is unofficial and subject to improvement without notice.)