Weblogs Forum - Programming with "Duh" Typing

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Programming with "Duh" Typing

370 replies on 25 pages. Most recent reply: Aug 8, 2007 9:54 AM by James Watson

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 370 replies on 25 pages [ « | 1 ... 16 17 18 19 20 21 22 23 24 ... 25 | » ]

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 6:51 AM

> A test T in a statically typed language can guarantee that
> the software is correct while the same program written in
> a different language can still pass test T and yet fail in
> other areas (that wouldn't fail in a statically compiled
> language).

I would like to point out that proving statically that software is correct is impossible. A static type system only proves that what you typed makes some kind of sense...but what kind of sense? it's unknown unless you run the program.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 7:00 AM

> > But it does not mean anything that the code passed
> > compiling. You have to run it afterwards, haven't you?
> and
> > that's my point: since you are going to run it, why
> bother
> > with static typing and even compilation? just run the
> > program and correct it as you go. It's a much more
> > rewarding experience.
>
> Here's to hoping that you never have the job of writing
> the software that runs an autopilot for an airplane. Or a
> pacemaker.

I actually am involved in defense programming (for THALES). The customer does not accept the code unless it is accompanied by a receipt that 100% of it has been tested functionally.

I know it's boring to write test cases, and I can tell you I have been caught tearing my fleshes many times over test documents 100s of pages long (even documents split in several parts!). And let me say it again: it's boring!

But big companies like THALES, Raytheon etc do not accept code that has not been fully tested and for all cases and possible values. You can't release C++, Java or ADA code that has not been fully tested beforehand (and in many cases, tested by two or three individual teams).

I think the above fact speaks for itself about the value of static type systems vs functional testing!

Petrik de Heus

Posts: 19
Nickname: p8
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 7:11 AM

> > > On the other hand, I can't think of a test written in
> a
> > > statically typed language that would be made
> > unnecessary
> > > in a dynamically typed language because of the fact
> > that
> > > types are optional in that language.
> >
> > I can.
> >
> > Try the following in Java:
> >

assertEquals("10000000000", (new
> Double(Math.pow(10,
> > 10)).intValue()));

> > Ruby gives the expected result even for very large
> > numbers:
> >

10.power!100000

>
> This example has nothing to do with static typing. It has
> to do with the nature of the way the numbers are being
> represented. In Java you could use a BigInteger and it
> would work properly. A 32 bit integer type in a dynamic
> language would also be unable to store such large
> numbers.

It's an example of a test written in a statically typed language(Java) that is unnecessary in a dynamically typed language(Ruby) because of the fact types are 'optional' in that language.

Ruby is smart enough to see the difference.
>> 10000000000.class
=> Bignum
>> 100.class
=> Fixnum

> > In Java you can do:
> >

"" + new Object()

> > Which might not give the expected result.
> > In Ruby this creates an error.
> >

p "Object " + Object.new
> > => TypeError: can't convert Object into String

>
> I think it's pretty odd to the one example of operator
> overloading in Java when Ruby supports operator
> overloading universally. And, of course, this has nothing
> to do with static typing. It has to do with operator
> overloading. It's actually a really nice feature and it
> annoys me when I can't use it in Python and have blot the
> code with str() calls.

It's an example of a test written in a statically typed language(Java) that is unnecessary in a dynamically typed language(Ruby).

