Phlip <phlip2...@gmail.com> writes: > John Bokma wrote: > >> my $x = ( 5, "hello", sub {}, [], {} )[ int rand 5 ]; >> >> what's $x? The answer is: it depends. > > That's why my blog post advocated (as usual for me) developer tests. > Then you either mock the rand, like all developers should, or you get > what you pay for, and Principle of Least Surprise still applies...
Yup, I agree with you that (to some extent) an IDE should be able to determine types, especially if programmers don't reuse variables, like (again Perl): my $result = .... # int : : if ( ... ) { $result = .... # string } # $result can be still an int, or either a string, depending on the # test. > Over the past decade, teams discovered that developer tests more than > made up for the lack of rigor in dynamic languages. A dynamic language > with tests can be more productive than a static language, even with > its runtime type checks AND with its tests. Yup, this matches up with my experience. I can't recall that I ever bumped into an issue in Perl (the dynamic language I've been using the most for the past years). Not saying that it hasn't happened, but I just can't recall. Probably also the reason why a "new" language I am learning is also dynamic: Python ;-) > However, our editors must catch up to us. When I test, I am statically > declaring a set of types, even if the language would prefer to > dynamically fling them hither and yon. We should leverage that. I am all for testing, but it should IMO not get into the way. I am quite happy with Emacs as an editor (I "recently" switched), it satisfies most (if not all) of the items on the check list. -- John Bokma j3b Hacking & Hiking in Mexico - http://johnbokma.com/ http://castleamber.com/ - Perl & Python Development -- http://mail.python.org/mailman/listinfo/python-list