The Artima Developer Community
Sponsored Link

Weblogs Forum
To type or not to type

17 replies on 2 pages. Most recent reply: Mar 16, 2004 1:39 AM by Gregg Wonderly

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 17 replies on 2 pages [ « | 1 2 ]
Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: To type or not to type Posted: Mar 4, 2004 5:57 PM
Reply to this message Reply
Advertisement
> > How do unit tests help avoid errors?
When you write the tests first, you must think through the methods that you are testing, before you write them
So we're talking about programmer tests in TDD - rather than unit tests in general?

Don't we always have to "think through the methods" before we write them?

Any errors covered by those test cases have been avoided
This claim is quite odd given that the first TDD step is to make the "programmer test" fail - so much for avoidance.


> > How do unit tests let you see what is going on in the code?
Every action that can be performed in the code is performed *first* in a unit tests. The unit tests are living examples of how to use the code
It's not clear to me now what the original claim "types let you see..." really means.


> > How do unit tests give you important structure?
In order to test a unit you must isolate it from other units. Therefore you must manage the dependencies surrounding that unit to keep it isolated
So like any other concrete use, writing "programmer tests" would tell us something about how well the code was structured - but how do tests "give ... important structure".

Again, it's not obvious to me now what additional structure static-checking provides over dynamic-checking.

If you want to know the "types" of the input variables or the "types" of the return values, or the "types" of the associated objects, the tests will tell you
So the "programmer tests" must provide exhaustive coverage of each parameter type (and subtype) and result type?

phil jones

Posts: 14
Nickname: interstar
Registered: Apr, 2003

Re: To type or not to type Posted: Mar 7, 2004 10:33 AM
Reply to this message Reply
Not much success in avoiding the war, huh? :-)

But let's get back to the original assertion which could be phrased : "People argue about types because different people need different things. And they're tacitly talking about the kind of people they are and the kind of projects they work on."

Now, this is obviously true. In a sense these arguments are a kind of politics. Compare : "some people like government to tax economic activity and spend the money on welfare and protecting worker's rights, and some people don't".

When people argue about politics, they are often asserting the kind of person they are, and the kind of project they are working on (ie. the economic "class" they belong to.)

But the real reason people argue this, *isn't* because they like talking about themsleves. The reason is that if they DON'T argue, then there's an increased danger that the other world-view will seize control of the state and impose their preferences it.

In the same way, we argue about types because people are always trying to foist projects and the use of languages which accord to the opposite world view on us. If we don't try to defend our view, these people will sell languages based on the opposite principles to our employers, and our educators and our customers, and we will be forced to live with them.

Sideswipe : I also can't help noticing you work for the company which has had been most pernicious in using the "one language fits all" message as a marketing strategy. Perhaps you could advocate some of this pluralism in Sun. When are we going to get Self (which Sun invented) or TCL (which it bought) pushed as assiduously as Java? :-)

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: To type or not to type Posted: Mar 16, 2004 1:39 AM
Reply to this message Reply
> Getting back to Jim's original post - his assertion that
> strong statically typed languages are slower to develop
> rapid prototypes in - I think is also missing the point.
> The key to developing code rapidly is using a programming
> language with fewer average lines of code per function
> point (e.g. Perl, Smalltalk, ML) than ones with more (e.g.
> C, C++, Java). Most research that I know of (McConnell in
> Rapid Development is a great summary) says that average
> programmers write the same number of lines of code a day,
> regardless of the programming language. So choose one
> which has fewer lines and you'll develop faster. Other
> than that, I thought Jim's analysis was great.

I think it really depends on what you call the language. Your basic comment here, says to me, that you would never consider a library, or a platform (Java is a platform not a language) provided capability as a simplifying capability.

All languages end up with a certain platform of capabilities that are typically tied to a version of the language/platform. Languages which have a single source tend to have more features that are 'standard' than languages which are designed by committed and sold by the masses. C and C++ have hardly anything beyond basic math and programming constructs that you can rely to be present on every OS that you might try to run such a program on. Posix provides a set of functions with standard interfaces to operating system provided capabilities. There is essentially no standard for GUI display control in C or C++ because there is no 'platform'. C and C++ have a huge number of libraries for a wide range of things that you can get/buy. It is typically possible (ignoring cost of purchase) to get a wide range of C/C++ software with no effort for nearly any project you might imagine.

Perl and Python have tons of libraries that are widely varied in what they do as well. The big issue is that you ahve to look everywhere and integrate everything to get a platform to base your application on. The next release of your application will likely require a reintegration effort to get the best version of all the modules you found back together and to create/adapt tests.

Java's platform is provided by the vendor. The platform has a spec, and all the vendors have to meet the spec. So, any place you take Java code, you'll find the same functionality. There might be bugs, but the spec says what you can depend on, and you can hold that up to your JVM vendor.

Microsoft's languages in the .NET environment with the whole managed code business present a similar guarantee. You'll get the same environment everywhere (well, everywhere where the OS can run).

Productivity in any of these environments will depend on the stability of the platform/language, and your abilities to create any new Application Oriented Meta language representation in your API that makes it simple to create your app.

Most people don't write code to draw a line by having explicit pixel manipulations everywhere such as

setPixel(ctx, 1, 2);
setPixel(ctx, 1, 3);
setPixel(ctx, 1, 4);
setPixel(ctx, 1, 5);

instead, there is a functional line drawing capability

drawLine( ctx, 1, 2, 1, 5 );

Graphics drawing is such old hat, that all these things are well known, and always provided. In a new application domain, you might have to create the primatives that support the language that you'll use to describe the program structure that will make your work easy.

For all intents and purposes, there is no language, that if it can solve a particular class of problem, could not represent that solution as a single line of code!

This is the point that you have to grasp. It's not about fewer lines of code. It's not about consiseness of expression. It's only about the possibility of expressing a solution in a structure that is maintainable (based on the life cycle of the software), and existing as a code which is capable of providing a valid execution model for the needed solution.

Static typing has to be changed to make the program compile, and thus be executable. With untyped, or dynamicly typed languages, and TDD, tests are written to conclusively prove that the program is not broken. For me, these are dramtically different situations.

Flat View: This topic has 17 replies on 2 pages [ « | 1  2 ]
Topic: How Mortal These Fools Be... Previous Topic   Next Topic Topic: One Assertion Per Test


Sponsored Links



Google
  Web Artima.com   

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