The Artima Developer Community
Sponsored Link

Weblogs Forum
Is Static Typing a Form of Bad Coupling?

74 replies on 5 pages. Most recent reply: Apr 23, 2006 1:52 PM by Isaac Gouy

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 74 replies on 5 pages [ « | 1 2 3 4 5 | » ]
Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: New refactoring type Posted: Apr 12, 2006 10:40 PM
Reply to this message Reply
Advertisement
Leo Lipelis wrote
> But I still can't get rid of the feeling that a lot of
> niceties in IDEs are just coverups for the base platform
> deficiencies.

"I was pretty adamant about dynamic typing and that was because I wanted people to make their programs right, and if the types were getting in the way, type compatibility encouraged them to leave them the way they are instead of correcting them. I thought the types were actually in the way.

I will say with the advent of automatic refactoring tools, the refactoring menu, that those seem to work better with some type information to work with, and so my goal of beautiful programs seems to be served by having types.

I don't know that the jury's really still out on that, maybe the jury will always be out on that. I like it all. Certainly having power tools like Eclipse makes the simple things like having to type a lot of types just not a problem. Maybe I've gotten to the point where I don't care."

Ward Cunningham, mp3 podcast interview
http://www.gridsummit.com/Multimedia/WardC_24K.mp3

Bruce Eckel

Posts: 874
Nickname: beckel
Registered: Jun, 2003

Uses for static typing Posted: Apr 13, 2006 12:54 AM
Reply to this message Reply
I'm certainly a fan of dynamically-typed languages. But I have also see at least two situations where static typing is helpful:

1) When dealing with less-mature programmers, the structure imposed by static typing can be helpful.

but more compelling is this:

2) I've had a bit of experience with ActionScript lately, doing Flex programming. ActionScript is derived from ECMAScript (formalized Javascript), which is fairly dynamic. However, ActionScript allows optional static typing, and this is particularly useful when using FlexBuilder, because the IDE can do more for you if it is told what types it is working with.

Steve Donovan

Posts: 24
Nickname: stevedonov
Registered: May, 2005

Re: Uses for static typing Posted: Apr 13, 2006 3:39 AM
Reply to this message Reply
>However, ActionScript allows optional static typing, and this >is particularly useful when using FlexBuilder, because the >IDE can do more for you if it is told what types it is >working with.

Rather like that underrated language, JScript.NET.

Something that approaches the static/dynamic typing issue from the other way is Boo, which uses static type inferencing wherever possible (it only _looks_ like Python!). Places where it can't infer types are the places where you do want to see explicit type annotations, for instance method signatures. But if an object is declared to be a duck, then method calls will be dispatched dynamically on that object.

But programming of course doesn't usually happen in a tool-free vacuum. A programmer with a good IDE could be more productive in C#, for all the reasons that people love the Java/Eclipse combination. And that advantage would kick in once an application has hit a certain size and complexity.

In other words, different tools for different jobs. In no other field would we require our favourite penknive to cut both salami and timber, and then scale industrially.

Although statically-typed, a Boo ueber-IDE would still have to do a lot more work, because there aren't so many static type annotations.

The point that the actual writing of programs is a small part of the total development effort is very valid. _reading_ code is a far more common activity. And I find that excessive type annotations make something less readable, speaking as a human. Of course, if I would be speaking as an IDE then I might tend to the other view ;)

damien morton

Posts: 15
Nickname: dmost
Registered: Jan, 2004

Re: Is Static Typing a Form of Bad Coupling? Posted: Apr 13, 2006 5:01 AM
Reply to this message Reply
Bill Venners:
Looks like I'm going to be learning Haskell soon time permitting, because the local Silicon Valley Patterns group is going to have a track on it. So after that I may be better able to understand the issues.

I wouldnt say that by learning Haskell, you will want to use it professionally, but its certainly changing the way I think about programming, which is a good thing.

Someone else mentioned that typing is a kind of a contract, and one that can be checked by the compiler. In dynamic languages, those contracts are checked using unit tests, and for my python programs I tend to find that I liberally sprinkle assert statements all over the place checking the types of method arguments. Optional typing, in my mind, moves some of the load of type checking from runtime asserts to compile time checks. A worthy goal, but why not simply move to implicit typing.

A type can be inferred from context, as in the example you provide. The language defines the rules for type inference, and then that allows me to express a fully statically typed program with less verbosity.

Right, and the types can also be partially inferred, for example, the type of "foo(x,y) { return x + y; }" is the set of all types of x and y for which a "+" operation is defined. The type needs to be fully resolved before execution, but you get the idea.

