News & Ideas Forum (Closed for new topic posts) - Type Checking and Techie Control

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

News & Ideas Forum (Closed for new topic posts)
Type Checking and Techie Control

23 replies on 2 pages. Most recent reply: Jan 11, 2006 6:58 AM by Michael Babcock

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 23 replies on 2 pages [ « | 1 2 ]

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Type Checking and Techie Control

Posted: Jul 11, 2003 5:19 PM

I think both static and dynamic typing have their merits and are not mutually exclusive. I'd like to see a language that has both.

Try these for both static and dynamic typing:

Dylan http://www.functionalobjects.com/

Claire http://claire3.free.fr/description.htm

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Type Checking and Techie Control

Posted: Jul 11, 2003 7:59 PM

> It is not necessary to try and quantify how many
> bugs are caused by the lack-of type-checking for
> three reasons:
>
> 1. It may not matter based on the type of application
> or system your are building.

Huh?

> 2. The answer is greater than 0.

I disagree. It has to be enough to justify the drawbacks. If you are going to write an program with 1000 bugs in one month using Java or C#, versus writing the same program with 1001 bugs in one week using Python or Ruby, which is better? You've got three extra weeks of testing to find one bug.

Anyway, how do you know that compile-time type checking reduces the number of bugs? Maybe it just changes the nature of bugs.

> 3. I can program in languages with strong typing.
> I don't consider this overly burdensome. In fact,
> I would love it if Python included this as an
> optional feature.

