Unless you intend to strictly enforce types (rather than validity) on your dynamic code, there is no burden on the developer.
Of course there is. I program more in dynamic languages (particularly JS) than in statically-typed ones, and I always keep worrying about passing representation A of some data rather than representation B. I find myself having to look at the source code of callees far more than I think I should be.
On the other hand, my academic life revolves around statically-typed languages (Haskell). The way Haskell's type system is designed means that there are entire programming paradigms that are not just available but production-ready in Haskell, but are virtually impossible in any other popular language. For a concrete example, see software transactional memory.
I'm also a huge fan of pushing as much lower-level drudgery as possible to machines to free up human minds for higher-level thinking, and a good type system combined with good type inference goes a long way.
I am not familiar with Haskell typing - Haskell is on my "languages to learn" list right after Clojure. I just need an excuse to move it up. Lately I bumped the project in favor of a "learn to use Google's App Engine" project.
It's interesting you feel like this with JS. I spend most of my time with Python and seldom have any doubts about what should I do. I usually make little assumptions on the type of the object I am receiving and don't think much about it.
Do look at Haskell whenever you can. Haskell (and ML/F# to an extent) pushed me from the "static typing is a PITA" camp to the "static typing done right is a magnificent benefit to programming" camp.
I wonder to what degree this depends on the individual programmer. I had a class in University that used both Ruby and O'Caml (only the more functional aspects allowed for use there) for different projects.
We did Ruby first and O'Caml afterwards (we were to implement a scheme interpreter for the O'Caml project). Anyway, the impression I got was that most students hated O'Caml and loved Ruby, but while it was harder to get used to working in O'Caml I loved what the typing system did for me.
Every time I'm working in a language like Ruby and suffer from a bug a type system would have caught, it frustrates me. Perhaps for other programmers, every time they have to do extra work so the type inference works when in a language like Ruby they wouldn't have to, they get frustrated.
I prefer my frustration up front, and honestly, found that O'Caml told me, "You didn't think of this nimrod" mostly when I needed it, and rarely when it was just being a pain.
I quote Simon Peyton-Jones: "STM requires runtime logging of every memory read and write. In an imperative language (such as C#), in which the very fabric of computation involves reads and writes, STM is bound to be expensive. [Lots of work has been done to omit redundant logging based on program analysis, but it's still expensive.] When do you need readTVar/writeTVar? Answer, precisely when you are manipulating state shared between threads."
It looks like STM works better for functional languages and you have to mark shared data somehow. And then you have to mark the code that manipulates shared data somehow (so it won't prematurely launch missiles). Then you're reinvented monad.
I reserve right to be wrong so I'd like to see what are the ways for imperative languages.
With the same performance, static protection against irreversible side-effects, and clever aversion of the privatization problem? I'm not aware of any. While STM can be theoretically done in any memory-safe imperative language, Haskell -- mainly because of its purity and type system -- seems to be the only language in which it can be fast enough and correct enough for practical use.
edit: well, Clojure restricts mutability too, so STM is sort of tractable there, but it doesn't get the other benefits that Haskell's type system gives you.
Comments
Unless you intend to strictly enforce types (rather than validity) on your dynamic code, there is no burden on the developer.
Of course there is. I program more in dynamic languages (particularly JS) than in statically-typed ones, and I always keep worrying about passing representation A of some data rather than representation B. I find myself having to look at the source code of callees far more than I think I should be.
On the other hand, my academic life revolves around statically-typed languages (Haskell). The way Haskell's type system is designed means that there are entire programming paradigms that are not just available but production-ready in Haskell, but are virtually impossible in any other popular language. For a concrete example, see software transactional memory.
I'm also a huge fan of pushing as much lower-level drudgery as possible to machines to free up human minds for higher-level thinking, and a good type system combined with good type inference goes a long way.
I am not familiar with Haskell typing - Haskell is on my "languages to learn" list right after Clojure. I just need an excuse to move it up. Lately I bumped the project in favor of a "learn to use Google's App Engine" project.
It's interesting you feel like this with JS. I spend most of my time with Python and seldom have any doubts about what should I do. I usually make little assumptions on the type of the object I am receiving and don't think much about it.
Do look at Haskell whenever you can. Haskell (and ML/F# to an extent) pushed me from the "static typing is a PITA" camp to the "static typing done right is a magnificent benefit to programming" camp.
I wonder to what degree this depends on the individual programmer. I had a class in University that used both Ruby and O'Caml (only the more functional aspects allowed for use there) for different projects.
We did Ruby first and O'Caml afterwards (we were to implement a scheme interpreter for the O'Caml project). Anyway, the impression I got was that most students hated O'Caml and loved Ruby, but while it was harder to get used to working in O'Caml I loved what the typing system did for me.
Every time I'm working in a language like Ruby and suffer from a bug a type system would have caught, it frustrates me. Perhaps for other programmers, every time they have to do extra work so the type inference works when in a language like Ruby they wouldn't have to, they get frustrated.
I prefer my frustration up front, and honestly, found that O'Caml told me, "You didn't think of this nimrod" mostly when I needed it, and rarely when it was just being a pain.
I don't understand why you need monads to get STM. orElse is neat, but there are other ways to do the same thing in imperative languages.
I quote Simon Peyton-Jones: "STM requires runtime logging of every memory read and write. In an imperative language (such as C#), in which the very fabric of computation involves reads and writes, STM is bound to be expensive. [Lots of work has been done to omit redundant logging based on program analysis, but it's still expensive.] When do you need readTVar/writeTVar? Answer, precisely when you are manipulating state shared between threads."
http://www.0x61.com/forum/programming-haskell-cafe-f245/is-t...
It looks like STM works better for functional languages and you have to mark shared data somehow. And then you have to mark the code that manipulates shared data somehow (so it won't prematurely launch missiles). Then you're reinvented monad.
I reserve right to be wrong so I'd like to see what are the ways for imperative languages.
Oh, tons of work has been done in trying to bring STM to imperative languages, most notably with STM.NET (which is what SPJ's referring to there).
With the same performance, static protection against irreversible side-effects, and clever aversion of the privatization problem? I'm not aware of any. While STM can be theoretically done in any memory-safe imperative language, Haskell -- mainly because of its purity and type system -- seems to be the only language in which it can be fast enough and correct enough for practical use.
edit: well, Clojure restricts mutability too, so STM is sort of tractable there, but it doesn't get the other benefits that Haskell's type system gives you.