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

Groups > comp.lang.java.programmer > #8590 > unrolled thread

in praise of type checking

Back to article view | Back to comp.lang.java.programmer

Contents

  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
      Re: in praise of type checking Arne Vajhøj <arne@vajhoej.dk> - 2011-11-06 17:32 -0500

Page 1 of 2  [1] 2  Next page →

#8590 — in praise of type checking

I changed the result of a widely used method from boolean to int.  The
neat thing was the compiler (actually the Intellij syntax checker)
made sure I fixed up every invocation of that method. It would not let
me forget even  one. 

Imagine a language with loosey goosey type checking where it was
entirely up to you entirely to ensure all the invocations were
corrected.  You could never be sure.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to 
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

[toc] | [next] | [standalone]

#8596

Roedy Green wrote:
> I changed the result of a widely used [sic] method from boolean to int.  The
> neat thing was the compiler (actually the Intellij syntax checker)
> made sure I fixed up every invocation of that method. It would not let
> me forget even  one. 

It must not have been that widely used, then, if all the uses were in the one project.

> Imagine a language with loosey goosey type checking where it was
> entirely up to you entirely to ensure all the invocations were
> corrected.  You could never be sure.

If the method were actually widely used, then all your users would discover the uses that IntelliJ had no access to.

Type checking can only check the code to which you have access.  If the API in question were available to more than one project, especially if some of them weren't yours, it'd still be entirely up to you entirely to ensure all the invocations were corrected.  You could never be sure.

Until you get the angry support call.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#8598

On 10/6/11 6:43 AM, Lew wrote:
> Roedy Green wrote:
>> I changed the result of a widely used [sic] method from boolean to int.  The
>> neat thing was the compiler (actually the Intellij syntax checker)
>> made sure I fixed up every invocation of that method. It would not let
>> me forget even  one.
>
> It must not have been that widely used, then, if all the uses were in the one project.
>
>> Imagine a language with loosey goosey type checking where it was
>> entirely up to you entirely to ensure all the invocations were
>> corrected.  You could never be sure.
>
> If the method were actually widely used, then all your users would discover the uses that IntelliJ had no access to.
>
> Type checking can only check the code to which you have access.  If the API in question were available to more than one project, especially if some of them weren't yours, it'd still be entirely up to you entirely to ensure all the invocations were corrected.  You could never be sure.
>
> Until you get the angry support call.
Unless you knew that was likely, in which case you would deprecate the 
old method and create a new method which returns int.

Related to type checking, it sounds like Roedy went from "I need a 
yes/no status" to a "I need more types of status."

int is the wrong way to go for that Roedy.  Consider enum or a Status 
class. ;-)

[toc] | [prev] | [next] | [standalone]

#8641

On Thu, 6 Oct 2011 06:43:04 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>
>It must not have been that widely used, then, if all the uses were in the o=
>ne project.

It was widely used within the project. It is internal code I use for
generating references to bookstores/books/electronics at various
online stores.

Even if it were widely distributed, and even if it were a public
method, type checking at least warns my clients I have changed the
signature of a public method without warning them. They may want to
shoot me, but at least they know precisely WHY they want to shoot me.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to 
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

[toc] | [prev] | [next] | [standalone]

#8644

On Fri, 07 Oct 2011 12:43:19 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote:

[snip]

>Even if it were widely distributed, and even if it were a public
>method, type checking at least warns my clients I have changed the
>signature of a public method without warning them. They may want to
>shoot me, but at least they know precisely WHY they want to shoot me.

     Careful.  Maybe they could get a justifiable homicide defence out
of that.  Please ask your executor to keep us posted.  <BEG>

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8647

On 10/7/2011 3:43 PM, Roedy Green wrote:
> On Thu, 6 Oct 2011 06:43:04 -0700 (PDT), Lew<lewbloch@gmail.com>
> wrote, quoted or indirectly quoted someone who said :
>
>>
>> It must not have been that widely used, then, if all the uses were in the o=
>> ne project.
>
> It was widely used within the project. It is internal code I use for
> generating references to bookstores/books/electronics at various
> online stores.
>
> Even if it were widely distributed, and even if it were a public
> method, type checking at least warns my clients I have changed the
> signature of a public method without warning them. They may want to
> shoot me, but at least they know precisely WHY they want to shoot me.

     Even in my private code that I never intend to distribute to
anyone at all, I make a point of changing something's name if I change
its nature.  That's seldom onerous, because a change in nature usually
means the old name is no longer appropriate:

	/* old */ boolean isImportant() ...
	/* new */ float[] isImportant() ... // say, what?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#8606

On 06.10.2011 08:33, Roedy Green wrote:
> I changed the result of a widely used method from boolean to int.  The
> neat thing was the compiler (actually the Intellij syntax checker)
> made sure I fixed up every invocation of that method. It would not let
> me forget even  one.

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.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#8639

On Thu, 06 Oct 2011 22:31:42 +0200, Robert Klemme
<shortcutter@googlemail.com> 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.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
It should not be considered an error when the user starts something
already started or stops something already stopped. This applies
to browsers, services, editors... It is inexcusable to 
punish the user by requiring some elaborate sequence to atone,
e.g. open the task editor, find and kill some processes.

