61–70 of 93 posts
Haskell occupies a niche similar to Hamilton's quaternions (for classical physics) and Heisenberg's matrices (for quantum mechanics) - not mandatory, inaccessible to the masses and abandoned with haste once a more intuitive tool is found.
But they will always be there if you need them.
Earlier quoted context omitted.
I believe you are attributing a library issue to a language. Reasoning about laziness? Polymorphism that can only be implemented using existential types plus Typable? Even purity is a double-edged sword (some algorithms are inherently mutable)[1]. Some of Haskell's problems in real-life projects can definitely be attributed to the language itself. So the practical reason for using Haskell today is to take advantage o…
> Polymorphism that can only be implemented using existential types plus Typable? I'm curious where you came across this. In an external library you were using, or in the process of trying to implement some kind of dynamic typing in your own code?
class Cond a l where
applies :: a -> TreePos Full l -> Bool
data Condition l =
forall c . (Cond c l, Eq c, Show c, Typeable c) => Condition cEarlier quoted context omitted.
Haskell is beautiful, I love it, but I can easily see his points. There are a few traps one can easily fall in: - Reach a point in a complex application where it becomes hard to reason what laziness will do to performance. - End up in type-hell. E.g. some libraries extensively use existential quantification of type variables. Before you know it, you are chasing "type variable x would escape its scope"-type or error m…
> Artificially pure packages. There are some packages that link to C libraries, but (forcefully) provide a pure interface. (Or in other words: purity is just convention) Explain? What would the alternative be? > Using functions with worse time or space complexity, to maintain purity. This seems like the opposite of your previous complaint. > For a lot of code you end up using monads plus 'do' notation, making your pr…
Box the value that is the result of evaluation an expression that calls impure code in IO?
This is what I'd expect for calling impure code in third-party libraries.
Instead of:
fibServer x = quickHttpServe $ writeBS $ B.pack $ show (fibonacci x)
fibServer = quickHttpServe . writeBS . B.pack . show . fibonacci
fibOf42Server = quickHttpServe . writeBS . B.pack . show . fibonacci $ 42
main = print = main = foo >>= print
Anyway, it's a little style thing, but it's nice to use the composition operator (.) when you want composition and the application operator ($) when you want application. It makes the code look nicer and it shows its intent more clearly. And really, they are different concepts, even if they both type-check the same.
And finally, remember that function application, by default, is the highest-precedence operator in Haskell. When you write:
foo . (bar 42) . baz
foo . bar 42 . baz
Earlier quoted context omitted.
How those languages fare in other fields, like, constraint programming? http://hackage.haskell.org/package/monadiccp The real point is that Haskell is quite good in many areas and is excellent in parallelism and concurrency. While other languages are excellent in concurrency and not so good in other areas. Those many languages are the answer for the sole field of concurrency and Haskell is the answer when you combine…
Sure Haskell is good for more than just concurrent programming, but the article was leaning on concurrency and parallelism in its comparison with Node.js And I should also point out that said "blub" languages can also implement those features which they lack that Haskell includes by design. Some have better features than Haskell, IMO (ie: Qi/Shen sequent types and the ability to turn the type system off when you don'…
Lisp can do some of these, but it is not exactly a "blub" language. Is there a nice comparison of Qi and Haskell? Once you implement such a large, non-trivial system (such as an advanced type system), I really doubt using Lisp macros rather than implementing a compiler is easier. Macros that do such non-trivial things also do not compose well, so I doubt Lisp is beneficial for this purpose.
What's more important is applying some important concepts in haskell - functional programming and dividing your program into tiny self-contained parts. You can write this way in most languages - Ruby, Python, Scala, etc. The fancier parts of Haskell - lazy evaluation, static typing, whatever - are less important to making software that works than its functional nature.
Let's have a talk about the $ operator. When you use it more than once per line, you're writing code that looks weird and is hard to read. Switch to the similar function-composition operator, and everything looks more idiomatic. Instead of: fibServer x = quickHttpServe $ writeBS $ B.pack $ show (fibonacci x) Just write: fibServer = quickHttpServe . writeBS . B.pack . show . fibonacci The case for $ is where you want…
a . b . c . d $ e
a $ b $ c $ d $ e
Let's have a talk about the $ operator. When you use it more than once per line, you're writing code that looks weird and is hard to read. Switch to the similar function-composition operator, and everything looks more idiomatic. Instead of: fibServer x = quickHttpServe $ writeBS $ B.pack $ show (fibonacci x) Just write: fibServer = quickHttpServe . writeBS . B.pack . show . fibonacci The case for $ is where you want…
Earlier quoted context omitted.
The problem is not why one "would be willing to put a few weeks or months into learning their most important tool", but why one would be willing to put a few weeks or months into learning the next silver bullet, and repeat that two or three times a year. Experienced developers have learned that, typically, newer languages are better than older ones, but they typically do not get better by leaps and bounds across the…
I don't think anyone has been advocating any programming language as the "next silver bullet". Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn. Additionally, Haskell isn't a new little "fad" language. It is a pretty old research effort that accumulated many novel and useful ideas that are worth learning. I understand someone who…
The question then raised is whether any given new programming language or paradigm will bring that 5% productivity gain, and in what circumstances. If it were an obvious and clear path to greater productivity, and superior to other paths to greater productivity (such as spending more time learning your editor and shell and environment, or learning about a new library in the language your work is written in, or learning new tricks in your current language), no one would hesitate to increase their productivity in this way.
You seem to assume that people are choosing not to become more productive by opting not to switch to Haskell or learn Haskell or something about Haskell. There are thousands of programming languages. Shall we learn them all to become five thousand percent more productive?
I'm not opposed to learning new languages. I think folks should tinker. But, I don't think it is provable that learning Haskell will make you more productive than other activities.
Earlier quoted context omitted.
The problem is not why one "would be willing to put a few weeks or months into learning their most important tool", but why one would be willing to put a few weeks or months into learning the next silver bullet, and repeat that two or three times a year. Experienced developers have learned that, typically, newer languages are better than older ones, but they typically do not get better by leaps and bounds across the…
I don't think anyone has been advocating any programming language as the "next silver bullet". Even a small productivity gain (say 5%) over a long period of time can make a very large difference, and is worth spending weeks to learn. Additionally, Haskell isn't a new little "fad" language. It is a pretty old research effort that accumulated many novel and useful ideas that are worth learning. I understand someone who…
So, yes, I agree that learning about languages is something one should do often, but I do not think one should try to become fluent in a new language (and its libaries) too often.
And yes, IMO that does apply to Haskell, too.