The Artima Developer Community
Sponsored Link

Weblogs Forum
Programming with "Duh" Typing

370 replies on 25 pages. Most recent reply: Aug 8, 2007 12:54 PM 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 ... 7 8 9 10 11 12 13 14 15 ... 25  | » ]
Cedric Beust

Posts: 140
Nickname: cbeust
Registered: Feb, 2004

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 2:37 AM
Reply to this message Reply
Advertisement
> I'd also be interested in any thoughts on this. I have a
> lot of experience with testing Java; my company has around
> 32,000 unit tests (= 32,000 test methods, not test
> classes), and as the number of tests have gotten larger
> it's become more and more of a maintenance issue.

In my experience, this problem is more caused by limitations of the testing framework than the language itself (one of the reasons why I created TestNG in the first place). For example, test groups have helped used immensely in bringing some kind of order in their testing code base.

If you are not familiar with TestNG, I'd be curious to hear from you if you think it could solve some of your testing problems (http://testng.org).

Either way, I'd be interested to know more about your test code base maintenance problems, but we should probably take this offline since this is not the topic of this thread.

Unless, of course, you have come up with a few ideas on how a different programming language could have avoided these problems in the first place...

--
Cedric

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 9:02 AM
Reply to this message Reply
> >
> > 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.

That's why I was thinking that to do this well, you'd need basically two versions of the same language. One that was dynamic and another that was static. This should be possible, I think, given that it's possible to have optional typing. Outside of the typing, the features would be the same so that the resulting code would look like the original code with type declarations.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: One size fits all? Posted: Jul 11, 2007 9:16 AM
Reply to this message Reply
> Isaac wrote-
>
> You seem convinced the split is between statically type
> checked languages and dynamically type checked languages -
> perhaps you underestimate the differences within each
> group.

I think part of the reason that this debate is difficult is that often two languages are compared that have very different features. For example, I prefer Python to Java for certain things but I'm not sure that dynamic typing is why. It's nice to not have to declare types for sure (although I sometimes look back at code I wrote and have no idea what it does) but the real productivity gains (for me) come from the ability to pass functions as arguments and declare nested methods and the functional features that the language provides. So comparing Java to Python is not just comparing dynamic to static. It's an apples to oranges comparison.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 9:23 AM
Reply to this message Reply
> > 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.
>
> That's why I was thinking that to do this well, you'd need
> basically two versions of the same language. One that was
> dynamic and another that was static. This should be
> possible, I think, given that it's possible to have
> optional typing. Outside of the typing, the features
> would be the same so that the resulting code would look
> like the original code with type declarations.

There's another possibility also. The type declarations could be put someplace else. Take a look a the proposal I have at the end of this blog: http://www.artima.com/weblogs/viewpost.jsp?thread=155960

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 9:45 AM
Reply to this message Reply
> There's another possibility also. The type declarations
> could be put someplace else. Take a look a the proposal I
> have at the end of this blog:
> http://www.artima.com/weblogs/viewpost.jsp?thread=155960

It's viable. I guess I'm not sure of the advantage. It kind of seems like you just don't 'like' seeing the types in the source. Type inference as implemented in Scala pretty much eliminates this excepting method declarations. Are the types in the method declarations still too much for you?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: One size fits all? Posted: Jul 11, 2007 9:57 AM
Reply to this message Reply
James Watson wrote
> the ability to pass functions as arguments
> and declare nested methods and the functional features
> that the language provides. So comparing Java to Python
> is not just comparing dynamic to static. It's an apples
> to oranges comparison.

ceteris paribus? who do we think we're kidding? :-)

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 10:01 AM
Reply to this message Reply
> 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'm not sure why you would want to do that. The purpose of any of these high level languages is to enable humans to instruct computers. Why translate your source code into a second human readable language before translating it into computer code?

If the code in the initial language was too 'loose' then it would not be possible to 'tighten' the code in the second language. Simply because information missing in the source cannot be conjured out of thin air and inserted into the translation. Thus, the translation cannot be more precise than the original; At best it can match it.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 10:11 AM
Reply to this message Reply
> > 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'm not sure why you would want to do that. The purpose
> of any of these high level languages is to enable humans
> to instruct computers. Why translate your source code
> into a second human readable language before translating
> it into computer code?

For the same reason a potter bakes his creations in a kiln only after he has created the form that he desires.

> If the code in the initial language was too 'loose' then
> it would not be possible to 'tighten' the code in the
> second language. Simply because information missing in
> the source cannot be conjured out of thin air and inserted
> into the translation. Thus, the translation cannot be
> more precise than the original; At best it can match it.

The information would not have to be conjured out of thin air. The the type information that is in the source but scattered throughout it would be centralized in a way that a human can find it easily.

