Weblogs Forum - A Type System is a Set of Tests

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
A Type System is a Set of Tests

73 replies on 5 pages. Most recent reply: Apr 26, 2006 4:08 AM by Achilleas Margaritis

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 73 replies on 5 pages [ « | 1 ... 2 3 4 5 ]

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: A Type System is a Set of Tests

Posted: Apr 25, 2006 10:00 AM

> Michael Feathers wrote
> -snip-
> > Programs are far more liable to crash with null pointer
>
> > exceptions.
> >
> > If the true concern is not having programs crash, then
> > language designers should have dealt with the null
> issue
> > earlier. As it stands, I only know of the Nice
> language
> > and some halfway features in C# 2.0 that attempt to
> tackle
> > this.
>
> Just to beat this flat, I'll join Vesa Karvonen in saying
> language designers did deal with the null issue earlier,
> using static type checking - see Haskell & Clean.

True enough. I should've said the designers of mainstream languages, and in fact I did until I accidently hit back while I was replying and I had to retype my reply. :(

> (Ada is so large that I'm never sure what it does or does
> not provide, but if non-null pointer types were not
> already available in some form then they clearly will be
> available in Ada 2006. iirc C#2.0 adds nullable value
> types, it does not add non-null reference types.)
>
> > In most dynamically typed languages it's very easy to
> > avoid crashes on null dereferences and do something
> better
> > than just catching at the top level of your program:
> you
> > subclass null provide your own behavior. I suspect
> that
> > the reason most designers of statically typed languages
> > don't allow this is because they are scared of giving
> > developers that much control.
>
> Another day, another conspiracy theory? :-)
>
> Michael, would you say that most designers of dynamically
> type checked languages don't provide explicit type
> declarations because they are scared of giving developers
> that much control?
>
> imo that would just be an attempt to divert a discussion
> of technical merits by demonizing people with a different
> viewpoint.

If you want to see demons, see demons. I just said that I felt that they were scared of doing it. Sometimes fear is justified. Many language designers are very explicit about the fact that they restrict language features to prevent misuse. For what it's worth, I don't think that's a conspiracy. ;)

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: A Type System is a Set of Tests

Posted: Apr 25, 2006 10:56 AM

Michael Feathers wrote
-snip-
> If you want to see demons, see demons. I just said that I
> felt that they were scared of doing it. Sometimes fear is
> justified. Many language designers are very explicit
> about the fact that they restrict language features to
> prevent misuse.

Do you have any examples of language designers being very explicit that they haven't included non-null typing because they fear misuse?

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: A Type System is a Set of Tests

Posted: Apr 25, 2006 11:04 AM

language designers should have dealt with the null issue earlier ... I should've said the designers of mainstream languages

To design a mainstream language is to maintain backward compatibility. To deal with language issues is to break backward compatibility. You figure that out.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: A Type System is a Set of Tests

Posted: Apr 25, 2006 11:19 AM

> language designers should have dealt with the null
> issue earlier ... I should've said the designers of
> mainstream languages
>
> To design a mainstream language is to maintain backward
> compatibility. To deal with language issues is to break
> backward compatibility. You figure that out.

I don't think I agree with that. Backwards compatibility isn't such a big issue when you design a new language. For some communities, maybe. It seems like many people have done whatever it takes to make their language look like C.

For what it's worth, I agree that functional programming languages have a lot of these things under control. It's just a shame that they aren't mainstream and it doesn't look like there is a great bridge over to them from the dominant languages we have today.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: A Type System is a Set of Tests

Posted: Apr 25, 2006 12:06 PM

-snip-
> It seems like many people have done whatever it takes to
> make their language look like C.

Yes, and with reason:

"On the surface, however, neptune is much closer to C++ or Java. Basic things like variable declarations, control structures, operators and literals will all be familiar to a C++ or Java programmer. When learning the language this means people will be able to use much of what they already know and will be able to be productive almost immediately..."
http://blog.quenta.org/2006/04/why-neptune.html

"We think that C programmers will have little trouble adapting to our dialect and will find Cyclone to be an appropriate language for many of the problems that ask for a C solution."
Cyclone: A Safe Dialect of C
http://www.research.att.com/projects/cyclone/

On the non-null topic 'we have extended Cyclone with a new kind of pointer, called a "never-NULL" pointer'.

> For what it's worth, I agree that functional programming
> languages have a lot of these things under control. It's
> just a shame that they aren't mainstream and it doesn't
> look like there is a great bridge over to them from the
> dominant languages we have today.

iirc towards the end of this interview Anders Hejlsberg acknowledges the influence of functional programming languages on LINQ
http://channel9.msdn.com/ShowPost.aspx?PostID=159952

and Erik Meijer frequently proclaims that "Functional Programming Has Reached The Masses; It's Called Visual Basic" :-)
http://lambda-the-ultimate.org/node/1406

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

Re: A Type System is a Set of Tests

Posted: Apr 25, 2006 12:50 PM

> > To design a mainstream language is to maintain backward
> > compatibility. To deal with language issues is to break
> > backward compatibility. You figure that out.
>
> I don't think I agree with that.

