211–220 of 227 posts
If Haskell, Lisp and friends are so great for building large software systems then surely people are going to flock to them and do exactly that. And if that didn't happen, of course the proponents of these languages would sit down and try to figure out why this wasn't happening. Right?
Earlier quoted context omitted.
That does make more sense, and I appreciate the more thorough explanation. It seems a bit ironic though, that Python makes you more specific and certain about the output type than Haskell!
It is only ironic until you realize static typing can often save you from writing code, and not just require more code.
Earlier quoted context omitted.
It is only ironic until you realize static typing can often save you from writing code, and not just require more code.
In general, sure. Doesn't change that the "read" function seems to break the spirit of that.
Earlier quoted context omitted.
In general, sure. Doesn't change that the "read" function seems to break the spirit of that.
How so? Inferring which implementation of "read" to use based on the types is exactly the same spirit of inferring which implementation of "length" to use. Haskell can maintain consistency in both, but dynamically typed languages must revert to explicitly choosing the implementation in the former.
Earlier quoted context omitted.
I'm personally on a quest to "get" Haskell right now, but I really don't see what's so special about that or unique to Haskell. Languages have long accomplished what `read` does by simply casting/coercing the string into the desired type. In python, for example, I'd call int() on the input strings I want to turn into integers.
On your quest I'd recommend the following: http://www.amazon.com/gp/aw/d/0134843460 http://www.cs.yale.edu/homes/hudak/SOE/ http://book.realworldhaskell.org
Earlier quoted context omitted.
How so? Inferring which implementation of "read" to use based on the types is exactly the same spirit of inferring which implementation of "length" to use. Haskell can maintain consistency in both, but dynamically typed languages must revert to explicitly choosing the implementation in the former.
Yes, it goes nicely with that spirit. But it doesn't go nicely with "have a well-specified return type for all functions that you know in advance", as "read" can return anything. It's great for languages to pick the right implementation of "length" on the fly, but the point is, they all return integers. "read"? Who knows what type you'll get back in Haskell, the "you must specify [or at least plan out the] output typ…
Earlier quoted context omitted.
as a rubyist who has dabbled a bit in haskell, i think the two camps are exactly the same in terms of proselytising. it's just frustrating to see people using "less-capable" languages and imagining how much happier/more productive/safer they'd be if they only adopted yours.
The difference there is that Haskell actually does offer some functionality and concepts that aren't really present in most other programming languages. Ruby, on the other hand, is pretty unremarkable. It doesn't really offer anything beyond what older languages like Perl and Python, for example, offer.
That facilitates dsls and I believe it's important enough to note as significant.
Earlier quoted context omitted.
Yes, it goes nicely with that spirit. But it doesn't go nicely with "have a well-specified return type for all functions that you know in advance", as "read" can return anything. It's great for languages to pick the right implementation of "length" on the fly, but the point is, they all return integers. "read"? Who knows what type you'll get back in Haskell, the "you must specify [or at least plan out the] output typ…
Read in Haskell returns a well defined type, it just happens to be polymorphic.
Earlier quoted context omitted.
Read in Haskell returns a well defined type, it just happens to be polymorphic.
By that broad a definition of "a well defined polymorphic type", so does every function in every language, at least those that can say "everything's an object/function/data/etc!"
Earlier quoted context omitted.
By that broad a definition of "a well defined polymorphic type", so does every function in every language, at least those that can say "everything's an object/function/data/etc!"
the type is statically checked, not dynamically checked. Unlike something that just returns an unknown existential "object" type.