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 ... 18 19 20 21 22 23 24 25 | » ]

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 12:00 PM

Cedric Beust wrote
> I stand corrected. My phrasing was probably too broad,
> and I was just trying to debunk the myth that "the
> Smalltalk browser was already doing all these refactorings
> 20 years ago".
>
> The truth is that it was not, and it could not.
>
> Using an AST to guide a refactoring is certainly a step up
> from doing a string search/replace, but as I showed above,
> there is only so far it can go when it's dealing with a
> tree that doesn't contain any typing information.

imo it's beyond dispute that the availability of type information allows refactoring to be more precise and automatic.

I haven't checked the Ruby example but clearly the claim is that they are also using AST to guide refactoring.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 12:08 PM

James Watson wrote

> Yes, I am talking about 'correct' in the way it's defined
> by the vast majority of English speakers. The definition
> you attempted to apply to 'correct' is circular.

The vast majority of English speakers are not computer programmers, and are presumably unaware of other "terms of art" which we might expect an experienced programmer to understand.

I find it strange that you (like Michael Feathers) prefer the ambiguity of English to less ambiguous technical vocabulary.

> If we define 'correct' to mean that it compiles then
> static typing can prove software to be 'correct'. It
> means nothing.

It would mean that a compiler can show software to be correct (even a Smalltalk compiler).

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 12:50 PM

> I find it strange that you (like Michael Feathers) prefer
> the ambiguity of English to less ambiguous technical
> vocabulary.

I prefer ambiguity to useless oversimplifications. I find it strange that you think defining 'correct' as "passing all tests" to be preferable to the commonly understood "meets all requirements". If we use the 'passes all tests' definition, a program that is not tested is, by definition, correct.

> > If we define 'correct' to mean that it compiles then
> > static typing can prove software to be 'correct'. It
> > means nothing.
>
> It would mean that a compiler can show software to be
> correct (even a Smalltalk compiler).

Yes. You've seem to be getting the idea.

Petrik de Heus

Posts: 19
Nickname: p8
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 2:32 PM

> If you are trying to prove that "if you bypass the Java
> type system, then you end up in the same situation as in a
> dynamically typed language", then... well, duh.
>
> Not sure what you are trying to prove here and how this
> relates to the point I was making about the pitfalls of
> duck typing.

Java doesn't force you to avoid reflection.
Ruby isn't is forcing you to use duck typing.
@animals.each { |a|
raise ArgumentError unless a.is_a? A
a.eat
}
Of course this would still leave the same problem with refactoring in your example.

> Using an AST to guide a refactoring is certainly a step up
> from doing a string search/replace, but as I showed above,
> there is only so far it can go when it's dealing with a
> tree that doesn't contain any typing information.

