HN Theater @HNTheaterMonth

Here's a example from the New York Times--Haskell in the Newsroom.

Eric Hinton (whose first programming language was Haskell) gave a phenomenal talk about the cultural shift to Haskell at NYT, and the interesting ways in which they use it.

Some examples include Fashion Week image processing to analyze which colors are in style, building composite images by hue (and the massive speedups they get from parallel processing), book review analysis, high-speed video processing, and so on.

Worth checking out just to gain a newcomer's perspective to programming, what they were able to accomplish with Haskell, and how they integrated it into their existing environment.

[0] http://www.infoq.com/presentations/haskell-newsroom-nyt

EDIT: Clarity.

Haskell is used in the NYTimes special features group that deploys 60+/yr web apps.

http://www.infoq.com/presentations/haskell-newsroom-nyt

tldw:

- RoR shop, too slow and can't afford to scale simply by spinning up more AWS instances.

- Haskell type system results in fewer bugs, less downtime than RoR.

- Haskell's Conduit library is great for information flow (e.g. scanning Twitter firehose for breaking stories).

- Static binaries for easy deployment.

- Declarative style and expressiveness helps coworkers understand code quickly.

⬐ virtualwhys

It's worth pointing out that the presenter's first language was Haskell and he's been coding in it for over a decade.

LYAH won't get you from apples to expert in weeks, much less months; more likely years.

Consider me skeptical -- needing to build the latest and greatest of Haskell [7.8] from source on a modern Linux distro (CentOS binary with antiquated libgmp.so.3 dependency, seriously?) is a gigantic PITA compared to virtually every other language where you just download a standlaone binary of latest & greatest from langugage X, modify your PATH, and hit the ground running.

⬐ dllthomas

Why do you need to build the latest and greatest? Building the very latest gcc/clang is also going to be a PITA. In either case, there's a perfectly servicable binary distribution and the stuff packaged in my OS's repo is still plenty usable.

⬐ virtualwhys

> Why do you need to build the latest and greatest?

Why shouldn't I? When Scala 2.11 was released I downloaded the binary, changed my PATH, fired up a new terminal and started exploring the latest release. Takes 2 minutes or so.

I'd like to do the same with Haskell. 7.8 looks to have significant language improvements that I want to explore vs. read about and be stuck on 7.4.1 (Fedora 18's provided version).

⬐ dllthomas

So go ahead and download the binary:

https://www.haskell.org/ghc/download_ghc_7_8_2#binaries

You're not comparing apples to apples.

⬐ virtualwhys

> So go ahead and download the binary

Indeed I did just that, the issue is that the only binary distributions for Linux are CentOS 6 and some flavor of Debian, both of which are dinosaurs compared to any modern distro. The long and short is the installation fails due to a missing dependency on antiquated libgmp.so.3, thus cooking my CPU for an hour and building from source.

If you want to talk about barriers to Haskell adoption, this is certainly one of them.

⬐ dllthomas

"both of which are dinosaurs compared to any modern distro."

Without any clue of what constitutes "any modern distro" in your mind, I don't see how this can proceed further. Note that Centos 6.5 and Debian wheezy are the latest from their respective projects. I believe the Debian version will happily install under recent Ubuntu and derivatives.

I'm sorry your preferred distro doesn't have better support.

⬐ virtualwhys

Fedora here, Debian's not an option (which would work as it's got the libgmp every "modern" Linux distro has).

CentOS binary is the only choice and it won't work. FWIW CentOS 6 is equivalent to Fedora 12 or so (latest is Fedora 20).

Anyway, it's done, but a serious PITA, hopefully in future there will be a more sane way to get started exploring the latest & greatest.

⬐ massysett

There are builds for both 32- and 64-bit Linux that were made on a Debian Wheezy system which depend on libgmp.so.10, which usually gets you GMP 5.x.

http://www.haskell.org/ghc/download_ghc_7_8_2

⬐ coolsunglasses

IMVUs average spin-up time for new engineers that don't know any Haskell is ~8-15 days.

I don't recommend LYAH and don't think it's an efficient way to learn Haskell at all.

My guide for learning Haskell: https://gist.github.com/bitemyapp/8739525

