The Artima Developer Community
Sponsored Link

Weblogs Forum
Graceful Failure

53 replies on 4 pages. Most recent reply: Aug 30, 2005 2:50 PM by Gregg Wonderly

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 53 replies on 4 pages [ « | 1 2 3 4 | » ]
Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure Posted: Aug 26, 2005 1:43 PM
Reply to this message Reply
Advertisement
> > In Java, this confusing duality is removed by not
> > providing any automatic construction. In many cases, I
> > have typed
> >
> > MyType s = new MySubType(...);
> >
> > which is not redundant at all.
>
> No doubt you have also often typed MyType s = new
> MyType(...);
which is redundant. Anyway the type
> inferencing languages that I am familiar with always let
> you be explicit when you need/want to be.

I hardly ever instantiate an object without arguments. Maybe you are used to building an object by hand with dynamic languages and usually start with an empty object?

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure Posted: Aug 26, 2005 1:48 PM
Reply to this message Reply
> In case the Boo link doesn't make it clear enough what a
> type inferencing language does, I'll give a quick
> example.

I know what type inferencing is. What I needed was the semantics and the syntax that was used.

>
> s = "foo"
> s = 1

>
> The second line causes the compile-time error "cannot
> convert int to string".

This is a pretty risky issue, because I often find myself doing:

String s = "foo";

if( some_expr ) {
...10 lines of code...
String s = "har";
}

And the compiler reminds me that 's' is already declared. This helps me understand problems that I would otherwise create with Boo. Namely, if I used type inferencing as boo implements it, the second assignment of s to "har" would have erased the previous assignment silently and I would have to spend some time chasing down a variable reuse bug that Java would have caught for me.

Thus, I'm not convinced that Boo is providing any value with its implementation here. It is simply trying to let you type less, which in this case, is not beneficial.

Joe Bowbeer

Posts: 2
Nickname: joebowbeer
Registered: Aug, 2005

Re: Graceful Failure Posted: Aug 27, 2005 10:46 AM
Reply to this message Reply
Josh Bloch (offlist) writes:

This is not a failure of Java's static type checking, but of my ability to anticipate the future. We could have used parameterized static factories instead of constructors, and placed appropriate bounds on the type parameters in the static factories. At least one reader (David Gates) caught this. I think that should have ended the debate right there.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Graceful Failure Posted: Aug 28, 2005 11:12 AM
Reply to this message Reply
Gregg You are going to have to give me a formal description of the inference mechanisms you are talking about, or you are gonna have to tell me which language specifically I am comparing my experiences to.

I was thinking of Nice and Scala
http://nice.sourceforge.net/
http://scala.epfl.ch/


> In Java, this confusing duality is removed by not
> providing any automatic construction. In many cases, I
> have typed
>
> MyType s = new MySubType(...);
>
> which is not redundant at all.

afaik languages that provide type inference also allow you to explicitly declare types - so you would be able to express write
   MyType s = new MySubType(...);

and when you wanted to express something more basic you can avoid the duplication
   MyType s = new MyType(...);
let s = new MyType(...);

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Graceful Failure Posted: Aug 28, 2005 11:23 AM
Reply to this message Reply
Gregg type inferencing as boo implements it
Rather than a complaint about type inference, isn't this about not distinguishing new variable definition?

let s = "foo";

if( some_expr ) {
...10 lines of code...
let s = "har";
}

Symbol s is already defined.
Previous definition: ...
compilation failed with 1 error

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure Posted: Aug 28, 2005 1:08 PM
Reply to this message Reply
> > In Java, this confusing duality is removed by not
> > providing any automatic construction. In many cases, I
> > have typed
> >
> > MyType s = new MySubType(...);
> >
> > which is not redundant at all.
>
> afaik languages that provide type inference also allow you
> to explicitly declare types - so you would be able to
> express write
>
   MyType s = new MySubType(...);

> and when you wanted to express something more basic you
> can avoid the duplication
>
   MyType s = new MyType(...);