I meant backward compatibility in a very broad sense starting with "paradigm compatibility", so that programmers don't have to learn (m)any new ways to design software.

> Backwards compatibility isn't such a big issue when you
> design a new language.

I have to disagree. Backward compatibility, in a broad sense, is a huge issue.

One form of backward compatibility these days seems to be single dispatch OO. Many of the mainstream languages are based on single dispatch OO and vast masses of programmers have been trained to design software under that paradigm and scoff at anything else. How can anything be done without inheritance?

Another popular form of backwards compatibility is to run on the JVM, so that Java libraries can be used easily.

> For some communities, maybe. It seems like many people
> have done whatever it takes to make their language look
> like C.

Control structures such as while and for are also a form of backward compatibility. Provide those and convenient syntax for imperative programming (implicitly mutable variables) and you've not only copied the syntax, but also the essense of the semantics.

There are many many more examples of "backward compatibility" like the above and maintaining backwards compatibility always has a cost. For instance, if you want to run on the JVM, it will likely make proper tail call optimization extremely difficult if not impossible. This means that you are then pretty much stuck within the imperative for-loop paradigm.

> For what it's worth, I agree that functional programming
> languages have a lot of these things under control. It's
> just a shame that they aren't mainstream and it doesn't
> look like there is a great bridge over to them from the
> dominant languages we have today.

What kind of bridge do you mean/want?

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Good programming practice needed, not exotic language features

Posted: Apr 25, 2006 1:58 PM

Michael Feathers:
I like working with programmers who write a bit of code and then ask themselves "is there some simpler way of doing this?" If the answer is yes, they stop and redo it before going on. I think that filling in the types after working dynamically would be just like this, and it is just like the "Fast Green Bar" rule in TDD. The thing that is sad, is that there are so many programmers who never revisit a line of code after they have typed it. They don't sketch the contours, they start at the corner of the page and try to move outward in elaborate detail.

Do you have any evidence that programmers are more likely to adopt this programming style - to revisit and refactor code as they go - when working in a dynamic rather than a statically typed language? I would say that this is (or should be) good practice in whatever language you use. I am frequently confronted with code that has been crafted in the copy/paste method. A coder takes code from some place where something similar is being done, pastes it and makes some modifications. A competent programmer would, of course, recognize that if something similar is done at different places, the code should be normalized and thus be made much cleaner and easier to maintain. What is at fault here is the programmer and not the language. Let's face it, most programmers are limited by their own programming skills and not by the flexibility or expressivity of the language they happen to use (and for obvious reasons this is especially true in widely used languages). Let's also not forget that programmers need an open and critical mind in order to be able to question and improve their own code, something that I'm afraid is not being taught in many language 101s.

I doubt that pluggable types or whatever magic language features you may invent will have any impact on bad programming practice. May I heretically suggest that most of the PL discussions going on (often fervently) on sites like this are strictly irrelevant.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Good programming practice needed, not exotic language features

Posted: Apr 25, 2006 3:55 PM

> Do you have any evidence that programmers are more likely
> to adopt this programming style - to revisit and refactor
> code as they go - when working in a dynamic rather than a
> statically typed language? I would say that this is (or
> should be) good practice in whatever language you use. I
> am frequently confronted with code that has been crafted
> in the copy/paste method. A coder takes code from some
> place where something similar is being done, pastes it and
> makes some modifications. A competent programmer would, of
> course, recognize that if something similar is done at
> different places, the code should be normalized and thus
> be made much cleaner and easier to maintain. What is at
> fault here is the programmer and not the language. Let's
> face it, most programmers are limited by their own
> programming skills and not by the flexibility or
> expressivity of the language they happen to use (and for
> obvious reasons this is especially true in widely used
> languages). Let's also not forget that programmers need an
> open and critical mind in order to be able to question and
> improve their own code, something that I'm afraid is not
> being taught in many language 101s.
>
> I doubt that pluggable types or whatever magic language
> features you may invent will have any impact on bad
> programming practice. May I heretically suggest that most
> of the PL discussions going on (often fervently) on sites
> like this are strictly irrelevant.

I get you, but my interest in this is mostly selfish. I was thinking about the type of language I'd like to program in. Doubtless, languages have some influence on the way people program, but I agree with you, programmers and their practices can build upon or subract from just about anything a language can offer.

Now, that said, I do feel strongly that today's languages make recovery too hard. They are biased toward ease of expression and correctness of program construction. Nobody seems to be looking at it from the other point of view, which is: okay, someday we'll have projects with ten million lines of code written in this language. What language features would make it easier to clean up? What features would get in the way?

I've seen programming language designers ask what it takes to do programming in the large, but not recovery in the large.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Good programming practice needed, not exotic language features

Posted: Apr 25, 2006 4:32 PM

> okay, someday we'll have
> projects with ten million lines of code written in this
> language. What language features would make it easier to
> clean up? What features would get in the way?

I'm not sure what you mean by recovery - recovery from error in a running program? recovery of design intent from an existing code base?

Do you have a concrete example.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Good programming practice needed, not exotic language features

Posted: Apr 25, 2006 4:53 PM

