Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!nx01.iad01.newshosting.com!newshosting.com!novia!news-out.readnews.com!news-xxxfer.readnews.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: in praise of type checking Date: Sat, 8 Oct 2011 09:35:36 -0700 (PDT) Organization: http://groups.google.com Lines: 70 Message-ID: <19264117.413.1318091736115.JavaMail.geo-discussion-forums@prib32> References: <9f6hhqF717U1@mid.individual.net> <82lu87t4e47t1256r1vh7ich0esreter46@4ax.com> <9fb3m5F79oU1@mid.individual.net> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 216.239.45.130 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1318091859 29292 127.0.0.1 (8 Oct 2011 16:37:39 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 8 Oct 2011 16:37:39 +0000 (UTC) In-Reply-To: <9fb3m5F79oU1@mid.individual.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=216.239.45.130; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8651 Robert Klemme wrote: > Roedy Green wrote: >> Robert Klemme wrote, quoted or indirectly quoted someone who said : >>> I'm surprised you mention the compiler and syntax checker. In my >>> Eclipse changing the return type of a method is a refactoring which wil= l >>> easily change all affected methods in code which is part of the project= . >>> Lew's caveats apply of course. >> >> I changed the return type. That meant the caller now had to deal with >> 3 possible values instead of two. There is a no way a refactor can >> handle that. It is called Change Signature in IntelliJ. It is great >> for swapping parms, or changing a type, or adding a new parm. When you >> add a new parm, you still have to visit all the invocations to touch >> up if the default value does not apply. >=20 > Oh, yes! Of course you are right. Shouldn't have posted that late.=20 > Sorry for the noise. >=20 > I find interesting that the debate static vs. dynamic typing comes up=20 > every once in a while. The static typers have the intuition on their=20 > side that with more expressiveness in languages and stricter enforcement= =20 > of contracts less errors will happen. The dynamic typers usually refer= =20 > errors being caught with tests - which you have to write anyway - even=20 > for programs in statically typed languages. And then the higher=20 > productivity of dynamic languages may actually pay off. Tests find bugs after they happen. The compiler finds bugs before they hap= pen. Tests are optional. A programmer can choose (unwisely) not to write tests;= they can't choose to avoid the compiler. Tests can be incomplete; everyth= ing gets compiled. You have to write tests; you already have a compiler. In practice, the tests "which you have to write anyway" are often not writt= en. You've worked on projects where the tests are insufficient, yes?=20 As for "the higher productivity of dynamic languages", the facts have not b= een presented into evidence for that. The question involves fully defining= "productivity", which must include maintenance costs else you have not int= ernalized the costs that strongly-typed languages aim to avoid. Case in point - in one Language War of PHP vs. Java for Web applications, a= PHP fanboy mentioned that they allowed exception crashes, complete with st= ack traces, to appear in the browser when the application fubared. Well, n= o wonder they were more "productive". If I could bring myself to inflict c= rashes on the user, I'd be far more "productive", too, even in Java. I am *not* arguing against dynamically-typed languages, nor in favor of Jav= a. I am pointing out that any such comparison must account for the consequ= ences and costs of each approach. Next time you have to refactor a million= -plus-line software system involving dozens of programmers, think about how= type safety and other compile-time checks can or should help, or not, vs. = tests and other run-time techniques. Look at the state of tests on that pr= oject, and how much they cover or fail to cover. =20 Unfortunately your conclusion flies in the face of published research. (I = don't have references handy, sorry.) By all accounts, bugs found (and thus= prevented!) at compile time are far, far cheaper than bugs found (and thus= not prevented!) in testing, which in turn are far, far cheaper than bugs f= ound in production (surely no one can argue that those were prevented!). T= his is only about bugs; the cost of maintenance, enhancement and refactorin= g apply as well. You have to internalize all the costs to fairly compare t= he approaches. --=20 Lew