The Artima Developer Community
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

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 370 replies on 25 pages [ « | 1 ... 13 14 15 16 17 18 19 20 21 ... 25  | » ]
James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing Posted: Jul 23, 2007 6:11 AM
Reply to this message Reply
Advertisement
> I failed to find where you were told "this was absolutely
> not the case" so obviously I'm missing chunks of the
> discussion.

Achilleas Margaritis wrote: "Interactive development is way much faster than anything else."

Seems pretty absolute to me.

> I hope one day we'll think it really strange that anyone
> quarrels about it being faster to program with A rather
> than B without providing some kind of evidence, and
> being specific about the circumstances.

Don't hold your breath.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing Posted: Jul 23, 2007 11:10 AM
Reply to this message Reply
James Watson wrote
> > I failed to find where you were told "this was
> > absolutely not the case" so obviously I'm missing chunks
> > of the discussion.
>
> Achilleas Margaritis wrote: "Interactive development is
> way much faster than anything else."
>
> Seems pretty absolute to me.

Seems to be a statement about interactive development not about dynamically checked languages.

(I could be missing context - simply including the "Posted:" data and time would be solve that problem.)

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Static Type Checks are not Tests Posted: Jul 23, 2007 11:20 AM
Reply to this message Reply
> > Sure, there are differences, but at the end of it,
> > traditional tests and type systems serve the same
> purpose.
-snip-
Erik Engbrecht wrote
> Just because two things serve similar, overlapping
> purposes, doesn't mean that they are the same thing. I
> don't think one can be substituted for another. When you
> use a dynamic language, you are trading a measure of
> certainty about your code for flexibility.

Mostly I agree but let's not forget other tools - static analysis in addition to the language compiler, automatic test generation, ...

For example, static analysis of byte code compiled from the dynamically checked language Erlang

"The DIALYZER: a DIscrepancy AnaLYZer for ERlang programs"
http://www.it.uu.se/research/group/hipe/dialyzer

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Static Type Checks are not Tests Posted: Jul 23, 2007 11:44 AM
Reply to this message Reply
> > There are languages out there with extensible type
> > systems. They blur the lines even further.
>
> Just because two things serve similar, overlapping
> purposes, doesn't mean that they are the same thing. I
> don't think one can be substituted for another. When you
> use a dynamic language, you are trading a measure of
> certainty about your code for flexibility.

That's all fine and good, but I never said that they can be substitute for each other. I merely said that that type checking and test are both aspects of the same thing, type checks are, in effect, tests.

Now, I don't expect we'll ever agree on this. The internet is prone to long run on debates over definitions, and people who argue definitions are both right and wrong because each side can shift definitions to make their case. I choose a definition which highlights commonality, and I find it useful to highlight that commonality. If you don't like definition or think that it implies more than I implied, so be it. That's okay. :-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing Posted: Jul 23, 2007 11:50 AM
Reply to this message Reply
> James Watson wrote
> > > I failed to find where you were told "this was
> > > absolutely not the case" so obviously I'm missing
> chunks
> > > of the discussion.
> >
> > Achilleas Margaritis wrote: "Interactive development is
> > way much faster than anything else."
> >
> > Seems pretty absolute to me.
>
> Seems to be a statement about interactive development
> not about dynamically checked languages.
>
> (I could be missing context - simply including the
> "Posted:" data and time would be solve that problem.)

Or if it were really so important you could look it up yourself. You were the one that took it upon yourself to comment on the discussion. It would seem to be sensible to get this 'context' that you mention before doing so. I don't understand why the burden is on me to show you why I didn't do what you've accused me of.

http://www.artima.com/forums/flat.jsp?forum=106&thread=209353&start=187&msRange=1

