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 ... 4 5 6 7 8 9 10 11 12 ... 25  | » ]
Alan Keefer

Posts: 29
Nickname: akeefer
Registered: Feb, 2007

Re: imperative, and functional, and oo, ... Posted: Jul 9, 2007 4:14 PM
Reply to this message Reply
Advertisement
> Alan Keefer wrote
> > So it might not be that you have to constantly
> run
> > the code, but in order to do a refactoring you have to
> run
> > the code at some point...
>
> I believe that paper was published in 1997, things change,
> it hasn't worked like that for many years.

So how exactly does it work, then?

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: imperative, and functional, and oo, ... Posted: Jul 9, 2007 4:16 PM
Reply to this message Reply
> Cedric Beust wrote
> > Right: it's just a simple string replace that requires
> > human intervention.
>
> You are mistaken, it's not just a simple string replace -
> and I think you've heard that before - it would be a lot
> easier to implement in Ruby if it was.

You keep telling everyone they're mistaken, but you're not telling us why :-)

Please do tell how renaming a function works in the Smalltalk IDE, and how it would address the code I supplied here:

http://beust.com/weblog/archives/000414.html

--
Cedric

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: imperative, and functional, and oo, ... Posted: Jul 9, 2007 4:21 PM
Reply to this message Reply
By the way, and just to get the conversation started, here is what the Smalltalk wiki has to say on the subject:

Rename Method
Renames all implementors of the method and all references to the method. Symbols with the same name are also renamed.

Note that it's not even "methods from other classes with the same name are also renamed", it's "symbols"...

Source:
http://wiki.cs.uiuc.edu/RefactoringBrowser/Rename+Method

--
Cedric

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: imperative, and functional, and oo, ... Posted: Jul 9, 2007 4:27 PM
Reply to this message Reply
Cedric Beust wrote
> The truth is that certain refactorings are just plain
> impossible to achieve automatically in dynamic languages

That's true. (Let's not quibble about type recovery.)

And ...

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: imperative, and functional, and oo, ... Posted: Jul 9, 2007 4:29 PM
Reply to this message Reply
Sorry, this should have been "Ruby", not "Smalltalk".

--
Cedric

> By the way, and just to get the conversation started, here
> is what the Smalltalk wiki has to say on the subject:
>
> Rename Method
> Renames all implementors of the method and all references
> to the method. Symbols with the same name are also
> renamed.
>
> Note that it's not even "methods from other classes with
> the same name are also renamed", it's "symbols"...
>
> Source:
> http://wiki.cs.uiuc.edu/RefactoringBrowser/Rename+Method
>
> --
> Cedric

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: imperative, and functional, and oo, ... Posted: Jul 9, 2007 4:35 PM
Reply to this message Reply
Cedric Beust wrote
> Note that it's not even "methods from other classes with
> the same name are also renamed", it's "symbols"...

It's only half-an-hour since you acknowledged that refactorings can be made on a case-by-case basis.

Incidentally, if you think that is manual then I guess you don't actually remember what it's like to do refactoring using a text editor.

Chuck Allison

Posts: 63
Nickname: cda
Registered: Feb, 2003

Re: Programming with "Duh" Typing Posted: Jul 9, 2007 4:41 PM
Reply to this message Reply
I've heard of Scala - now I guess it's time to really look into it. But let me say that it is just copying ML with its type inferencing and val binding keyword. ML was developed in 1972. What goes around comes around! I suppose that's why OCaml is so popular: it has the power of ML and the speed of C++.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

It's the parse trees... Posted: Jul 9, 2007 4:49 PM
Reply to this message Reply
> > You are mistaken, it's not just a simple string replace
> > and I think you've heard that before - it would be a
> > lot easier to implement in Ruby if it was.

Cedric Beust wrote "You keep telling everyone they're mistaken, but you're not telling us why :-)"

Alan Keefer wrote "So how exactly does it work, then?"


Search and replace on parse trees - hardly simple string replace.

martin cohen

Posts: 3
Nickname: mjcohen
Registered: Oct, 2003

Re: Programming with "Duh" Typing Posted: Jul 9, 2007 5:33 PM
Reply to this message Reply
for example:
>
function foo(x){
if(x) return 4
else return "z"
}

This would be just fine in gawk:)

David Beutel

Posts: 29
Nickname: jdb
Registered: May, 2003

Re: Programming with "Duh" Typing Posted: Jul 9, 2007 5:51 PM
Reply to this message Reply
Type inference ("duh" typing) sounds like a win, at least for variables: keep the advantages of a static language, but add an advantage of a dynamic language by removing some duplication.

I also like Michael Feathers' perspective on optional typing:

> A type system is a set of tests. It's just the set of
> tests a language designer could invent without seeing
> your program. The tests are hard-coded in the compiler
> and it would be nice to have more control over them.

Conversely, for dynamic languages, what about adding some advantage of a static language? I'd like to be able to run a set of tests (or take a snapshot from production) and have the execution environment show me what type of data has been in each variable or parameter--not for just an instant, like in a debugger, but written into the source code.

It could be saved for later to generate warnings or errors if future data goes out of those type bounds, and to help with refactoring. If a variable has contained a variety of types, it could show a common subclass that works for all uses, or an ad hoc interface generated automatically, or perhaps a history of specific types coordinated with the type history of collaborating variables. I'll need to be able to reset the history for certain code changes.

