Weblogs Forum - Is Static Typing a Form of Bad Coupling?

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Is Static Typing a Form of Bad Coupling?

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

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 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 13, 2006 12:46 PM

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.

Achilleas Margaritis wrote
> 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.

Because the program may be correct.

"... a type system for a general-purpose language must always either over- or under-approximate: either it must reject programs that might have run without an error, or it must accept programs that will error when executed." p239 Programming Languages: Application and Interpretation

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: New refactoring type

Posted: Apr 13, 2006 1:28 PM

> 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.
>
I think the main benefit of (b) is that it simplifies dynamic metaprogramming, which unleashes a lot of developer power. This week we were looking at Common LISP macros at the Silicon Valley Patterns group, and these macros are a straighforward way to generate LISP code at runtime that you then run. In Ruby, you can add methods and fields to classes and even objects at runtime. For example, Ruby on Rails' ActiveRecord looks at a database table and dynamically morphs itself into an active record for that table at runtime. I think the main benefit of (b) is not so much that you can make a variable point to an int one minute and a string the next, but that you can make a variable point to an object whose class is dynamically created at runtime, and easily call any of its methods.

Yes, you can do all those kinds of metaprogramming in a statically typed language such as Java too, either doing static metaprogramming via code generation, or at runtime by using reflection, dynamic proxies, dynamic loading of classes that you use via interfaces they implement, etc. But it is a lot easier in a dynamic language. Variables in dynamic languages can just as easily provide access to an object whose class was invented by the running program as a class you wrote by hand in source.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Is Static Typing a Form of Bad Coupling?

Posted: Apr 13, 2006 1:35 PM

> 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
> t actually did something, but that isn't fleshed out at
> the moment.)
>
OK. It sounds like your approach in Python is consistent Gilad Bracha's notion that optional types shouldn't affect the runtime semantics. I also think that if people end up doing runtime type checks a lot in Python as systems grow in complexity, then having a shorthand way to specify the types and indicate you want a decorator to check them dynamically would be useful.

What my imagination is struggling with is how much value optional type annotations could give you for static analysis of the program. Are there other benefits you hope that optional type annotations would provide in Python besides the easier dynamic checking one? Oh, I guess explicitness of the code when programmers are reading it is one. Any others?

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: New refactoring type

Posted: Apr 13, 2006 1:41 PM

Vesa Karvonen wrote:

> 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.
>
Could you give some examples of what you mean by "specify and enforce abstractions?" I think I have an idea of what you mean. I try to design things in Java so that I take advantage of static analysis. I'll have methods take an enum instead of just taking an int, for example. Or I'll make one get method for each attribute rather than have one get methods for all attributes that takes a string attribute name. In both of these cases I opt for the design that will enable more type checking.

Is this the kind of thing you are talking about? Can you give some other examples?

Jim Jewett

Posts: 11
Nickname: jimj
Registered: Apr, 2005

Re: Is Static Typing a Form of Bad Coupling?

Posted: Apr 13, 2006 2:08 PM

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

> OK. It sounds like your approach in Python is consistent
> Gilad Bracha's notion that optional types shouldn't affect
> the runtime semantics.

The types themselves, yes. But the decorators certainly could. A decorator could raise an exception if the type wasn't correct, or it could try to adapt the argument so that it is correct.

My personal view is that some of this ought to move to compile-time and not require a decorator. The psyco extension already does this (with type inference, rather than introspection on type specifiers) and provides a fallback for cases when it is wrong; effectively it compiles to a fast path and a safe path, with an extra case statement to choose between them.

Guido is still leaning towards the annotation not meaning anything in the absense of a decorator, because he doesn't want to close off any avenues. (The multiple pluggable types that Gilad discusses.)

> I also think that if people end up
> doing runtime type checks a lot in Python as systems grow
> in complexity, then having a shorthand way to specify the
> types and indicate you want a decorator to check them
> dynamically would be useful.

