sell me on strong typing, type safety, etc.

[ultranewb]

hello all.

i have always coded in what i will loosely call "dynamic" languages
where i didn't have to worry about type. i have built large, complex
systems with such languages. nothing ever "blew up." any bugs were
always relatively minor, relatively easy to find and fix, etc. the
systems i have built have always been successful.

in giving haskell a look, i noticed the strong emphasis on "strong
typing," "type safety," etc. in fact, in looking at some propaganda
for one of the web frameworks available for haskell, it seemed every
other word out of the mouth of the developer was "strong SAFE typing,"
even going so far as to emphasize one selling point being "type safe
urls."

i'll bite. what's the big deal with all this emphasis on type? if
someone cares to address it, convince me that i need to be a lot more
worried about type than i ever needed to be before. you have my
attention.

(fwiw, i do appreciate that haskell seems to infer most types so that
i don't have to declare them. the bigger issue for me would be not
allowing things like lists to contain mixed types.)

thanks.

[John Coleman]

Hi, The following article is about the somewhat similar language ML rather than
Haskell, but has an interesting example about how ML's type system was able
to detect that a sort algorithm was buggy:

http://static.usenix.org/publications/library/proceedings/vhll/full_papers/koenig.a

[ultranewb]

On Mar 31, 8:25 pm, John Coleman <jcole...@franciscan.edu> wrote:
> Hi, The following article is about the somewhat similar language ML rather than
> Haskell, but has an interesting example about how ML's type system was able
> to detect that a sort algorithm was buggy:
>

> http://static.usenix.org/publications/library/proceedings/vhll/full_p...

Thanks - will have a look.

[ingo.w...@googlemail.com]

Am Freitag, 30. März 2012 18:53:19 UTC+2 schrieb ultranewb:
> hello all.
>
> i have always coded in what i will loosely call "dynamic" languages
> where i didn't have to worry about type. i have built large, complex
> systems with such languages. nothing ever "blew up." any bugs were
> always relatively minor, relatively easy to find and fix, etc. the
> systems i have built have always been successful.

Very good. It looks like you are one of those people who do it right intuitively.
This means you should never get a complaint from the Haskell type checker.
Hence, as far as it concerns you, the type system will not get in your way and you'll not notice it even exists.
It may be comforting for other people (such as your clients or those who must maintain your code later), though, to know with mathematical certainty that your code is correct as far as the types are concerned.

> i'll bite. what's the big deal with all this emphasis on type?

Not all people are geniuses and something get it wrong.
Better to tell them it's wrong before they run it.

> (fwiw, i do appreciate that haskell seems to infer most types so that
> i don't have to declare them. the bigger issue for me would be not
> allowing things like lists to contain mixed types.)

What would you do with such a list if you don't know what is in there?
In every case, you'll have some mechanism that does type discrimination at run time.
You can, of course, do that in Haskell as well though it may be somewhat more explicit than in, say, javascript.

[ultranewb]

On Apr 1, 10:23 pm, ingo.wechs...@googlemail.com wrote:

> Not all people are geniuses and something get it wrong.
> Better to tell them it's wrong before they run it.

i'm not bad by any means, but i don't believe i'm God's gift to the
programming world
either :-) i think most of what we untyped folks do is less "writing
code 100%
mathematically correct" and more simply structuring code and
circumstances so that it
doesn't need to be.

i read the article the previous poster posted. i'm impressed that the
type checker
was able to catch that particular bug the way it did. whether it
actually does
flow analysis, or the type checking is so good that it seems to do it,
it's
impressive enough, i guess. assuming the thing can catch serious,
hard-to-find bugs
from non-trivial non-toy problems, i guess that's of value. and of
course i see
the value of mathematical proofs of correctness.

i'd normally say that it would be up to the individual at this point
to decide
whether the value of the strong-typing justifies what you give up in
terms of
hassle and "pain in the ass" factor, except that here the type
inferencing
apparently doesn't force you to give up too much, except perhaps in
the way of
mixed-type structures and what not.

> What would you do with such a list if you don't know what is in there?

sure, you normally need to know what's in there (although the compiler
or
interpreter or whatever you're running might not).