assertEquals("123", "1" + new Long(2) + new Long(3));
assertEquals("15", "1" + (new Long(2) + new Long(3));

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 8:39 AM

> It's an example of a test written in a statically typed
> language(Java) that is unnecessary in a dynamically typed
> language(Ruby) because of the fact types are 'optional' in
> that language.
>
> Ruby is smart enough to see the difference.
> >> 10000000000.class
> => Bignum
> >> 100.class
> => Fixnum

Again this is not a static typing issue. You could build the same functionality using static types.

> It's an example of a test written in a statically typed
> language(Java) that is unnecessary in a dynamically typed
> language(Ruby).
>
> assertEquals("123", "1" + new Long(2) + new Long(3));
> assertEquals("15", "1" + (new Long(2) + new Long(3));

Again it is not. There is nothing about dynamic typing that prevents you from implementing the same overloading for strings that exists in Java. In fact, it's a lot easier.

Just because there are differences between Java and Ruby doesn't mean they are related to static typing and dynamic typing.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 8:43 AM

> > A test T in a statically typed language can guarantee
> that
> > the software is correct while the same program written
> in
> > a different language can still pass test T and yet fail
> in
> > other areas (that wouldn't fail in a statically
> compiled
> > language).
>
> I would like to point out that proving statically that
> software is correct is impossible. A static type system
> only proves that what you typed makes some kind of
> sense...but what kind of sense? it's unknown unless you
> run the program.

You've made that point numerous times. No one is saying that static typing proves software is correct.

What a lot of people DON'T seem to realize that unit tests also don't prove software to be correct and that for most non-trivial applications, it is not feasible to prove correctness at all.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 8:48 AM

> Only yesterday I had a serious error which was in a test
> version sent to the customer, just because I was bored to
> run the whole series of tests.

You are making the error of generalizing your personal experience to the entire industry.

I have no doubt that with your level of expertise, you are only very rarely a victim of bugs caused by the dynamicity of the language you are using. You are most likely very thorough in the way you write your tests and you run them very diligently at each change.

I maintain that the safety net offered by statically typed languages in invaluable for teams of 10, 50, 200 programmers in projects where literally, tens of thousands of lines of code are checked in every day and where functional tests take entire days to run.

> So I prefer dynamic systems with interactive development,
> which cuts the development time at least by half, instead
> of the endless cycle of edit-compile-run-debug.

Honestly, I certainly see some improvement in productivity when I write code in Ruby or even Javascript, but:

- It's never because of a faster edit-compile-run-debug cycle. Eclipse makes this cycle ultra fast, and most of my time is usually spent getting the system up and running (i.e. web server or database accesses) or restoring it to a state that corresponds to the area that I'm currently working on or debugging.

- I always pay some kind of price down the road, such as a few months later when I realize I need to do some massive refactoring.

--
Cedric
http://testng.org

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 8:55 AM

Cedric Beust wrote
> You are making the error of generalizing your personal
> experience to the entire industry.

You would never do that! :-)

> when I write code in Ruby or even Javascript
...
> - I always pay some kind of price down the road, such as a
> few months later when I realize I need to do some massive
> refactoring.

Would that be because of the lack of refactoring tools for Ruby and Javascript?

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 9:00 AM

> Cedric Beust wrote
> > You are making the error of generalizing your personal
> > experience to the entire industry.
>
> You would never do that! :-)

Touche' :-)

> > when I write code in Ruby or even Javascript
> ...
> > - I always pay some kind of price down the road, such as a
> > few months later when I realize I need to do some massive
> > refactoring.
>
> Would that be because of the lack of refactoring tools for
> Ruby and Javascript?

Indirectly.

The fact that I'm paying this price and that there are no reliable refactoring tools for dynamically typed languages come from the same cause: the types are gone.

Like we established in this discussion, the absence of types in a large code base is a big problem for automatic and human actions alike.

--
Cedric
http://testng.org

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 9:04 AM

James Watson wrote
> ... unit tests also don't prove software to be correct and
> that for most non-trivial applications, it is not feasible
> to prove correctness at all.

Seems like that a matter of definition - "correct", "correctness"?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 9:14 AM

> James Watson wrote
> > ... unit tests also don't prove software to be correct
> and
> > that for most non-trivial applications, it is not
> feasible
> > to prove correctness at all.
>
> Seems like that a matter of definition - "correct",
> "correctness"?

You'll have to explain what you mean by that if you want a meaningful answer.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 9:15 AM

