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 8 ... 25 | » ]

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 4:54 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.

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.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

The List example

Posted: Jul 8, 2007 5:06 PM

imo one of the lessons here is don't use scala List as an example of type inference for generic collections - because it brings in too many other issues, choose another collection instead.

Another lesson might be choose a slightly bigger example because it'll make the code volume difference more obvious. One of the things floating around reddit over the last week was this:

http://gensym.org/2007/4/7/enumerate-map-filter-accumulate

:note that he says the Java isn't bad at all, and then he provides a second slightly larger example which he thinks make the difference more apparent.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 8, 2007 5:13 PM

"number of working lines of code a programmer can produce in a day"

That notion has been around sooooo long without being reconsidered.

I assure you the number of lines of code I can produce a day working within a Smalltalk environment is very different than the number of lines of code I can produce a day writing Smalltalk with a text editor. I know because I've tried both. ;-)

Furthermore, on a productive day I would both add functionality and remove code by refactoring.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Programming with

Posted: Jul 9, 2007 2:39 AM

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

I'm pretty sure you'll find people who feel pretty much similarly about any mainstream language. After all, it's not so long since Java was the proclaimed as the be all and end all of languages by large swaithes of the programming community, and there are plenty of C and C++ programmers around who have still to be convinced that any other language is anything other than a transient fashion.

, and my
> theory has been a bit reason they "love" it is because
> they feel very productive when writing code.

You may well be right, though all programmers "love" writing productive code regardless of the language used.

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

Here is where too many (simultaneous) inferences are starting to be drawn about the causes of people's feelings. Phrases "dynamic language stay out of their way" and "fighting the compiler" have become a journalistic hacks that don't really mean anything. However, I might be persuaded that a language, like Java, that has a larger vocabulary and very much larger library could take longer to master than a smaller language, which would lead to the conclusion that smaller languages are easier, or more fun, to use.

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

I think the measure of a language is not the appearance of the language on paper but in its capabilities. Can you write a better word processor (or whatever) in language x than y. How easily can a team produce a working product? Having produced something, how easily can you modify it. How easily can someone else debug it, etc? These are more important questions than being able to say "My language uses seven words where your uses eleven.".

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 4:14 AM

