I’m a software engineer. I write code for a living. I’m also a programming language junkie. I love programming languages. I’m
Learning that many languages, I’ve developed some pretty strong opinions about what makes a good language, and what kind of things I really want to see in the languages that I use.
My number one preference: strong static typing. That’s part of a more general preference, for preserving information. When I’m programming, I know what kind of thing I expect in a parameter, and I know what I expect to return. When I’m programming in a weakly typed language, I find that I’m constantly throwing information away, because I can’t actually say what I know about the program. I can’t put my knowledge about the expected behavior into the code. I don’t think that that’s a good thing.
But… (you knew there was a but coming, didn’t you?)
This is my preference. I believe that it’s right, but I also believe that reasonable people can disagree. Just because you don’t think the same way that I do doesn’t mean that you’re an idiot. It’s entirely possible for someone to know as much as I do about programming languages and have a different opinion. We’re talking about preferences.
Sadly, that kind of attitude is something that is entirely too uncommon. I seriously wonder somethings if I’m crazy, because it seems like everywhere I look, on every topic, no matter how trivial, most people absolutely reject the idea that it’s possible for an intelligent, knowledgeable person to disagree with them. It doesn’t matter what the subject is: politics, religion, music, or programming languages.
What brought this little rant on is that someone sent me a link to a comic, called “Cartesian Closed Comic”. It’s a programming language geek comic. But what bugs me is this comic. Which seems to be utterly typical of the kind of attitude that I’m griping about.
See, this is a pseudo-humorous way of saying “Everyone who disagrees with me is an idiot”. It’s not that reasonable people can disagree. It’s that people who disagree with me only disagree because they’re ignorant. If you like static typing, you probably know type theory. If you don’t like static typing, that there’s almost no chance that you know anything about type theory. So the reason that those stupid dynamic typing people don’t agree with people like me is because they just don’t know as much as I do. And the reason that arguments with them don’t go anywhere isn’t because we have different subjective preferences: it’s because they’re just too ignorant to understand why I’m right and they’re wrong.
Everything about this argument is crap, and it pisses me off.
Most programmers – whether they prefer static typing or not – don’t know type theory. Most of the arguments about whether to use static or dynamic typing aren’t based on type theory. It’s just the same old snobbery, the “you can’t disagree with me unless you’re an idiot”.
Among intelligent skilled engineers, the static versus dynamic typing thing really comes down to a simple, subjective argument:
Static typing proponents believe that expressing intentions in a static checkable form is worth the additional effort of making all of the code type-correct.
Dynamic typing proponents believe that it’s not: that strong typing creates an additional hoop that the programmer needs to jump through in order to get a working system.
Who’s right? In fact, I don’t think that either side is universally right. Building a real working system is a complex thing. There’s a complex interplay of design, implementation, and testing. What static typing really does is take some amount of stuff that could be checked with testing, and allows the compiler the check it in an abstract way, instead of with specific tests.
Is it easier to write code with type declarations, or with additional tests? Depends on the engineers and the system that they’re building.
http://wp.me/p93aK-12
And just like clockwork, the first comment is: a link to an argument that essentially says “If you’re not an idiot, then there’s really no such thing as dynamic typing’. If you were really smart, you’d see that it’s just marketing hype. But sadly, many of you are just too dumb to realize it.
There’s a trivial game here. Obviously, in a language like Python, every variable represents a value of type “Value”. So obviously, when a python programmer writes “def foo(x, y)”, that really means exactly the same thing as “def foo(x: Any, y: Any): Any” in Scala.
Of course, this entirely misses the point. For the way that some people program, they’re making a deliberate choice to program in a way where they don’t specify types.
I don’t like to program that way. I have a hard time accurately presenting their arguments, because for me, static typing is vastly better. The process of specifying types fits well with my thought processes as I’m figuring out how to build something, and the compiler’s type-checker is really good at catching the kinds of errors that I frequently make.
But that’s me.
There are a ton of people who could make a great argument about why, for the way that they program, spending time writing out elaborate type declaration just to satisfy the compiler is a waste of time.
Maybe, if you consider programming a loner activity done by individuals. But the fact is most developers work as part of a team. This is where I can see the argument for dynamic typing really falling apart (it is not a personal decision). It is a lot harder to realize the productivity benefits of dynamic languages (arguable) when you can no longer make any guarantees about the code you did not write.
As a Haskell programmer myself I have seen that comic before. But you know what? It gave me a chuckle and I moved on. It wasn’t the foundation of any argument and I certainly didn’t put a lot of weight into it. Do not take it so seriously?
In general, the further along in the life cycle of a system you go before discovering a discrepancy, the more expensive it becomes to correct it. It’s cheaper to discover a problem during requirements specification than during design, cheaper to discover it during design than during development, etc.
My problem with weak typing is that it allows a class of problems that would have become obvious during development in a strongly typed language to survive into testing or possibly even operations.
Or, alternatively, we could argue that all too often, static typing gives developers a false sense of security. Instead of taking the time to write tests of their code, they just assume that because the types check, the program must be correct.
I mean seriously – how many strongly typed systems make it into production without any serious bugs? If there have any been any, I haven’t heard of ’em.
“Beware of bugs in the above code; I have only proved it correct, not tried it.” — Donald E. Knuth
That’s like arguing we should deliberately infect our food with salmonella so that chefs don’t assume it’s safe and forget to cook it thoroughly. The fact that neither dynamic nor static typing can automatically catch bugs unrelated to parameter typing doesn’t mean there’s no benefit in automatically catching what bugs we can catch at compile time rather than run time.
If this was actually true, you’d never get in an airplane, drive a car, or set foot on an elevator.
I’m sorry, but as someone involved with aviation… Stop the bullshit. Static typing does not mean mathematical proof, although such proof will probably create an effective *strong* typed map of the code (note difference between static and strong).
And static typing is no guarantee that some constant won’t cause a crash, because compiler is not an engineer. Instead we test, test, test, and then give it to someone else with little forgiveness to test and certify again.
No one has said that static typing means mathematical proof, so kindly stop misrepresenting my argument. Again, static typing eliminates the possibility of a particular category of bugs. The fact there are additional categories of bugs that still may be present doesn’t change that fact. You could use dynamic typing and test for typing related bugs manually during testing, but what is the benefit of doing something manually during testing that can be done automatically during development?
I agree with you, but I still believe that there are two legitimate points of view here, so I’m going to play devils advocate.
If the amount of effort required to write the type declarations in a way that satisfies the compiler is larger than the amount of effort required to write the tests, then there’s an obvious benefit to the testing approach.
It’s theoretically possible to annotate a program to death with type information. For example, you could require that every array be defined with an index type for the allowed range of index values, and then all of the code that works with an array use the index types. Then you’d never have an index out-of-bounds error.
It’s obviously a silly idea: the amount of effort that it would take, the number of silly types, the range of perfectly reasonable code that would become incredibly difficult and cumbersome to write would be ridiculous. The cost would clearly outweigh the benefits.
The fundamental question of the value of static type-checking is: where does the tradeoff lie? For some very skilled programmers, it’s clear that they believe that the balance point comes in different places.
“Static typing does not mean mathematical proof,”. Static typing to some extend is mathematical prove of some properties – depending on how far you go then you can ensure some invariants about code – say it is fine in GHC to encode property to encode invariandts of red-black trees other then the ordering. If you go further to LiquidHaskell then you could also encode it as well. Sure most common type systems are not proves of very strong properties but they do provide some guarantees (in most extream forms there are decidable type systems which ensure terminations – they are not turing complete but covers many of the interesting programs).
Of course the question is this worth the investment is separate (for me it is as the more bugs are caught by compiler the less debugging time I need to spent during testing – hence I can spend more time developing and writing tests – others might disagree).
Respectfully, bugs in the systems you describe are actually relatively common, and defect rates for them are published.
The argument “there must be no bugs because people who’ve never checked would stop using them if there were” holds no water.
I’m going to use the term “statically-typed programmer” and “dynamically-typed programmer” to refer to a member of each camp. The terminology is wrong on a bunch of levels, but I can’t think of a better way of expressing it.
What bugs me about the dynamically-typed programmer argument is the idea that satisfying the whims of the type checker is a hoop that you just have to jump through. I think that’s a completely bogus argument.
The effort that a statically-typed programmer expends in getting their program to pass type checking is also expended by a dynamically-typed programmer. For the dynamically-typed programmer, that effort is spent testing and debugging. Fixing a type error is fixing an error, and it’s an error that the compiler found for you.
What the dynamically-typed programmer should be arguing is that you need to systematically test your programs no matter what, even if you’re using a strong statically-typed language, and if you’re going to the trouble of doing that anyway, it doesn’t take very much effort at all to also test what a statically-typed language would call “type errors”.
(I can’t remember who it was who I heard make this argument. I think it was one of the Scheme denizens. However, hearing this was the first time that the dynamically-typed programmer’s brain actually made sense to me. I’ve never badmouthed a decent dynamically typed language or its user base since.)
Like Mark, I far prefer strongly statically typed languages, because they protect me from myself, because I really like programming, but I hate debugging. Strong static type systems let me pretend that the time I’m spending debugging is actually time spent programming.
Oh, don’t get me wrong; tracking down a really good bug gives you the thrill of the chase. But most of my bugs are really stupid.
I’m sure that dynamically-typed programmers feel something similar. Writing tests is, after all, also programming if you look at it the right way.
That’s just fine with me.
Besides, all sufficiently large “real” systems are multi-layered. A technology for one layer may well be inappropriate for another layer.
Satisfying the whims of a static type checker really can be a pointless, annoying hoop. Consider this Python script:
str = some_file.read()
if sys.version_info[0] >= 3:
str = str.decode(‘latin-1’)
In Python 2, we call read(), knowing we will get back a narrow string. In Python 3, we call read(), get a list of bytes, and then convert it to a narrow string.
A Python 2 static type checker would reject this, as str.decode does not exist. A Python 3 static type checker would reject this as well, as you would be assigning a byte list to a string variable. But at runtime, there will be no type error in either case.
Here, static type checking would be only an obstacle.
All you’re really saying here is that Python’s type system is not well suited for static checking. I think that most people here would agree with that.
If the language was designed with strong static types in mind, then libraries (standard and otherwise) would reflect that reality. Python’s libraries do not, and for perfectly understandable reasons.
That’s not really all he’s saying, though. Dynamic typing here allows your code to seamlessly support both the old and new versions of a changed API, without having to fiddle with conditional compilation or anything like that. That’s a true advantage.
One complaint I hear from programmers using Haskell is that the type system makes things tightly coupled. If the type signature changed in version 0.3.2 of a lib, then you can’t easily make your program support both 0.3.2 and 0.3.1.
You seem to use “dynamically” and “weakly” as synonyms but I thought that was not so?
E.g. C is statically but weakly typed (because the compiler will let you cast anything to anything). Whereas Python is dynamically but strongly typed (everything has a type, but you may need to interrogate it at runtime to find out).
I’m not nearly the language maven that you are, but I think you understate an important issue near the end:
My sense of a lot of strongly statically typed languages (e.g. Haskell) is that expressing some reasonable behaviors is either impossible or requires jumping through a surprising number of extremely baroque hoops. (Flexible monad compsition comes to mind, but I know I’ve seen some other extreme examples.)
At the same time these type systems are still not capable of catching a lot of common errors, such as fencepost errors. So one still needs unit testing and good test practices.
So it isn’t clear to me how much the type system actually delivers net value (benefits – costs). I don’t think your quote above really covers this issue.
Actually, that’s not entirely true. Fencepost errors of the original kind (i.e. do you count the fenceposts or the gaps) can be caught by static typing if you let the type checker work for you.
In Haskell, I could write this:
newtype Post = Post Int
newtype Gap = Gap Int
gapBeforePost :: Post -> Gap
gapBeforePost (Post n) = Gap n
gapAfterPost :: Post -> Gap
gapAfterPost (Post n) = Gap (n+1)
postBeforeGap :: Gap -> Post
postBeforeGap (Gap n) = Post (n-1)
postAfterGap :: Gap -> Post
postAfterGap (Gap n) = Post n
In a dynamically typed language, one would typically represent both Post and Gap with an integer. With newtype, one can never accidentally confuse a Post with a Gap. Moreover, thanks to newtype (possibly with appropriate INLINE pragmas), the abstraction has exactly no run-time overhead.
This isn’t a hypothetical example, by the way. I once had to implement something very like diff. Distinguishing between a line (Post) and the positions between lines (Gap) turned out to be extremely valuable, and eliminated a large class of potential fencepost errors.
Here’s how I always looked at it: coders who use static typing prefer to find specific bugs at compile time, such that there is no possibility of those bugs happening at runtime, since the code wouldn’t even compile without fixing them. Whereas coders who use dynamic typing, prefer to find those same bugs at runtime.
Or at test time, which isn’t the same as run time.
Yes, as someone who enjoys working with both (all, really) types of languages, thank you for trying to inject some civility into the discussion.
I do see things a little differently though as far as what the advantages and disadvantages of each are.
Eg, I write a lot of Python and I pay attention to what kinds of mistakes I make and what kinds of bugs I find in code that others make. Very few of those mistakes are ones that a strong static type system would have caught. Every once in a while, but very rarely. When I do make those kinds of mistakes, they are usually caught very quickly and are very simple to debug.
On the other hand, one of the big advantages of static typing from my perspective is as a sort of automatic documentation. If I’m browsing the API of a library and see that a function takes an argument of one type and returns another, I immediately understand, even without reading a description, quite a bit about how I can use it. Combining that with what I know about other types in play, I feel like I can reason more about how the pieces will all fit together before I’ve written any code. Without type info, I’m more dependent on good documentation, examples, and small experiments in a REPL (which, in fairness, is much easier to do in a dynamically typed language).
how do you feel about homoiconic languages?
in theory there is no difference between theory and practice, in practice there is
— someone
Instead of throwing in my two cents on static typing vs dynamic typing like everyone else is doing (even though this article seems to be more about why not to argue about it) I’m just going to say thanks for turning me on to Cartesian closed comics. Some of them are pretty funny.
When you really look at it, they’re merely just different styles. One is punk-rock, the other is heavy metal. Who really cares.
The comic is very carefully drawn; the overlap of “people who know type theory” and “proponents of dynamic typing” is not empty; it is simply small compared to the overall number of people who are proponents of dynamic typing.
Do you believe this statistic is wrong? I think the percentage of PHP users who know Haskell is much smaller than the percentage of Haskell users who know PHP.
Lately I have been finding myself wishing that Python had some of Java’s features. Dynamic typing is becoming more annoying and is actually less helpful to me now.
But I still want to retain the ability to do dynamic typing for situations where I want to put *anything* into a variable and pass it off to another layer of a system.
Wouldn’t generics and/or Object correspond to ‘put anything into a variable’? (Setting aside a low-level details such as primitive types which as element of Java – not general discussion).
“easier to write code with type declarations”. Cute, but in any language of the Hindley-Milner-Damas variety, you don’t actually have to write type declarations.
I think you read to much into the CCC strip – sure there should be some overlap between the green and blue circle, but to interpret the “areas” into stupidity – maybe you are a bit to critical here 😀
To be honest: I had a big grin on my face when I saw this comic and I kinda like it 😀 – it has just some truths in it: most peoply favoring “dynamical” typed languagues just don’t know any good type-system or don’t know how to work with instead of against it.
(Sure the other way is true as well – dynamic languagues have some merits – I love LISP – but in the end I would choose a strong type system everytime)
I’m not a serious programmer, only did one year of CS before switching to physics (and later maths). I know the difference (I think) between static and dynamic typing, however I was wondering if you could give a quick idea of what type-theory entails?
That said, I might as well join the rest of the commenters in stating my opinion of static vs dynamic:
I prefer static typing, mostly because I like to know exactly what is going on under the hood and dynamic typing acts a bit too much as a black box to me. Also in dynamically typed languages I tend to get incredibly weird bugs which take me days to find which eventually turn out to be due to something not acting like the type I expected.
On the other hand, if I need to do a quick and dirty calculation (usually less than a page of code) I can do it much quicker if I dont have to worry too much about types. So as long as the problem I’m working on is simple enough that I know I wont have bugs, I’ll use a dynamically typed language.
I think Dynamic typers are people whose code puts lost of objects in arrays.
And Static typers are people whose code takes lost of objects out of arrays.
Is this the part where we all pretend you have to know type theory to have a practical opinion on your tools?
The average programmer with no type theory knowledge but who speaks one static and one dynamic can explain to you the practical difference between the two, and which side of the line they fall on.
Despite your silly little chart, which is drawn from zero data, it’s pretty close to a 50/50 divide.
You don’t need to understand type theory. Watch.
“Static typing allows you to write stricter code which lets the compiler back you up. Dynamic typing allows you to write simpler, more natural code with fewer casts, which lets you focus more on the work.”
I for one have little preference between the two; after you work with enough languages you come to realize that this is a relatively minor point in language design, and that the kind of neckbeard who writes angry cursing blog posts about something like this is just bikeshedding so that they can feel like a language designer.
You want evidence? Try TypeScript. Your experience change vs. Javascript is actually quite small.
This does not matter. And if you’re familiar with type theory, I’m sure you have a long, boring explanation of why it actually does matter, which when applied to my 20 years in the profession will turn out actually still to completely not matter one bit.
Sorry, champ. Dynamic vs Static just isn’t that important. (For the record, I have a mild preference for static, because I like the casts; they make me feel safe and like my compiler can help me. But in reality, when you start keeping data, like through PSP/TSP, the practical bug count rate difference is near-zero.)
Have fun talking about how angry you are that nobody’s allowed to disagree, that it’s an undesirable attitude that is too common, then responding with an opinion guess that has no data, and lots of fabricated charts which clearly graph your expectations to back it up. It feels very Fox News in here.
I kind of don’t even know whether I expect you to permit a severe criticism.
Who is this in reply to? The author of the comic, who’s not here?
It’s for the blog’s author.
John, if you’re talking to Mark (the blog author), why do you talk about “your” charts and graphs, when the only chart-like thing in the post is a link to a diagram which the post is criticising?
Yeah, pronouns are hard for people who don’t even try to understand.
Good job completely misunderstanding Mark’s post. (Hint: his point agrees with yours. Just not said in an assholish and passive-aggressive way. Leave the “I bet you won’t even print this!” to angry letters to the editor writers.)
Manifest typing (i.e. explicitly stating the types of things) and the static/dynamic typing divide are orthogonal things.
Statically typed languages with type inference can require very few type annotations, and the types are still statically determined. As an example, manifest typing is very rarely required in Haskell. It is often used because it often serves as documentation, but it is optional most of the time.
Dynamically typed languages can also have types explicitly stated. As an example, you can do manifest typing in Perl with sigils: my @foo; declares a foo variable with array type.
It may be hard to discuss static vs dynamic typing when the other person is an idiot that conflates static typing with manifest typing. (That last statement is made in jest and not in any way intended to be taken seriously.)
“It may be hard to discuss static vs dynamic typing when the other person is an idiot that conflates static typing with manifest typing.”
Yeah, except I didn’t. Try to turn down the insults-as-a-way-to-cope.
Erlang is statically typed but not manifestly typed, and is a standing example of my claims. There are quite a few others.
It’s not surprising that a Haskell programmer, fascinated with his superiority for knowing Haskell-brand type theory, made this mistake.
.
“(That last statement is made in jest”
Did you really think it would be taken that way just because you said this?
Social positioning is not cute or funny, and even if you immediately disavow it, the people you do it to are left with a very bad taste in their mouths.
Jests are friendly unexpected things that make people laugh, instead.
“Erlang is statically typed” … This is news to me, care to explain ?
Seriously? I guess you don’t write Erlang, then.
Try io:format(“~s~n”, [27]).
Maybe I need some explanation, or misunderstand dynamic typing, but everywhere I look it says Erlang is dynamically typed. I don’t understand how io:format(“~s~n”, [27]). indicates otherwise: it compiles fine but results in a runtime error. What am I missing ?
Okay, then try -behaviour().
I mean seriously, there’s a point at which if I give you an answer, I’m going to sound like a complete dick.
John, if you just didn’t know what you were talking about, that would be fine. Ignorance can be cured.
But throw in an air of superiority and condescension and you’ve got yourself a world class idiot.
Go study the subject matter a bit before making a fool out of yourself again.
Nice post
I am uncertain if you mean me.
If you do, and if that’s meant seriously, thank you kindly.
This commenting UI makes it almost impossible to determine which level the comment is on. Sorry no, I meant it for the original author – MarkCC
Two points for Mark:
1. You seem to be conflating ignorance with idiocy, which is one of my pet peeves. The fact is, we’re all ignorant about a great many things; the alternative would be omniscience. So, telling someone “you only think that way because you are not aware of certain facts” is not the same as calling someone an idiot. (Though it might still be untrue, and thus somewhat presumptuous.)
2. It’s not clear to me that this comic strip is unambiguously pro-static-typing; I think it could alternatively be interpreted as saying, “The people who prefer static typing are mostly language theorists who don’t know what it’s like to have to get real work done.”
Pingback: A Lazy Sequence: Static types are great, but I don't use them in practise
during decades of programming, i’ve used a lot of languages, and implemented a few as well. i like static typing, but it’s not a showstopper for me either way. i appreciate it when available, but it’s not the deciding factor for me in selecting my tools. nowadays i mostly program in erlang and python. when i’ve used ocaml, i loved the security of having the compiler watch my back. i miss it sometimes in erlang, but pattern matching of tagged tuples combined with a little development rigor gets me much of the same benefit, at the cost of a little more effort.
that said, i have little tolerance for type declarations. irritating tedium, doing bookkeeping the compiler ought to do for me. after years (decades) of C, C++, and Java, Ocaml’s type inference was a revelation for me.
as for the debates, they just don’t interest me. i can see value in both positions. i guess i’m a pragmatist, and i tired of holy wars long ago. i have noticed that the most strident voices in these debates are often those with the least breadth of experience. they’re less interested in discourse than in defending their own choices or limitations.
I generally find the accuracy/relevance of a criticism more important than it’s severity.
I think the debate is a bit blurry these days and the real debate should be about the tools. There are a lot of statically compiled & typed languages now that share a lot of traits with dynamically typed languages. For example, Mirah and Kotlin have a lot in common with Ruby. Mirah is essentially Ruby minus the handful of features that prevent it from being a statically compiled language. Type inference, removes much of the need of explicitly typing everything while preserving most of the advantages of having a strongly typed language. Scala takes this to a ridiculous level and represents the worst of both worlds, IMHO.
Statically typed languages come with smarter tools. I program both Ruby and Java. My Java IDE is very helpful and infers all sorts of context about what I’m doing, warns me against common mistakes, and provides me with good feedback on what it thinks I’m doing as well as time saving quick fixes for common problems. Than it offers me all sorts of options to semantically restructure my software (refactoring). My ruby IDE can’t even tell me the name of a function I just declared three lines up. It’s like being thrown back 20 years in time. The reason is the type system and the inherent ambiguity of Ruby. Neither tools nor humans can make much sense of it without running it. Don’t get me wrong, I actually like Ruby. But I hate the fact that the tools suck so much.
Perhaps I can reasonably disagree with your statement that reasonable people can reasonably disagree 😉 I’m being tongue-in-cheek here, but if we accept your premise that individuals can be equally knowledgable (however that’s defined) and reach incompatible conclusions, doesn’t it follow that the author of that cartoon can believe his preferences are “correct” while still being reasonable?
Of course not! This applies to everyone *except* me! I’m always right.
I understand all too well that you’re whinging about fabricated charts and Fox News, even though point of the blog post is essentially the same as your ‘criticism’.I understand all too well that you’re whinging about fabricated charts and Fox News, even though point of the blog post is essentially the same as your ‘criticism’.
That was meant to be a reply to John Haugeland.
Mark, I’m always impressed by how much our viewpoints differ when you blog on this general topic. My background is Big Software — systems with millions of lines of code, written by hundreds of programmers over years or even decades. Military systems, avionics for commercial jetliners, the IRS, stuff like that. I always stumble when reading your articles when you say something that seems to apply only to single-programmer pieces of software.
I am, however, willing to admit after 45 years in the field that Big Software may be inherently EVIL. Projects developing it fail so often and so horribly expensively that we probably shouldn’t even be trying to do them. We should find some other way to meet whatever need they’re trying to fill.
“It’s not surprising that a Haskell programmer, fascinated with his superiority for knowing Haskell-brand type theory, made this mistake.”
Yeah, except I didn’t. Try to turn down the insults-as-a-way-to-cope.
It’s insightful to point out that an important motivation for static types is information preservation. That completely summarizes my own preference for static typing.
But I think (though I’m not sure) there’s an equally deep argument for dynamic typing that everybody misses. I think dynamic types especially in lisps are an attempt to encourage programming at a more general level. In this view, types are just a mental crutch that may be useful to the individual programmer but that hinder the development of the program at the most general level.
At least, that’s the only justification I could come up with for dynamic typing coming from a static typing point of view 🙂
I like BOTH kinds of languages, Haskell AND Python.
I also like this blog post, and agree that both Haskell and Python are the best tool for different situations.
I wish we could use the flames in this comment section to POWER THE INTERNET.
“POWER THE INTERNET”
The Internet is powered by porn.
Nice article. I am often frustrated by the low level of discourse about typing.
I prefer dynamic typing (not weak typing, as you called it once in the post). Dynamic typing means that type information is available to the program at runtime. Static means it is available at compile time. Note that these are not mutually exclusive. Java has both static and dynamic types.
The reason I prefer dynamic typing is that it more closely fits the types of abstractions that I would like to use. No static type system I have used can even express all of the kinds of things I want to do. It is not about hoops. The information about the expected behavior cannot even be captured.
Please also note that I do like that static typing captures and enforces that information. I find it comforting when I can tell the compiler exactly what I expect. But having one static type system for a language is self-limiting.
I think you are leaving out some important advantages of static type-checking:
1) Refactoring, if you change the type of something, you know immediately what you have to update. Although this can be achieved with testing, testing with full coverage is unlikely
2) Features enabled by types: auto-complete, type-at-cursor-position etc …
3) Code optimization. The more you know statically, the more chances you have to optimize (better layout etc …).
I am very surprised the argument: “but you have to write the unit tests anyway” convinced you. I find this argument very weak. First, unit tests “might” catch typing errors, which is very different from: “there will be no type-errors at all”.
However, I agree that there is a real trade-off.
There is sometimes a lack of flexibility when using a statically typed language. In my opinion, these cases occur when you are trying to write something “Meta” (think test framework).
So there is a legit use case for dynamically typed constructions. Statically typed languages deal with these kind of issues with ad-hoc constructions such as reflexion, which is not that much better than a good old eval (except maybe in terms of security?).
Pingback: Maybe type checking is a good idea | prose :: and :: conz
Hi Mark.
I read this article a while back and bookmarked it because it held a moderate and well-balanced opinion on the type systems debate, and it struck a chord with me because I feel strongly that both static typing and dynamic typing has their own merits. Strongly enough to design a new programming language around the concept actually. You can check it out at http://www.lbstanza.org. I wonder what your opinion on optionally-typed systems are. My advisor was one of the earliest implementers of the Apple Dylan project, and we feel that Stanza is a decent modern incarnation of it.
Cheers.
-Patrick