Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #8719

Re: in praise of type checking

Show all headers | View raw

On 11-10-11 02:48 AM, Robert Klemme wrote:
> On 08.10.2011 18:35, Lew wrote:
>> 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 will 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.
>>>
>>> Oh, yes!  Of course you are right.  Shouldn't have posted that
>>> late. Sorry for the noise.
>>>
>>> I find interesting that the debate static vs. dynamic typing comes
>>> up every once in a while.  The static typers have the intuition on
>>> their side that with more expressiveness in languages and stricter
>>> enforcement of contracts less errors will happen.  The dynamic
>>> typers usually refer errors being caught with tests - which you
>>> have to write anyway - even for programs in statically typed
>>> languages.  And then the higher productivity of dynamic languages
>>> may actually pay off.
>>
>> Tests find bugs after they happen.  The compiler finds bugs before
>> they happen.
>>
>> Tests are optional.  A programmer can choose (unwisely) not to write
>> tests; they can't choose to avoid the compiler.  Tests can be
>> incomplete; everything 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
>> written.  You've worked on projects where the tests are insufficient,
>> yes?
>>
>> As for "the higher productivity of dynamic languages", the facts have
>> not been presented into evidence for that.  The question involves
>> fully defining "productivity", which must include maintenance costs
>> else you have not internalized 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 stack traces, to appear in the browser when
>> the application fubared.  Well, no wonder they were more
>> "productive".  If I could bring myself to inflict crashes 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 Java.  I am pointing out that any such comparison must account for
>> the consequences 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 project, and how much
>> they cover or fail to cover.
>>
>> Unfortunately your conclusion flies in the face of published
>> research.  (I don't have references handy, sorry.)
> 
> Which conclusion?  Here are my two points with a bit more explanation:
> 
> 1. It is interesting that the discussion dynamic vs. static typing comes
> up again and again.  This indicates that people are not able or do not
> want to settle it.
> 
> 2. Static typing is not automatically superior to dynamic typing in
> every case.  (Neither is the opposite true but because of the thread's
> subject I am of course arguing in favor of dynamic typing to balance
> other positions).
> 
> To add a bit more explanation: I believe the reason for 1 is the former:
> people /cannot/ settle this because "dynamic vs. static typing" leaves
> out too many aspects which are important for success and cost of
> software projects: these are at least nature of the software (and size),
> people (skills and number) and process used.  Yet people often search
> for simple and catchy rules which explains the popularity of the topic.

As Gene said (and I happen to agree with), there is no one optimum. One
guy in one situation will see that dynamic typing suits his purposes
better than static typing (or at least he thinks it does), and another
guy in another situation thinks that static typing is better than
dynamic typing (and he in turn may have good reasons, adequate reasons,
or lousy reasons for believing so).

Let's also keep in mind that since there is no hard and fast answer to
this one, it's an appealing subject for debate, and let's also keep in
mind that since the bar to discussing this is apparently low, every new
generation of novices thinks they can dive right in too. After all,
you'll have guys with 6 months of Ruby and no other language under their
belts (this is *not* a subtle dig at you :-)) and they think _they_ can
claim that dynamic typing is better than static typing.

>> 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 found in production (surely no one can
>> argue that those were prevented!).
> 
> Certainly.  But the cost of bugs found during testing depends on the
> process used: that the compiler does not catch a bug does not
> automatically mean that it's late into the project that it is caught.
> And "lateness" is the most driving factor for cost because the more time
> passes the more code can be written which depends on the faulty code.
> 
>> This is only about bugs; the cost
>> of maintenance, enhancement and refactoring apply as well.  You have
>> to internalize all the costs to fairly compare the approaches.
> 
> Type information for e.g. method arguments certainly helps make code
> readable but it is easy to write spaghetti code in statically and
> dynamically typed languages.  Maintainability also depends on quality of
> documentation and the overall design.

Static typing (a la Java) and dynamic typing (a la Python) are a small
part of the puzzle here. A strongly-typed dynamically-typed language is
arguably much better than a weakly-typed statically-typed language.

Furthermore, if we look at the entire spectrum, where does a Java
variable lie? Without any further constraints, it looks pretty weak
compared to a functional language variable, which really *is* a variable
- single-assignment...and depending on the language you'd probably be
using immutable values as well. If you're following good practice by
coding to an interface, that Java variable's static type may be as wide
ranging as a List or Map (and generifying may not pin it down much more
either), and if it's not a final, and if the value is mutable (which is
probable), you're not gaining nearly as much over a dynamically typed
variable as you think.