Cedric Beust wrote
> The fact that ... there are no reliable refactoring tools
> for dynamically typed languages ...

For some definitions of "reliable" and "dynamically typed languages" ;-)

You know the refactoring tools for Smalltalk have been around for about a decade, and you know that the "rename method" refactoring cannot be fully automated in Smalltalk, but you don't seem to know what that means in practice.

Does it mean that Smalltalkers don't use the refactoring tools but go back to refactoring manually?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 9:16 AM

James Watson wrote
> You'll have to explain what you mean by that if you want a
> meaningful answer.

I mean you seem to be quarreling about definitions without providing any.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 9:22 AM

> > Is that a practical approach across all of software
> > development or only in particular situations?
> >
> > Wouldn't it depend on the risks / losses (including
> user
> > opportunity cost) of something going wrong?
> >
> > When might it be practical, when might it not?
> >
> > Would your opinion be different if you the programmer
> were
> > liable for user losses?

Achilleas Margaritis wrote

> Is there such a case out there? most programs contain an
> EULA which relieves the developer from any responsibility.

When you answer 4 questions with a question, it seems to me that you are far more interested in stating that your view is correct than thinking about when it might not be correct.

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 9:23 AM

> Does it mean that Smalltalkers don't use the refactoring
> tools but go back to refactoring manually?

I have no idea how Smalltalk programmers work, but it would certainly be silly not to use the tools they are given as long as they are an improvement over manual labor.

Any automated refactoring is superior to manual refactoring, even if it's a simple string search/replace that asks for confirmation from the user, as is the case in dynamically typed languages.

--
Cedric
http://testng.org

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 9:24 AM

> > > But it does not mean anything that the code passed
> > > compiling. You have to run it afterwards, haven't
> you?
> > and
> > > that's my point: since you are going to run it, why
> > bother
> > > with static typing and even compilation? just run the
> > > program and correct it as you go. It's a much more
> > > rewarding experience.
> >
> > Here's to hoping that you never have the job of writing
> > the software that runs an autopilot for an airplane. Or
> a
> > pacemaker.
>
> I actually am involved in defense programming (for
> THALES). The customer does not accept the code unless it
> is accompanied by a receipt that 100% of it has been
> tested functionally.
>
> I know it's boring to write test cases, and I can tell you
> I have been caught tearing my fleshes many times over test
> documents 100s of pages long (even documents split in
> several parts!). And let me say it again: it's boring!
>
> But big companies like THALES, Raytheon etc do not accept
> code that has not been fully tested and for all cases and
> possible values. You can't release C++, Java or ADA code
> that has not been fully tested beforehand (and in many
> cases, tested by two or three individual teams).
>
> I think the above fact speaks for itself about the value
> of static type systems vs functional testing!

It speaks nothing of the value of static type systems over functional testing.

If you've paid attention, the primary arguments, at least as posed by myself and James Watson, have been centered around how static typing saves time by:
(1) Catching typos
(2) Automating Refactoring
(3) Increasing code clarity

If I mispell a function name in a dynamic language, I have to wait until something causes that codepath to be executed before I find that error. Yes, eventually it will be found. But it can take a long time to do it.

Also, you have to remember that a lot of programming may go into a piece of software during system concept development before it becomes millions of lines of Ada.

So let's say a systems engineer thinks he has a brilliant new nueral network architecture to use to distinguish troop transports from school buses. Long term the NN may be in software, an FPGA, an ASIC, or even some hybrid approach. But for now the engineer wants to figure out if it will actually work, so he codes it up in his favorite language and sets it to work on training data.

A day and a half later the thing bombs out because in a rarely executed branch he typed inptu_vector instead of input_vector.

That's not exactly fun...

In a statically typed language the error would have been caught. Any decent Java IDE would have underlined it as soon as it was typed.

Flat View: This topic has 370 replies on 25 pages [ « | 16 17 18 19 20 21 22 23 24 | » ]

Previous Topic

Next Topic