seems like an impressive language. assuming you static guys would
allow one of us
dynamic guys to get anywhere near it, i'll download a compiler/
interpreter and play
around with it. just hope a hole doesn't appear in the space-time
continuum :-)

regards.

[Roman W]

On Friday, March 30, 2012 5:53:19 PM UTC+1, ultranewb wrote:
> i'll bite. what's the big deal with all this emphasis on type? if
> someone cares to address it, convince me that i need to be a lot more
> worried about type than i ever needed to be before. you have my
> attention.

You say that you've always built correctly working systems with few bugs using
dynamic typing. You don't say how much excess (as compared to systems built
using static typing) testing code you have to put in just to make sure that
your types are correct. For example, if adhering to "100% unit test coverage" credo,
you'd have to check the return type of every function for at least most typical
inputs, to make sure it returns the correct type. That's a lot of effort not needed
in static-typed languages.

Another aspect of this is run-time performance. Dynamic typing comes at a cost,
since the type information must be carried around together with the object.

RW

[ingo.w...@googlemail.com]

Am Montag, 2. April 2012 11:03:22 UTC+2 schrieb Roman W:
> On Friday, March 30, 2012 5:53:19 PM UTC+1, ultranewb wrote:
> > i'll bite. what's the big deal with all this emphasis on type? if
> > someone cares to address it, convince me that i need to be a lot more
> > worried about type than i ever needed to be before. you have my
> > attention.
>
> You say that you've always built correctly working systems with few bugs using
> dynamic typing. You don't say how much excess (as compared to systems built
> using static typing) testing code you have to put in just to make sure that
> your types are correct. For example, if adhering to "100% unit test coverage" credo,
> you'd have to check the return type of every function for at least most typical
> inputs, to make sure it returns the correct type. That's a lot of effort not needed
> in static-typed languages.

Indeed.
The 100% coverage of the type checker is especially useful when it comes to refactoring, modifications, etc.
For example, the type checker answers the question "What needs to be changed if I redesign this type, piece of code or what not?" very quickly and comprehensively.

[ingo.w...@googlemail.com]

Am Sonntag, 1. April 2012 22:35:21 UTC+2 schrieb ultranewb:
> On Apr 1, 10:23 pm, ingo.wechs...@googlemail.com wrote:
>
> i'd normally say that it would be up to the individual at this point to decide
> whether the value of the strong-typing justifies what you give up in terms of
> hassle and "pain in the ass" factor, except that here the type inferencing
> apparently doesn't force you to give up too much, except perhaps in the way of
> mixed-type structures and what not.

Yes, this is a point worth noting.

For example, Simon Peyton Jones, the main author of the Glasgow Haskell Compiler is of the opinion that a type system you have to fight with is not good enough.

Hence, Haskell (and related languages with very similar type systems) may be a bit better than you expect. An indication may be that there is really no way to cheat (with regards to types) in Haskell, whereas in Java, for example, you have a cast operation. They need it, because the type system is not powerful enough from the outset.

Another way to put this: There is the set of all correct (i.e. free of bugs) programs in language X. Then there is the set of all correct programs that can be written without having to cheat with the type system of X. The objective is to have the difference, i.e. the set of correct programs that can only be written by cheating the type system as small as possible. And in this regard, Haskell is far better than conventionally statically typed languages.

Hence, static typing is not always the same. When it gets a "pain in the ass" the type system is no good. But in Haskell, every active programmer can tell you stories of how the type system uncovered errors early. And in almost all cases, going back and thinking about it makes it clear that one's design was bad (if it was not just a stupid, easy to fix error).
Complaints of the form "The type system does not let me do X, lest X is completely legitimate." are almost unheard of. Hence, Haskell programmers actually regard the type system as their best friend, not as their enemy that gets in their way.

[Roman W]

On Monday, April 2, 2012 11:51:54 AM UTC+1, ingo.w...@googlemail.com wrote:

> For example, Simon Peyton Jones, the main author of the Glasgow Haskell Compiler is of the opinion that a type system you have to fight with is not good enough.

"Fight with" is subjective. Often I think that I'm fighting the language, when in reality I'm suffering from my ignorance.

RW

[Roman W]

I agree. For example, you can track the usage of your class by simply searching for the class name in the code. If you don't declare your types, you have no way of knowing what part of the code will be affected.

BTW, initially I read your post as sarcastic ;-)

