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 2 3 4 5 6 7 ... 25 | » ]

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Programming with "Duh" Typing

Posted: Jul 7, 2007 9:25 PM

> Irrelevant, this is NOT what I wrote. There is no way you
> can add an Integer in my example. It is a stupid and
> useless warning.

I'm looking at it from a compiler writers perspective. All you have is a parameterized type left hand side of a declaration/assignment, and and right hand side expression with a generic type. Peeking at the rhs expression to determine if it is a pure constructor would be an utter hack. Why do that when very simple type inference gives you even more, and is sound?

> Your example is just plain bad code (which you intended it
> to be, not a knock on you) for a lot of reasons, and you
> can't stop bad code.

It's bad code that *could* be stopped if java didn't allow generic types to be assigned to parameterized types. It should be an error, and I was dumbfounded when I found out that it isn't in java for "source" compatibility. I mean, we have to go through utter type bondage with all the wildcard types flying around in normal code, but some sucker comes flying in with a generic type and, blam, the type system is in shambles.

They may as well have slammed covariant generic types in as well: it's useful at times even though it is incorrect formally. (OK, OK, that was a wee bit offsides.)

Agree to disagree?

Cheers,
Carson

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Programming with "Duh" Typing

Posted: Jul 7, 2007 11:27 PM

> Agree to disagree?

Fair enough. :-)

Back to the original topic, I hereby reject the premise of this blog, which is that typing things twice makes you much less productive.

Just how much time do you spend typing? Compared to designing, thinking about patterns, developing APIs, looking up other APIs, asking marketing what they want, looking at log messages to track down a bug, etc. I claim that actual time spent typing is very small, maybe 5%. So, even if every line of code was a List declaration, and you never used the IDE to help, at worst, all you lose is 5%. In reality, it's much less than that, it's minuscule. Typing things twice cannot have a big negative effect on productivity.

If actual time spent typing were significant, we'd all go to typing schools to earn a big raise.

Next, I'd argue that typing things twice can make you more productive. A good carpenter measures twice, and cuts once. Is he less productive?

Think of typing

List foo = new ArrayList();

As two chances to think about your code. As "pair programming with Java". You are reminded to think about the left side, which should be an interface. And is this a List or a Set? Is there an order, can an element appear twice, think!. Maybe it's a Map!

On the right side, you can get more detailed. Should this thing be immutable? Thread safe? How often will I be inserting elements? If there is a natural order of elements, what is it?

By encouraging the programmer to think, twice, about what they are doing, Java can make them more productive. Whether the programmer takes advantage is up to them... :-)

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 3:34 AM

> Other than in unit tests, I'm hard-pressed to remember
> ever wanting to write such code. An object will have a
> list, and it will be read from a configuration file or
> have a setter or something, but the times I'm wanted to
> initialize it with two hard coded strings is, well,
> never.
>
> In that case, I'm gonna have to write List<String>
> explicitly, and Java seems much more reasonable typing
> wise, and the benefits of more explicit type checking are
> less of a burden to implement.

Good type inferencers can infer the type even if the string isn't hard-coded. The method that reads the data from the configuration file returns a List<String>, and the compiler knows this, so it can infer the type. The compiler knows that this method returns a list of strings because this method reads data directly from the file (the compiler knows that this data is of type string), and puts this data in a list (so the compiler knows that this is a list of strings).

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 5:37 AM

Typing doesn't make any measurable difference in productivity - I would even argue that more typing is better for productivity if it leads to more readable code.

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 7:47 AM

> As two chances to think about your code. As "pair
> programming with Java". You are reminded to think about
> the left side, which should be an interface. And is this
> a List or a Set? Is there an order, can an element appear
> twice, think!. Maybe it's a Map!

By application of the inductive hypothesis, I propose:


  List foo is_a List = (List) new create allocate ArrayList() is_a List as List

My God. Think of the productivity.

Here's a mental exercise: every time you use your IDE to generate a bunch of boilerplate java code, think to yourself: why isn't the compiler doing this? My conclusion is that it is primarily due to a lack of two things: type inference and closures.

What's that saying about arguments and the internets?

Cheers,
Carson

Lalit Pant

Posts: 51
Nickname: litan
Registered: Jun, 2007

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 9:06 AM

I think that a statically typed language with Type-Inference gives us the best of both worlds: the strong type safety of static typing, and the better expressiveness and productivity of dynamic typing.

