Don't bother. Go straight to Haskell and just Haskell.

No excuses, no compromises, no mental backflips to justify not learning something new. Learn Haskell properly and then see for yourself why "hybrids" are a waste of time.

Hybridized approaches are like asking for a hole in your bathroom floor when you're being offered indoor plumbing with a porcelain toilet instead of an outhouse.

But let me do something you didn't do, which is to actually explain my position. Hybrid languages afford a flexibility and power not available to language puritans. It's very nice to have things first-class DSLs that don't rely on slow monad stacks, heterogeneous lists that don't rely on existential qualification, stateful programming that isn't a type system hack (do I really need to understand existential uninstantiated types to twiddle a bit in a vector?), first-class side-effects without monad stack weirdness (unsafe escapes don't count), Turing-complete macros at load time, inheritance and class qualification that isn't crippling and/or dependent on weird compiler extensions... In the course of learning Haskell I find myself banging my head against a type-system wall to do something that would be trivial in Clojure or Scala.

Now I like Haskell, but Clojure and even Scala offer very flexible and powerful defaults together with programming escape hatches anywhere you want them. This is very powerful. It's not clear how to have a similar in a strongly typed strict language. Monads and weird compiler extensions don't cut it.

You can easily, easily spend more time debating it - learning nothing - than you would just checking it out for yourself.

If you were banging your head against the wall, you were suffering from bad pedagogy, not a bad language.

I went through the same experience! I know exactly what you're talking about, but you don't know what you're missing!

So lets stop debating and instead focus on fixing the pedagogy. You won't regret it.

Try this course: http://www.seas.upenn.edu/~cis194/lectures.html

Ping me via my email if you need help.

Why are you talking to me about Applicatives? Applicatives are easy. I'm not complaining about what the type system can do. I'm complaining about what it can't do. And it can't do a lot. For instance, it can't "safely" twiddle a bit in a vector without resorting to a compiler trick involving uninstantiable existentially typed monads. It can't produce DSLs that live outside the type straitjacket, so you get really complicated stuff, like the kudzu-like system of the Lens library, full of existential types and higher-rank types and restrictions, that still is not actually typesafe. And so on. I'm repeating myself already.

Monads and weird compiler extensions are not the same as a language that respects the programmer who wants to do something unusual. This is what I'm saying. Don't tell me about applicatives as a response. It's not a response, and it's insulting.

When you say "uninstantiable existentially typed monads" you're showing off your knowledge and being verbose when you actually mean "ST". There's no actual problem here, you're using big words to seem impressive despite the fact that by being obscure you're condescending to them and to me. ST works the way it does so you can't accidentally leak mutable references. There's nothing particularly limiting about it beyond that. ST is like a generic transients that works for any data type instead of the blessed ones.

You don't need to care that ST is existentially typed in order to use it at all. That's like complaining about how difficult it is to weld steel so you live in a mud hut instead. Division of labor applies here because abstractions and types work in Haskell.

There's nothing wrong with twiddling bits in Haskell. I do it all the time. You're complaining that the type system won't let you lie to your users and say a side effect is

    a -> ()
    -- instead of
    a -> IO ()

"Can't produce DSLs that live outside the type straitjacket" What? You can build a DSL on hash-maps and symbols in Haskell the same as Clojure users do. Haskell users don't do that because it sucks. ADTs and free monads are nicer.

Name-dropping lens as if it's a negative to Haskell is nuts. You're not obligated to use lens if you're still learning Haskell, but finding it difficult to use is a sign you miscalculated your knowledge.

The foundational building block of writing one's first lens is scrubbing out the (fmap . fmap) pattern, which is a use-case even Clojurians can relate to. There's no "there" there to complain about.

Your library 'clearley' would be easier to understand if it had types.

Have you considered a book like Joy of Clojure? http://www.manning.com/fogus2/ I found the first edition of Joy of Clojure improved and clarified my Clojure. Also, back off the defprotocol/defrecord in Clojure until your design is cleaner and more firmed up.

You're not here to be learn or share anything so I'm backing out of the conversation. Provided some clarity on the obtusity before parting.

tl;dr nonsense, intentionally obscure appeals to things that are "too complicated" which are comparable to refusing to drive a car you couldn't build yourself.

You can learn how to build the car later after you understand why it was engineered that way.

They have hijacked every sane discussion about programming into a condescending -- "Do you have monads and typeclasses ?".

It's absolutely unhealthy.

State is not Evil.

Languages like clojure, scheme take imperative features and give it more beautiful abstractions.

In what profession, do you find people complaining about the very foundations and thinking it's cool ? It's like Musicians saying Rhythm is stupid.

