Weblogs Forum - Graceful Failure

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

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

Back to Topic List

Reply to this Topic

Search Forum

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 29, 2005 4:22 PM

> > 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?

It means that there is a benefit that I get from a language feature which many find to be intrusive. Perhaps they've always ignored exceptions, or otherwise buried them into print statements that are uninformative (no stack trace) and believe that this makes their program better?

It is slightly interesting to compare this to dynamic type checking arguments. I don't know whether that's a valid comparison though. I'd have to think about that more.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Graceful Failure

Posted: Aug 29, 2005 6:45 PM

> > 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?
>
> It means that there is a benefit that I get from a
> language feature which many find to be intrusive. Perhaps
> they've always ignored exceptions, or otherwise buried
> them into print statements that are uninformative (no
> stack trace) and believe that this makes their program
> better?
>
> It is slightly interesting to compare this to dynamic type
> checking arguments. I don't know whether that's a valid
> comparison though. I'd have to think about that more.

Well, forgive me if this seems too much of a caricature, you seem to be having it both ways - dynamic languages are worse than Java because they don't trap errors until runtime, but it's OK for Java not to trap errors until runtime (errors which other languages might exclude through static type checking).

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Graceful Failure

Posted: Aug 29, 2005 11:17 PM

> > > 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!

Perhaps it's worth noting that there are dynamically type checked languages which do allow the distinction, for example Lua

local s = "foo"
if ( some_expr ) then 
   ...10 lines of code...
   local s = "bar"
end

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure

Posted: Aug 30, 2005 6:29 AM

> > > > 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!
>
> Perhaps it's worth noting that there are dynamically type
> checked languages which do allow the distinction, for
> example Lua
>

local s = "foo"
> if ( some_expr ) then 
>    ...10 lines of code...
>    local s = "bar"
> end

Yes, but as I mentioned above, I still have to type something there, so why not type the 'type' of the value?

This is what I am trying to understand. When is it better to not have a type associated with the variable. When does that add value, regardless of the whole too much typing or too much to read issues.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure

Posted: Aug 30, 2005 7:45 AM

> > It is slightly interesting to compare this to dynamic type
> > checking arguments. I don't know whether that's valid
> > comparison though. I'd have to think about that more.
>
> Well, forgive me if this seems too much of a caricature,
> you seem to be having it both ways - dynamic languages are
> worse than Java because they don't trap errors until
> runtime, but it's OK for Java not to trap errors until
> runtime (errors which other languages might exclude
> through static type checking).

I am saying that under most circumstances, the external data that a program deals with, is an unknown. So, you have to catch certain runtime errors related to processing malformated, out of range, or otherwise invalid data.

Many languages have differing support for this issue. I have adopted practices and principals for using the Java exception mechanism that allow me to take care of such issues, and because of the ways that I do that, I also create more robust error handling.

I like using Jini and RMI based programming techniques because it's then all live code. This means that the objects that I am using and the data that they contained can be more thoroughly controlled under many circumstances.

It's definately not a perfect world though...

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Graceful Failure

Posted: Aug 30, 2005 9:07 AM

> Yes, but as I mentioned above, I still have to type
> something there, so why not type the 'type' of the value?

imo Having to type 'something' to disambiguate nested variable definition from assignment is a separate concern - we need to justify explicit type declarations on their own merits.

> This is what I am trying to understand. When is it better
> to not have a type associated with the variable. When
> does that add value, regardless of the whole too much
> typing or too much to read issues.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure

Posted: Aug 30, 2005 11:58 AM

> > Yes, but as I mentioned above, I still have to type
> > something there, so why not type the 'type' of the
> value?
>
> imo Having to type 'something' to disambiguate nested
> variable definition from assignment is a separate concern
> - we need to justify explicit type declarations on their
> own merits.
>
> > This is what I am trying to understand. When is it
> better
> > to not have a type associated with the variable. When
> > does that add value, regardless of the whole too much
> > typing or too much to read issues.

Conditional syntax can create confusion to the compiler as well as to the reader of any syntactically complex, or multi-faceted expression of program structure. For instance, optional '{' and '}' for blocks is a bad language design decision. it allows the

if( i < 5 )
if( c != 'g' )
a();
else
b();

bug to be created. So, I generally use { } everywhere, because I've learned that lesson and it's faster to typing those characters then it is to find that bug.

In the case of optional typing, the example I cited, is the most prevalent issue in my mind. It has bad enough of an outcome, namely a difficult to track bug in the software, that it's important to me to disallow that choice.

Providing a unifying, repetative and well understood syntax base for language expression seems pretty valuable to me as well.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Graceful Failure

Posted: Aug 30, 2005 1:16 PM

-snip-
> In the case of optional typing, the example I cited, is
> the most prevalent issue in my mind. It has bad enough of
> an outcome, namely a difficult to track bug in the
> software, that it's important to me to disallow that
> choice.

As we've seen, being able to disambiguate variable definition from variable use is a valid concern, but as we have other means to remedy the problem it cannot be /the/ reason for explicit type declaration.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Graceful Failure

Posted: Aug 30, 2005 2:50 PM

> -snip-
> > In the case of optional typing, the example I cited, is
> > the most prevalent issue in my mind. It has bad enough
> of
> > an outcome, namely a difficult to track bug in the
> > software, that it's important to me to disallow that
> > choice.
>
> As we've seen, being able to disambiguate variable
> definition from variable use is a valid concern, but as we
> have other means to remedy the problem it cannot be /the/
> reason for explicit type declaration.

But what magic am I missing by having explicit type declarations. I.e. what's not happening that would add value to my software if I didn't provide typing?

We have the whole duck typing thing. In my RCL language that I did at AT&T on the 5ESS switch, 10+ years ago, I provided duck typing. But that was because I didn't have interfaces. When Java came out about 1 year after I finished v1.0 of my language, I was sold on interfaces. I later added optional typing so that you could declare method arguments to be typed explicitly. It was still a runtime check though. But that was a decision based on not complicating my compiler. It had to be maintainable by people without compiler design degrees/experience.

What I learned about duck typing was it made it easy to throw software together that you didn't have a good design based for yet, while you were prototyping. But, eventually, it comes back to haunt you because you can't point a programmer at the softwares requirements except on a completely separate piece of documentation which will likely not be kept up to date. With explicit typing, we have written requirements that are readable, in the context that they apply. I find that useful.

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

Previous Topic

Next Topic