Type-Inference:
- Increases the expressive density of the language (allows you to get the same thing done with less code and increased readability).
- Makes internal/embedded DSLs feasible

In my opinion, these factors lead to increased expressiveness and productivity.

And we get to retain all the benefits of static type safety (including the availability of compile-time type information - which allows IDEs to provide powerful capabilities).

Jules Jacobs

Posts: 119
Nickname: jules2
Registered: Mar, 2006

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 9:31 AM

Static typing + type inference doesn't give you the full expressiveness of dynamic typing. Programs that would be correct in a dynamically typed setting, but rejected by the type checker will still be rejected by the type checker, for example:

function foo(x){
  if(x) return 4
  else  return "z"
}

The type checker will reject this because a function can only return values of one type in a statically typed language.

Jarle Stabell

Posts: 3
Nickname: jarle
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 10:59 AM

function foo(x){
>   if(x) return 4
>   else  return "z"
> }

>
> The type checker will reject this because a function can
> only return values of one type in a statically typed
> language.

The type checker can accept this if the language contains a type subsuming both integers and strings, for instance an "Any" type.
Or it could perhaps return a disjuntive type like "Integer or String"?

On the fence I'm currently sitting on, what cannot be done statically in a "perfect" statically typed language approximates "unmaintainable".

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 11:20 AM

Jules Jacobs wrote
> Static typing + type inference doesn't give you the full
> expressiveness of dynamic typing.

I think you mean something different by expressiveness than Lalit Pant.

> Programs that would be correct in a dynamically typed
> setting, but rejected by the type checker will still be
> rejected by the type checker

Well "Types do not ensure the correctness of a program. They only guarantee that the program does not make certain kinds of error" but of course you are right to say that the type checker may reject programs which cannot be shown to be valid (although they are indeed valid).

(I was going to agree that type inference doesn't change anything about that but doesn't type inference provide the means to type subexpressions that might otherwise cause the type checker to choke - thereby increasing expressiveness?)

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 12:18 PM

> Static typing + type inference doesn't give you the full
> expressiveness of dynamic typing. Programs that would be
> correct in a dynamically typed setting, but rejected by
> the type checker will still be rejected by the type
> checker, for example:
>
>

function foo(x){
>   if(x) return 4
>   else  return "z"
> }

>
> The type checker will reject this because a function can
> only return values of one type in a statically typed
> language.

I'm not sure I want that level of expressiveness. <smile/>

In theory, a statically typed language could provide for such a bizarre method using intersection types:

  public (String|int) foo(boolean x) {
    if(x) return 4
    else  return "z" 
   }

Where the type (String|int) would give you the intersection of methods of the two types. It's an interesting idea to think about, but seems like a pretty esoteric case that, in my day to day code at least, I don't come across much. YMMV. Perhaps a more realistic place to use intersection types is in method arguments, in place of method overloading. This would be kind of a poor man's multimethod with the large advantage that a method is defined in one and only one place and the corresponding disadvantage that the developer would have to dynamically dispatch on the runtime types himself.

Another interesting idea to ponder is union types. Consider the following code:

  Bar x = ...
 
  if( x instanceof Foo ) 
  {
     String z = x.aMethodOnFoo(); //<-- At this point, the type of x is the union type (Bar&Foo)
  }

After an instanceof test (and using some flow analysis), the variable tested against would accrete types by becoming the union of its original type and the type tested against. You wouldn't have to cast it. It would revert to its old type once the scope of the instanceof test ended (e.g. when it hit an "or", at the end of the if block, etc.) I know this would save me a lot of boilerplate. (I have an IntelliJ macro set up to do this for me.)

To wander slightly back on topic, one thing to note about the

 var x = ...

style of type inference is that you get quasi-duck typing. You can change "..." to whatever you like, and so long as the rest of the program works out typewise, fine, much like arguments to templated functions in C++. It walks like a duck and quacks like a duck, but make sure it does so at compile time, rather than waiting until runtime to find out.

It's pretty crazy how far you can get with just a dash of pragmatic type inference (no where near a full Hindley–Milner system) in an imperative language. In GScript, you are required to declare types in only four places:

* Method signatures (excluding closures/blocks whose arguments may be type inferred and whose return value is always inferred)
* New expressions
* Class declarations (extends, implements)
* Class fields that are public or that have no initialization expression