Ruby is strongly typed so type info is always available.
In your @animals example it knows C is a different type than A and B.
If the Ruby Refactoring Browser knows which types (A, B and C) call the duck-typing method (eat), it would let you make changes by hand (I think it already works like this, as do Java IDE's in the case of reflection).

The Ruby Refactoring Browser could also use your tests in the AST. It could see all types that are assigned to variables (it would sort of use your tests for type inference, I have know idea but I think this is alos how the SmallTalk Refactroing browser works). So if you try to refactor and it's still unclear if it's save to make changes, the browser could give you a warning that you'll need to change it by hand and that you probably missed a test case.

I guess the Ruby Refactoring Browser will get most refactorings right except maybe for the more advanced dynamic stuff. But these are problematic in Java as well (ie. reflection).

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

word games

Posted: Jul 30, 2007 2:38 PM

James Watson wrote
> I prefer ambiguity to useless oversimplifications. I find
> it strange that you think defining 'correct' as "passing
> all tests" to be preferable to the commonly understood
> "meets all requirements".

Where is it commonly understood that 'correct' means "meets all requirements"?

"And the final question is ‘How do we know that the program is in fact correct?’ The theory of programming tells us that this final assurance can in principle be given by mathematical reasoning and proof, guaranteeing that the specifications are a logical consequence of the text of the program." "The ideal of program correctness" Tony Hoare

Programs are verified "correct" against a specification - in contrast, the only way we can validate the program "meets all requirements" is to ask someone "is this what you wanted?".

> If we use the 'passes all tests' definition, a program
> that is not tested is, by definition, correct.

If we apply the same level of absurdity to your suggested definition we will conjure up an equally absurd conclusion.

A program that is not tested is by definition untested.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 2:39 PM

> But these are problematic in Java as well
> (ie. reflection).

We are discussing the pros and cons of dynamic typing vs. static typing. Reflection is how you do dynamic typing in Java. We are not arguing about Java vs. Ruby. Are you having trouble understanding that?

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: word games

Posted: Jul 30, 2007 3:00 PM

> James Watson wrote
> > I prefer ambiguity to useless oversimplifications. I
> find
> > it strange that you think defining 'correct' as
> "passing
> > all tests" to be preferable to the commonly understood
> > "meets all requirements".
>
> Where is it commonly understood that 'correct' means
> "meets all requirements"?

On earth. You should visit sometime.

> Programs are verified "correct" against a specification -
> in contrast, the only way we can validate the program
> "meets all requirements" is to ask someone "is this what
> you wanted?".

The definition of specification that would apply here would be: "precise documentation of requirements." I love that you accused me of 'quarreling over definitions'.

http://www.google.com/search?hl=en&q=define%3A+specification&btnG=Google+Search

* A precise statement of a set of requirements, to be satisfied by a material, product, system or service. It is desirable that the requirements, together with their limits, should be expressed numerically in appropriate units

* The English word specification has a few meanings, or word senses. The Webster's New World Dictionary gives the following meaning: "2 [usually pl.] a)a detailed description of the parts of a whole b) a statement or enumeration of particulars, as to actual or required size, quality, performance, terms, etc. [specifications for a new building]".

* a clear and accurate description of the technical requirements for materials, products, or services including the minimum requirement for materials' quality and construction and any equipment necessary for an acceptable product. In general, specifications are in the form of written descriptions, drawings, prints, commercial designations, industry standards, and other descriptive references.

* Detailed, exact statement of required particulars, especially a statement prescribing the construction, operating environment, functions, performance, or quality of a product

* In engineering and manufacturing, the term specification has the following meanings: An essential technical requirement for items, materials, or services, including the procedures to be used to determine whether the requirement has been met. Specifications may also include requirements for preservation, packaging, packing, and marking. See requirements analysis.

> > If we use the 'passes all tests' definition, a program
> > that is not tested is, by definition, correct.
>
> If we apply the same level of absurdity to your suggested
> definition we will conjure up an equally absurd
> conclusion.

Do you mean, a software application with no requirements is correct? Or more clearly, a software application with no requirements cannot be incorrect. Actually, that makes perfect sense. I wish I could get more people to understand that it is in fact the case.

Petrik de Heus

Posts: 19
Nickname: p8
Registered: Jul, 2007

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 3:02 PM

> > But these are problematic in Java as well
> > (ie. reflection).
>
> We are discussing the pros and cons of dynamic typing vs.
> static typing. Reflection is how you do dynamic typing in
> Java. We are not arguing about Java vs. Ruby. Are you
> having trouble understanding that?

Hmm, I thought the topic was "duh" typing.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 3:09 PM

This thread is getting so long it deserves its own forum.

Who wants to register http://programmingwithduhtyping.org ? :-)

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 30, 2007 3:36 PM

> > > But these are problematic in Java as well
> > > (ie. reflection).
> >
> > We are discussing the pros and cons of dynamic typing
> vs.
> > static typing. Reflection is how you do dynamic typing
> in
> > Java. We are not arguing about Java vs. Ruby. Are you
> > having trouble understanding that?
>
> Hmm, I thought the topic was "duh" typing.

Where '"duh" typing' is type inference in a statically typed language. This is something that Java does not (in general) provide. The discussion has never been about whether Ruby is better than Java. Pointing out that Java also allows dynamic typing is neither here nor there.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 31, 2007 6:23 AM

> I have no doubt that with your level of expertise, you are
> only very rarely a victim of bugs caused by the dynamicity
> of the language you are using. You are most likely very
> thorough in the way you write your tests and you run them
> very diligently at each change.
>
> I maintain that the safety net offered by statically typed
> languages in invaluable for teams of 10, 50, 200
> programmers in projects where literally, tens of thousands
> of lines of code are checked in every day and where
> functional tests take entire days to run.

Even in this case, the usefulness of static type checking is limited. The functional tests have to cover 100% of the requirements as well, just like in smaller projects.

In fact, the bigger the project, the bigger the need for testing.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 31, 2007 6:24 AM

> > > Is that a practical approach across all of software
> > > development or only in particular situations?
> > >
> > > Wouldn't it depend on the risks / losses (including
> > user
> > > opportunity cost) of something going wrong?
> > >
> > > When might it be practical, when might it not?
> > >
> > > Would your opinion be different if you the programmer
> > were
> > > liable for user losses?
>
> Achilleas Margaritis wrote
>
> > Is there such a case out there? most programs contain
> an
> > EULA which relieves the developer from any
> responsibility.
>
> When you answer 4 questions with a question, it seems to
> me that you are far more interested in stating that your
> view is correct than thinking about when it might not be
> correct.