> > okay, someday we'll have
> > projects with ten million lines of code written in this
> > language. What language features would make it easier
> to
> > clean up? What features would get in the way?
>
> I'm not sure what you mean by recovery - recovery from
> error in a running program? recovery of design intent from
> an existing code base?
>
> Do you have a concrete example.

The latter, really. Once entropy gets the upper hand, how easy is it to recover. We've been writing refactoring tools.. but I think it's time to ask: what makes it easy and what makes it hard? We should ask the same set of questions wrt testing. If a system doesn't have tests, is there anything that a language is doing to make it easy or hard to get them in after the fact.

I can't point to a specific example, but the problem is so pervasive, I don't think I need to. Just look at any average code base.

Erik Engbrecht

Posts: 210
Nickname: eengbrec
Registered: Apr, 2006

Redefining Null

Posted: Apr 25, 2006 5:02 PM

>In most dynamically typed languages it's very easy to avoid crashes on null dereferences and do something better than just catching at the top level of your program: you subclass null provide your own behavior.

Which one(s)? I just tried Python and it didn't work. I didn't think it would.

Vesa Karvonen

Posts: 116
Nickname: vkarvone
Registered: Jun, 2004

"average" is jargon for "incompetent"

Posted: Apr 25, 2006 10:57 PM

I like working with programmers who write a bit of code and then ask themselves "is there some simpler way of doing this?" If the answer is yes, they stop and redo it before going on.

Michael, based on this criteria, you'd like working with me. ;-)

I think that filling in the types after working dynamically would be just like this, and it is just like the "Fast Green Bar" rule in TDD.

I doubt it would happen. Why would a programmer who never revisits his code break habit to add type annotations after getting his code to run without crashing immediately?

The thing that is sad, is that there are so many programmers who never revisit a line of code after they have typed it. They don't sketch the contours, they start at the corner of the page and try to move outward in elaborate detail.

Yeah. I wish I could tell you in more detail, but that is so true.

I think that a huge problem in our field (programming / software engineering) is that it is too easy to start. Anyone can write a "Hello, world!" program and, sadly, after doing it, many people seem to think that they are competent programmers. I've seen many "programmers" who never really read books about programming techniques. They barely know how to use for-loops and actually don't use them in many cases where they would actually simplify things. The complexity (eloborate detail) of the designs (code) they produce is incredible. In most other engineering fields, such designs would be killed before reaching production - the design flaws would be plainly apparent (e.g., a house with the only exit on the third floor) or the cost of building and maintaining physical objects of such complexity would be plainly prohibitive (e.g. you just can't pack an arbitrary number of gears into a wrist watch).

I think that "average programmer" is jargon for "incompetent programmer" or, at least, that's the way it seems to be used. For instance, adoption of a higher level language that could significantly help to improve the productivity of capable programmers is often prevented by considerations of the form "where can we find (average) programmers who can program in that language". Learning a programming language is one thing that a competent programmer can do in a reasonable amount of time.

Still, I don't think that incompetence is the fault of individuals. Individuals can learn and become competent. The fault is in the system that tolerates, or even rewards, incompetence.

Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: "average" is jargon for "incompetent"

Posted: Apr 26, 2006 2:16 AM

I've seen many "programmers" who never really read books about programming techniques.

I would go as far as to say that the majority of (in-house applications) programmers have never opened a book since their initial training.

Achilleas Margaritis

Posts: 674
Nickname: achilleas
Registered: Feb, 2005

Re: A Type System is a Set of Tests

Posted: Apr 26, 2006 4:08 AM

> It's funny you mention that. I visit a lot of teams and
> class cast exceptions are rare.

The more complex a problem gets, the more the class cast exception problem becomes. In the company that I work for, we deal with complex algorithms, and the problem was so severe that we ended up naming variables by the types of the objects expected in the collections.

I guess the problem is far less important when Java is used for run-of-the-mill projects.

> Programs are far more
> liable to crash with null pointer exceptions.

What people do not realize is that it is values that are types. 0 is a type. The set of integers is the logical union of all integer values. Null is also a type.

>
> In most dynamically typed languages it's very easy to
> avoid crashes on null dereferences and do something better
> than just catching at the top level of your program: you
> subclass null provide your own behavior.

But the problem is not how to deal with null, but not to compute null in the first place.

> I suspect that
> the reason most designers of statically typed languages
> don't allow this is because they are scared of giving
> developers that much control. But, it is yet another case
> where preventing people from doing bad things prevents
> them from doing good things as well.

I do not think the argument holds. Handling the null pointer exception is exactly the same as subclassing null. If a statically typed language provides resumable exceptions, then the null pointer exception can be handled in a way that is meaningful.

But the problem is that null should not be there...

> I don't know that we
> could calculate the monetary loss of crashes due to null
> pointer exceptions, but I'm sure it's rather large. I
> can't believe the simplified null that we have in most
> languages is worth that cost.

I agree...but that is a problem of bad type systems, not of having type systems.

Flat View: This topic has 73 replies on 5 pages [ « | 2 3 4 5 ]

Previous Topic

Next Topic