Why I Love Haskell: An Example
thenewsh.blogspot.com
thenewsh.blogspot.com
Skipping out on that visibility when showing how Haskell is expressive seems like a missed opportunity.
You don't search for words in the documentation etc., but enter the type of the function you want. This often works pretty well.
For beginners who are likely to be searching for core libraries, the other Hoogle might be more useful.
Note that this is true even though I reversed the argument order. It does fuzzy-matching of some sort. It will also help if you know the name of the function, since it searches those, too.
So you can give it "blah" and "Blah" and it would find the method "capitalize" for instance.
Hoogle is like that but for Haskell, and instead of giving inputs and outputs you give it a few types and it looks for them in the function signatures.
https://play.golang.org/p/UPlzWR5OCO
Gives the same result as https://www.ietf.org/mail-archive/web/tls/current/msg03416.h... SHA256 test vector.
Looks easier to understand, to me...
Anyways, it probably is simpler, because it doesn't solve the same problem that the Haskell code solves. The Haskell code allows you to generate some bytes from the infinite stream even if you don't yet know how many you need; your go version must know how many you need before you start.
In order to do the same thing in go you're going to need to use an iterator or a goroutine + channel. Try doing that as cleanly as the Haskell version.
Here's a slightly modified version of bluefox's code where the prf function returns an unbounded io.Reader: https://play.golang.org/p/ZAj8q4eXEi
And here's a version that's modified a bit more, but still essentially the same, to trade LOC for matching the spec very cleanly: https://play.golang.org/p/Rpy0yIwVN1
Writing and Reading to a pipe only errors if the pipe has been closed. We return an io.Reader, instead of an io.ReadCloser, so consumers can't close the Read side. Internally, the Write side is never closed either. So, in practice, Reading and Writing also won't ever error.
The point is it no longer looks so superior to the Haskell version, especially since there were many LOC in the haskell version just defining the Key datatype which go never does.
There is no doubt a steep learning curve with Haskell and FP in general. You may be thinking: what is all this <$> <*> and $ nonsense! However once learned, you can look at the Haskell code and it is more clear precisely what it is doing (and what it can't possibly do).
I think the article undersells Haskell. Haskell gives you code purity. Purity means you can reason about a function. A function that takes in an Int and returns an Int won't read data from your disk. It won't call a web service to get the answer. It won't update the counter int on your class and then one day cause it to overflow, causing another class that reads the counter int to throw an exception. This makes maintaining code a hell of a lot easier and more pleasant.
> Haskell provided a very light-weight syntax.
> Haskell allows partial-application of functions.
> Haskell allows definitions of unbounded data structures...
> Higher-order functions like "iterate" and "map"...
> Monads allowed me to avoid having to explicitly track side effects ... [also] purity and strong type checking.
> Libraries of higher order functions for monads allowed me to limit the syntactic cost of using monads.
Finally, the last point does not contradict the first. You can have lightweight syntax and use it to express heavyweight ideas. Then you can have libraries which help to alleviate that weight. This is a non-trivial task—it involves the abstraction power of your language and, in the case, the logical power of your type language.
If you're going to make an audacious claim then we need to see evidence to support that claim. The author didn't do this. All the author did was show us a Haskell implementation.
Not everything is a paper in Nature. I understand your point but he's honest about it just being a propaganda piece.
And, frankly, what's wrong with that?
Thanks to the author for taking the time to share.
That it doesn't solve OUR problem, which is "help us chose if Haskell if better", even though it pretends to?
Is there anything good on doing web development in a functional style? I keep hearing about Om and Clojurescript in relation to React, but I have no idea where to start.
Functional languages reward (require?) a different kind of problem domain analysis than imperative languages do, and one of the things they are least good at is "I want to track the state of a bunch of discrete things that share similarities in structure", ie, 90% of Web programming. (But then again maybe that's only 90% of web programming because OO was the fad-of-the-day when web programming took off.)
There's the old adage that data structures tell you a lot more than flowcharts; languages like Haskell and ML kind of turn that on its head. Rather than using functions to apply and track changes of state to abstracted chunks of memory, you apply and track changes of state by composing the functions with each other. This is great for some problem domains (eg, I think there's a reason that so much prototyping and code analysis is done in Haskell and ML) and less great for others (interfacing with a table-based database always felt kludgey to me, for instance).
I do think they attract a certain type of person, namely the kind of person who prefers debugging on paper to debugging in memory. Haskell may well have a debugger, but I've never used it because I always do a static debug, usually with a physical code printout. Then again I'm also a crotchety geezer.
TL;DR: many functional languages aren't great for the kinds of problems a lot of developers today are trying to solve, but the process of refactoring those problems in a way that does make functional languages useful is often a Good Thing for a developer to do.
[0] I would argue it's not "functional" except in an accidental sense; it's a "symbolic" language that happens to have first-class functions. Lisp is mostly useful for writing more Lisp (but note "mostly"; I'm a confirmed Lisp Weenie and I find myself very productive in it).
The author picked a cryptographic function from a rather important and widely deployed real-world internet protocol (TLS 1.2), but of course since the author is writing about Haskell readers assume it must be some esoteric academic nonsense that undoubtedly involves category theory, whatever that is.
- HLint, a very helpful linter for ideomatic Haskell
- QuickCheck, Fuzz-testing function's properties
- hpc, Pretty code coverage
The libraries you mentioned though are indeed all really fantastic, and after learning how to use them you'll miss them dearly when they're unavailable.
-- Vim:
haskellmode-vim for show type and insert type, among other things.
ghcmod-vim for HLint and HCheck, also used by Syntastic and NeoComplCache.
neco-ghc uses ghcmod-vim for nifty Haskell completion, powered by neocomplcache.
Syntastic automatic syntax checking for vim.
--Emacs:
structured-haskell-mode: https://github.com/chrisdone/structured-haskell-mode
haskell-emacs: http://chrisdone.com/posts/haskell-emacs
Most companies don't prioritize paying a potentially highly compensated worker to learn an obscure language when the job can just as effectively be solved using standard skills and languages that are much easier to acquire(hire).
Also, despite the passionate defence that many functional-first language advocates give, I have never seen any conclusive evidence that these languages, in general, produce better results than the standard suspects.
Choosing something like Haskell or anything else niche should be a group decision. Even when it comes to prototyping! "Guys, I'm going to prototype this .NET code in F#. Who wants to join?", instead of a developer sitting in a corner applicating his functors while others around him do something arguably simpler. It's incredibly short-sighted!
This is not aimed at you though, since I'm not sure if this was your case, I'm only guessing based on your post.
When pressed in combination with the alt button, it can navigate back to the previous page I was viewing. But not when someone captures onkeypress and cancels it.