Should you use Haskell for a new project?

What are the pros and cons of trying to do a new project in Haskell, as opposed to some more mundane imperative language like Python or Java? Let's assume for the sake of argument that you are doing this for an employer, rather than for yourself as a side project. And let's also assume that you have a bit of Haskell experience, but like most programmers most of your work has been in mundane imperative languages.

To begin with, there are a couple of concerns that might kill an attempt to use Haskell.

1. You might not be able to get management approval. Haskell is an obscure language with a reputation for difficulty. The bosses might well say no. 
2. You might need to work with an existing codebase in something like Java or Python. Not possible from Haskell.

If those don't kill the project, there's the cost-benefit tradeoff. On the benefits side:

1. Haskell code is very concise. (definitely) And greater concision means faster development. (possibly) 
2. Haskell code is less likely to contain errors, because of very strict typing. (probably) 
3. Haskell coders are disproportionately capable, because the language is obscure and difficult. (probably)

On the costs side:

1. You have much more experience in other languages. It would take at least a year, maybe two before you'd be up to pro standards in Haskell. 
2. The community of Haskell programmers is small. It might be difficult to hire anyone if the project grew; you might be faced with training someone from scratch, not just in a new language, but in a new programming paradigm.

So, this isn't anything like a slam dunk. Quite the opposite, actually. There are a couple of issues that might nix the project right up front, and then a daunting cost-benefit calculation.

Steve Yegge on Google's Engineering Culture

The ever-voluminous Steve Yegge wrote an interesting post back in 2012 about liberal and conservative elements in programming. By "conservative", he means practices that emphasize safety and rigor; "liberal", conversely, emphasize freedom and flexibility. He then used these labels to categorize programming languages, features, development practices, and cultures.

Here's what he had to say about Google's engineering culture:

Google -- Diagnosis: Conservative. They began life as slightly liberal and have grown more conservative ever since. Google was only software-liberal in the very very early days, back when the search engine itself was written in Python. As they grew, they quickly acquired a software conservatism driven entirely by the engineers themselves.  Manifestos were written about the dangers of using multiple languages, and strict style guides were put in place to severely limit "risky" or "hard to read" language features of the few languages they did allow.  ...  In internal surveys, Google engineers commonly cite bureaucracy, churn and complexity as core obstacles to feature advancement and rapid launches.  Google has made serious attempts on several occasions to reduce this bureaucracy, but they always get pushback from -- surprise -- the engineers themselves, who have grown so staunchly conservative that they actively (and even more often, passively) resist the introduction of more flexible stacks and technologies.  ...

Having seen Google from the inside, I can say Steve nailed it. I had expected Google to be sort of an over-grown startup, a really intense place where you had to work extremely hard, but where you had a lot of freedom to do things however you wanted, as long as it worked. What I found was something quite different: a culture that was incredibly strict[1], top-down[2], and bureaucratic[3].

If Steve is right, what I expected to find at Google is actually found at Amazon and Facebook.

[1]: Check out the C++ style guide (click "Toggle all summaries" to see the document in its full form). Then consider that the code review culture routinely enforces all of it. I remember having check-ins rejected for spaces at the ends of lines, for example.

[2]: I still think I should have quit or transferred the day my lead rejected the fifth rewrite of a design document.

[3]: The most prominent manifestation of Google's bureaucratic nature is the "promo packet", an elaborate document used to apply for promotion. It is typically at least a dozen pages long, with a long series of testimonials by the applicant's bosses and peers singing his praises for the promotion committee. It's like going up for tenure or a partnership, but it's done for every step up, not just once in your career.

Building a Compiler, Briefly

During the last meeting of the Toronto Haskell group, we briefly discussed the question of how to build a compiler, and in particular the problem that building a real one is a daunting task.

I've done a bit of digging into various approaches and guides. There are a lot of them, because every respectable CS curriculum needs a compilers course.

The one I find most intriguing is by Niklaus Wirth, the guy behind Pascal and Modula-2. In his "Compiler Construction" PDF, he guides you through building a compiler as a series of exercises in a bit over a hundred pages. Given that other texts run well past 500 pages, a tractable treatment is quite a relief. I get the impression you could work through the guide in 2-3 of weeks full time or perhaps a quarter as a side project.