Yes, but I hope that doesn't happen. Realistically, most typechecks in python are bugs, because they end up excluding too much. (They check for a string of text, but don't get updated to allow unicode, or they check for an integer, but don't allow a gmpy.mpz.)

If you pass something that really won't work, you already get a TypeError (or an AttributeError), when you try to use it.

In theory, catching these at compile time instead of waiting for run-time should still be a huge gain. In practice, when I've compared my own python to my own java, the type safety didn't actually buy me anything. Usually, the code actually did work in python, and when it didn't, the problem was generally a RunTimeError even in java. (Usually a NullPointerException, rarely a ClassCastException.)

> What my imagination is struggling with is how much value
> optional type annotations could give you for static
> analysis of the program. Are there other benefits you hope
> that optional type annotations would provide in Python
> besides the easier dynamic checking one?

A breakthrough for me was replacing "type specifier" with "parameter annotation". It is useful in pretty much the exact same ways as introspection is generally useful.

> Oh, I guess explicitness of the code when programmers
> are reading it is one.

Readability is probably the most important reason, but whether annotations (particularly type specifiers, which might cease to be optional in many organizations) would really help or actually hinder (because of too much boilerplate) ... I'm not sure.

-jJ

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Is Static Typing a Form of Bad Coupling?

Posted: Apr 13, 2006 2:34 PM

Jim Jewett wrote
> Usually, the code actually did work in python, and when it
> didn't, the problem was generally a RunTimeError even in
> java. (Usually a NullPointerException, rarely a
> a ClassCastException.)

That's why it's Nice that non-null types can be separated from nullable types :-)

http://nice.sourceforge.net/safety.html#id2448199

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Re: Is Static Typing a Form of Bad Coupling?

Posted: Apr 13, 2006 3:05 PM

Michael Feathers: 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.

My point was that the tests would have to run before they can give you "additional information", and this isn't a trivial requirement. In a nonchecked environment, simple typos, forgotten code paths and the like are a serious obstacle to getting the code to run in the first place, and this is certainly true when you are doing serious refactoring. You just have to rename a function, then your tests may (or may not!) reveal that some code is still calling the function under the old name and thus producing a runtime exception - a static check could already have told you that. Refactoring support is one of the major advantages of static type checking. To pretend otherwise just isn't credible.

"The type system is about how to name and organize sets of those behaviors" (i.e. abstractions), yes, but naming isn't just a superficial addition to "the actual runtime code". It *is* the code. Writing code *is* about "how to name and organize" abstractions, unless it is in assembler ;-)

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: New refactoring type

Posted: Apr 13, 2006 3:22 PM

Is this the kind of thing you are talking about?

Basically, yes. As I have implied, Java is extremely limited in this sort of thing. The first technique you mention, using enums, wasn't even available until recently. The only other way to create new types is to use classes and interfaces and those imply non-trivial overheads both syntactically and performance wise, so you really don't want to create a class for every little abstraction.

Can you give some other examples?

Yes. If I wanted to, I could probably produce such examples for the rest of my life; they are literally everywhere. However, I've already written an example with explanations here. See my article discussing the direction example posted on Sep 21, 2005 12:15 PM in the following thread http://www.artima.com/forums/flat.jsp?forum=106&thread=127941 . (Not having an obvious way (if there is a way?) to link to specific posts in Artima forums is very limiting.)

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: New refactoring type

Posted: Apr 13, 2006 4:47 PM

Michael Feathers wrote
> 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 guess you mean something like class Foo { NotBar obj; }
Just curious - what's the practical situation that motivates this?

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: New refactoring type

Posted: Apr 13, 2006 5:50 PM

Vesa Karvonen wrote:

> Not having an obvious way (if there is a way?) to
> link to specific posts in Artima forums is very limiting.)
>
Sorry about that. I long ago recognized that as a deficiency, and in our new architecture there will be a URI for each individual forum message that you can link to if you want to send people to an individual post. But I haven't done that in the legacy architecture, which we're using here.