RW

[ultranewb]

> You say that you've always built correctly working systems with few bugs using
> dynamic typing. You don't say how much excess (as compared to systems built
> using static typing) testing code you have to put in just to make sure that
> your types are correct.

Normally it's minimal. If i do anything, it's normally user-input
scrubbing/filtering vs. type checking, but not too much beyond that.

Just so i can see where a static guy is coming from, give me a
reasonable, "non-exotic" situation where you think there would need to
be a lot of testing code for typing.

> For example, Simon Peyton Jones, the main author of the Glasgow Haskell Compiler
> is of the opinion that a type system you have to fight with is not good enough.

I like this guy! (I once walked out on a project when I saw what I'd
have to do to declare the type of a particular template in C++. The
declaration literally went beyond 80 characters and scrolled to the
next line.)

[Dirk van Deun]

: > i have always coded in what i will loosely call "dynamic" languages
: > where i didn't have to worry about type. i have built large, complex
: > systems with such languages. nothing ever "blew up." any bugs were
: > always relatively minor, relatively easy to find and fix, etc. the
: > systems i have built have always been successful.

: Very good. It looks like you are one of those people who do it right intuitively.

I'd rather suppose that the original poster is used to writing in a
style in which you make fewer errors of the kind which are hard to
find without a type checker. Imagine clean, short, imperative
statements; not a lot of higher order functions; rarely if ever any
partially applied functions or complex function compositions; global
variables instead of threading values through your code; loops and
counters; and strange as it may sound, no abstractions pilfered from
category theory. Haskell needs a good type checker, because the
language invites us to write in a style in which you may need it a
lot. Other languages and other styles less so. You could say that
the Haskell type checker is an enabler for the Haskell style of
programming.

Dirk van Deun
--
Licensed to (kill -9)

[Roman W]

On Monday, April 2, 2012 8:17:06 PM UTC+1, ultranewb wrote:
> Just so i can see where a static guy is coming from, give me a
> reasonable, "non-exotic" situation where you think there would need to
> be a lot of testing code for typing.

Using the OOP paradigm: let's say you have a Factory producing Widgets. In a
static-typed language, you'll declare the buildWidget method with return type IWidget.
You know at compile time that the object returned by this method has a given interface.
In a dynamic-typed language, you can only test this at runtime, by testing the objects
returned by the factory method.

RW

[ultranewb]

[ultranewb]

> I'd rather suppose that the original poster is used to writing in a
> style in which you make fewer errors of the kind which are hard to
> find without a type checker. Imagine clean, short, imperative
> statements; not a lot of higher order functions; rarely if ever any
> partially applied functions or complex function compositions; global
> variables instead of threading values through your code; loops and
> counters; and strange as it may sound, no abstractions pilfered from
> category theory. Haskell needs a good type checker, because the
> language invites us to write in a style in which you may need it a
> lot.

There's a good bit of truth here as far as coding style for past
projects. And I hadn't considered that writing in a "Haskell-esque
style" might justify more of a need for something like static type
checking. Good insight.

By the way, have you heard of a language called "Pure" (used to be
called "Q") which seems to be very similar in syntax to a dynamically-
typed Haskell?

> Using the OOP paradigm: let's say you have a Factory producing Widgets. In a
> static-typed language, you'll declare the buildWidget method with return type
> IWidget. You know at compile time that the object returned by this method has
> a given interface. In a dynamic-typed language, you can only test this at
> runtime, by testing the objects returned by the factory method.

Not trying to be difficult here, I just honestly still don't "get
it." Why do I need to test what type of stuff is coming out of the
factory? I mean, if I designed the factory to pump out objects of a
specific type, why can't I just assume that that's what it will do at
runtime?

[Paul Rubin]

ultranewb <pineapp...@yahoo.com> writes:

> Not trying to be difficult here, I just honestly still don't "get
> it." Why do I need to test what type of stuff is coming out of the
> factory? I mean, if I designed the factory to pump out objects of a
> specific type, why can't I just assume that that's what it will do at
> runtime?

The Factory might make the wrong type by accident, or there might be
some buggy plumbing in your program between the factory and where the
produced widget is actually used.

You should read Chris Smith's article:

http://web.archive.org/web/20080822101209/http://www.pphsg.org/cdsmith/types.html