In addition the information that could not be determined automatically (or any problems that are found) would be resolved by the human operator making it possible for the machine to 'understand' the structure.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 10:15 AM
Reply to this message Reply
> > There's another possibility also. The type
> declarations
> > could be put someplace else. Take a look a the proposal
> I
> > have at the end of this blog:
> >
> http://www.artima.com/weblogs/viewpost.jsp?thread=155960
>
> It's viable. I guess I'm not sure of the advantage. It
> kind of seems like you just don't 'like' seeing the types
> in the source. Type inference as implemented in Scala
> pretty much eliminates this excepting method declarations.
> Are the types in the method declarations still too much
> h for you?

It's not that, really. It's the fact idea that different programs or contexts could have different constraints for the same base code. Rather than having, say, generics, you could have a code that appears naked of type annotations and add them on a context by context basis to tighten up the checking. I'd imagine that if a language was implemented this way, you'd probably want an IDE option where you saw the annotations in the source regardless of the fact that they are held elsewhere.

Beyond that, I think that there are other powerful things that could be enabled by having a simple base language and annotations held elsewhere. People could write their own specific type rules, like, for instance, this class can never be held as an instance of that class. Or, no class in this package can have a dependency on a class in this package. This blurs the line between testing and typing a bit. You can programmatically add constraints on particular methods or constraints on an entire program.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 10:28 AM
Reply to this message Reply
> It's not that, really. It's the fact idea that different
> programs or contexts could have different constraints for
> the same base code. Rather than having, say, generics,
> you could have a code that appears naked of type
> annotations and add them on a context by context basis to
> tighten up the checking. I'd imagine that if a language
> was implemented this way, you'd probably want an IDE
> option where you saw the annotations in the source
> regardless of the fact that they are held elsewhere.

I had considered that might be one of the goals. I didn't see it in your initial post though. I may have missed it. I agree that the IDE would definitely be a necessity. I;m not sure if the code would be understandable in a large program, however, without it. Personally, I am wary of languages with source that cannot be easily read without an interpreting tool to the point of dismissing them, regardless of how robust the tooling may be.

Another concern would be whether this form of code reuse would actually be realizable. This idea seems reminiscent of AOP (which I'm not that familiar with) in one aspect. It also seems to be a lot like the basic ideas behind OO design that are often not realized.

> Beyond that, I think that there are other powerful things
> that could be enabled by having a simple base language and
> annotations held elsewhere. People could write their own
> specific type rules, like, for instance, this class can
> never be held as an instance of that class. Or, no class
> in this package can have a dependency on a class in this
> package. This blurs the line between testing and typing a
> bit. You can programmatically add constraints on
> particular methods or constraints on an entire program.

All of this is very provocative and I don't mean to be dismissive of them. Have you made made any attempt to create such a language; perhaps as a mod on an existing one?

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

other tools Posted: Jul 11, 2007 10:38 AM
Reply to this message Reply
> > > 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'm not sure why you would want to do that. The
> purpose
> > of any of these high level languages is to enable
> humans
> > to instruct computers. Why translate your source code
> > into a second human readable language before
> translating
> > it into computer code?
>
> For the same reason a potter bakes his creations in a kiln
> only after he has created the form that he desires.

A couple of comments
- when we talk at this general level its really easy to completely misunderstand what's meant
- and it feels a little like when the only tool you have is a hammer, everything looks like a nail: we have other tools besides programming languages

1) When we want to "sketch out" an idea maybe that's exactly what we should do!

"Sketching is not only the archetypal activity of design, it has been thus for centuries." http://billbuxton.com/

2) We might consider working with checkable subsets of standard English http://attempto.ifi.unizh.ch/site/

3) We might interactively work out the properties of our software design with an analysis tool http://alloy.mit.edu/

...

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 10:46 AM
Reply to this message Reply
> > It's not that, really. It's the fact idea that
> different
> > programs or contexts could have different constraints
> for
> > the same base code. Rather than having, say, generics,
> > you could have a code that appears naked of type
> > annotations and add them on a context by context basis
> to
> > tighten up the checking. I'd imagine that if a
> language
> > was implemented this way, you'd probably want an IDE
> > option where you saw the annotations in the source
> > regardless of the fact that they are held elsewhere.
>
> I had considered that might be one of the goals. I didn't
> see it in your initial post though. I may have missed it.
> I agree that the IDE would definitely be a necessity.
> . I;m not sure if the code would be understandable in a
> large program, however, without it. Personally, I am wary
> of languages with source that cannot be easily read
> without an interpreting tool to the point of dismissing
> them, regardless of how robust the tooling may be.

The difference with this, though, is that the base language just looks like a dynamically typed language. It should be complete in the sense that you can imagine it executing and see the complete algorithm. The annotations in another file would really act as constraints which disallow certain conditions at compile or load time. They would not add functionality.