You posted quite a bit in the topic you pointed to, and gave several URLs. Which URL points to the article that has examples of using types to "specify and enforce abstractions?"

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: New refactoring type

Posted: Apr 13, 2006 6:40 PM

Isaac Gouy wrote:
> I guess you mean something like

class Foo { NotBar
> obj; }

> Just curious - what's the practical situation that
> motivates this?

Not much practical use to that.. it was "off the cuff" but I know of many designs where they are unwritten rules like "instances of class B are only used in class A or it's subclasses.

It would also been nice to add build constraints as tests, sort of like what Bob Martin has done with his JDepend fixture in Fitnesse.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Is Static Typing a Form of Bad Coupling?

Posted: Apr 13, 2006 6:55 PM

piglet:
> My point was that the tests would have to run before they
> can give you "additional information", and this isn't a
> trivial requirement. In a nonchecked environment, simple
> typos, forgotten code paths and the like are a serious
> obstacle to getting the code to run in the first place,
> and this is certainly true when you are doing serious
> refactoring. You just have to rename a function, then your
> tests may (or may not!) reveal that some code is still
> calling the function under the old name and thus producing
> a runtime exception - a static check could already have
> told you that. Refactoring support is one of the major
> advantages of static type checking. To pretend otherwise
> just isn't credible.

The thing is, it can be a trivial requirement. If you have a good test harness, you just run the tests. And, I welcome runtime exceptions when I'm refactoring in a dynamically typed language. They let me know when I make mistakes.

Statically typed languages have no monopoly on refactoring tools. The first full featured refactoring tool was written for Smalltalk, and truth be told it's probably still more advanced than the ones written for Java. It's certainly less opaque. I've heard of people doing wonderful things with John Brant's rewrite engine.

> "The type system is about how to name and organize sets of
> those behaviors" (i.e. abstractions), yes, but naming
> isn't just a superficial addition to "the actual runtime
> code". It *is* the code. Writing code *is* about "how to
> name and organize" abstractions, unless it is in assembler
> ;-)

I agree with you, you're preaching to the choir. In fact, I often mention that programming is about two things: naming and structure. I also believe that the most powerful refactoring is 'rename class' because it helps people think about their programs differently. I like anything that makes it easier to reconceptualize existing code and act on those reconceptualizations.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Is Static Typing a Form of Bad Coupling?

Posted: Apr 13, 2006 11:11 PM

Michael Feathers wrote The first full featured refactoring tool was written for Smalltalk, and truth be told it's probably still more advanced than the ones written for Java.
Truth be told, the Refactoring Browser doesn't fully automate method renaming, because there isn't enough (type) information to identify the correct call sites.

I've heard of people doing wonderful things with John Brant's rewrite engine.
Yes, it's a little ironic that a rewrite engine provides a powerful tool for making changes that do not preserve behaviour.

In IntelliJ IDEA they call it "Structural search & replace"
http://www.jetbrains.com/idea/features/search_replace.html

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: New refactoring type

Posted: Apr 13, 2006 11:23 PM

Michael Feathers wrote
> Not much practical use to that.. it was "off the cuff" but
> I know of many designs where they are unwritten rules like
> "instances of class B are only used in class A or it's
> subclasses.

Pity, I mistakenly thought it might be one of those problems you encounter all the time.

(instances of class B only used in A... seems like an inner-class & visibility kind of thing?)

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: New refactoring type

Posted: Apr 14, 2006 2:20 AM

You posted quite a bit in the topic you pointed to, and gave several URLs. Which URL points to the article that has examples of using types to "specify and enforce abstractions?"

Sorry, with "article" I was referring to my post there in the thread. The specific example I was referring to is the example discussing the Direction module. It is a very simple example and the main point I tried to communicate there is that there are two kinds of type annotations: those the specify (application specific) abstractions and those that do not. I just reread my posts in the thread and practically all of them are relevant for this thread also.

Flat View: This topic has 74 replies on 5 pages [ « | 1 2 3 4 5 | » ]

Previous Topic

Next Topic