In other words, I agree wholeheartedly that design and other practices
outside of simple reliance on the type system are major factors. I'd go
so far as to say that regardless of your competency, that the type
system in use will not matter that much. Not until you use really strict
type systems like that of Haskell.

> Two more points to consider
> 
> 1. Static typing won't detect design and architecture flaws which are
> generally considered to be the most expensive to remedy.

Agreed.

> 2. Static typing is only of limited help in detecting concurrency issues
> which are often hard to track down and thus expensive.
> 
> Kind regards
> 
>     robert
> 
AHS

-- 
I tend to watch a little TV... Court TV, once in a while. Some of the
cases I get interested in.
-- O. J. Simpson

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

in praise of type checking Roedy Green <see_website@mindprod.com.invalid> - 2011-10-05 23:33 -0700
  Re: in praise of type checking Lew <lewbloch@gmail.com> - 2011-10-06 06:43 -0700
    Re: in praise of type checking Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2011-10-06 09:52 -0700
    Re: in praise of type checking Roedy Green <see_website@mindprod.com.invalid> - 2011-10-07 12:43 -0700
      Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-07 14:57 -0700
      Re: in praise of type checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-07 20:18 -0400
  Re: in praise of type checking Robert Klemme <shortcutter@googlemail.com> - 2011-10-06 22:31 +0200
    Re: in praise of type checking Roedy Green <see_website@mindprod.com.invalid> - 2011-10-07 12:36 -0700
      Re: in praise of type checking Robert Klemme <shortcutter@googlemail.com> - 2011-10-08 16:05 +0200
        Re: in praise of type checking Lew <lewbloch@gmail.com> - 2011-10-08 09:35 -0700
          Re: in praise of type checking Robert Klemme <shortcutter@googlemail.com> - 2011-10-11 07:48 +0200
            Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-11 13:04 -0700
            Re: in praise of type checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-11 17:52 -0300
              Re: in praise of type checking Patricia Shanahan <pats@acm.org> - 2011-10-12 01:49 +0100
                Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-11 19:12 -0700
            Re: in praise of type checking Lew <lewbloch@gmail.com> - 2011-10-11 19:10 -0700
  Re: in praise of type checking Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-10-06 20:29 -0400
    Re: in praise of type checking Robert Klemme <shortcutter@googlemail.com> - 2011-10-06 23:56 -0700
      Re: in praise of type checking Gunter Herrmann <notformail0106@earthlink.net> - 2011-10-07 13:57 -0400
  Re: in praise of type checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-07 07:19 -0300
    Re: in praise of type checking Roedy Green <see_website@mindprod.com.invalid> - 2011-10-07 12:39 -0700
      Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-07 15:03 -0700
        Space probes was Re: in praise of type checking Tom Anderson <twic@urchin.earth.li> - 2011-10-11 19:26 +0100
          Re: Space probes was Re: in praise of type checking Leif Roar Moldskred <leifm@dimnakorr.com> - 2011-10-12 01:15 -0500
            Re: Space probes was Re: in praise of type checking Travers Naran <tnaran@gmail.com> - 2011-10-12 07:23 -0700
            Re: Space probes was Re: in praise of type checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-12 20:04 +0000
            Re: Space probes was Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-12 13:53 -0700
              Re: Space probes was Re: in praise of type checking Leif Roar Moldskred <leifm@dimnakorr.com> - 2011-10-12 16:55 -0500
                Re: Space probes was Re: in praise of type checking Gene Wirchenko <genew@ocis.net> - 2011-10-12 15:02 -0700
                Re: Space probes was Re: in praise of type checking Leif Roar Moldskred <leifm@dimnakorr.com> - 2011-10-13 00:08 -0500
                Re: Space probes was Re: in praise of type checking Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-10-13 07:48 -0300
                Re: Space probes was Re: in praise of type checking "John B. Matthews" <nospam@nospam.invalid> - 2011-10-14 07:09 -0400
                Re: Space probes was Re: in praise of type checking Martin Gregorie <martin@address-in-sig.invalid> - 2011-10-12 22:03 +0000
            Re: Space probes was Re: in praise of type checking Tom Anderson <twic@urchin.earth.li> - 2011-10-14 14:14 +0100
  Re: in praise of type checking RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2011-10-07 11:50 +0100
    Re: in praise of [loosey goosey] type checking) RedGrittyBrick <RedGrittyBrick@spamweary.invalid> - 2011-10-07 12:20 +0100
  Re: in praise of type checking Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-10-07 14:00 +0000

csiph-web