If you haven't written a State Machine with goto's and never marvelled at it's beauty ... please just try it.

I agree!

You're mistaken if you think Haskell users don't take advantage of state or side effects. They do, you just don't understand the difference.

Try this course:

http://www.seas.upenn.edu/~cis194/lectures.html

Then see LYAH's section on the State monad:

http://learnyouahaskell.com/for-a-few-monads-more

Then reflect on ST:

http://www.haskell.org/haskellwiki/Monad/ST

Then this example using mutable variables and closures:

http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions...

Side-effecting closures mutating variables!

It's not "no state or side effects".

It's about making state and side effects typed and explicit so they can be properly composed and manipulated.

I love that sentence. It makes me think Haskell is like Bartok.

http://www.sm.luth.se/csee/courses/timber/reading/VanRoy.pdf

http://www.epsa.org/forms/uploadFiles/3B6300000000.filename....

http://c2.com/cgi/wiki?ConceptsTechniquesAndModelsOfComputer...

I certainly didn't find Clojure to be a waste of time; to my mind it's a far more practically-minded language. It's philosophy of decoupling components is also interesting. For example, in Haskell, the static type system is coupled to the language; in Clojure, the static type system is an optional library.

I'm moving everything over that I can. Some legacy Clojure at work I'll have to leave alone for now, but going forward it's Haskell wherever I can.

What is your take on the "you have to write clever, complicated code to make haskell work" (1). I've read that a lot of the code use for the language shootout is far from idiomatic haskell, but just plain clever, in order to get decent performance...

(1): http://jxyzabc.blogspot.ca/2009/03/haskell-vs-ocaml-or-ravin...

Haha, no. I write pretty dumb Haskell myself. The author might've tripped into a library beyond their faculties. Also possible, they might've tried to make something "practical" before they really knew what they were doing. I made this mistake in the past myself.

The library I've been working on makes my boring Haskell obvious: https://github.com/bitemyapp/bloodhound/

I even tweeted a sample of my code making fun of how "stupid-simple" my Haskell is :)

I might refine the code later, but for now I'd rather KISS until I'm prepared to firm up the design.

You can get down a rabbit-hole with Haskell if you want, but the same is equally true of Clojure/Scala/C++/Ruby/Python/Perl.

Even then, the rabbit-hole at least has typed hand-rails.

Negatives?

Uhhh, missing libraries (which I am working to help remedy)

You develop a "nose" for libraries for which you aren't the audience. It's not a big or unavoidable negative, but there are definitely libraries on Hackage made to prove a point rather than for use in production. These libraries are easy to identify. Some of them are prefixed acme-*

The primary negative that matters is simply that Haskell is deeply unfamiliar to most working programmers, so while it's 100% worth it, the road to Haskell isn't as well-trodden or smooth as it would be going between Python <---> Ruby.

I'm working to remedy this as well. I've been teaching Haskell for the last ~6 months.

In reality this isn't necessary very often. It is important to understand persistent data structures, how they differ from imperative ones, and which to use in different situations. However with a good understanding of the fundamentals (just as in imperative code) you'll be writing idiomatic performant functional code fairly easily.

Everybody who hasn't should be learning Haskell, regardless of background.

Teaching somebody Haskell is faster than explaining why the 1,001 dumb things mainstream languages do are dumb. I don't want to waste my time explaining why null values are dropdead stupid when I can just show them "Maybe".

We can talk about where we're headed after that.

Another issue is that Haskell is somewhat weighted towards finance and they're a bunch that tends to be somewhat proprietary about their IP. Some exceptions (Ermine) exist.

Some notable projects that come to mind include git-annex and Parsec. Parsec has been preeminent parser-combinator library since forever.

Also: pugs, pandoc, gitit, Darcs, xmonad, Idris (same person that did whitespace, haha)

Recently? Cryptol. That's pretty major.

I'm building stuff in Haskell, right now. Specifically, the easiest to use Elasticsearch client in the world.

One was needed. Badly. The ES API's data structures were never specced out properly, just documented on an ad-hoc basis. The Haskell library I'm working on will, if nothing else, mean that there's a reference for how the JSON is structured.

Anyway, empower thyself, learn some Haskell: https://gist.github.com/bitemyapp/8739525

Edit:

Ah, I thought I knew that username from somewhere. The negative-nancy is Timothy Baldridge, an employee of Rich Hickey's company Cognitect. Cognitect is "the" Clojure company and represents the inner-clique.

On the other hand, I don't have to be a php'r to know facebook was built in that language or a C++ programmer to know what google has done with it.

The negative-nancy is Timothy Baldridge, an employee of Rich Hickey's company Cognitect.