That said, Wirth does make some simplifications for pedagogical purposes. The source language is Oberon-0, which is a pared-down version of Oberon, so almost but not quite a real language. The target architecture is a simplified RISC instruction set, with an interpreter that fits in a page. You build the compiler from scratch, rather than using tooling like ANTRL, parsec, or LLVM, which you'd presumably leverage in an actual implementation. And the treatment of code optimization is brief. So, choices were definitely made.

But all in all it is possible to make building a simple compiler the work of a couple of weeks rather than a months-long slog.

Three functional programming languages

Scala is a functional programming language that is designed to work well with Java. That doesn't come free, of course. The language makes some compromises to play well with legacy Java code and the JVM, but it does make Scala a very good Java 2.0. If you are interested in functional programming and want a language that you may actually get to use professionally, Scala is the safe bet. But it will not cure your cynicism.

Programming in Scala

Lisp was shot in the head a generation ago by Algol-style syntax, but like Lisbeth Salander, it never quite died. A tenacious band of enthusiasts keeps insisting the language is special, and has never been proved wrong. If you want to learn a timeless classic of a language with a reputation for changing the way you look at programming, Lisp is a good choice. Also, Paul Graham will send you a mash note.

Practical Common Lisp

Haskell is a pure functional programming language known for extreme expressivity. SkyNet would be 300 lines in Haskell, tops. Its relentlessly orthodox functional nature will force you to confront, interrogate, and ultimately deconstruct the imperative paradigm you have been trained in. You will see imperative coding for the fire-lit cave that it is and depart for a sun-bright world of functional programming. (Actual results may vary -- Platonic enlightenment not guaranteed.)

Learn You a Haskell for Great Good

Dynamic typing vs static

A programming language is statically typed if the type of every variable has to be declared when it is created. Pascal, C, and Java are all statically typed. In dynamically typed languages, on the other hand, the types of variables are not declared up front; you just assign a value (however created) to a variable. Python and Lisp are dynamically typed.

One of the perennial arguments among software developers is whether dynamic or static typing is best. Generally speaking, the proponents of static typing emphasize security: having to declare the type of every variable gives the compiler a lot of information about what can be done with it, allowing the compiler to catch a lot of errors. The fans of dynamic typing, on the other hand, emphasize flexibility and brevity; which translate to development speed. Redundancy like this, in Java, is their enemy:

Foo foo = new Foo();

My background features mostly languages with static typing (C++ and Java). It wasn't until I got to Google that I had a chance to work with a major system written in a dynamically typed language (Python). This was TNT, a system for running end-to-end tests in the ads serving pipeline.

Overall, I found dynamic typing to be more hindrance than help for the project. I kept running into typing mismatches that in statically typed languages would have been caught at compile time, but which didn't show up until run-time in TNT. And since the system takes half an hour to run, the difference between run-time and compile-time error reporting is huge.

My take-away from this experience is that dynamic typing is great for small projects that run quickly and fit between one pair of ears. In those cases, the redundancy and verbosity of declared types just gets in the way. But the larger the project, and the slower the debugging cycle, the more helpful static typing becomes.

I'm hoping Dart's system of optional type declarations catches on and makes it into Python at some point.

Akin to blasphemy

From Programming in Scala by Odersky/Spoon/Venners:

If you're coming from an imperative background, such as Java, C++, or C#, you may think of VAR as a regular variable and VAL as a special kind of variable. On the other hand, if you're coming from a functional background such as Haskell, OCaml, or Erlang, you might think of VAL as a regular variable and VAR as akin to blasphemy.

TRVTH.

FP languages are expressive

I've spent this week learning functional programming using two languages from opposite ends of the FP space: Haskell, an uncompromisingly functional language, and Scala, which mixes in some OO concepts with an eye to inter-operation with Java.

The central argument for FP is expressivity. Because of the power of the tools FP languages offer, you are supposed to be able to get a lot done with only a few lines of code.

To test this claim, I used both languages to implement a program from The Practice of Programming by Kernighan and Pike. The program reads in a file of text, generates a Markov-chain transition map from it, and then uses the map to produce random text. The authors implemented this program in several major languages, and found that the amount of code needed varied significantly: the C program was 150 lines, the Java was 105, and C++ clocked in at 70 lines.

Both Haskell and Scala did better than this. The Haskell program was 45 lines, and Scala did even better, at 41(!).

As far as I can tell, the FP enthusiasts' claim of greater expressivity is right on the money.