Static types are great, but I don't use them in practice(brehaut.net)
brehaut.net
Static types are great, but I don't use them in practice
http://brehaut.net/blog/2013/static_types
3 comments
Btw., ML is from the 1970s...
I've found the opposite. Granted, Scheme is an exceptionally productive language. However, I recently worked on a project in Racket and then moved over to Haskell. I've found Haskell to be more productive even in the very short term.
Now, admittedly, not all the productivity gain is from types. However, they certainly help me, not just in making the code robust but also in writing it in the first place. And typeclasses actually do make the language concretely more expressive in certain ways.
Admittedly, Haskell is very different from other languages and requires a good investment to learn in the first place. However, I think it's well worth it.
Now, admittedly, not all the productivity gain is from types. However, they certainly help me, not just in making the code robust but also in writing it in the first place. And typeclasses actually do make the language concretely more expressive in certain ways.
Admittedly, Haskell is very different from other languages and requires a good investment to learn in the first place. However, I think it's well worth it.
> Now, admittedly, not all the productivity gain is from types. However, they certainly help me, not just in making the code robust but also in writing it in the first place. And typeclasses actually do make the language concretely more expressive in certain ways.
You said you started out in Racket. Did you try Typed Racket? You don't necessarily need to move to Haskell to get a type system (though you won't get typeclasses).
You said you started out in Racket. Did you try Typed Racket? You don't necessarily need to move to Haskell to get a type system (though you won't get typeclasses).
I looked at it, but never used it. I certainly like the core idea and it would probably have been better for me than just using plain Racket. However, moving over to it--and getting other people to use it--would not have been that much easier than moving to Haskell.
I was missing some specific type features: algebraic data types with pattern matching and custom numeric types (I needed 18-bit unsigned ints, of all things). I don't think Racket supports either of these. The numeric types, I suppose, are just a special case of wanting typeclasses. I really like typeclasses :P.
Additionally, I had several non-type-related reasons to move to Haskell: laziness, purity (my teammates decided that global variables and having IO everywhere are fun) and more functional data structures (vectors in particular).
I was missing some specific type features: algebraic data types with pattern matching and custom numeric types (I needed 18-bit unsigned ints, of all things). I don't think Racket supports either of these. The numeric types, I suppose, are just a special case of wanting typeclasses. I really like typeclasses :P.
Additionally, I had several non-type-related reasons to move to Haskell: laziness, purity (my teammates decided that global variables and having IO everywhere are fun) and more functional data structures (vectors in particular).
Yeah, ML-family languages generally aren’t designed for rapid development, but rather for building reliable software. I haven’t used ML or OCaml extensively, but do use Haskell at work. Granted, it does take longer to write code than in a language with a more relaxed type system. But I don’t really mind, because the end product is invariably constructed well and with great care. More time developing, less time debugging.
And really, type errors are supposed to be helpful. In fact they usually are, unless somebody decided to get overclever. With typeclasses, for example, you can do a lot of neat things you probably shouldn’t in real code! But if the error messages are unhelpful, that is a failing on the part of the implementation as well.
And really, type errors are supposed to be helpful. In fact they usually are, unless somebody decided to get overclever. With typeclasses, for example, you can do a lot of neat things you probably shouldn’t in real code! But if the error messages are unhelpful, that is a failing on the part of the implementation as well.
My number one preference: longer blog entries. That's part of a more general preference, for analyzing information. When I'm reading, I know what kind of thing I expect in a blog post, and I know what I expect to return…
…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 discourse and have a different opinion. We're talking about preferences.
…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 discourse and have a different opinion. We're talking about preferences.
have a look at typed clojure
https://github.com/frenchy64/typed-clojure
https://news.ycombinator.com/item?id=4697634
https://github.com/frenchy64/typed-clojure
https://news.ycombinator.com/item?id=4697634
While they have a lot of advantages over neanderthal languages like C, and it's great that once you've gotten your program to compile, whole classes of bugs will be virtually impossible, I much prefer programming in Scheme.
With ML and OCaml, I really hated spending hours wrestling with the compiler and puzzling over obscure error messages that seem to require taking college level courses in type theory in order to understand.
In comparison, programming in Scheme (and even Common Lisp) is incredibly quick and easy, and a real joy.
True, when I need maximal robustness, I do wind up spending a lot more time writing unit tests in Scheme than I would in ML or OCaml. But for rapid prototyping and programming as I think, Scheme is very hard to beat.