6 ms·

I'm glad that the author is picking up a new functional programming language, but choosing OCaml over Haskell because of support for the Javascript implementati

I'm glad that the author is picking up a new functional programming language, but choosing OCaml over Haskell because of support for the Javascript implementations strikes me as choosing a BMW over a Mercedes[0] because of the number of cupholders it has. If you don't have a particular goal in mind (ie, "I work at Jane Street and need to be compatible with our existing code"), there are a number of other factors in the OCaml vs. Haskell discussion that are far more important. > JS is the only realistic way to write web apps Javascript is the only realistic way to write the front-end of webapps. But that doesn't mean you're wedded to it for your backend technology. And I don't think either OCaml or Haskell have sufficiently advanced DOM bindings, etc. that I'd recommend using either one for client-side work in the browser. [0] I'm not sure if this is a flamewar topic for car nerds - my point is to pick two high-end luxury cars that are both well-respected and each have their own merits.

copergi 13y ago
I write all my javascript in haskell, and haven't had any problems. What do you need/want "DOM bindings" for?
- rprospero 13y ago
  As someone who would like to write his javascript in Haskell, how do you put text on the page without interfacing with the browser's DOM?
  - copergi 13y ago
    Is that a trick question? I don't know how or why you would try to do that.
    - jarrett 13y ago
      You do it all the time in web apps. For example, changing the text of a toggle link between "show" and "hide." For example, with jQuery: $('#toggleLink').click(function() { if ($('#toggleLink').html() == 'Show') { showRollout(); $('#toggleLink').html('Hide'); } else { hideRollout(); $('#toggleLink').html('Show'); ] });
      - copergi 13y ago
        I think you misread something. He asked how to do it without manipulating the DOM.
    - rprospero 13y ago
      I assure you that it's not a trick question, just a poorly worded one. Imagine that I'm making a page that converts meters to millimeters. The obvious part of the haskell code is convert :: Double -> Double convert = 1000 * The part which isn't obvious to me is how I get input from the user or display the result. I know how to do that in the IO monad through standard haskell, but I wouldn't know how to handle it in Haskell compile to javascript for the web browser. I would have thought that you would need a binding to the DOM to read from forms and the like.
      - copergi 13y ago
        I think fay uses its own FFI, but with haste you just use the normal FFI to call normal javascript functions the same way you would interface with C code from haskell. There's no need for special bindings or anything. You could certainly make a wrapper for jquery if you were crazy (and I'm sure someone has already done so), but this idea that you need some special DOM library to do things that javascript already does out of the box is kinda odd.
        rprospero 13y ago
        Thanks for the clarification. The key part that I was missing was the FFI. I'd encountered projects like this in the past with either no FFI or no documentation for the FFI and I couldn't figure out how to talk to the DOM. I'm more than happy to drop down to javascript for those parts, but I wasn't sure that I'd have the option.
  - nightski 13y ago
    http://elm-lang.org/ http://elm-lang.org/ for example. To display text in the browser you would use - main = plainText "Hello, World!" From the page: "Elm is a functional language that compiles to HTML, CSS, and JavaScript". So yes, technically this is working with the DOM. But you are not writing code that interacts with a "DOM binding" directly per se.
    - platz 13y ago
      I'm excited for PureScript for the property that it compiles to sane javascript. http://purescript.readthedocs.org/en/latest/intro.html#hello-purescript http://purescript.readthedocs.org/en/latest/intro.html#hello...
      - nightski 13y ago
        Awesome, had not heard of this project before! Thanks for sharing.
    - rprospero 13y ago
      I've played with Elm for a toy project before and I do have high hopes for it. I also think it's the greatest monad tutorial ever - you don't truly miss them until they're gone. (To clarify: At the time that I last used Elm, the Signal type was a functor, but was intentionally being kept from being a monad for design reasons. Working around this restriction tought me a lot on why I needed monads.
      - groovy2shoes 13y ago
        I didn't really understand applicative functors until I was playing with Elm. Working with Signals was pretty fun, and when I found out they were applicative functors, it was like a light bulb going off above my head. Elm is a really fun way to start exploring purely functional programming.
  - mutagen 13y ago
    I'm curious about this as well so I did some searching. Fay[1], a subset of Haskell that compiles to JavaScript, seems to be the primary choice. There are DOM and jquery bindings for it and this blog post[2] looks like a great introduction. There are other options, this [3] article outlines a number of them as a greater overview of both server and client side programming with Haskell. I also found an intriguing article [4] on the Haskell site but it appears to be out of date, referencing libraries that are no longer in development. [1]https://github.com/faylang/fay/wiki https://github.com/faylang/fay/wiki [2]http://ocharles.org.uk/blog/posts/2013-12-23-24-days-of-hackage-fay.html http://ocharles.org.uk/blog/posts/2013-12-23-24-days-of-hack... [3]http://www.stephendiehl.com/posts/haskell_web.html http://www.stephendiehl.com/posts/haskell_web.html [4]http://www.haskell.org/haskellwiki/Haskell_in_web_browser http://www.haskell.org/haskellwiki/Haskell_in_web_browser
skybrian 13y ago
It sounds like you have a very language-centric view of the world. In practice, deployment is everything. (Why do people write code in Objective C? Because iPhone.) Having a solid implementation for your target platform is very good reason to pick a language.
- chimeracoder 13y ago
  > It sounds like you have a very language-centric view of the world. > Having a solid implementation for your target platform is very good reason to pick a language. I'm not sure where you got that out of my comment; it was exactly the opposite. My point was that neither OCaml nor Haskell have particularly strong implementations in this area (to my knowledge). Last time I checked, the ability to write Javascript using both languages was of experimental and/or novelty use only (hence the "cupholders"). And that still doesn't change the fact that a web app can be written in any language - the only part that needs to run in Javascript is the client-side. Depending on how you architect your app, this may not be much at all. (There are very few webapps that actually need much logic in Javascript - if you want to avoid JS[0] while writing complex webapps, it's actually very easy to do so in many cases.) [0] or anything else that is translated into JS
  - avsm 13y ago
    > Last time I checked, the ability to write Javascript using both languages was of experimental and/or novelty use only (hence the "cupholders"). Facebook uses an OCaml js_of_ocaml-based frontend for a large chunk of their production code editing. Not a great video, but here's the CUFP 2013 talk on the topic: http://www.youtube.com/watch?v=gKWNjFagR9k http://www.youtube.com/watch?v=gKWNjFagR9k
  - coolsunglasses 13y ago
    Haste is a strong, useful, and impressively complete Haskell to JS compiler. Fay is used in production apps as well. PureScript is less mature still but pretty nice.
    - 13y ago
fzltrp 13y ago
Car metaphors don't always match well with the situations they try to illustrate. Obviously if you had the chance to be offered either one of these two cars, you'd probably try them out and pick the one you feel the most comfortable with, but also which would best fit your needs. If all other factors have been weighted, and it boils down to the number of cup holders, would you stop there short of making a choice, because of the apparent superficiality of the argument? The author expressed his interest in both languages, and brought other arguments than just the js one.
deleted 13y ago
[deleted]
coolsunglasses 13y ago
What's weirder about this is Haskellers have no problems using Fay, PureScript, and Haste for JavaScript.
jfb 13y ago
BMW has legendarily terrible cup holders, by the way.
alphonse23 13y ago
See, from what I took from the article, is that maybe it would make for a really solid client side web application language. On the other end of this, i feel like server side languages are moving more into the direction of multi-core support, i.e. Rust, Golang, Erlang... oCamel could fit nicely as a client-side web application language for DOM manipulation, like ClojureScript -- at least that's my take on it, but it really couldn't compete with the newer multi-core languages -- speedwise.
spyder81 13y ago
js_of_ocaml has excellent DOM bindings: http://ocsigen.org/js_of_ocaml/api/index http://ocsigen.org/js_of_ocaml/api/index I'm also looking at whether TyXML can be used with js_of_ocaml for statically typed goodness: http://ocsigen.org/tyxml/ http://ocsigen.org/tyxml/
kristianp 13y ago
It does seem a little spurious at first, but part of the argument is that as js apps get larger, a static, functional language can be argued for to avoid problems with larger js codebases.

copergi 13y ago

I write all my javascript in haskell, and haven't had any problems. What do you need/want "DOM bindings" for?

rprospero 13y ago
As someone who would like to write his javascript in Haskell, how do you put text on the page without interfacing with the browser's DOM?
- copergi 13y ago
  Is that a trick question? I don't know how or why you would try to do that.
  - jarrett 13y ago
    You do it all the time in web apps. For example, changing the text of a toggle link between "show" and "hide." For example, with jQuery: $('#toggleLink').click(function() { if ($('#toggleLink').html() == 'Show') { showRollout(); $('#toggleLink').html('Hide'); } else { hideRollout(); $('#toggleLink').html('Show'); ] });
    - copergi 13y ago
      I think you misread something. He asked how to do it without manipulating the DOM.
  - rprospero 13y ago
    I assure you that it's not a trick question, just a poorly worded one. Imagine that I'm making a page that converts meters to millimeters. The obvious part of the haskell code is convert :: Double -> Double convert = 1000 * The part which isn't obvious to me is how I get input from the user or display the result. I know how to do that in the IO monad through standard haskell, but I wouldn't know how to handle it in Haskell compile to javascript for the web browser. I would have thought that you would need a binding to the DOM to read from forms and the like.
    - copergi 13y ago
      I think fay uses its own FFI, but with haste you just use the normal FFI to call normal javascript functions the same way you would interface with C code from haskell. There's no need for special bindings or anything. You could certainly make a wrapper for jquery if you were crazy (and I'm sure someone has already done so), but this idea that you need some special DOM library to do things that javascript already does out of the box is kinda odd.
      - rprospero 13y ago
        Thanks for the clarification. The key part that I was missing was the FFI. I'd encountered projects like this in the past with either no FFI or no documentation for the FFI and I couldn't figure out how to talk to the DOM. I'm more than happy to drop down to javascript for those parts, but I wasn't sure that I'd have the option.
- nightski 13y ago
  http://elm-lang.org/ http://elm-lang.org/ for example. To display text in the browser you would use - main = plainText "Hello, World!" From the page: "Elm is a functional language that compiles to HTML, CSS, and JavaScript". So yes, technically this is working with the DOM. But you are not writing code that interacts with a "DOM binding" directly per se.
  - platz 13y ago
    I'm excited for PureScript for the property that it compiles to sane javascript. http://purescript.readthedocs.org/en/latest/intro.html#hello-purescript http://purescript.readthedocs.org/en/latest/intro.html#hello...
    - nightski 13y ago
      Awesome, had not heard of this project before! Thanks for sharing.
  - rprospero 13y ago
    I've played with Elm for a toy project before and I do have high hopes for it. I also think it's the greatest monad tutorial ever - you don't truly miss them until they're gone. (To clarify: At the time that I last used Elm, the Signal type was a functor, but was intentionally being kept from being a monad for design reasons. Working around this restriction tought me a lot on why I needed monads.
    - groovy2shoes 13y ago
      I didn't really understand applicative functors until I was playing with Elm. Working with Signals was pretty fun, and when I found out they were applicative functors, it was like a light bulb going off above my head. Elm is a really fun way to start exploring purely functional programming.
- mutagen 13y ago
  I'm curious about this as well so I did some searching. Fay[1], a subset of Haskell that compiles to JavaScript, seems to be the primary choice. There are DOM and jquery bindings for it and this blog post[2] looks like a great introduction. There are other options, this [3] article outlines a number of them as a greater overview of both server and client side programming with Haskell. I also found an intriguing article [4] on the Haskell site but it appears to be out of date, referencing libraries that are no longer in development. [1]https://github.com/faylang/fay/wiki https://github.com/faylang/fay/wiki [2]http://ocharles.org.uk/blog/posts/2013-12-23-24-days-of-hackage-fay.html http://ocharles.org.uk/blog/posts/2013-12-23-24-days-of-hack... [3]http://www.stephendiehl.com/posts/haskell_web.html http://www.stephendiehl.com/posts/haskell_web.html [4]http://www.haskell.org/haskellwiki/Haskell_in_web_browser http://www.haskell.org/haskellwiki/Haskell_in_web_browser

skybrian 13y ago

It sounds like you have a very language-centric view of the world. In practice, deployment is everything. (Why do people write code in Objective C? Because iPhone.) Having a solid implementation for your target platform is very good reason to pick a language.

chimeracoder 13y ago
> It sounds like you have a very language-centric view of the world. > Having a solid implementation for your target platform is very good reason to pick a language. I'm not sure where you got that out of my comment; it was exactly the opposite. My point was that neither OCaml nor Haskell have particularly strong implementations in this area (to my knowledge). Last time I checked, the ability to write Javascript using both languages was of experimental and/or novelty use only (hence the "cupholders"). And that still doesn't change the fact that a web app can be written in any language - the only part that needs to run in Javascript is the client-side. Depending on how you architect your app, this may not be much at all. (There are very few webapps that actually need much logic in Javascript - if you want to avoid JS[0] while writing complex webapps, it's actually very easy to do so in many cases.) [0] or anything else that is translated into JS
- avsm 13y ago
  > Last time I checked, the ability to write Javascript using both languages was of experimental and/or novelty use only (hence the "cupholders"). Facebook uses an OCaml js_of_ocaml-based frontend for a large chunk of their production code editing. Not a great video, but here's the CUFP 2013 talk on the topic: http://www.youtube.com/watch?v=gKWNjFagR9k http://www.youtube.com/watch?v=gKWNjFagR9k
- coolsunglasses 13y ago
  Haste is a strong, useful, and impressively complete Haskell to JS compiler. Fay is used in production apps as well. PureScript is less mature still but pretty nice.
  - 13y ago

fzltrp 13y ago

Car metaphors don't always match well with the situations they try to illustrate. Obviously if you had the chance to be offered either one of these two cars, you'd probably try them out and pick the one you feel the most comfortable with, but also which would best fit your needs. If all other factors have been weighted, and it boils down to the number of cup holders, would you stop there short of making a choice, because of the apparent superficiality of the argument? The author expressed his interest in both languages, and brought other arguments than just the js one.

deleted 13y ago

[deleted]

coolsunglasses 13y ago

What's weirder about this is Haskellers have no problems using Fay, PureScript, and Haste for JavaScript.

jfb 13y ago

BMW has legendarily terrible cup holders, by the way.

alphonse23 13y ago

See, from what I took from the article, is that maybe it would make for a really solid client side web application language. On the other end of this, i feel like server side languages are moving more into the direction of multi-core support, i.e. Rust, Golang, Erlang... oCamel could fit nicely as a client-side web application language for DOM manipulation, like ClojureScript -- at least that's my take on it, but it really couldn't compete with the newer multi-core languages -- speedwise.

spyder81 13y ago

js_of_ocaml has excellent DOM bindings: http://ocsigen.org/js_of_ocaml/api/index http://ocsigen.org/js_of_ocaml/api/index I'm also looking at whether TyXML can be used with js_of_ocaml for statically typed goodness: http://ocsigen.org/tyxml/ http://ocsigen.org/tyxml/

kristianp 13y ago

It does seem a little spurious at first, but part of the argument is that as js apps get larger, a static, functional language can be argued for to avoid problems with larger js codebases.