One of the more powerfull aspects of a dynamic language is being able to say "print x+y" and just have it work, for many possible values of x and y. At runtime, the right "add" method is discovered and executed, based on what the runtime types of x and y are. I can do this in C# today, sort of, by calling MethodInfo.Invoke and having the system find the best matching method to invoke, based on the parameters.

I love programming in Python, but having recently worked on some huge projects in curly brace langauges, I wouldnt consider doing one using Python. I still use python to put together smaller pieces of code, (although Im forcing myself to use Haskell, as a way of learning it).

Strong typing (explicit or implicit) has saved me enough time that I perfer to keep using it. In fact, in some ways, I would like to see stronger typing enter the languages I use, for example, non-nullable references (al-la Nice).

Id also like to see Eifell-style pre and post-condition contracts enter the language, as I feel that this gives many of the benefits of unit testing, while making the tests part of the source code itself rather than separate entities. You would still need unit tests, but the focus would be on testing the interoperation between classes rather than the classes themmselves. I heard a rumor that C# 3.0 may well get pre- and post-condition contracts via Spec#, and that the approach has been highly successful in indentifying bugs and even race conditions.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: New refactoring type Posted: Apr 13, 2006 6:49 AM
Reply to this message Reply
> > So, unless someone convinces me otherwise, I'm against
> the
> > idea of "decoupling" types from their functional usage.
> >
> Perhaps Gilad Bracha can convince you. I found this paper
> via a link someone posted earlier in this topic to a
> discussion on lambda the ultimate:
>
> http://pico.vub.ac.be/~wdmeuter/RDL04/papers/Bracha.pdf
>
> It is short and easy to understand, so take a look. He
> defines optional typing as something that doesn't affect
> the runtime semantics of the program, and points out that
> in that case, you could plug in more than one type system.
> He also claims that you can enjoy most of the analysis
> benefits of statically typed languages via this optional,
> pluggable approach.
>
> His conclusion:
>
> The dichotomy between statically typed and dynamically
> typed languages is false and counterproductive. The real
> dichotomy is between mandatory and optional type systems.
>
> A new synthesis that combines most of the advantages of
> both static and dynamic typing is both possible and
> useful, based on the notions of optional and pluggable
> type systems. In summary:
>
> 1. Mandatory typing causes significant engineering
> problems
> 2. Mandatory typing actually undermines security
> 3. Types should be optional: runtime semantics must not
> depend on the static type system
> 4. Type systems should be pluggable: multiple type system
> for different needs


Types constrain the expressiveness of the language. While all major programming
languages are Turing-complete, and so may be considered “equally expressive”,
the fact is that a mandatory type system greatly reduces the number of
legal programs that can be expressed in a language.


If a program is not legal, then I why should a compiler accept it? I think that the concept that "a mandatory type system reduces the number of legal programs that can be expressed in a language" is a very wrong one.


Once
a mandatory type system is in place, the temptation to rely upon it is irresistable.
It becomes a basis for optimizations and for security guarantees that
fail ungracefully if the underlying assumptions of the type system do not hold.


If a type system is sound, then programmers can safely rely on it. If a type system pretends to be strong but it isn't (like C/C++, for example), then of course there are going to be security problems.

It seems to me that the paper is more about "strongly typed" languages that are proved to be weakly typed rather than anything else.


If the type system fails, system behavior is completely undefined.


In programming languages with proper type systems, the above happens in compile time, or in run-time under completely controlled circumstances.


Formalizations make simplifying assumptions.
These assumptions tend to be make the formal model an inaccurate
reflection of reality, and invalidate any reasoning based on the formal model.


I guess the author has some examples in his mind, which are not presented in the paper though.


In
addition, implementations tend to have bugs, so even the most carefully vetted
type system may fail in practice.


Which program does not have bugs? I prefer though the bugs to be a problem of wrong specifications rather than sloppy coding.

The paper is more about why C/C++/Java suck rather than why mandatory type systems are bad. It actually presents no evidence for 'significant engineering problems'. Mandatory type systems are good in ML and Haskell, and the Hindley-Milner type inference system does not prohibit encapsulation and run-time polymorphism: an interface can be expressed as a tuple of functions that point to different implementations using closures.

Supporters of dynamic typing usually fall in two camps: a) those that do not want the effort of pressing those keystrokes to write the type annotations, and b) those that think an algorithm that assumes a variable is an integer one time and a string another time is a good thing. While I am in the static camp, I like type inference (i.e. category (a)), but I really can not see any benefit from (b), unless hacking is in order.

Michael Stover

Posts: 28
Nickname: mstover
Registered: Jul, 2005