I'm not really sure why you feel the need to badger me over minutia like this. I can see why (superficially) the statement I made might look like the same logical error I proposed that he had made earlier but it isn't. If you want to make a case that it is, then do it. Show how the statement I made is an example of the 'no perfect solution fallacy'. That is, show me where I either assumed that a perfect solution to the problem of typing errors exists or that interactive development should be rejected as a solution for it because it some portion of the typing errors problem will still exist after implemented.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Static Type Checks are not Tests Posted: Jul 23, 2007 12:11 PM
Reply to this message Reply
> That's all fine and good, but I never said that they can
> be substitute for each other. I merely said that that
> type checking and test are both aspects of the same thing,
> type checks are, in effect, tests.

If that's all you are saying, isn't that really just a semantical argument?

My frustration with this discussion and ones like it is that focus on static typing as merely some sort of compatibility test. It's pretty clear to me that this isn't really a significant benefit of static typing. It's a strawman that's easily knocked over but even people who like static typing persist in using at as the main argument for static typing.

When Java introduced generics syntax, there was a lot of talk about how this would make software safer. This argument never made any sense to me because in all my years of professional Java development, I've never seen a (well-tested) production application fail because of a ClassCastException. The value I see in generics is that they make code (when used judiciously) far easier to understand despite their unsightly appearance.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Programming with "Duh" Typing Posted: Jul 23, 2007 12:16 PM
Reply to this message Reply
> > 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.
>
> I think the productivity feel of Python and Ruby has
> mostly to do with how succinctly those languages allow you
> to express what you want the program to do, but also to
> some extent how that economy of syntax makes programs
> readable. Bruce Eckel touched on that here:
>
> http://www.artima.com/intv/aboutme2.html
>
> I think those things (concise expression when writing code
> and the uncluttered, easier to read code that results) do
> contribute to programmer productivity, but a lot of other
> factors come into play. I recently put together a new
> website, a site for a contest we're helping TIBCO run:
>
> http://www.ajaxchallenge.com/
>
> I did it in about two weeks, which maybe makes it sound
> like a Rails app, but it's a Java app. I did use Scala for
> the controllers, because I wanted to try Scala out. But
> Scala had very little to do with my productivity. If
> anything, Scala slowed me down because I don't know it
> very well. What made me productive was that we used our
> existing architecture. I think a lot about productivity,
> because I want to hire programmers and I want to maximize
> the ROI, and I think architecture is key, as I wrote in
> this blog post:
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=95622
>
> Despite that, though, I do find plausible what I've heard
> several people say about the number of working lines of
> code a programmer can produce in a day. Eckel mentions it
> in the interview I point to first in this message.
> Basically the claim is that a programmer can produce X
> working lines of code a day, no matter the language. So if
> a programmer can express the same concept in fewer lines
> of code in one language compared to another, that
> programmer would be more productive in the more concise
> language.
>
> There's a lot more to productivity than that, of course,
> but I am considering using Scala more and more for our
> future development, because the claim I hear there is that
> you can do things in about half the volume of code in
> Scala compared to doing it in Java. I want to take
> advantage of that.

I visit my friend Scott Meyers whenever I go through Portland. Last time, Scott (a long-time C++ guy) pointed out that static typing buys you two things: (1) Support within IDEs (2) the compiler can generate more efficient code. Noticeably absent was any discussion of "safety," and Scott is all about programming better.

I find Scala interesting because it does a lot more for you (Actors, Functional programming, and the brilliant understanding of what a switch statement really means, for example) while being more succinct. I don't object to static type checking in general, but I object to (1) Its overuse and (2) The belief that it's a magical solution to program correctness, and that no alternative solution could possibly be better.