Since many programming problems are intractable (that's the nature of programming, see the halting problem etc), we should test all our code. So why do we have static type systems? they do not really prevent errors.

I was a big supporter of static typing, but as of late I have come to love dynamic typing. It's just so much easier to write code with dynamic typing.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 5:12 AM

I think that the amount of typing that you have to do does have a lot to do with the perceived advantages of dynamically typed and type inferencing systems, but there's another part also.

Traditional statically typed languages like Java and C++ are less orthogonal. In them, there's a whole class of changes that require you to change declarations all the way across your program. It's stunning to work in a language where, when you want to make a change, you generally just have to do it in one place.

It seems like it shouldn't make an "aha!" difference to the vast majority of programmers because many don't refactor as much as they should. The cost of macro-level refactoring is just too high in those languages, and people often just try to work around problems. But, it does make a big difference at the micro-level. If you're developing an algorithm which uses a vector of pairs of vectors of ints and strings and you choose to change the data representation, you're probably going to have to change the code in many more places in a traditional static language. And, this sort of futzing with algorithms and infrastructure code is common in development.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 5:44 AM

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

That's a really, really good question.

I think people feel productive when they are creating the perception that they are productive. Feeling and looking productive is often a matter of producing "working software." Of course that "working software" has to be rewritten twice as well as undergoing many refactorings along the way, many (but not all) of which could be avoided with up-front design.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 6:15 AM

> I think that the amount of typing that you have to do does
> have a lot to do with the perceived advantages of
> dynamically typed and type inferencing systems, but
> there's another part also.
>
> Traditional statically typed languages like Java and C++
> are less orthogonal. In them, there's a whole class of
> changes that require you to change declarations all the
> way across your program. It's stunning to work in a
> language where, when you want to make a change, you
> generally just have to do it in one place.
>
> It seems like it shouldn't make an "aha!" difference to
> the vast majority of programmers because many don't
> refactor as much as they should. The cost of macro-level
> refactoring is just too high in those languages, and
> people often just try to work around problems. But, it
> does make a big difference at the micro-level. If you're
> developing an algorithm which uses a vector of pairs of
> vectors of ints and strings and you choose to change the
> data representation, you're probably going to have to
> change the code in many more places in a traditional
> static language. And, this sort of futzing with
> algorithms and infrastructure code is common in
> development.

Statically typed languages are pessimistic about the impact of changes and attempt to deductively identify places where one change breaks other code. Dynamically typed languages are optimistic about failure and rely on empirical techniques to locate it.

In my subjective experience, if code is going to be changed many times before a case will be encountered that will trigger failure elsewhere, then dynamic languages are more productive because you can avoid the work of fixing the other code every time you make a change.

It should be noted that using comprehensive unit tests will work against this advantage of dynamic languages. Both static checking and automated unit testing force you to examine the details in your code early, possibly too soon.

But I think in the long run, if you are building a production system (for some definition of "production"), then letting problems fester is extremely risky.

Nemanja Trifunovic

Posts: 172
Nickname: ntrif
Registered: Jun, 2004

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 6:26 AM

> Since many programming problems are intractable (that's
> the nature of programming, see the halting problem etc),
> we should test all our code. So why do we have static type
> systems? they do not really prevent errors.

Static typing won't "prevent" errors, but it will help you find some errors much faster. An example: http://worsethanfailure.com/Articles/Many-Shades-of-Cout.aspx

The compiler reported the issue and probably the lines of code that caused the problem on the spot. With dynamic typing and unit-testing it would take longer.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 6:28 AM

> Statically typed languages are pessimistic about the
> impact of changes and attempt to deductively identify
> places where one change breaks other code. Dynamically
> typed languages are optimistic about failure and rely on
> empirical techniques to locate it.
>
> In my subjective experience, if code is going to be
> changed many times before a case will be encountered that
> will trigger failure elsewhere, then dynamic languages are
> more productive because you can avoid the work of fixing
> the other code every time you make a change.
>
> It should be noted that using comprehensive unit tests
> will work against this advantage of dynamic languages.
> Both static checking and automated unit testing force you
> u to examine the details in your code early, possibly too
> soon.
>
> But I think in the long run, if you are building a
> production system (for some definition of "production"),
> then letting problems fester is extremely risky.

The nice thing about tests, though, is that you can select the level. For a while, I've been thinking that the real problem is that type systems are too coupled to programs:

http://www.artima.com/weblogs/viewpost.jsp?thread=156197

What we really need are systems which allow us to lock things down program qualities when we need to a lighten them when we need to, with little fuss. It's a shame that these choices are hardcoded by choice of language right now. People should be able to make choices locally.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 6:28 AM

> It seems like it shouldn't make an "aha!" difference to
> the vast majority of programmers because many don't
> refactor as much as they should. The cost of macro-level
> refactoring is just too high in those languages, and
> people often just try to work around problems. But, it
> does make a big difference at the micro-level. If you're
> developing an algorithm which uses a vector of pairs of
> vectors of ints and strings and you choose to change the
> data representation, you're probably going to have to
> change the code in many more places in a traditional
> static language. And, this sort of futzing with
> algorithms and infrastructure code is common in
> development.

Having used Python for a relatively short while, I can see where you are coming from but I also have a feeling that static typing can really make macro-scale refactoring easier.

For example, I am refactoring two completely unrelated programs written in Java and I have been able to make large scale changes without breaking the code (beyond my own stupid errors.) I can do this because when I want to change something, I can either select the item in an IDE and have it tell me where it is used or just change it and let the compiler tell me what I need to change.

What I find in Python is that I can barely reuse my old code, much less modify it without a lot of pain. I don't know of any tool that will allow me to select a type I have created and find where it is used. I can write things from scratch really quickly but if I want to create something that will be useful 6 months from now, I have to put a lot more effort into documentation than is required in Java.

Don't get me wrong, I think Java is way too verbose but from what I know, Scala is not verbose at all. I think I've been able to do things in Scala with less code than is needed in Python, even.

I just don't think it makes sense to say Java is too verbose, so lets get rid of static typing.

I'm not sure that you are arguing for dynamic languages. I merely want to analyze more closely what is it about a language that makes it more productive.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 7:37 AM

> > Since many programming problems are intractable (that's
> > the nature of programming, see the halting problem
> etc),
> > we should test all our code. So why do we have static
> type
> > systems? they do not really prevent errors.
>
> Static typing won't "prevent" errors, but it will help you
> find some errors much faster. An example:
> http://worsethanfailure.com/Articles/Many-Shades-of-Cout.as
> px
>
> The compiler reported the issue and probably the lines of
> code that caused the problem on the spot. With dynamic
> typing and unit-testing it would take longer.

True. But, I don't think we should see it as a dichotomy. 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.

Michael Hobbs

Posts: 51
Nickname: hobb0001
Registered: Dec, 2004

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 8:29 AM

People who comment on this debate often sum it up as “different strokes for different folks.” Being a developer who often swims in both waters, I’ve discovered that the reason lies deeper than simple personal preference. It depends on what type of programming you are doing.

Static typing lends itself well to programming when you already have a good design, either in your mind or in a spec, which is why it is often used in enterprise development. With static typing, you get stronger guarantees from the compiler that your design was translated correctly into code.

Dynamic typing, on the other hand, lends itself better to exploratory programming, where you’re not even sure what the design is. For example, a field named “address” may be a simple string today. Tomorrow, you may discover that a simple string won’t cut it and change the field to point to an object that breaks the address down into component fields. Dynamic typing gives you stronger guarantees that your design works, by giving you immediate runtime feedback without a lot of superfluous typing.

Now, regarding the topic of type inference, I’ve spent quite a bit of time using Haskell, which is another language that uses type inference. I agree that at first, it feels like you’re using a dynamic language, but with some extra sanity checks provided by the compiler. After you do some more exploratory-type programming, though, you’ll soon be reminded that it is not a dynamic language. Taking the example above, say you want to change the type of the “address” field to be an object for the purposes of unit testing the verifyZip() method. You’ll discover that it isn’t an easy process. Not only do you have to change the verifyZip() method to treat the address as an object, you have to change ALL of the other methods/functions that interact with address in order to get the change to even compile. (Then, you have 50/50 chance that the design change doesn’t work well and you have to change it all back.)

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.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 8:53 AM

> People who comment on this debate often sum it up as
> “different strokes for different folks.” Being a developer
> who often swims in both waters, I’ve discovered that the
> reason lies deeper than simple personal preference. It
> depends on what type of programming you are doing.
>
> Static typing lends itself well to programming when you
> already have a good design, either in your mind or in a
> spec, which is why it is often used in enterprise
> development. With static typing, you get stronger
> guarantees from the compiler that your design was
> translated correctly into code.
>
> Dynamic typing, on the other hand, lends itself better to
> exploratory programming, where you’re not even sure what
> the design is. For example, a field named “address” may be
> a simple string today. Tomorrow, you may discover that a
> simple string won’t cut it and change the field to point
> to an object that breaks the address down into component
> fields. Dynamic typing gives you stronger guarantees that
> your design works, by giving you immediate runtime
> feedback without a lot of superfluous typing.

The unfortunate thing, though, is that we obligated to make this decision once for a project. Some areas of enterprise apps are rather exploratory. The business wants to try something in release and if it does work, they want to completely rework it the next time. Going dynamic for that might be good.

On the other hand, I agree that static typing can help when you've settled a design. It can make some refactoring easier. But, it's a two-edged sword. If you have good refactoring tools you can make large changes atomically. If you don't, you have to break a lot of code to do some pervasive changes and you end up approaching these larger refactorings far less incrementally than you would in a dynamically typed language.

To me, all of that points toward the need to be able to be selective about the strength of our guarantees, in the same project, at different points in time. Developers should be able to say "I want to add type annotations here, now that the code as settled." And, "I want to ignore type checking here while I'm doing this large refactoring."

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 9, 2007 8:56 AM

> Dynamic typing, on the other hand, lends itself better to
> exploratory programming, where you’re not even sure what
> the design is. For example, a field named “address” may be
> a simple string today. Tomorrow, you may discover that a
> simple string won’t cut it and change the field to point
> to an object that breaks the address down into component
> fields. Dynamic typing gives you stronger guarantees that
> your design works, by giving you immediate runtime
> feedback without a lot of superfluous typing.
>
> Now, regarding the topic of type inference, I’ve spent
> quite a bit of time using Haskell, which is another
> language that uses type inference. I agree that at first,
> it feels like you’re using a dynamic language, but with
> some extra sanity checks provided by the compiler. After
> you do some more exploratory-type programming, though,
> you’ll soon be reminded that it is not a dynamic language.
> Taking the example above, say you want to change the type
> of the “address” field to be an object for the purposes of
> unit testing the verifyZip() method. You’ll discover that
> it isn’t an easy process. Not only do you have to change
> the verifyZip() method to treat the address as an object,
> you have to change ALL of the other methods/functions that
> interact with address in order to get the change to even
> compile. (Then, you have 50/50 chance that the design
> change doesn’t work well and you have to change it all
> back.)

This is a good concrete example and I'd like to continue with it.

Now, when you say you can change the address to be an Object in the dynamic language without changing the rest of the code, I assume you are making this new object so that it acts like a string object. If this is not what you mean please humor me and clarify a bit.

In Scala, I believe you can get around changing any declarations that refer to the address as a String (mostly method declarations, I would imagine) using implicit conversions. The downside is that the implicit conversions are a bit opaque but not much more so that duck-typing, in my estimation.

In addition, the information provided by static typing allows for automated refactoring of the kind you mention here. The time that it takes to make this kind of change is not significant with these tools.

One reoccurring problem I have in Python is that there are changes that cannot be made without updating calls in other places. For example, if I find that I need to change a method to use a generator instead of returning a list-like type, I have to go and update any calls to the result that uses list methods. In a static-typed language this is easy, and can often be automated. In Python, I use a run-debug, run-debug, cycle until I fix all the code. Perhaps this is just ignorance on my part but this concerns me when contemplating large complex systems written in dynamic languages.

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

Previous Topic

Next Topic