CoffeeScript vs Haskell

With CoffeeScript, there's never really a question of what is going on. If you're worried that something went wrong in the compilation process, the output is very human readable and mostly 1 to 1 with the CoffeeScript code, making debugging easier as the code that is being executed by the interpreter can be double checked.

CoffeeScript is the most popular of the compile to Javascript languages, so long term support is much less of a worry than with others.

It also means there are many plugins and tools for integrating it into many different build systems, giving it it nearly universal support.

Javascript is a very verbose language so CoffeeScript's goal is to lighten it to make it less tedious.

Various design choices are built around making CoffeeScript more terse with things like optional parenthesis in function calls, cleaner function declarations, no curly braces, and significant white space. Because Javascript can get pretty deeply nested at times, having a lightweight syntax helps with readability.

The result is a language with a minimalistic syntax with lots of syntax sugar.

The golden rule of CoffeeScript is: "It's just JavaScript". The code compiles one-to-one into the equivalent JS, and there is no interpretation at runtime. You can use any existing JavaScript library seamlessly from CoffeeScript (and vice-versa). The compiled output is readable and pretty-printed, passes through JavaScript Lint without warnings, will work in every JavaScript runtime, and tends to run as fast or faster than the equivalent handwritten JavaScript.

CoffeeScript adds syntax that is not only more terse than javascript, smoothing over the rough edges, but also enforces a more human readable syntax to the point where a non-programmer can understand some logic.

Many programmers that are not use to coffeescripts syntax will find it foreign if they don't read the single page API, but generally it is quick to understand and although self documenting code is a myth coffeescript is definitely very close.

if hungry then eat food for food in fridge when food isnt poison and it isnt bedtime

Seems a lot more concise and comprehensible to many programmers and most others than the alternative syntax:

var food, i, len;

if (hungry) {
  for (i = 0, len = fridge.length; i < len; i++) {
    food = fridge[i];
    if (food !== poison && it !== bedtime) {
      eat(food);
    }
  }
}

Passing functions as callbacks is central to how Javascript is written, but the default syntax for functions is very verbose and hard to read. Various CoffeeScript syntax decisions help with ease of writing and reading functions.

The most obvious change is that the function keyword is changed from function to ->. Writing out the word function is very clunky especially when you need to use multiple nested functions.

One of the more opinionated choices of CoffeeScript is the use of significant whitespace, and optional parens around function arguments. While this can be used poorly, it can also be used to great effect with nested functions. For example, a function that takes an object that defines anonymous functions will end in a mess of parens and curly braces:

asyncAction({
  success: function(data){ /* handle data */ },
  error: function(error){ /* handle errors */ }
});

In CoffeeScript you could rewrite this as:

asyncAction
  success: (data) -> /* handle data */
  fail: (error) -> /* handle errors */

Other helpful features are automatic returning of the last statement to make short anonymous functions easier so (a, b) -> a+b would replace function (a, b) { return a+b; }, as well as binding functions to the current context object with =>.

Because Javascript functions can take variable amounts of parameters, it is helpful to be able to use splats to extract an array of arguments in a function.

For example, if you have a function like: (a, b, rest...) ->any amount of parameters sent to the function after a, b will be stored in an array in the variable rest. You can also put splats at the start or middle of the arguments list, such as (a, middle..., b) ->.

When calling a function you can use a splat to apply an array as arguments as well.

Even for loops and if statements. For example, to get mapped array, you don't have to use any Array methods, just the language features:
food = ( stuff for stuff in fridge when stuff.isEatable() )

CoffeeScript was created by a Ruby programmer and a number of syntax features are modelled on Ruby equivalents, so will be familiar to Ruby programmers. For example, implicit returns, i.e. the last variable of each function is implicitly returned, so "return" keyword need not be present.

Skip the documentation build, just write documentation with literate CoffeeScript.

CoffeeScript has a literate mode which let's you use markdown (used by almost everything, such as reddit, github, stack exchange, etc) with code indented how you would normally in markdown and simply enables you to run the code.

This enables you to quickly write FORMATTED, custom documentation that's easily displayed with no build step for the documentation.

With source maps, you can get the proper location of where an error occurred directly in precompiled code, making it easier to debug without the tedious step of translating the compiled code back to the original code in your head.

Having indention-based code blocks is particularly helpful in JavaScript because of its functional callback based nature. In JavaScript you find yourself writing functions within object and passing functions to functions. You can find statements ending with a confusing melange of braces like )}})}). With significant whitespace, most of the needs for braces go away.

Easy to read and easy to work with structures like list.

Haskell's referential transparency, consistency, mathematics-oriented culture, and heavy amount of abstraction encourage problem solving at a very high level. The fact that this is all built upon little other than function application means that not only is the thought process, but even concrete solutions are very transferable to any other language. In fact, in Haskell, it's quite common for a solution to simply be written as an interpreter that can then generate code in some other language. Many other languages employ language-specific features, or work around a lack of features with heavy-handed design patterns that discourage abstraction, meaning that a lot of what is learned, and a lot of code that is needed to solve a particular problem just isn't very applicable to any other language's ecosystem.

It is pure and does not mix other programming paradigms into the language. This forces you to learn functional programming in its most pure form. You avoid falling back on old habits and learn an entirely new way to program.

All Haskell implementations are completely free and open source.

As Haskell lends itself exceedingly well to abstraction, and borrows heavily from the culture of pure mathematics, it means that a lot more code conforms to very high-level abstractions. You can expect code from vastly different libraries to follow the same rules, and to be incredibly self-consistent. It's not uncommon to find that a parser library works the same way as a string library, which works the same way as a window manager library. This often means that getting familiar and productive with new libraries is often much easier than in other languages.

Haskell's Purely Functional approach means that code is referentially transparent. This means that to read a function, one only needs to know its arguments. Code works the same way that expressions work in Algebra class. There's no need to read the whole source code to determine if there's some subtle reference to some mutable state, and no worries about someone writing a "getter" that also mutates the object it's called on. Functions are all directly testable in the REPL, and there's no need to remember to call methods in a certain order to properly initialize an object. No breakage of encapsulation, and no leaky abstractions.

Conciseness of Haskell lets us to write the expression on the whiteboard or paper and discuss with others easily. This is a strong benefit to learn FP over other languages.

The base language relies primarily on function application, with a very small amount of special-case syntax. Once you know the rules for function application, you know most of the language.

It's often said that, in Haskell, if it compiles, it works. This short feedback loop can speed up learning process, by making it clear exactly when and where mistakes are made.

Every function that expects more than one arguments is basically a function that returns a partially applied function. This is well-suited to function composition, elegance, and concision.

Haskell is a very terse language, particularly due to its type inference. This means there's nothing to distract from the intent of the code, making it very readable. This is in sharp contrast to languages like Java, where skimming code requires learning which details can be ignored. Haskell's terseness also lends itself to very clear inline examples in textbooks, and makes it a pleasure to read through code even on a cellphone screen.

Haskell is really popular in universities and academia as a tool to teach programming. A lot of books for people who don't know programming are written around Haskell. This means that there are a lot of resources for beginners in programming with which to learn Haskell and functional programming concepts.

Since the basic syntax is very similar to mathematics, Haskell syntax should be easy for people who have taken higher math courses since they would be used to the symbols used in maths.

Makes categorical higher order abstractions easy to use and natural to the language.