[toc] | [prev] | [next] | [standalone]

#8650

On 10/07/2011 09:36 PM, Roedy Green wrote:
> On Thu, 06 Oct 2011 22:31:42 +0200, Robert Klemme
> <shortcutter@googlemail.com>  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.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#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 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.)  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!).  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.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#8694

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.

> 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.

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.

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

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#8716

On Tue, 11 Oct 2011 07:48:07 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

[snip]

>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.

     Or that there is no one optimum.

>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).

     Which explains why it comes up again and again.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#8719

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

[toc] | [prev] | [next] | [standalone]

#8726

Arved Sandstrom wrote:
...
> 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).
...

It does not even have to be different people. Some tasks seem easier to
me in a dynamically typed language, others with static typing.

Patricia

[toc] | [prev] | [next] | [standalone]

#8730

On Wed, 12 Oct 2011 01:49:46 +0100, Patricia Shanahan <pats@acm.org>
wrote:

>Arved Sandstrom wrote:
>...
>> 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).
>...
>
>It does not even have to be different people. Some tasks seem easier to
>me in a dynamically typed language, others with static typing.

     Quite.  I prefer static, because I like to catch the trouble up
front.  This is at a cost of flexibility, and sometimes, I want/need
that flexibility.

Sincerely,

Gene Wrichenko

[toc] | [prev] | [next] | [standalone]

#8729

On Monday, October 10, 2011 10:48:07 PM UTC-7, Robert Klemme wrote:
>  ...

Your points are cogent and your conclusions make sense.

Each tool in the toolshed has a purpose. I am not against dynamically-typed languages at all.  One has to use the qualities of the tool to enhance one's purpose.

No question that both sides offer value to the systems development process.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#8611

On 10/6/2011 2:33 AM, Roedy Green wrote:
> I changed the result of a widely used method from boolean to int.  The
> neat thing was the compiler (actually the Intellij syntax checker)
> made sure I fixed up every invocation of that method. It would not let
> me forget even  one.
>
> Imagine a language with loosey goosey type checking where it was
> entirely up to you entirely to ensure all the invocations were
> corrected.  [...]

     Are you speaking of Python, or of Lisp?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#8616

On Oct 7, 2:29 am, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> On 10/6/2011 2:33 AM, Roedy Green wrote:
>
> > I changed the result of a widely used method from boolean to int.  The
> > neat thing was the compiler (actually the Intellij syntax checker)
> > made sure I fixed up every invocation of that method. It would not let
> > me forget even  one.
>
> > Imagine a language with loosey goosey type checking where it was
> > entirely up to you entirely to ensure all the invocations were
> > corrected.  [...]
>
>      Are you speaking of Python, or of Lisp?

... or Ruby.  These languages work remarkably well and in fact for me
it's more fun to code in Ruby than in Java.

Cheers

robert

[toc] | [prev] | [next] | [standalone]

#8635

Hi!

Robert Klemme wrote:
> On Oct 7, 2:29 am, Eric Sosman<esos...@ieee-dot-org.invalid>  wrote:

>>       Are you speaking of Python, or of Lisp?
> ... or Ruby.

And then there are languages where you can decide if the compiler should
be that picky.
There are for instance: Clipper5, Perl, Visual Objects...
The advantage is:
You can create all "regular" code in strict mode, the few places using
nasty tricks can be the exception and special TLC.

Gunter in Orlando, Fl

[toc] | [prev] | [next] | [standalone]

#8619

On 11-10-06 03:33 AM, Roedy Green wrote:
> I changed the result of a widely used method from boolean to int.  The
> neat thing was the compiler (actually the Intellij syntax checker)
> made sure I fixed up every invocation of that method. It would not let
> me forget even  one. 
> 
> Imagine a language with loosey goosey type checking where it was
> entirely up to you entirely to ensure all the invocations were
> corrected.  You could never be sure.

I'm not sure of the technical meaning of "loosey goosey" type checking:
I expect you mean a mishmash of dynamic typing + weak typing, maybe more
so the weak typing aspect, but you'd have to explain. Or perhaps you
mean type safety, which is different yet again - dynamic typing can
absolutely be type safe, for example.

Having said that, I don't myself see the awfulness inherent in *me*
having to check that all the uses of a changed method are still correct.
For at least the first 25 years of my programming career this is what I
did anyway, on the hopefully rare occasions that I'd make such a change
well into coding. After all, there were not that many IDEs available to
do the grunt work [1].

Also, in which circumstances would you be willing to change the return
type of a method in such a significant way (boolean to int is profound)
and _not_ manually (visually and individually) check each and every call
site yourself? How can you just leave it up to the IDE to do the
refactoring, and report back simply that code will continue to compile?

AHS

1. I leave aside the argument that a comprehensive set of command-line
tools or something like Emacs *is* an IDE also.
-- 
I tend to watch a little TV... Court TV, once in a while. Some of the
cases I get interested in.
-- O. J. Simpson

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web