I have little experience with dynamic languages, but I think this would be useful, as I sometimes search for all calls to a function to figure out what types are coming into its parameters. Does the SmallTalk editor do this for refactoring? Even if this is insufficient for refactoring, it would make a nice addition to a dynamic language, making the source code easier to understand without imposing the static burden.

Steve Bendiola

Posts: 2
Nickname: bendiola
Registered: Jul, 2007

Re: Programming with Posted: Jul 9, 2007 6:20 PM
Reply to this message Reply
>> Also, at JavaOne, Martin Odersky mentioned he was
>> considering some form of optional duck typing for Scala.

From http://www.scala-lang.org/docu/changelog.html#v2.6.0

Structural subtyping

class File(name: String) {
def getName(): String = name
def open() { /*..*/ }
def close() { println("close file") }
}

def test(f: Object { def getName(): String }) { println(f.getName) }

test(new File("test.txt"))
test(new java.io.File("test.txt"))

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Programming with Posted: Jul 9, 2007 7:43 PM
Reply to this message Reply
> >> Also, at JavaOne, Martin Odersky mentioned he was
> >> considering some form of optional duck typing for
> Scala.
>
> From http://www.scala-lang.org/docu/changelog.html#v2.6.0
>
> Structural subtyping
>

> class File(name: String) {
> def getName(): String = name
> def open() { /*..*/ }
> def close() { println("close file") }
> }
>
> def test(f: Object { def getName(): String }) {
> println(f.getName) }
>
> test(new File("test.txt"))
> test(new java.io.File("test.txt"))
>


Thanks. So the test definition in this example is saying that f must be some subclass of Object that has a method getName that takes no parameters and returns a String. At points of invocation of test, the compiler checks to make sure that's true. Inside the test method, it uses reflection to call getName. Is that correct?

If so, it seems like it could address some of those situations in which you want to change something from one type to another, but the types don't implement a common interface with the methods you want to call. I think there's an example like that in the chapter on duck typing in the Prag's Ruby book. I wonder, are there other benefits of dynamic languages that the people here think might not be possible or as easy with an approach like this? I guess my question is, to what extent would an approach like this (structure subtyping in an otherwise statically typed languge) provide the benefits of dynamically typed languages that are usually missing in the statically typed ones.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Programming with "Duh" Typing Posted: Jul 9, 2007 8:06 PM
Reply to this message Reply
"Type inference may quack like dynamic typing, it may walk like dynamic typing, and it may fly like dynamic typing, but it doesn’t swim like dynamic typing."

I liked all your comment, not only this quote! As a current user of Ruby and JavaScript, with tens of thousands of Ruby and thousands of lines of JavaScript, I can back you on your claims.

Generally, the level of insight in this thread has been quite good, with clearly debated points of views and sharing of personal experiences.

Way to go guys!

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Programming with "Duh" Typing Posted: Jul 9, 2007 8:46 PM
Reply to this message Reply
"In the end, maybe it does come down to personal preference after all. ;-) It would seem that my experimental coding style is a whiteboard style and that yours is a notebook style. That is, with a whiteboard, it's a lot easier to wipe out a large chunk of writing and redraw something different. I'd wager that you mull over a design in your mind longer than I do before putting it into code."

Same here. It's not always that I need to revert my hurried changes, but it does happen. With Revision Control Systems, it's quite easy to revert changes anyway. For example, I created a custom inheritance framework in JavaScript using the little OO library of someone else. I didn't like the result of it, even though it took a few iterations for me to decide on it. Then I reverted it all back once I decided I didn't like it and that it just couldn't be salvaged.

As Fred Brooks said, "Build one to throw away."

By incorporating that idea in programming with dynamic typed languages, one can keep on throwing away all the time and still have a working system to work with. :-)

I'm sure that it's easy to keep the things that matter working well enough even during the large refactorings. As long as one works with proper modularization, reusing, testing, eating own dogfood, the chaos ends up being productive. Dynamic typed language + modularization + components = rocks. :-)

Now if you have an explosion of non-modularized, non-componentized, non-tested, non-used, lines of code, maybe it would be better to have static typing in place to help with the mess. I think not everyone strives for the same patterns, so there's enough room for both approaches. Not to mention that by being pragmatic, one uses what is available as well.

Thomas Guest

Posts: 236
Nickname: tag
Registered: Nov, 2004

Re: imperative, and functional, and oo, ... Posted: Jul 10, 2007 1:53 AM
Reply to this message Reply
> With statically typed languages, it's mathematically
> provable that the code after refactoring is equivalent to
> the one you started with, and it's the kind of peace of
> mind that I am not willing give away for large scale
> projects...

I'll admit that Eclipse (and similar) are fine tools for cleaning up Java code. Do such tools also work well on C++, with its various complicated compilation phases?

I'd prefer to emphasize testing over mathematically provable (and bug-preserving) transformations. Have you also proved that Eclipse's implementation is mathematically correct? (Last time I used Eclipse, it had a tendency to crash.) I'd also like to see large scale projects built from small independent components; each small enough to fit in one person's head.

Like many others on this topic, I've come to favour dynamic languages for many components. They keep my software smaller, more readable, softer. Static typing in practice seems more about strapping code to the machine so it can run faster -- an important consideration for some components, of course.

Flat View: This topic has 370 replies on 25 pages [ « | 4  5  6  7  8  9  10  11  12 | » ]
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