[ultranewb]

> You should read Chris Smith's article:

A good article. In fact, because of this very thread, I had just
started to figure out on my own some of the points the article
addresses. For instance, because of being forced to program in C, C+
+, Pascal, etc. in early years, I always had the notion that static
type systems only seem to be good for checking for typos that I will
catch easily enough anyway when I run my code, but at the huge cost of
cluttering up my code, turning what should be several lines into a
page or more, and giving me carpel-tunnel syndrome from all the typing
I am forced to do. The best thing I ever did was get away from those
languages as quickly as humanly possible (which I did a long time
ago). But the point is, until this very thread, I always associated
"static typing" with those languages, particularly utter crap
languages like Java and C++.

I think what I started to learn from this thread (correct me if I am
wrong) is that a type system like Haskell's is just a whole different
kettle of fish, not just because you aren't forced to clutter your
code with huge numbers of type annotations like "public static void
main blah blah..." over and over again, but because the type system is
really something more than just a glorified typo-catcher.

If you static guys happen to run into this topic with dynamic guys
very often, I think the best thing you can do is get them to
understand from the get-go that static typing DOES NOT necessarily
equal programming in a hellhole like C++ or Java or Pascal.

> The Factory might make the wrong type by accident, or there might be
> some buggy plumbing in your program between the factory and where the
> produced widget is actually used.

I don't think the article addressed this, or told me why I should be
concerned about it. Either way, a lot of this stuff might boil down
to a "cultural" or "religious" thing. I've seen what I will call
"defensive coding" written by colleagues that makes my eyes glaze over
(basically reams of code checking for type everywhere you can check
for it). Me? I don't do it, and nothing blows up, but far be it from
me to criticize someone else's "culture" or "religion."

At any rate, a successful thread. What do you know, I actually
learned something.

[Arved Sandstrom]

Good article, thanks for pointing it out. I already went through the
phase quite a while back of thinking that "strong" and "weak" could be
clearly explained; now I'm casting around for lots of well-argued points
of view on typing so as to just start solidly understanding types. I
think it's probably the case that most of us programmers need a few
kicks at the can before we start understanding types and type systems.

There is still a small stubborn part of me that wants to use the
"strong" and "weak" characterizations. To use Smith's definition near
the end of the article, I like his initial description of a "weak"
system as one that "that worries [one], or makes [one] feel
uncomfortable." I think that this is what a lot of people mean when they
look at a system that permits a whole bunch of operations; it just feels
sloppy. "3" + 2.5 is no less defined than a type system that doesn't
permit this, it just can feel "weaker".

AHS

--
A fly was very close to being called a "land," cause that's what they do
half the time.
-- Mitch Hedberg

[Roman W]

On Tuesday, April 3, 2012 6:58:03 PM UTC+1, ultranewb wrote:

> Not trying to be difficult here, I just honestly still don't "get
> it." Why do I need to test what type of stuff is coming out of the
> factory? I mean, if I designed the factory to pump out objects of a
> specific type, why can't I just assume that that's what it will do at
> runtime?

But that's a different question: "why test software?".

RW

[ultranewb]

On Apr 4, 5:32 pm, Roman W <bloody_rab...@gazeta.pl> wrote:
> But that's a different question: "why test software?".

No, that's not the question. I think everyone agrees software should
be tested, and I test software extensively. The question is whether
one should have reams of type-testing code strewn throughout software
to constantly check dynamically the types of widgets coming from
factories.

For me, it's good enough to do this (Smalltalk-style):

Car new.

I never thought I had to do this:

(Car new isa: Car) ifTrue: [...] ifFalse:[...].

[Roman W]

I don't mean that you need to put it in the actual production code. I was thinking of unit tests.

RW

[ultranewb]

On Apr 4, 11:43 pm, Roman W <bloody_rab...@gazeta.pl> wrote:
> I don't mean that you need to put it in the actual production code. I was thinking of unit tests.

Ah, well we agree one needs to do unit tests - sure.

[ultranewb]

> "3" + 2.5 is no less defined than a type system that doesn't
> permit this, it just can feel "weaker".

Tcl: your worst nightmare, heh:

# add string and number

> expr "3" + 2.5
5

# concat a string and number