Re: New refactoring type Posted: Apr 13, 2006 9:21 AM
Reply to this message Reply
> snip looking at variables and not knowing
> their types never strikes me as useful
.[/i]
>
> It's useful when you want to have a function like this:
>
>

> def f(a, b)
> return a + b;
> end
>


There's an implicit type there - that a and b are <i>addable</i>. And addable to each other even. Given that I don't know what a and b are, I have no idea what this function might do. It might add 2 to 1 and get 3. It might add "2" to 1 and get "21". Or it might at ["2"] to 1 and get ["2",1], or ["2","1"]. You might say, what difference does it make as long as it does the right thing in the right circumstance? Of course, no infrastructure makes any difference if things just work :-)

>
> that works for any two arguments that understand addition.
> This is a trivial example, but there are a lot of
> f patterns that apply to arguments of many different
> types. Java's generics are super-verbose and super-ugly
> and do not present a good solution to my mind.

They are verbose and ugly and limiting too. I don't like them much. Too much static typing can get in the way. But sometimes, even those generics are nice. If a variable somewhere is marked as type '?' - that's still telling you potentially useful information.

I will step back and say I think static/dynamic or mandatory/optional typing is probably an 80/20 type thing - ie, 80% of the time, it's nice to have the static typing and extra information in the code. And 20% of the time, you really just want a duck so you can make it quack.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: New refactoring type Posted: Apr 13, 2006 9:38 AM
Reply to this message Reply
> The paper is more about why C/C++/Java suck rather than
> why mandatory type systems are bad. It actually presents
> no evidence for 'significant engineering problems'.

I encounter them. With some refactoring work, I wish I could just turn off the typing system for a little while, run the program dynamicaly with tests, and then turn it back on again. There are times when static typing it gets in the way. Don't get me started on what it is like to try to get tests into a statically typed system that wasn't written with tests in mind. That's a particularly grievous engineering problem.

The idea that I want to run with is that typing rules are really tests and they should be as flexible as tests. I should be able to, in a particular program, say "I don't want the Foo class to ever hold a Bar. It can hold anything else but not a Bar." I know AspectJ can give you that sort of compile time checking. If the type system is in the hands of the programmer, it can be another tool to put additional constraints on a program and alter them on an as needed basis.

One could argue that compile time type systems aren't as strong as they could be because they never become program specific, they are devised as a tool for all programs in a specific language.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: New refactoring type Posted: Apr 13, 2006 10:11 AM
Reply to this message Reply
One could argue that compile time type systems aren't as strong as they could be because they never become program specific, they are devised as a tool for all programs in a specific language.

While that is partially true, I think that the problem is actually that the statically typed mainstream OO languages just don't make it possible or easy to use types to really define (or encode) and enforce any kind of program specific properties. (You might want to google for "phantom types" and look at opaque signature ascription in ML.)

In C++, for example, one can use typedefs to specify alias names for types, but there is no easy way to create arbitrary new types that would not be implicitly convertible to their underlying representation. For example, the STL containers define container::size_type as an alias for the type used to hold the size of a container. You should basically always use container::size_type in certain contexts. However, due to implicit conversions and the fact that container::size_type is just an alias (and not a new type), you may accidentally use some other type, like int.

In sane static type systems you can create new types simply to create program specific abstractions. Here is a copy of what I have argued here earlier:
- You should use types to specify and enforce abstractions. When you do so, the types actually help to detect errors.
- Type ascriptions that do not either specify or enforce abstractions are unnecessary. You don't fundamentally need them.
- Manifest typing (as in Java and C++) leads to verbosity (having to read/write unnecessary words).
- Type inferred languages allow you to omit the unnecessary type ascriptions.

Jim Jewett

Posts: 11
Nickname: jimj
Registered: Apr, 2005

Re: Is Static Typing a Form of Bad Coupling? Posted: Apr 13, 2006 11:19 AM
Reply to this message Reply
> > When I say x = 1, I can pretty much
> > assume that x is of type int. [maybe different bit size]

The value currently assigned to x is an integer.

Unless you know all possible code paths that could set x, you don't know whether the variable x might sometimes be a float, or even a generic object, and you don't know whether it is nullable.

> ... implicit typing means that ... every variable
> and expression has a type known at compile time
> ... I as the programmer don't always have to
> explicitly say what it is.

> ... optional typing ... if you leave the type
> declaration out, the variable actually doesn't have a
> type. That variable can hold onto anything, as in Python.

> [examples]

> In an optional typing language (I don't know of one of
> these, but Guido's discussion of doing this in Python is I
> would think an example of the concept)

It is still in the talking stage, but the current plans are much weaker; basically, you could annotate a function parameter with (anything you want, including) a type, but it wouldn't change the semantics unless you also did something else (probably wrapping it in a decorator) to say what to do with that annotation.