Should get you going quickly.

In this video Erik Hinton talks about using Haskell in the fast-paced New York Times environment:

http://www.infoq.com/presentations/haskell-newsroom-nyt

⬐ arms

This is one of the better Haskell videos I've seen - it's nice to see use cases in a high speed environment like the NYT.

⬐ cgag

Love the bit about conduits, lenses and data abstraction, really excellent stuff. The intro may not be interesting for people already into haskell but he makes a solid case for it if you're not sold.

⬐ Goopplesoft

A bit off topic but that crowd was awfully dry. This guy had a pretty good sense of humor and made his keynote quite entertaining but not even a chuckle from the audience.

⬐ larrybolt

Not having any experience with Haskell it's very entertaining to watch him talk about the topic. Even to the point where it seems like learning Haskell is highly rewarding.

On top of that, because he gives examples from "Fashion week", I can watch his presentation with my girlfriend who has absolutely no programming skills whatsoever but thinks it really cool! Gives a bit of perspective that programming isn't only about making boring web-apps. (Of course the game-industry proves programming can be fun, but this shows a different aspect than games.)

⬐ Goopplesoft

Absolutely, I really enjoyed it as a non-Haskell guy as well.

⬐ revertts

Often that's just because the mic isn't setup to capture audience noise - I've been to a few lectures where the audience was very engaged/entertained, but from the recording you'd think they were all sitting there in complete silence.

⬐ Goopplesoft

ah that makes sense. Was a bit annoyed because it seemed like every attempt he made to warm the audience up failed.

⬐ Kototama

Great talk. The cameramen zoomed on the guy just when the slides with some code are shown! Anyway the slides can be found here:

http://codemesh.io/slides/erik-hinton.pdf

⬐ rwosync

I think this really gets to the core strength of Haskell, which for me has always been having code that we can rapidly prototype but migrate into production and have living in the codebase for a long time. I've written code in good deal of languages and haven't found a language with the power/weight ratio that Haskell has.

The slight cost I have found though is that a lot of the tools he mentioned have a rather steep learning curve ( monads, parsec, repa, conduits, lens ) especially for those coming from an imperative background. But learning any of them is an investment in your programming skills that pays off ten-fold down the road.

⬐ QuantumChaos

Also, it has a fairly shallow learning curve when it comes to syntax (compared to say, lisp), at least for someone coming from a C family background. I learned Haskell after a period of doing a lot of Python programming, and I find the syntax of the two very similar.

⬐ yarrel

Haskell has a much more baroque syntax than Lisp and it really doesn't compare to the C family syntactically or executionally. At best it's a kind of Pythonized Prolog that thinks Perl is a model rather than a warning.

⬐ nnq

> it has a fairly shallow learning curve when it comes to syntax

Now imagine a pilot saying: "fighter jets have a fairy shallow learning curve compared to gliders"... Syntax has nothing to do with it and you will never find a language with simpler syntax than Lisps.

(and let's just pretend Common Lisp does not exist - I bet you are scared by Lisp because you've seen code written by an experienced CL hacker, and I know, it tends to scare the shit out of you at first sight :) )

⬐ chrismonsanto

I would prefer Haskell with a Lisp syntax. Haskell's syntax adds a lot of accidental complexity to the language. My #1 complaint is how infix operators can be imported and assigned precedence/associativity. It is nearly impossible for a human to parse unfamiliar code, let alone understand it. And the sheer size and complexity of the grammar also rears its head when doing non-trivial metaprogramming.

We create these problems for ourselves when we write languages with complicated grammars. And for what? So people don't have to learn how to read Lisp code? A lot of the gain of Haskell is that the super strong type system constrains the form of programs, making it easier to reason about them. Well, constraining the syntax has similar benefits. One being that now my editor can more effectively "reason" about the surface syntax of a program. See Paredit, which enables functionality that isn't possible unless you can easily find the extent of an expression.

⬐ lgas

There is Liskell: https://github.com/haskell-lisp/liskell

⬐ chongli

