Live data from Hacker News

Code iOS Apps in OCaml

psellos.com

11–20 of 29 posts

Re: Code iOS Apps in OCaml

#11
post #2

OCaml is a highly underappreciated language. The biggest problem is the haphazard syntax, but if you can get over that, it's really a joy to use for application programming. You get the strongly-typed, type-inferred, functional aspects of Haskell, but without the drawbacks of laziness (for example, you can safely do IO outside the IO monad, and space leaks are less common) and with a simpler type system. There are no…

OCaml's largest problems, IMO, are: 1. Global interpreter-lock, and the effect that has on the ability to write multi-threaded programs. 2. False negative proof, the same issue Haskell has. The fact that it's "had its chance" to catch on and hasn't done so marks it as a failure (or "not production ready") in the eyes of people who make decisions. Scala has better odds than Ocaml and Haskell for this reason alone. 3.…

The global interpreter lock is a large one IMO. One of the huge advantages of type safety is that you can use types to help enforce thread safety rules, but if the interpreter itself can't handle it, that's a huge problem!

Re: Code iOS Apps in OCaml

#12
post #2

OCaml is a highly underappreciated language. The biggest problem is the haphazard syntax, but if you can get over that, it's really a joy to use for application programming. You get the strongly-typed, type-inferred, functional aspects of Haskell, but without the drawbacks of laziness (for example, you can safely do IO outside the IO monad, and space leaks are less common) and with a simpler type system. There are no…

OCaml's largest problems, IMO, are: 1. Global interpreter-lock, and the effect that has on the ability to write multi-threaded programs. 2. False negative proof, the same issue Haskell has. The fact that it's "had its chance" to catch on and hasn't done so marks it as a failure (or "not production ready") in the eyes of people who make decisions. Scala has better odds than Ocaml and Haskell for this reason alone. 3.…

> is Scala an acceptable ML?

I thought it might be until I tried OCaml, and the difference between type inference that only works on locals and pervasive inference is huge. Also the fact that JVM interop makes it hard to avoid null pointers is a big strike against it.

Still, I agree that the odds are in its favour vs OCaml for things that don't need to be close to the metal.

Re: Code iOS Apps in OCaml

#13
post #11

Earlier quoted context omitted.

OCaml's largest problems, IMO, are: 1. Global interpreter-lock, and the effect that has on the ability to write multi-threaded programs. 2. False negative proof, the same issue Haskell has. The fact that it's "had its chance" to catch on and hasn't done so marks it as a failure (or "not production ready") in the eyes of people who make decisions. Scala has better odds than Ocaml and Haskell for this reason alone. 3.…

The global interpreter lock is a large one IMO. One of the huge advantages of type safety is that you can use types to help enforce thread safety rules, but if the interpreter itself can't handle it, that's a huge problem!

Is the global interpreter lock there in AOT compiled code too or just in interpreted code? (IIRC OCaml supports both compiled and interpreted)

Re: Code iOS Apps in OCaml

#14
post #11

Earlier quoted context omitted.

The global interpreter lock is a large one IMO. One of the huge advantages of type safety is that you can use types to help enforce thread safety rules, but if the interpreter itself can't handle it, that's a huge problem!

Is the global interpreter lock there in AOT compiled code too or just in interpreted code? (IIRC OCaml supports both compiled and interpreted)

Both - it's required for the garbage collector.

Re: Code iOS Apps in OCaml

#15
post #2

OCaml is a highly underappreciated language. The biggest problem is the haphazard syntax, but if you can get over that, it's really a joy to use for application programming. You get the strongly-typed, type-inferred, functional aspects of Haskell, but without the drawbacks of laziness (for example, you can safely do IO outside the IO monad, and space leaks are less common) and with a simpler type system. There are no…

OCaml's largest problems, IMO, are: 1. Global interpreter-lock, and the effect that has on the ability to write multi-threaded programs. 2. False negative proof, the same issue Haskell has. The fact that it's "had its chance" to catch on and hasn't done so marks it as a failure (or "not production ready") in the eyes of people who make decisions. Scala has better odds than Ocaml and Haskell for this reason alone. 3.…

I do not think Scala is an ML. The use of the word acceptable and indeed restricting it to an ML derivative loses the point of what Scala is supposed to be. Scala is supposed to be something different: a successful melding of OOP and functional. And it is the best at that I have seen. It succeeds on this better than the next biggest contender: F#, which is the most acceptable ML, IMO. F# is more typically functional, using the usual Hindley Milner Inference and sharing a core with OCaml but with significant whitespace. So it can be very succinct. Typically functional idioms like algebraic data types, Piping, point free, currying and combinators is more natural to F# than Scala's more OOP way. I prefer F# to Scala but that is merely a subjective preference.