So in the simplest case, you could annotate a parameter as an int, but go ahead an pass a string anyhow. The annotation would have no more effect than a comment. (Presumably, there would be standard decorators that actually did something, but that isn't fleshed out at the moment.)

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Re: Is Static Typing a Form of Bad Coupling? Posted: Apr 13, 2006 11:41 AM
Reply to this message Reply
Somebody wrote: "And I find that excessive type annotations make something less readable, speaking as a human. Of course, if I would be speaking as an IDE then I might tend to the other view."

It is exactly the other way round. A compiler with type inference may be happy without type annotations. It is not difficult for a machine to look up what type the method getSomething() can possibly return. It just has to check the call graph. For a human reader, checking call graphs all the time can become tedious, and that is why type annotations have been invented (or so I guess ;-). Type annotations make code much more readable for the human programmer, and this is especially true for the maintainer. It has been said bofre, I'll say it again: most programmers in the real world spend most of their time as maintainers of legacy code, not as developers of beautiful pristine new programs. Type declarations make dependencies explicit. Hidden, implicit dependencies are a pain in the ass.

"With some refactoring work, I wish I could just turn off the typing system for a little while, run the program dynamicaly with tests, and then turn it back on again."

I find this odd. If you actually did this, your tests would reveal exactly what the type checker told you already, before you switched it off.

damien morton

Posts: 15
Nickname: dmost
Registered: Jan, 2004

Re: Is Static Typing a Form of Bad Coupling? Posted: Apr 13, 2006 1:21 PM
Reply to this message Reply
It is exactly the other way round. A compiler with type inference may be happy without type annotations. It is not difficult for a machine to look up what type the method getSomething() can possibly return. It just has to check the call graph. For a human reader, checking call graphs all the time can become tedious, and that is why type annotations have been invented (or so I guess ;-).

Theres no reason why the editor/IDE cant use the compiler to dynamically insert the current set of inferred type annotations directly into the code. Obviously there would have to be a distinction between the annotations given by the programmer and those given by the system.

Where syntax colouring uses the syntactic output of the compiler, editor/IDE type annotation would use the inference system of the compiler.

Bruce Eckel

Posts: 874
Nickname: beckel
Registered: Jun, 2003

Re: Is Static Typing a Form of Bad Coupling? Posted: Apr 13, 2006 1:26 PM
Reply to this message Reply
> that is why type
> annotations have been invented (or so I guess ;-).

I missed a reason in my previous comment, and the one that is often considered most compelling by language designers:

3) So that the compiler can generate more efficient code.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Is Static Typing a Form of Bad Coupling? Posted: Apr 13, 2006 2:36 PM
Reply to this message Reply
> "With some refactoring work, I wish I could just turn
> off the typing system for a little while, run the program
> dynamicaly with tests, and then turn it back on
> again."

>
> I find this odd. If you actually did this, your tests
> would reveal exactly what the type checker told you
> already, before you switched it off.

If you could run the code dynamically, the tests would give you different information. Tests are about behavior among objects. The type system is about how to name and organize sets of those behaviors. Imagine a Java program with no interfaces. You could probably use 'extract interface' a zillion different ways and still have the same behavior.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Is Static Typing a Form of Bad Coupling? Posted: Apr 13, 2006 2:42 PM
Reply to this message Reply
damien morton wrote
> One of the more powerfull aspects of a dynamic language is
> being able to say "print x+y" and just have it work, for
> many possible values of x and y.

Cough, cough... and just have it not work, for many possible values of x and y :-)

Tom Moertel

Posts: 2
Nickname: tmoertel
Registered: Apr, 2006

Re: Is Static Typing a Form of Bad Coupling? Posted: Apr 13, 2006 2:52 PM
Reply to this message Reply
> > > When I say x = 1, I can pretty much
> > > assume that x is of type int. [maybe different bit
> size]
>
> The value currently assigned to x is an integer.
>
> Unless you know all possible code paths that could set x,
> you don't know whether the variable x might sometimes be a
> float, or even a generic object, and you don't know
> whether it is nullable.

The original poster was writing about Haskell, and he can rest assured that x is 1. The x = 1 declaration is not an assignment; it is a binding in which the value 1 is bound to the variable x. While that variable is in scope, its value will always be 1. (In Haskell, bindings are permanent and values cannot be changed.)

Cheers,
Tom

Flat View: This topic has 74 replies on 5 pages [ « | 1  2  3  4  5 | » ]
Topic: Is Static Typing a Form of Bad Coupling? Previous Topic   Next Topic Topic: Python seeks mentors and students for Google Summer of Code


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us