> append x "string" 3
string3

[Roman W]

Exactly. And with dynamic typing, some of the testing which would be done automagically by the compiler needs to be shifted to unit tests, which require active maintenance. More work.

RW

[ultranewb]

>> What would you do with such a list if you don't know what is in there?

> sure, you normally need to know what's in there

On second thought, I disagree. You don't necessarily need to know
what's in a list.

Erlang:

xlength([]) -> 0;
xlength([_|Xs]) -> 1 + xlength(Xs).

56> xlength([5]).
1
57> xlength("hi").
2
58> xlength([]).
0
59> xlength([1, $2, "three", {four, 5}, {}]).
5

[ingo.w...@googlemail.com]

Am Freitag, 6. April 2012 17:22:43 UTC+2 schrieb ultranewb:
> >> What would you do with such a list if you don't know what is in there?
>
> > sure, you normally need to know what's in there
>
> On second thought, I disagree. You don't necessarily need to know
> what's in a list.

You're right.
Of course you can do many things with a list without knowing what's in there. Haskell has plenty of functions with [a] (list of unknown things) in the type.

My question should have been: What would you do with the elements of such a list? You're not going to tell me that you want to put different things into a list just to count them, or to reverse them?

[ultranewb]

On Apr 6, 10:32 pm, ingo.wechs...@googlemail.com wrote:
> My question should have been: What would you do with the elements of such a list? You're not going to tell me that you want to put different things into a list just to count them...?

Why not? Just off the top of my head, picture an application where
you need to count whatever elements are in a file, whether it be text,
numbers, characters, whatever. Maybe you don't know what's in the
file. The list could represent the file that was read in.

You have to be careful about assumptions like "nobody would ever need
to do such-and-such by using such-and-such in such-and-such way to do
it." The problem domain is too big.

[Paul Rubin]

ultranewb <pineapp...@yahoo.com> writes:
> Why not? Just off the top of my head, picture an application where
> you need to count whatever elements are in a file, whether it be text,
> numbers, characters, whatever. Maybe you don't know what's in the
> file. The list could represent the file that was read in.

You would typically use a sum type for that:

data FileElement = TextElement String | NumberElement Int | ...

and then use a list of type [FileElement]. Lisp like languages are
sometimes called "unityped". They aren't type-free. They have just one
type, which is a big sum type, and they use it for everything.

[ultranewb]

On Apr 6, 10:32 pm, ingo.wechs...@googlemail.com wrote:

> Am Freitag, 6. April 2012 17:22:43 UTC+2 schrieb ultranewb:
> Of course you can do many things with a list without knowing what's in there. Haskell has plenty of functions with [a] (list of unknown things) in the type.

But Haskell can apparently only handle homogeneous lists, I assume
because of the strong typing. The point of my erlang example was,
dynamic typing can handle lists of truly unknown stuff, where the list
could be a hodge-podge of anything.

[Mark T. B. Carroll]

ultranewb <pineapp...@yahoo.com> writes:

> But Haskell can apparently only handle homogeneous lists, I assume
> because of the strong typing. The point of my erlang example was,
> dynamic typing can handle lists of truly unknown stuff, where the list
> could be a hodge-podge of anything.

But, in actual real-world programs, given that we also have fixed-length
tuples, heterogeneous lists very rarely crop up; sum types, and type
class restrictions, cover typical needs. Haskell /can/ handle
heterogeneous lists using tricks with existential types and suchlike --
for instance, see http://homepages.cwi.nl/~ralf/HList/paper.pdf -- and I
think I once made use of that kind of technique, but the need just
doesn't usually come up. Lists typically aren't just a "hodge-podge of
anything" unless the type system wasn't expressive enough, like lacking
good algebraic types, to say truly what the useful thing is that the
list's elements have in common. Even when one's serializing and
deserializing one normally has lists of bytes or legal datastructure
elements or something. At least, a quick glance through the code I've
written suggests that, at most, I've used functional dependencies to
constrain what kinds of things I have in homogeneous lists passed to the
same function, relative to each other (so, to take an odd but possibly
illustrative example, if the first argument lists hippos, then the
second must have cats, or something), but I'm just not managing to
imagine the motivating example for these truly hodge-podge lists given
sufficiently expressive typing.

Mark