There are a number of things that Scala does naturally that are cumbersome in other languages because of how it manages to meld a powerful combination of orthogonal features. To use Scala as just another functional language is to miss its power. Those who criticize OOP have not used a language that does it right. Abstractly, in a simplified categoric setting, we can consider OOP (objects as coalgebras) and FP (algebraic data types) as duals of each other. A proper unification of the concepts gives something more powerful than either. I think Scala comes the closest. Sure you can be 100% functional in it, or replicate Java but to call it one or the other is to make the same mistake as to say that light is both a wave and a particle and think you understand what that means.

Re: Code iOS Apps in OCaml

#16
post #2

OCaml is a highly underappreciated language. The biggest problem is the haphazard syntax, but if you can get over that, it's really a joy to use for application programming. You get the strongly-typed, type-inferred, functional aspects of Haskell, but without the drawbacks of laziness (for example, you can safely do IO outside the IO monad, and space leaks are less common) and with a simpler type system. There are no…

is it possible to just change syntax and keep the rest of ocaml system. For the syntax we can borrow ideas from Ruby or Python.

Re: Code iOS Apps in OCaml

#17
post #5
post #2

OCaml is a highly underappreciated language. The biggest problem is the haphazard syntax, but if you can get over that, it's really a joy to use for application programming. You get the strongly-typed, type-inferred, functional aspects of Haskell, but without the drawbacks of laziness (for example, you can safely do IO outside the IO monad, and space leaks are less common) and with a simpler type system. There are no…

Having suffered through C++ for several years, and having enjoyed writing SML/NJ, the syntax doesn't bother me at all. My big problem with OCaml is that the ecosystem is insanely poorly documented, and, if I understand this right (I am definitely not an OCaml expert), fractured. E.g., there's a lot of buzz about Jane Street's library, but, as far as I can tell, your code uses only their library or the built-in one, b…

Your request for a super-opinionated guide "get stuff done" guide will be available soon; http://realworldocaml.org

Re: Code iOS Apps in OCaml

#18
post #10
post #5

Earlier quoted context omitted.

Having suffered through C++ for several years, and having enjoyed writing SML/NJ, the syntax doesn't bother me at all. My big problem with OCaml is that the ecosystem is insanely poorly documented, and, if I understand this right (I am definitely not an OCaml expert), fractured. E.g., there's a lot of buzz about Jane Street's library, but, as far as I can tell, your code uses only their library or the built-in one, b…

There are a lot of problems with C++, but I've hardly heard syntax referred to as one of them.

You must not have talked to anyone that uses templates extensively.

Re: Code iOS Apps in OCaml

#19
post #6
post #3

Earlier quoted context omitted.

It seems like a lifetime ago, but I actually spent one year in college mainly learning OCaml. The language is really elegant, but I'm not sure I ever saw a real-life use for it until today.

Unison: http://www.cis.upenn.edu/~bcpierce/unison/index.html In fact I think this is the only software that I know is written in a functional language that I use on a regular basis. I've always figured that said very good things about OCaml. (Not that I've ever gotten around to learning OCaml, mind you.)

But, most FP languages have only recently started gaining real traction outside academia. There are some great tools written in e.g. Haskell: pandoc (a document converter), Hakyll (a static site generator), Darcs (version management), xmonad (an X11 window manager), git-annex, and multiple web frameworks (Yesod, Snap, Happstack).

In recent years, some important foundational libraries have been developed (bytestring, text, vector, repa, conduit/enumerator, etc.). I can imagine that it's pretty much the same in OCaml and F#.

Re: Code iOS Apps in OCaml

#20
post #17
post #5

Earlier quoted context omitted.

Having suffered through C++ for several years, and having enjoyed writing SML/NJ, the syntax doesn't bother me at all. My big problem with OCaml is that the ecosystem is insanely poorly documented, and, if I understand this right (I am definitely not an OCaml expert), fractured. E.g., there's a lot of buzz about Jane Street's library, but, as far as I can tell, your code uses only their library or the built-in one, b…

Your request for a super-opinionated guide "get stuff done" guide will be available soon; http://realworldocaml.org

I know, and I'm tepidly excited, but I'd had high hopes for Practical OCaml, too, and ended up being sorely disappointed. There's lots of good reasons to believe that Real World OCaml will be a totally different beast, but I'm trying to hold my enthusiasm until we get a bit closer to when it ships.
Post reply on HN