That's maybe 10% of the code you write, so it makes for some pretty clean lines and yet it is still possible to support a decent IDE. Its too bad that the functional weenies get all the good stuff. We lowly imperatives deserve a bone every once in a while too.

Cheers,
Carson

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 12:34 PM

>
> By application of the inductive hypothesis, I propose:
>


> List foo is_a List = (List) new create allocate
> te ArrayList() is_a List as List
>

> My God. Think of the productivity.

This is now the second time in this short thread that you've ignored my actual words and argued against a ridiculous strawman. It's getting old.

By "less typing is more productive" induction, all variables should have one letter names. My God. Think of the productivity.

Carson Gross

Posts: 153
Nickname: cgross
Registered: Oct, 2006

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 1:24 PM

> This is now the second time in this short thread that
> you've ignored my actual words and argued against a
> ridiculous strawman. It's getting old.

Aw, c'mon now. It's all in good fun. Where would the internet be today without strawmen, ad hominem, misrepresentation and ignorance?

In the spirit of fairness, I've spent a bit more time thinking about the

  List<String> foo = new ArrayList();

example, and I'm starting to come around to your way of thinking, and that it shouldn't be an error or a warning.

Where I was going astray was in ignoring the type-inference that java does with parameterized methods, which makes

  List<String> foo = Collections.emptyList();

work out. Why did they choose to do that forward type inference with parameterized methods, but not with parameterized type constructors? Interesting question for the javac guys. Another stumbling block in my thinking was that In GScript we do a much simpler backwards inference thanks to the "var" statement, without special-casing parameterized methods.

I hope we can still agree that this, however, should be a compile error and not a warning:

  List foo = new ArrayList();
  ...
  List<String> bar = foo;

That's just flat out crazy talk.

So, see, we are both arguing for the same thing: some type inference to cut down on code bloat. I'm arguing it from one direction and you are arguing it from the other. Your point of view has the advantage that it would be a small tweak to javac, whereas mine has the advantage that it will never be implemented in java, so I can continue to claim that it is superior without the possibility of falsification. That's the *best* kind of opinion to have on the internet.

Cheers,
Carson

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 3:37 PM

> Bill Venners wrote "the feeling of productivity"
>
> If only we knew whether there was any correlation between
> the feeling of productivity and actually being more
> productive.

As long as the productivity is not worse with verbose languages, I'd argue that it's better simply in terms of morale.

Morgan Conrad

Posts: 307
Nickname: miata71
Registered: Mar, 2006

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 4:07 PM

> In the spirit of fairness, I've spent a bit more time
> thinking about the
>

>   List<String> foo = new ArrayList();
>

> example, and I'm starting to come around to your way of
> thinking, and that it shouldn't be an error or a warning.

Victory, one convert at a time!

> I hope we can still agree that this, however, should be a
> compile error and not a warning:
>

>   List foo = new ArrayList();
>   ...
>   List<String> bar = foo; 
>

> That's just flat out crazy talk.

Agree. It should be a compiler error. In addition, every style and FindBugsy analyzer should flag it. Other than entry in a code obfuscation contest, why would you want to have two local references to the same thing?

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Programming with

Posted: Jul 8, 2007 4:27 PM

> Back to the original topic, I hereby reject the premise of
> this blog, which is that typing things twice makes you
> much less productive.
>
Actually that wasn't my premise here. What I attempted to do in this blog post was relate my recent experience that demonstrated to me that a statically typed language can have that "feeling of productivity" that you get in a dynamically typed language such as Ruby or Python. The salient point, which is what I found interesting, is that this implies that the feeling people get when they program in those languages comes not as much from the dynamically typed variables as from the mere conciseness of the code.

The context is that over the years I've encountered many people who love Ruby or Python. (They usually love one or the other.) They don't like it. They love it, and my theory has been a bit reason they "love" it is because they feel very productive when writing code. They feel like the dynamic language stays out of their way, where as with Java they feel like they are fighting the compiler all the time, and also that Java programs simply come out much more verbose than Python or Ruby ones.

What my recent experience with Scala demonstrates to me is that it is possible to throw out the verboseness bathwater without necessarily throwing out the static type checking baby. That's really what I was trying to get at with this blog post.

Flat View: This topic has 370 replies on 25 pages [ « | 1 2 3 4 5 6 7 | » ]

Previous Topic

Next Topic