I would too. Interfaces would be a very nice addition too (see Frank Sommers' post above).

But let's not confuse strong typing with dynamic typing; Python does have strong types, just not declarations and compile-time checking.

> As an illustrative example, there has certainly been
> widely publicized bugs relating to bad data and
> mismatched types. One in particular in the
> Mars Lander -- see
> http://mars.jpl.nasa.gov/msp98/news/mco990930.html.

I looked briefly, but I couldn't see where the problem was based on using a dynamically-typed language. Are you saying the lander software wasn't written in a statically-typed language and rewriting it in one would have eliminated that bug?

David Kempster

Posts: 9
Nickname: dkempster
Registered: Apr, 2003

Re: Type Checking and Techie Control

Posted: Jul 21, 2003 9:06 AM

This discussion comes up over and over. What is interesting is the static checking must be done side of the debate has never done anything with a dynamically typed language while the pro dynamic typing people have almost always done both.

The benefits of static typing are largely a myth. They were never there in the first place for safety. That was a justification used after the fact. Go back and see why C based languages for example have static typing in the first place. Also C is probably the least safe programming environment that there is.

Also someone talked about environments like IDEA that make good use of static typing, and that is true. But some of the features mentioned have been in Smalltalk environments from the start. I can ask to Inspect any variable and what do you know it tells me specifically what the object is and what methods it has. How?!? This must be impossible without strong typing right? Well the fact is the objects are strongly typed. It is just you don't have to tell what the variable is. This allows for polymorphism. Statically typed languages get around the type system and allow for polymorphism (which remember relies on the code NOT knowing what type it has - only what messages it responds to) by coming up with various cheats like casting and having the language use a richer notion of types.

I think if you are going to have a statically typed language you should have one like Eiffel that has a much better worked out theory of types and has generics so casting is not necessary.

But the fact is I know of no one that has used dynamically typed languages for any length of time that finds they have more bugs than a statically typed language. Don't just go by what you read in your CIS 101 text book.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Type Checking and Techie Control

Posted: Jul 21, 2003 12:03 PM

various cheats like casting and having the language use a richer notion of types
Why is having a richer notion of types cheating?

David

Posts: 18
Nickname: malven
Registered: Jul, 2003

Re: Type Checking and Techie Control

Posted: Jul 21, 2003 6:02 PM

David Kempster wrote:
"But the fact is I know of no one that has used dynamically typed languages for any length of time that finds they have more bugs than a statically typed language."

The way the question is phrased makes it impossible to refute. There are many other features that contribute to the "defect rate" of a language than typing. For example, there are *many* features of C++ that are problematic for non-expert programmers, and removing static typing wouldn't help one bit.

My own experience might be interesting to relate. For a long period of time, as a consultant I worked on projects in both Smalltalk and in C++. The overall defect rate in C++ was much higher and the productivity lower (as you might expect for general application programming). But we found that as components were evolved by different groups of programmers, relatively speaking many more integration errors crept into the Smalltalk code base over time.

One programmer would change a class in some way, seemingly have everything working, and then it would break code elsewhere in the application or in another application using a library. There was no comprehensive way to see what a change might affect, and often these bugs lay dormant in code until much later.

As Bob Martin and others have said, a comprehensive unit test suite can go a long way toward compensating for the lack of static typing. But lacking such a suite you are on dangerous ground as code gets large and multiple developers are working together.

BTW, contrary to your original statement, I have used many different OO languages (both statically and dynamically types) and I prefer static typing for building large-scale systems.

Ross Judson

Posts: 2
Nickname: rossjudson
Registered: Jul, 2004

Re: Type Checking and Techie Control

Posted: Jul 15, 2004 11:55 AM

Isaac is absolutely right. Implicit typing is very powerful and probably the best way to do larger-scale development.

Dynamic typing means you can't test it (code coverage etc). Static typing means that you sometimes have more typing to do, and that your program may be less able to adapt at runtime if the object model changes.

The best world is implicit typing coupled with something like Eclipse. You certainly don't have to wait until you "compile" your program to find out if there are typing errors in it; this is a flaw in the editing environment, not the language. Good language support within Eclipse for implicitly typed languages would give you the best of both worlds. A "to-do" list could show you implicitly called functions there's no current match for, and allow you to write them quickly.

The fact that Java 1.5's "templates" do not include the primitive types makes them borderline useless. I can count the number of times I've made a casting error while iterating over a collection class on one hand, in many years of Java coding. I can't count the number of times I've had to put together crappy object-based structures with wrapper objects or worse, just to handle primitives in a reasonable fashion (not to mention the ridiculous storage overhead this incurs).

I figured Java templates would allow me to make a collection of longs to doubles, and do it efficiently. Guess we'll all still be waiting...

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Type Checking and Techie Control

Posted: Jul 16, 2004 9:07 AM

I figured Java templates would allow me to make a collection of longs to doubles, and do it efficiently
For example?

This is the Nice programming language
http://nice.sourceforge.net/


   void main(String[] args){      
      let a = new ArrayList();      
      a.add(30000.0d);
      a.add(30000.0d);
      println(a[0]==a[1]);
   }

I:\Nice\Test>nicec --sourcepath .. -a t.jar -R Test
nice.lang: parsing
Test: parsing
Test: typechecking
Test: generating code
Test: linking
Test: writing in archive
nice.lang: writing in archive

I:\Nice\Test>java -jar t.jar
true

Greg Jorgensen

Posts: 65
Nickname: gregjor
Registered: Feb, 2004

Re: Type Checking and Techie Control

Posted: Jul 19, 2004 10:21 AM

> As an illustrative example, there has certainly been
> widely publicized bugs relating to bad data and
> mismatched types. One in particular in the
> Mars Lander -- see
> http://mars.jpl.nasa.gov/msp98/news/mco990930.html

As I understand that problem, it had nothing to do with programming language types. I don't know the code, but it sounds to me like a variable named "altitude" was interpreted by one team as feet and another as meters. The compiler/interpreter just saw a numeric type that seemed to match. I don't see how static typing can help in such cases, where the wrong algorithms or interpretations are applied to data.

If I had written that code I would probably have chosen a variable name like "altitudeMeters" to remind myself and others. That would work in either C++ or Python.

Greg Jorgensen
PDXPerts LLC, Portland, Oregon USA

Michael Babcock

Posts: 1
Nickname: mtb
Registered: Jan, 2006

Re: Type Checking and Techie Control

Posted: Jan 11, 2006 6:58 AM

I realize this is an old thread, but it seems worth pointing out:

If you really care that much about types in your Python code, just handle the exceptions yourself and either run unit tests or run it through pychecker.

For the most part, I've found as I embrace OOP more, the types don't really matter. That is to say, I have a function that parses and computes taxes on objects with a 'price' member which I convert to a decimal format before computation. I dont need to know what type of object it was, so long as it has a 'price' that can be converted to numeric (and Python's quite happy to convert strings for me too if they've been read in from files without converting).

Flat View: This topic has 23 replies on 2 pages [ « | 1 2 ]

Previous Topic

Next Topic