Lisp has a lot of syntax complexity that lies hidden under the covers. Sure, symbolic expressions appear regular and uniform but macros are often radically different from functions in syntax, despite looking otherwise identical in application. A big offender in this regard is the loop macro.

⬐ thirsteh

Completely agree. 9 times out 10, something compiles and works as expected, and can stay working in production for years. I don't know of any other language where I can do this and keep developing (and prototyping) the codebase.

(This is not to say that testing isn't necessary--in fact Haskell offers an amazing framework for fuzz testing, QuickCheck--but 100% code coverage unit tests is a pointless endeavor in Haskell.)

I will say that "rapid prototyping" of new applications is a bit tedious in Haskell (mainly because of the cabal etc. bootstrapping work you have to do), but prototyping new features in existing ones is smooth.

⬐ gregory144

Why do you say that unit testing is pointless in Haskell?

Edit: My bad - I missed the 100% part.

⬐ codygman

"100% code coverage unit tests is a pointless endeavor"

Thirsteh said 100% coverage of unit tests is pointless, not that unit testing itself is pointless. I'm not totally sure what thirsteh means by "100% is a pointless endeavor" though.

⬐ ehsanu1

thirsteh said that 100% code coverage is pointless, not that unit testing is pointless.

⬐ freyrs3

He said that aiming for 100% code-coverage tests in Haskell is pointless, not that unit-testing itself is pointless. Which I think is a pretty reasonable given that a lot of bugs cannot exist by construction in a lot of Haskell code.

Personally I very much enjoy unit-testing in Haskell especially with the new tasty library which makes combining all the Unit/QuickCheck/SmallCheck tests very pleasant.

[1] http://hackage.haskell.org/package/tasty

⬐ thirsteh

Indeed. I'm not a fan of 100% code coverage tests in any language, but it's especially apparent in Haskell where, as you said, if code compiles (and you keep most of your functions pure), there are whole classes of bugs that simply cannot exist.

⬐ axilmar

> Completely agree. 9 times out 10, something compiles and works as expected, and can stay working in production for years. I don't know of any other language where I can do this and keep developing (and prototyping) the codebase.

How is this even possible? Haskell can't catch the logic errors done over time and space, and these errors are the majority of errors in all programming languages, Haskell included.

⬐ thirsteh

I'm not trying to say you can't make errors in Haskell, just that, if you know what you're doing, slip-ups are extremely rare in the language. (Hence "9 times out of 10.")

It's true, to some extent, with other statically checked languages, but they usually don't have separation effects, sum types, etc.

⬐ axilmar

> if you know what you're doing

So it's 9 times of ten if you know what you are doing, which is hardly the most often case.

⬐ thirsteh

> So it's 9 times of ten if you know what you are doing, which is hardly the most often case.

If you don't at all know what you're doing, you're gonna fail every time, anywhere. It is obviously subjective, and I don't think I implied otherwise.

Do you know what sum types are? If so, won't you agree with me that there are many kinds of errors you can make in languages without them than in ones where the compiler complains if you haven't e.g. covered each constructor in a pattern match?

Even more so with separation of effects, and other things that only really exist in Haskell.

⬐ axilmar

> If you don't at all know what you're doing, you're gonna fail every time, anywhere.

Not really. In programming, most of the time you think you know what you are doing but you really don't remember all the states and all the details, which results in bugs.

> Do you know what sum types are?

I do.

> If so, won't you agree with me that there are many kinds of errors you can make in languages without them than in ones where the compiler complains if you haven't e.g. covered each constructor in a pattern match?

In non object-oriented languages or in object-oriented languages without abstract methods, it's certainly possible.

In object-oriented languages with abstract methods, it's not possible: for each missing case the compiler will complain with an error.

> Even more so with separation of effects, and other things that only really exist in Haskell.

Separation of effects doesn't really improve the situation with bugs. A bug may have its cause inside a pure computation.

⬐ thirsteh

Okay, it appears we fundamentally disagree, so let's end the discussion here.

⬐ drhodes

For those who missed it, there's a newish project called the holy haskell project starter. It generates a skeleton project with cabal sandbox, tests and a Foo/Bar module example: http://yannesposito.com/Scratch/en/blog/Holy-Haskell-Starter...