Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why OCaml, Why Now?

spyder.wordpress.com

Post reply on HN
Print view View original

61–70 of 106 posts

Re: Why OCaml, Why Now?

#61

Post by copergi »

jarrett wrote: post #30
copergi wrote: post #11

Earlier quoted context omitted.

Is that a trick question? I don't know how or why you would try to do that.

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'); ] });

I think you misread something. He asked how to do it without manipulating the DOM.

Re: Why OCaml, Why Now?

#62

Post by copergi »

rprospero wrote: post #49
copergi wrote: post #11

Earlier quoted context omitted.

Is that a trick question? I don't know how or why you would try to do that.

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 H…

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.

Re: Why OCaml, Why Now?

#63

Post by alphonse23 »

chimeracoder wrote: post #4

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 t…

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.

Re: Why OCaml, Why Now?

#64

Post by lpw25 »

bunderbunder wrote: post #40

Considering how strongly opposed the author is to dynamic typing, I'm actually kind of surprised they'd consider OCaml's type system to be acceptable. Technically, yes, it's a statically typed system. But its use of structural typing instead of nominative typing effectively means it takes half the compiler assistance you can get out of static type checking and chucks it out the window. Using structural typing means t…

Also, only some things in OCaml are structurally typed (modules, objects, polymorphic vairants), others are not (records, variants). For example:

    # type meters = I of int;;
    type meters = I of int

    # let meters i = I i;;
    val meters : int -> meters = 

    # type newtons = I of int;;
    type newtons = I of int

    # let newtons i = I i;;
    val newtons : int -> newtons = 

    # let f b = if b then newtons 12 else meters 12;;
    Characters 36-45:
      let f b = if b then newtons 12 else meters 12;;
                                          ^^^^^^^^^
    Error: This expression has type meters but an expression was expected of type
             newtons

Re: Why OCaml, Why Now?

#65

Post by dstefan »

kasey_junk wrote: post #58
dstefan wrote: post #56

Earlier quoted context omitted.

What are you mean at "not-quite-as-good-as-haskell"? What are the killer features of haskell?

Not the original commenter but for me the big ones are purity and cheap direct access to C code.

You can program in pure mode in scala too(and scalaz framework helps in it). FFI is great but i don't miss it. For better performance there is the java collections and libraries.

Re: Why OCaml, Why Now?

#66

Post by srean »

jeremyjh wrote: post #51
srean wrote: post #17

Felix is to C++ what F# is to C# http://felix-lang.org/share/src/web/tut/tutorial.fdoc (I am not the author, just excited about this language) OCaML programmers will feel immediately at home. It is a mature yet actively developed whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ and has coroutines and threads baked in, although use of threads is somew…

Have you actually used Felix? I agree it's a neat language but it felt to me like I'd really have to come up to speed on C++ to make much use of it. It's "FFI" is basically embedded strings of C++ source.

You can of course inline C++ snippets in Felix code as you mentioned, but that is not the only way to talk to C++. Felix allows you to create a Felix object from a C++ object (and the reverse) with minimal glue. Take a look here http://felix-lang.org/share/src/web/tut/cbind_index.fdoc.

With this two styles the boundary between Felix and C++ can be very fluid. It does not incur the typical efficiency hit of a dynamically loaded FFI, although it does allow dynamically loading shared libraries too.

If you dont want to use C++ libraries and classes from Felix, you dont need to know C++ to use Felix.

Re: Why OCaml, Why Now?

#67

Post by kenko »

srean wrote: post #17

Felix is to C++ what F# is to C# http://felix-lang.org/share/src/web/tut/tutorial.fdoc (I am not the author, just excited about this language) OCaML programmers will feel immediately at home. It is a mature yet actively developed whole program optimized, strongly typed, polymorphic, ML like language that can interact effortlessly with C and C++ and has coroutines and threads baked in, although use of threads is somew…

AFAICT you mention Felix whenever OCaml comes up, generally saying more or less the exact same thing each time.

Re: Why OCaml, Why Now?

#68

Post by spyder81 »

chimeracoder wrote: post #4

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 t…

js_of_ocaml has excellent DOM bindings: 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/

Re: Why OCaml, Why Now?

#69

Post by spyder81 »

mas644 wrote: post #27

Look, I love OCaml and it's my favorite language syntax-wise, but the real big elephant in the room is not its JS-backend maturity. Rather it doesn't have kernel thread support...all threads are user-level just like Python due to a global lock for garbage collection. This means threads do not run concurrently across multiple cores. This is UNACCEPTABLE in 2014 - roughly 8 years since processors went multi-core. Intel…

Yeah, I should've addressed this in my post. Right now multicore doesn't mean squat to me as I'm using it for JavaScript support. I did investigate this, but forgot to add the links (others have already replied with) about work that is progressing nicely.

I'll update the post once this traffic calms down a bit :)

Re: Why OCaml, Why Now?

#70

Post by throwaway7808 »

detrino wrote: post #33
talex5 wrote: post #24

Earlier quoted context omitted.

Don't feel too bad about it. The official OCaml tutorial is also confused: http://ocaml.org/learn/tutorials/structure_of_ocaml_programs... (someone really should go through these tutorials and fix the various misleading parts) Basically, the rule is to use "let () = ..." for your main block / top-level code and don't use ";;" ever.

For reference, here is the tutorial's example reformatted in a more reasonable way: open Random open Graphics let rec iterate r x_init i = if i = 1 then x_init else let x = iterate r x_init (i - 1) in r *. x *. (1.0 -. x) let main () = self_init (); open_graph " 640x480"; for x = 0 to 639 do let r = 4.0 *. (float_of_int x) /. 640.0 in for i = 0 to 39 do let x_init = Random.float 1.0 in let x_final = iterate r x_init…

The trouble with Ocaml is that you will probably get something like:

  $ ocaml o.ml
   File "o.ml", line 2, characters 0-13:
   Error: Unbound module Graphics
And after you've googled for a while and had done:

  sudo apt-get install liblablgl-ocaml-dev
The thing would install 23(!) packages. And after that you will get:

  $ ocaml o.ml
   Exception: Graphics.Graphic_failure "fatal I/O error".
After which, if you've been in the industry for a decade or two, you will probably decide that you'd better stop wasting your time on that particular language. Besides. It just looks ugly. Almost as ugly as perl.
Post reply on HN