By personally attacking a critic of your claims, you're only making your case weaker.

Personal attack? What personal attack? Are you reading the same comment I am? He identified someone. If identification amounts to a personal attack, then that would seem to indicate severe problems with the image of the person being identified!

Apart from the juvenile "negative-nancy", there's also the clear implication of ascribing untoward motives based on the person's identity.

Well, some projects document systems in MS WORD, you are using Haskell for documenting JSON structures. That's a step up.

The language flamewar is off-topic and inappropriate for HN. The personal attacks are beyond the pale.

> haskell + smart programming practices guarantee a crash

> free experience.

Yeah dwm, crashes all the time.

Why don't you try another approach to functional programming, like http://www.shenlanguage.org/ ?

If you think Haskell is The One True Way™, get a new pair of sun glasses.

/rant

Getting tired of puritans. You people are selling functional programming on the basis of "ideology", not merits.

Can the following be done in Haskell ?

* A Real Operating System.

* GPU programming.

* Embedded programming.

* If you can do all the above, can you replace Verilog ?

* Financial Programming.

  Ocaml is one of the "hybrids". Genetically impure,
  since it has "refs". But they have Jane Street.

  assertion : If all the haskell programmers are put in
  a gulag, they can't come up with a half-decent
  game. 
  
  Nintendo Gameboy Games were written in assembly with 
  goto's. 

  Why don't you guys take a moment and pat yourselves on
  the back ? Hypocrisy-2.0 is probably in the hackage. 
  

Haskell syntax is garbage.

(Common Lisp has a goto, gee what were they thinking ?)

Mathematicians pride themselves in their rich history of syntax.

Haskellers actually type "Arrow".

"I do consider assignment statements and pointer variables to be among computer science's most valuable treasures."

-- Only an Idiot could say that.

I don't know anything about the state of GPU programming in Haskell, so I'm not going to speak to that.

Regarding embedded, GHC can target some quasi-embedded platforms these days, but it's also possible to write embedded programs in (pardon the overloading) an embedded DSL that can compile to C. Check out the Atom library.

I've heard about some people doing hardware synthesis involving (again) embedded DSLs in Haskell - I don't really know the state of it, but IIRC Conal Elliot gave a talk on some related stuff at one of the Bay Area Haskell meetups.

Jane Street is doing a lot of O'Caml stuff, and that's awesome, but there's definitely a lot of Haskell in finance these days as well (I've seen several job postings, and heard some chatter generally). I don't know which is better represented, or how it compares to other stuff - most big finance places don't talk about what they're doing inside.

Oh, and Haskellers actually type "Arrow" when they're working with a particular generalization of functions. When they're actually working with functions, they type ->.

"GHC can target some quasi-embedded platforms these days, but it's also possible to write embedded programs in (pardon the overloading) an embedded DSL that can compile to C."

Haskell can't do any useful work without relying on C. Instead of having pride in what C can do, you have invented the following adjectives "hybrid", "mathematical language", "insecure", "impure", "pure".

Either,

1) Stop with the adjectives and get Real.

2) Prove that Haskell can replace C, the "impurity".

The same holds true for mathematical heritage. I would ask mathematicians to use Mathematica, not Haskell.

(I don't consider OCaml to be a part of this debate because OCaml is hybrid and Real, like C++)

Your and the haskell community's puritan behavior.

> you really don't know what you're talking about here.

Can't Parsec English ? I define the word hypocrisy, from a dictionary no less.

And Verilog is quite well entrenched, but if/when it's going to be replaced by something else, currently it seems that it will most likely be a Haskell derivative, something similar to Bluespec perhaps.

But can you clarify your point ? The cause of the rant seems to be for the "hybrids are a waste of time" line, however, most of the examples you provide are things that are currently done by, say, C/C++ but not by the hybrid languages.

Are you claiming that the hybrid languages are (or will be) much more widely used for developing 'A Real Operating System', embedded programming or mass-market games?

But on a different note, the reason why I program in Clojure rather than Haskell is that Clojure is so pragmatic. The JVM gives me access to almost every library I need, the JIT and GC are the fastest on the planet (for this sort of language). But most of all, Clojure trusts me. Clojure doesn't attempt to slap my hand when I make an impure function. It doesn't say "hey we can't figure out what type this function returns". Because at the end of the day, I don't care about that stuff. I only really care about writing good software, that fulfills my goals. If that means certain parts of my code are impure...I don't give a crap.

At least that's the way it's been for me for 4 years working with the language.

Huh? Haskell's polymorphism capabilities are more expressive and more expansive than most other languages'. Higher-kinded polymorphism, a mainstay in Haskell, is pretty rare to find almost anywhere else.