I am asking only because I haven't seen a software license that admits liability. Has anyone seen such a license?

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 31, 2007 6:30 AM

> If you've paid attention, the primary arguments, at least
> as posed by myself and James Watson, have been centered
> around how static typing saves time by:
> (1) Catching typos
> (2) Automating Refactoring
> (3) Increasing code clarity

And my replies to those arguments are:

(1) it's irrelevant because type errors in a dynamic system will be caught by the tests

(2) nothing that a good search & replace function can not do

(3) not really, especially in languages where lots of interfaces are involved (so you always see the interface, but not the implementation).

>
> If I mispell a function name in a dynamic language, I have
> to wait until something causes that codepath to be
> executed before I find that error. Yes, eventually it
> will be found. But it can take a long time to do it.

It seems to me that not all people run their code 100% all the time. If that is the case, then certainly, you are correct.

>
> Also, you have to remember that a lot of programming may
> go into a piece of software during system concept
> development before it becomes millions of lines of Ada.
>
> So let's say a systems engineer thinks he has a brilliant
> new nueral network architecture to use to distinguish
> troop transports from school buses. Long term the NN may
> be in software, an FPGA, an ASIC, or even some hybrid
> approach. But for now the engineer wants to figure out if
> it will actually work, so he codes it up in his favorite
> language and sets it to work on training data.
>
> A day and a half later the thing bombs out because in a
> rarely executed branch he typed inptu_vector instead of
> input_vector.
>
> That's not exactly fun...

So you mean the code that bombs out was not tested?

oh, the horror! :-)

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: Programming with "Duh" Typing

Posted: Jul 31, 2007 6:34 AM

> You being pretty forgiving by addressing only the point
> that Achilleas wants to argue.
>
> What he keeps avoiding is addressing the other parts of
> our argument. Most of the life of an application will be
> spent in maintenance and I believe that most of the cost
> of an application is in maintenance and enhancements.

Dynamic typing can make maintenance faster: you run the program, you pause it, you modify it, and when the results are satisfactory, you run the tests and if the tests are successful you release the code.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Programming with "Duh" Typing

Posted: Jul 31, 2007 6:48 AM

> I am asking only because I haven't seen a software license
> that admits liability. Has anyone seen such a license?

Noted, but I think it was a hypothetical question.

Flat View: This topic has 370 replies on 25 pages [ « | 18 19 20 21 22 23 24 25 | » ]

Previous Topic

Next Topic