> let s = new MyType(...);
>


I wasn't complaining about declaring with a super type. I was suggesting that sometimes that is useful because it keeps your code from referencing the subtype information by accident in cases where you don't want to expose the subtype details.

I use this feature in some cases...

I understand that typing can be optional in a type infering language. I am just trying to understand why that is a benefit that would make it beneficial to switch languages, or adapt a languages feature set.

So far we've only found that there might be less typing, or less characters in the program text. That is not an added value for me.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure Posted: Aug 28, 2005 1:23 PM
Reply to this message Reply
I said:

Thus, I'm not convinced that Boo is providing any value with its implementation here. It is simply trying to let you type less, which in this case, is not beneficial.

> Gregg type inferencing as boo implements it
> Rather than a complaint about type inference, isn't this
> about not distinguishing new variable definition?
>

> let s = "foo";
>
> if( some_expr ) {
> ...10 lines of code...
> let s = "har";
> }
>

> Symbol s is already defined.
> Previous definition: ...
> compilation failed with 1 error

That provides the proper error message and allows me to designate that a variable is a new declaration.

But, I still have to type a 'word' introducing the declaration. For fundamental types, you can automatically detect an appropriate type. But, for more complex types, you still need to support a super type declared type.

So, I don't see how using one word (let) verses the other (a type name) has actually provided a benefit. It has introduced another language syntactic element that the compiler and the user has to understand the meaning of.

Marcin Kowalczyk

Posts: 40
Nickname: qrczak
Registered: Oct, 2004

Re: Graceful Failure Posted: Aug 28, 2005 3:05 PM
Reply to this message Reply
> But, I still have to type a 'word' introducing the declaration.

Making the syntax of introducing a new variable the same as the syntax of assignment to an existing variable is ambiguous in the presence of nested functions. Python and Ruby got bitten by this.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Graceful Failure Posted: Aug 28, 2005 5:47 PM
Reply to this message Reply
> But, I still have to type a 'word' introducing the
> declaration. For fundamental types, you can automatically
> detect an appropriate type. But, for more complex types,
> you still need to support a super type declared type.

For more complex types you can also automatically detect an appropriate type in many cases, and support explicit declaration for other cases.

> So, I don't see how using one word (let) verses the other
> (a type name) has actually provided a benefit. It has
> introduced another language syntactic element that the
> compiler and the user has to understand the meaning of.

When that one word type name starts looking like
HashPropertyMap<AdjacencyListEdge<int>, double>
reading it twice becomes more of an issue.

Writing twice is cut/paste and changing is automated with a reasonable IDE - the issue is trying to find the code that does stuff from amongst the boilerplate.

Anyway, I was just curious why you thought there'd be more runtime bugs in a language that used local type inference than in Java.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure Posted: Aug 29, 2005 4:39 AM
Reply to this message Reply
> > But, I still have to type a 'word' introducing the
> declaration.
>
> Making the syntax of introducing a new variable the same
> as the syntax of assignment to an existing variable is
> ambiguous in the presence of nested functions. Python and
> Ruby got bitten by this.

Yes, this is precisly my concern!

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Graceful Failure Posted: Aug 29, 2005 10:24 AM
Reply to this message Reply
Howard wrote:

> > Do you think you would be more productive with
> > language that provided some minimal local type inference
>
> I find this difficult to answer, I will explain why:
>
> 1. I don't have a lot of experiance with this type of
> language (some Clean/Haskell experiance)

Yes, and Clean/Haskell are so utterly different to Java - Nice/Scala are perhaps more comparable.


> 2. There seems to be pro's and con's; yes there was less
> typing and it did find the type errors, but the error
> message were very obscure (like C++ template error
> messages)

Yes, although the wall I run into with Clean is something else - uniqueness typing


> 3. Like Gregg Wonderley has pointed out; the typing is
> probably not the limitation in writting speed, so reducing
> typing probably has little effect. I would add
> particularly in a good IDE that does code completion for
> you.
>
> 4. Declaring types adds clarity to a program, its part of
> the documentation