There is also a persistent misunderstanding of generics vs structural (duck) typing. People have begun to see how messy and convoluted the results of Java's generics mechanism have been. But it's far more fundamental than that -- the obsession with static typing, applied to a generics mechanism, has produced a straightjacket that obscures the original meaning of the term "generics," which should never have been applied to the feature in Java (which, I think, only appeared in the language because C# was adding a somewhat better version).

When you use a structurally typed language like Python or Ruby, you begin to understand what "generic" really means, and also how much effort you must go to in order to make a generic call in an overtyped language like Java. And it was a language decision -- C++ does it right; C++ templates are far more "generic" than Java's "generics" will ever be. Java's "generics" require far too much work with far too little payoff.

Many of my Artima Weblog postings discuss these topics in depth; you can also find my original analysis "Generics Aren't" here:
http://mindview.net/WebLog/log-0050
And numerous other discussions of Generics:
http://mindview.net/WebLog/ArticleIndex
I tried to summarize all this in the Generics chapter of "Thinking in Java 4e".

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming with "Duh" Typing Posted: Jul 23, 2007 12:56 PM
Reply to this message Reply
Hi Bruce,

> But it's far more fundamental than
> that -- the obsession with static typing, applied to a
> generics mechanism, has produced a straightjacket that
> obscures the original meaning of the term "generics,"
> which should never have been applied to the feature in
> Java

Can you expand on how the meaning of Generics is obscured by its implementation in Java?

And how would you improve it?

> When you use a structurally typed language like Python or
> Ruby, you begin to understand what "generic" really means,
> and also how much effort you must go to in order to make a
> generic call in an overtyped language like Java.

I'm having a hard time following... Python is not statically typed, how can it make me understand what "generic" really means? I, for one, find Python programs that I didn't write much harder to read, let alone modify, than their Java (or any other statically typed language) counterparts.

Basically, you're voicing interesting criticisms but without proposing any solution to support your views. I have my share of quibbles with Java and C++ generics, but each time I try to come up with better ideas, these end up even more flawed than those I'm trying to fix, so over the years, I have learned to appreciate the reflexion that has gone into the various generic implementations that I have seen.

Curious to see if you have a better solution.

--
Cedric
http://testng.org

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing Posted: Jul 23, 2007 12:59 PM
Reply to this message Reply
> Many of my Artima Weblog postings discuss these topics in
> depth; you can also find my original analysis "Generics
> Aren't" here:
> http://mindview.net/WebLog/log-0050

I don't really understand the premise of this analysis. Your point is that:
public class Communicate  {
  public <T> void speak(T speaker) {
    speaker.talk();
  }
}


Doesn't allow any method to be called on speaker. OK. I'm not sure I've ever seen any claim that they were meant to solve this problem. That's not to say that the problem isn't worth solving but if that's what you want to do it seems to me that declaring a type T just so you can call any method on it is also pretty pointless. It would be a lot clearer to add a key word like 'any' for this. The 'T' in such a declaration (e.g. your C++ example) is completely extraneous.

I think you gloss over that the Speaks interface provides semantic information about how the Robot and Dog classes are related. Just having two methods with the same name doesn't tell you anything like that. Only that both are passed to the same method as any parameters would give any hint. I could select on the Speaks interface and see all types that implement the interface. Unless I am looking at the talk method and follow all dependencies, there is no obvious sign of a sibling relationship. Whether this is valuable enough information to warrant the effort required is debatable but I think it's a little biased to ignore this benefit.

I also think that this statement misses the value of generics as implemented in Java:

"The conclusion that the Silicon Valley Patterns Group came to was that these so-called Generics seem to only solve the problem of automatically casting in and out of containers."

The value of generics is hardly the removal of explicit casting; that's merely a side-benefit. It's that it fills a gap in the Java type system that caused type information to not be traceable (or at least difficult to trace) through a huge set of design approaches. For someone who feels that the type information is useful, it's a patch over a flaw in the language. If you don't feel the type information is valuable, then Java is not a good fit for you with or without generics.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Static Type Checks are not Tests Posted: Jul 23, 2007 1:15 PM
Reply to this message Reply
> > > Sure, there are differences, but at the end of it,
> > > traditional tests and type systems serve the same
> > purpose.
> -snip-
> Erik Engbrecht wrote
> > Just because two things serve similar, overlapping
> > purposes, doesn't mean that they are the same thing. I
> > don't think one can be substituted for another. When
> you
> > use a dynamic language, you are trading a measure of
> > certainty about your code for flexibility.
>
> Mostly I agree but let's not forget other tools - static
> analysis in addition to the language compiler, automatic
> test generation, ...
>
> For example, static analysis of byte code compiled from
> the dynamically checked language Erlang
>
> "The DIALYZER: a DIscrepancy AnaLYZer for ERlang
> programs"
> http://www.it.uu.se/research/group/hipe/dialyzer

Yes, I think static analyzers should be leveraged far more than they are. The problem is they are effectively just warnings, and it is easy to simply ignore warnings.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Static Type Checks are not Tests Posted: Jul 23, 2007 1:21 PM
Reply to this message Reply
> Now, I don't expect we'll ever agree on this. The
> internet is prone to long run on debates over definitions,
> and people who argue definitions are both right and wrong
> because each side can shift definitions to make their
> case. I choose a definition which highlights commonality,
> and I find it useful to highlight that commonality. If
> you don't like definition or think that it implies more
> than I implied, so be it. That's okay. :-)

But where do we go to establish definitions? Far too many arguments boil down to the meaning of words, both on the internet and in "real life."

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: Programming with "Duh" Typing Posted: Jul 23, 2007 1:28 PM
Reply to this message Reply
> I also think that this statement misses the value of
> generics as implemented in Java:
>
> "The conclusion that the Silicon Valley Patterns Group
> came to was that these so-called Generics seem to only
> solve the problem of automatically casting in and out of
> containers."
>
> The value of generics is hardly the removal of explicit
> casting; that's merely a side-benefit.

Agreed. I'm surprised there are still people who think that the point of Generics in Java is just to remove casting.

To me, it's really about increased readability and understanding. Yes, sometimes the syntax is a bit hard to parse, but in exchange, we gain the following:

- Powerful automatic (and therefore safe) refactorings.
- Better understanding of API's we need to work with
- A more expressive way to express API's that we write and publish
- Objects that will be verified by the compiler to be of the correct type (we already had that in Java, but it's much improved now)

I'm more than happy to trade some syntactic sugar if it helps me produce (and use) more solid code, and after a few years of Java Generics usage, I'm now a firm believer that they are a step in the right direction.

--
Cedric
http://testng.org

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing Posted: Jul 23, 2007 3:55 PM
Reply to this message Reply
James Watson wrote "Show how the statement I made is an example of the 'no perfect solution fallacy'"

Actually I was interested that this disagreement, between someone in the throws of Smalltalk revelation and someone who has began to use Python, was couched in terms of dynamic type checking versus static type checking.

Seems like we should be thinking about resumable exceptions versus non-resumable exceptions, and deployment which includes the development environment versus deployment which excludes the development environment.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Static Type Checks are not Tests Posted: Jul 23, 2007 5:06 PM
Reply to this message Reply
Erik Engbrecht wrote
> Yes, I think static analyzers should be leveraged far more
> than they are. The problem is they are effectively just
> warnings, and it is easy to simply ignore warnings.

I think you just switched topic to project management - failed tests are also just warnings - software is shipped with known bugs. We bother about the unknown bugs because we can't assess the damage that they might do or whether they breach contractual agreements.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Static Type Checks are not Tests Posted: Jul 23, 2007 5:12 PM
Reply to this message Reply
Michael Feathers wrote
> I choose a definition which highlights commonality,
> and I find it useful to highlight that commonality.

Because... ?

Cui bono?

Flat View: This topic has 370 replies on 25 pages [ « | 13  14  15  16  17  18  19  20  21 | » ]
Topic: Programming with "Duh" Typing Previous Topic   Next Topic Topic: Python 3000 Plea for Help

Sponsored Links



Google
  Web Artima.com   

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