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 ... 6 7 8 9 10 11 12 13 14 ... 25 | » ]

Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: imperative, and functional, and oo, ...

Posted: Jul 10, 2007 11:17 AM

> If it's trivial, why couldn't we automate this process, at
> least to some degree?

We can definitely automate most of it, especially for languages that follow the imperative model. You can definitely imagine a translator that would just use "Object" to type all variables. Of course, it wouldn't compile and a human would have to fix all those by hand after the translation phase.

I was just wondering whether the approach "automate + human fix" is really that much of a gain over having a human translate it manually from scratch, which would allow them to adjust names to the target language guidelines, add comments, create more sensible class hierarchies, etc...

--
Cedric

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: imperative, and functional, and oo, ...

Posted: Jul 10, 2007 11:28 AM

> > If it's trivial, why couldn't we automate this process,
> at
> > least to some degree?
>
> We can definitely automate most of it, especially for
> languages that follow the imperative model. You can
> definitely imagine a translator that would just use
> "Object" to type all variables. Of course, it wouldn't
> compile and a human would have to fix all those by hand
> after the translation phase.

I don't think it would have to be that simplistic. I believe Scala manages to find the 'common denominator' of a number of declarations. The problem I see is that it might makes things too specific but that should be easy enough to manage on a case by case basis. Specifically, when you needed to pass a more general type to a method, you could loosen it.

> I was just wondering whether the approach "automate +
> human fix" is really that much of a gain over having a
> human translate it manually from scratch, which would
> allow them to adjust names to the target language
> guidelines, add comments, create more sensible class
> hierarchies, etc...

Well, that depends on the size and complexity of the code and how good a translator you have. The other things could be done after conversion as refactoring.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: imperative, and functional, and oo, ...

Posted: Jul 10, 2007 12:28 PM

> > There's been a lot of discussion here about the lack of
> > refactoring tools for dynamically typed languages, and
> the
> > amount of confidence we can have in refactoring tools
> for
> > statically typed languages, but ultimately, I think
> that
> > one thing that dynamically typed languages have going
> for
> > them today is ease of testing.
>
> That's an interesting statement.
>
> It seems to me that ease of testing doesn't have much to
> do with the language and everything to do with the
> programmer. A developer who is sensitive to the
> importance of testing will always come up with highly
> testable code, regardless of the language they program
> in.

Yes, it always comes back to programmers but the fact of the matter is, if you have a code base that was started by unenlightened programmers, or tended by unenlightened programmers, recovery is far harder in those languages than it has to be.

> I think that we're seeing more testable Ruby code than
> testable C++ code because Ruby is more recent, and
> developers who use it are part of a more recent generation
> that has been exposed to the importance of testing.

It's more than that. You don't have to retrofit interfaces or abstract classes, or peel final off of classes and methods; and it's easy to replace methods on classes or objects in a test-local way. Recovery is easier.

> Can you think of any features of certain dynamic languages
> that make them inherently more testable than, say, C++?
> (I can't at the moment, but I'll think about it some
> more)

The ones I just mentioned are a short list. Another advantage is turnaround time. Java is a lot better than C++ in this regard. There are systems with module interdependencies that would take months or years of non-stop development effort to fix just because of compile and link time. Dynamically typed languages have Java, C++, and C# beat in this regard.

David Beutel

Posts: 29
Nickname: jdb
Registered: May, 2003

Re: imperative, and functional, and oo, ...

Posted: Jul 10, 2007 12:49 PM

Instead of converting code to a static language, how about filling in types for a language with optional static typing (like ActionScript 3)? No round-tripping required.

And, in addition to basing it on a static analysis, how about the execution environment recording a history of which types have actually been in each variable while running tests?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: an example

Posted: Jul 10, 2007 12:51 PM

James Watson wrote
-snip-
> This would seem to be anecdotal evidence that testing
> doesn't replicate all the benefits of static analysis.

Michael Feathers may assert that type checking is just testing over and over again - but that doesn't make it so :-)

(Incidentally, afaict the real effort in static analysis is taking place developing tools to analyze C programs, for obvious reasons - C doesn't have much of a type system, and there's a lot of C programs.)

Larry Bugbee

Posts: 13
Nickname: bugbee
Registered: Dec, 2004

Inference as an aid to optional typing

Posted: Jul 10, 2007 1:17 PM

Earlier on this thread it was suggested type inference could help, especially if the inference results from a "test" run were saved and became the basis for typing future runs. I don't want to take anything away from those working this problem, but I respectfully suggest this is risky business. What assurances are there that the "test" run is truly representative? It might be representative for 80-90% of the code path, but how does one distinguish the validity of the 90% from the 10%? Sorry, but I believe type inference needs human review.

Okay, what if the "test" run was to insert tentative type declarations back into the [Python] source code and the programmer either blesses or deletes as appropriate. If a type were already declared, the inference engine could flag as a warning/error. And seeing inferred type suggestions unlike what you were thinking could be revealing. Now I have some confidence in the process.

I still go back to optional typing as the "best" blend of static vs dynamic. But having an inference engine insert tentative type declarations would be, perhaps, one way to make optional typing easier. Hmmmm.....

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: imperative, and functional, and oo, ...

Posted: Jul 10, 2007 1:19 PM

> Instead of converting code to a static language, how about
> filling in types for a language with optional static
> typing (like ActionScript 3)? No round-tripping
> required.

That's something that's being done. It's not something I find all that attractive and I don't really think does what Bill Pyne was looking for.

> And, in addition to basing it on a static analysis, how
> about the execution environment recording a history of
> which types have actually been in each variable while
> running tests?

