[eru]

> Learning a new framework that does the same thing like layout or user design; it's not like learning music and digging into a deeper discipline like moving from acoustic strumming to jazz improvisation, it's just learning new keywords to do the same crap because the old keywords have been remapped.

Perhaps you should look into Haskell, Clojure or Erlang for a change?

[retroencabulato]

I love HN. In response to a complaint about learning new frameworks, you suggest three other alternatives.

[WickyNilliams]

They are all languages (not frameworks), which are valid analogies to the guitar metaphor. They are so different from your usual C-like languages that they will be challenging to learn (and likely fun also)

[mercer]

I think the difference is not just that these are languages rather than frameworks, but also that each of these teach you different skills and approaches by their nature (that aren't 'new', so clearly have a stood the test of time).

[CmonDev]

All but one are profoundly old, yet making a come back.

[eru]

Haskell is from the 80s. Erlang is also pretty old, and Clojure is a Lisp, the second oldest programming language around. Which is the `but one'?

[CmonDev]

If you put it this way, Clojure is old too I guess.

[eru]

Though to be honest, Lisp has come a long way since the 50s.

[doktrin]

In the context of web applications, what do Haskell or Clojure bring to the table that makes them worth the learning curve?

[eru]

In the context of noname123's post they bring interesting learning to the table: they are not more of the same with renamed keywords. To quote,

> [...] it's not like learning music and digging into a deeper discipline like moving from acoustic strumming to jazz improvisation, it's just learning new keywords to do the same crap because the old keywords have been remapped.

Haskell _is_ digging deeper into the discipline.

I am sure one can make good arguments for some of the Haskell and Clojure frameworks for web applications. Alas, I am not qualified. I only used Haskell professionally for embedded development, and for rapid desktop application development, but I've never done web development seriously.

In any case, the Haskell answer for web development will probably include what all Haskell advocacy ever includes: purity and the strong static typing.

[chrisdew]

How do you Haskell on embedded systems? Are you talking about baremetal with 1-32K SRAM?

[sanderjd]

To take this thread yet further into self-parody, you might like Rust; it borrows some interesting stuff from Haskell (or really, the ML family), but is actively targeting embedded systems.

Edit: Also, I have heard that Ocaml can be made to work pretty nicely in an embedded environment.

[eru]

You can make OCaml (and Haskell) run on Xen, no need for a full blown operating system. (Not sure if that counts for anything.) The OCaml project for that is called mirage.

[eru]

No, not nearly that baremetal. I was talking about control processes running in dom0 of xen. They are embedded in the sense that there are `no user serviceable parts'.

(I just looked up embedded software on Wikipedia; it seems like the traditional use of the term is very different to how I used it here. Please pardon the confusion.)

[Ixiaus]

Ignoring the joy of writing software with much more powerful abstractions for a moment (Python, Ruby, JS, PHP all look like jalopies now compared to Haskell) out has very real industrial benefits:

Write software faster with fewer bugs, easier to maintain down the road because the "mental model" is maintained in the types by the compiler, it's more succinct, it's fast, some of the world's brightest computer scientists work on it, and so on...

[doktrin]

Thanks for your response. I'd like to dive a little deeper into the basis for these claims. My current stance is that there isn't sufficient reason to adopt Haskell for use in production.

> Write software faster with fewer bugs

Is there an evidentiary basis for the 'fewer bugs' claim? What type of software are people writing faster with Haskell?

>> easier to maintain down the road because the "mental model" is maintained in the types by the compiler

That seems fair.

>> it's more succinct, it's fast

In isolation, that's a bit hand wavy IMO.

>> some of the world's brightest computer scientists work on it

This is something I hear quite often from the Haskell community in particular. It may or may not be true, but it gets repeated far too often IMHO. It feels like a bit of an appeal to authority.

[eru]

>> Write software faster with fewer bugs > Is there an evidentiary basis for the 'fewer bugs' claim? What type of software are people writing faster with Haskell?

http://donsbot.wordpress.com/2007/05/01/roll-your-own-window... and especially http://donsbot.wordpress.com/2007/05/17/roll-your-own-window... give a good introduction into the mindset behind programming in Haskell.

The latter focusses on zippers. Zippers solve the problem of having a connection and a `cursor' into that connection to mark one element--in the case of XMonad we mark the window that has focus.

In C you would probably solve this with an array and an int. Unfortunately, the compiler can't help ensure that your int always points into the array, and that deleting and inserting are doing the right thing. Zippers help here.

[Ixiaus]

Interesting you should ask for more verification of my claim to fewer bugs because I'm about to embark on using Haskell in the new startup I'm working for and they may require stronger reasoning than I have been providing.

I've been thinking about how to qualify the claim logically or maybe quantify it. Anywho, aside from that I can tell you that the vast majority of bugs I introduce into my Python code (or other languages) are caught by GHC - these are bugs that purely have to do with my inability to remember what something is or is doing, or fear of refactoring something, or some tangled mess of types that are harder to reason about in Python because they're in my head instead of encoded in Haskell.

I've discovered that when I've been able to compile my Haskell programs the bugs I find in them are usually business logic bugs now. Occasionally I'll make use of QuickCheck / HUnit for automated property testing and unit testing, and that will help catch those business logic bugs.

Very subjective and anecdotal but I can promise you that the experience is very real.

> In isolation, that's a bit hand wavy IMO.

Sure, but if you take into account Haskell's denotational semantics vs. other language's operational semantics it should be pretty clear that Haskell inherits Mathematic's idiom for succinct expression. That idiom also informed the language designers when building Haskell's grammar and syntax, it's very flexible and abstract - both in the essence of the language (it's semantics) and its modality.

When reading idiomatic Haskell, there's a lot of information packed into a line, conceptually and syntactically.

> This is something I hear quite often from the Haskell community...

Sure, it probably borders on it, but in many ways other language communities commit the bandwagon fallacy (Go is one) - so I think you can poke holes all over the place. The fact though that proof proving systems and dependently typed languages like Agda and Idris (which are the future and I think will supplant Haskell unless Haskell can evolve) are being written in Haskell which speaks to the level of intellect and forward thinking in the community.

[59nadir]

> Ignoring the joy of writing software with much more powerful abstractions for a moment (Python, Ruby, JS, PHP all look like jalopies now compared to Haskell)

Just out of curiosity: Which abstractions are we talking about here that Haskell doesn't have? OO?

[Ixiaus]

I didn't write that sentence very well if that's how it was interpreted, sorry. I meant to say that the abstractions available to Haskell are more powerful.

I can't really think of any abstraction that's not available to it - even an Object System is possible in Haskell, it just wouldn't be as easy to use as Monads are.

[eru]

> I can't really think of any abstraction that's not available to it [...]

Dependent typing doesn't work very well in Haskell (yet).

[dasil003]

I believe he meant Haskell's abstractions are more powerful.