> Another concern would be whether this form of code reuse
> would actually be realizable. This idea seems reminiscent
> of AOP (which I'm not that familiar with) in one aspect.
> It also seems to be a lot like the basic ideas behind OO
> O design that are often not realized.

I wonder about the code reuse also. It may be that it is not realizable.

> > Beyond that, I think that there are other powerful
> things
> > that could be enabled by having a simple base language
> and
> > annotations held elsewhere. People could write their
> own
> > specific type rules, like, for instance, this class can
> > never be held as an instance of that class. Or, no
> class
> > in this package can have a dependency on a class in
> this
> > package. This blurs the line between testing and typing
> a
> > bit. You can programmatically add constraints on
> > particular methods or constraints on an entire program.
>
> All of this is very provocative and I don't mean to be
> dismissive of them. Have you made made any attempt to
> create such a language; perhaps as a mod on an existing
> one?

Unfortunately, no. Gilad Bracha wrote a while ago about "pluggable type systems" and there has been some research about them, but I haven't kept up. If I remember correctly, one of the systems is called JavaCOP and there was a paper at OOPSLA.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: other tools Posted: Jul 11, 2007 11:45 AM
Reply to this message Reply
> A couple of comments
> - when we talk at this general level its really easy to
> completely misunderstand what's meant
> - and it feels a little like when the only tool you
> have is a hammer, everything looks like a nail
: we
> have other tools besides programming languages
>
> 1) When we want to "sketch out" an idea maybe
> that's exactly what we should do!
>
> "Sketching is not only the archetypal activity of
> design, it has been thus for centuries."

> http://billbuxton.com/

I do it all the time on paper or a whiteboard but the work of translating the ideas to code often requires a lot of high-level rethinking. When I look at my original designs compared to what I end up doing, it's often different. I don't think this is unique to software. Architectural blueprints are rarely exactly representative of the final building, from what I understand.

There was a recent recording of Gershwin's Porgy and Bess that is based on recently discovered music from the initial performances. It's different in a number of ways (some substantial) from the sheet music that was published prior to the show.

> 2) We might consider working with checkable subsets of
> standard English http://attempto.ifi.unizh.ch/site/

I don't think this is really different than a programming language. On a side note, wasn't kind of the idea behind COBOL?

> 3) We might interactively work out the properties of our
> software design with an analysis tool
> http://alloy.mit.edu/

I've looked at Alloy after reading about it in Scientific American. In the end this is another programming language. It's odd to me that this language aims to test a design but doesn't make any attempt to bridge the gap between design and working code.

To me, programming is primarily a design exercise interspersed with technical problems. A good high-level programming language gets me closer and closer to a design language. To me, designing in one place and then replicating it in another by hand is no less misguided than printing out one document and typing the text into another.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: imperative, and functional, and oo, ... Posted: Jul 11, 2007 11:50 AM
Reply to this message Reply
> The difference with this, though, is that the base
> language just looks like a dynamically typed language. It
> should be complete in the sense that you can imagine it
> executing and see the complete algorithm. The annotations
> in another file would really act as constraints which
> disallow certain conditions at compile or load time. They
> would not add functionality.

I guess when I look at your example, I have to question that. For example, you specify that successors and words are hash-based dictionaries. A hash-based dictionary can have subtle differences in behavior from a sorted dictionary especially depending on the types being placed in it. In general, any polymorphic language will allow a given operation to behave in different ways. So specifying the type could change the code especially since there would be nothing to prevent the developer from exploiting polymorphism in this way.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: other tools Posted: Jul 11, 2007 12:10 PM
Reply to this message Reply
James Watson wrote
> I do it all the time on paper or a whiteboard but the work
> of translating the ideas to code often requires a lot of
> high-level rethinking. When I look at my original designs
> compared to what I end up doing, it's often different. I
> don't think this is unique to software.

Maybe you stop sketching too soon? ;-)

Talking at this level of generality gains us nothing - we need to ground discussion in concrete detail.


> > 2) We might consider working with checkable subsets of
> > standard English http://attempto.ifi.unizh.ch/site/
>
> I don't think this is really different than a programming
> language.

It is a language and the logic can be checked but that's about all it has in common with programming languages.


> > 3) We might interactively work out the properties of
> our
> > software design with an analysis tool
> > http://alloy.mit.edu/
>
> I've looked at Alloy after reading about it in Scientific
> American. In the end this is another programming
> language. It's odd to me that this language aims to test
> a design but doesn't make any attempt to bridge the gap
> between design and working code.

I don't wish to put words into your mouth, it seems like you're saying you don't understand the value of abstraction?


> To me, programming is primarily a design exercise
> interspersed with technical problems. A good high-level
> programming language gets me closer and closer to a design
> language. To me, designing in one place and then
> replicating it in another by hand is no less misguided
> than printing out one document and typing the text into
> another.

Should we design a house by clearing ground and piling up bricks? Abstraction! :-)

Flat View: This topic has 370 replies on 25 pages [ « | 7  8  9  10  11  12  13  14  15 | » ]
Topic: Programming with "Duh" Typing Previous Topic   Next Topic Topic: Python 3000 Plea for Help


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2017 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us