I find it interesting that skilled users of Clean/Haskell frequently write explicit type declarations even when the compiler will correctly infer the type.

otoh in those languages type declarations are visually distinct, above each function definition - so, to some extent, you can read what each function does without the type declarations getting in the way.

If we reduce the visual clutter from explicit type declarations is it easier to see the algorithm?

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure Posted: Aug 29, 2005 11:30 AM
Reply to this message Reply
> If we reduce the visual clutter from explicit type
> declarations is it easier to see the algorithm?

So far, I haven't seen anything mentioned that I would declare visual clutter. Perhaps this discussion is more about if you haven't been reading a lot of Java/... code that you might be overwhelmed in the senses with some of the language syntax.

I know this is the case for me when I read C++ code with inheritance declarations and templating all thrown in to a rather extensive collection of punctuation.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Graceful Failure Posted: Aug 29, 2005 2:13 PM
Reply to this message Reply
Gregg wrote So far, I haven't seen anything mentioned that I would declare visual clutter. Perhaps this discussion is more about if you haven't been reading a lot of Java... code that you might be overwhelmed in the senses with some of the language syntax.

If you have been reading a lot of Java code maybe you have become accustomed to living with clutter :-)

Do you think you'd be more productive with a language that provided nullable references and non-nullable references?

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure Posted: Aug 29, 2005 3:23 PM
Reply to this message Reply
> Gregg wrote So far, I haven't seen anything mentioned
> that I would declare visual clutter. Perhaps this
> discussion is more about if you haven't been reading a lot
> of Java... code that you might be overwhelmed in the
> senses with some of the language syntax.

>
> If you have been reading a lot of Java code maybe you have
> become accustomed to living with clutter :-)
>
> Do you think you'd be more productive with a language that
> provided nullable references and non-nullable references?

No, I don't believe so. I haven't seen a profound impact on my Java software. When I wrote a lot of C software, I used lint religiously to try and ferret out null pointers ASAP. But with Java, and RuntimeExceptions of all types, there is a subtle, but important programming behavior that I have adopted. It has made be actually pay a lot of attention to top level Threads, and important execution paths. I am now much more delibert in my programming style and making very important control loop design decisions.

This means that when runtime exceptions do occur, I don't typically have any issues that the software is not prepared to take an appropriate action for.

There are several Java platform APIs that are not as well prepared. You can loose a thread in a rather catastrophic way in those APIs. So, I've also learned that lesson and adopted wrapper APIs, or other practices that provide the necessary behaviors.

What I spend the most time doing in Java is programming GUI actions. Thats the place where there is so much minutia about matching up disabled components with stateful actions of the user. Managing preference mappings etc.

My http://swingutil.dev.java.net and http://packer.dev.java.net projects contain some of the tools that I use. I'm not needing language features, I need APIs and tools that exploit the features of the language to provide more productive interfaces for me to use.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Graceful Failure Posted: Aug 29, 2005 4:08 PM
Reply to this message Reply
> > Do you think you'd be more productive with a language
> > that provided nullable references and non-nullable
> > references?
>
> No, I don't believe so. I haven't seen a profound impact
> on my Java software. When I wrote a lot of C software, I
> used lint religiously to try and ferret out null pointers
> ASAP. But with Java, and RuntimeExceptions of all types,
> there is a subtle, but important programming behavior that
> I have adopted. It has made be actually pay a lot of
> attention to top level Threads, and important execution
> paths. I am now much more delibert in my programming
> style and making very important control loop design
> decisions.
>
> This means that when runtime exceptions do occur, I don't
> typically have any issues that the software is not
> prepared to take an appropriate action for.

Isn't that a just variation on the 'we adopted programming practices that avoid those kinds of mistakes' argument used by advocates of dynamic type checking?

Flat View: This topic has 53 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: The miseducation of C++ programmers Previous Topic   Next Topic Topic: My Pycon 2005 Presentation

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use