I guess that could be done. But it seems to me (intuitively) that if the type cannot be determined statically for something in the dynamic program, the code for that is unlikely compile as a static program. It's a thought, though.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Inference as an aid to optional typing

Posted: Jul 10, 2007 1:24 PM

> I still go back to optional typing as the "best" blend of
> static vs dynamic.

The problem I imagine would occur with this is that it's up to the individual programmer to decide whether to make it static or not. On group projects this is almost guaranteed to result in inconsistent use of static and dynamic typing.

BTW: Isaac, what's happening with StrongTalk?

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: an example

Posted: Jul 10, 2007 1:25 PM

> Michael Feathers may assert that type checking is just
> testing over and over again - but that doesn't make it so
> :-)

Nothing I say makes things so :-) Regardless, I didn't say that, I said that type checking was a form of testing.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Inference as an aid to optional typing

Posted: Jul 10, 2007 1:31 PM

> Earlier on this thread it was suggested type inference
> could help, especially if the inference results from a
> "test" run were saved and became the basis for typing
> future runs. I don't want to take anything away from
> those working this problem, but I respectfully suggest
> this is risky business. What assurances are there that
> the "test" run is truly representative? It might be
> representative for 80-90% of the code path, but how does
> one distinguish the validity of the 90% from the 10%?
> Sorry, but I believe type inference needs human review.
> .
>
> Okay, what if the "test" run was to insert tentative type
> declarations back into the [Python] source code and the
> programmer either blesses or deletes as appropriate. If a
> type were already declared, the inference engine could
> flag as a warning/error. And seeing inferred type
> suggestions unlike what you were thinking could be
> revealing. Now I have some confidence in the process.
>
> I still go back to optional typing as the "best" blend of
> static vs dynamic. But having an inference engine insert
> tentative type declarations would be, perhaps, one way to
> make optional typing easier. Hmmmm.....

I tend to think so too. I think that someone who is strongly for static typing might argue that it's a bit like a boat with holes (it's not only the hole that gets wet), but all these things are a matter of degree. I think that people who really want static typing should start to care more about null in Java, C++, and C#. Talk about a safety issue.

Larry Bugbee

Posts: 13
Nickname: bugbee
Registered: Dec, 2004

One size fits all?

Posted: Jul 10, 2007 1:53 PM

How quickly we forget.

One group here is looking at production systems, mostly large, and scalability, refactoring, and communication with multiple team members are the major issues. For them static typing seems to work best. I don't argue.

Another group seems to be focusing on smaller apps and prototypes. Only one or perhaps two programmers are involved and economy of expression is important to them. They have gravitated to dynamic. Personally, I count myself in this camp, although my day job involves large-scale enterprise systems.

So why do we have to think one size fits all? There are clearly advantages and disadvantages to each (static and dynamic). Depending on the problem you are trying to solve, choose wisely. ...and optional typing (with inference assistance) would be my choice. YMMV. ;-)

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Inference as an aid to optional typing

Posted: Jul 10, 2007 6:30 PM

James Watson wrote
> BTW: Isaac, what's happening with StrongTalk?

This will ruin any hope of gaining a reputation for omniscience - I haven't the slightest idea ;-)

But Google says - http://groups.google.com/group/strongtalk-general

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

a form of testing

Posted: Jul 10, 2007 6:46 PM

Michael Feathers wrote
> ... I said that type checking was a form of testing.

Any activity could described as "a form of testing" as long as the intent was to test something (in the most general sense) - standing up, biting an apple, ...

I hope within the context of programming we mean something more specific when we say "testing".

Are you talking about testing in the most general sense, or are you specifically talking about unit testing or ...

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: One size fits all?

Posted: Jul 10, 2007 7:18 PM

Larry Bugbee wrote
> So why do we have to think one size fits all?

You seem convinced the split is between statically type checked languages and dynamically type checked languages - perhaps you underestimate the differences within each group.

Are you aware of large scale production systems developed with dynamically type checked languages?

"Four-fold Increase in Productivity and Quality"
http://www.erlang.se/publications/Ulf_Wiger.pdf

"JP Morgan Chase - Kapital"
http://www.cincom.com/pdf/CS040819-1.pdf

Are you aware of rapid prototypes developed with statically checked languages?

"Haskell vs. Ada vs. C++ vs. Awk vs. ..."
http://web.cecs.pdx.edu/~apt/cs457_2005/hudak-jones.pdf

Kirk Pepperdine

Posts: 5
Nickname: kcpeppe
Registered: Jun, 2003

Re: imperative, and functional, and oo, ...

Posted: Jul 10, 2007 11:31 PM

>
> Is there any merit to the possibility of using Python (for
> example) to "sketch out" an idea and then have a converter
> of some kind produce the "go live" code in Scala (for
> example)?

I've watched a couple of teams attempt to automate the process of porting from one language to another. The problem gets quite difficult when you consider features that don't exist in the other. For example I watched a team port from Smalltalk to Java. It was an impressive effort however the amount of hand fixing that had to go on afterwards.. and the code didn't look like "Java". It was a mess. The other attempts that I've seen suffered from similar problems.

The most successful attempts that I seen were to proto-type using a dynamic language and then rewrite using C/C++ (embedded systems).

So it sound good in theory and there maybe a way to make it work in practice but I don't think straight language translation from the source code is the way to go. Maybe there is a combination of execution graphs and source code that could work but I think this would be an extremely complex solution.

Flat View: This topic has 370 replies on 25 pages [ « | 6 7 8 9 10 11 12 13 14 | » ]

Previous Topic

Next Topic