in before JSC
Why We Use OCaml
131–140 of 144 posts
Re: Why We Use OCaml
#132Hey HNers, I'm the CEO of Esper - there's been a lot of questions regarding the business case for OCaml and I think it'd be helpful to write here: 1) It's practical - for our team, we had developed in it before and had deployed a large system in it - we could get to where we wanted quickly. 2) we think it's a competitive advantage (see OP and PG's Beating the Averages essay) - additionally, since we deal with large a…
Oh. Ocaml again. Well, I'll chirp on the opposite side of discusion. The syntax is completely :%^&#$^ $% %^&*% up. Unreadable. Yes, it maybe somewhat pleasant to write code in such syntax, but readability sucks. Just like perl. Also ugly as perl as well. When do you people learn the lessons from C, Python and Haskell? That _readability_ is _the most important thing_ for any language. Now about design. Ocaml allows a mix of imperative+functional+oop! Which means that there are uncountably many ways to screw up the design, and only a few to get it right. And each OCaml primadonna developer thinks that his way is the right way. And the rest can't read his code. Fuck that.
To CEO of Esper. Interesting. How many decades of experience do you have? How many projects you've successfully shipped? How many of these there using this approach of using non-mainstream languages?
Re: Why We Use OCaml
#133Hey HNers, I'm the CEO of Esper - there's been a lot of questions regarding the business case for OCaml and I think it'd be helpful to write here: 1) It's practical - for our team, we had developed in it before and had deployed a large system in it - we could get to where we wanted quickly. 2) we think it's a competitive advantage (see OP and PG's Beating the Averages essay) - additionally, since we deal with large a…
Oh. Ocaml again. Well, I'll chirp on the opposite side of discusion. The syntax is completely :%^&#$^ $% %^&*% up. Unreadable. Yes, it maybe somewhat pleasant to write code in such syntax, but readability sucks. Just like perl. Also ugly as perl as well. When do you people learn the lessons from C, Python and Haskell? That _readability_ is _the most important thing_ for any language. Now about design. Ocaml allows a…
> Oh. Ocaml again.
Nothing forces you to read the posts you don't like.
> Well, I'll chirp on the opposite side of discusion. The syntax is completely :%^&#$^ $% %^&*% up. Unreadable. Yes, it maybe somewhat pleasant to write code in such syntax, but readability sucks.
Readability is mostly a matter of experience.
> Which means that there are uncountably many ways to screw up the design
And many ways to make it fit a given problem. It's again a matter of experience.
> And each OCaml primadonna developer thinks that his way is the right way. And the rest can't read his code. Fuck that.
Glad you give your opinion. Apparently you have an axe to grind against the OCaml community though. You could probably replace OCaml with any language with a lot of expressiveness, and still be correct - assuming there are "primadonna"s in the OCaml community and that "any other". Or do you mean that this happen only with OCaml?
Re: Why We Use OCaml
#134Earlier quoted context omitted.
Why do you think termination is easier to reason about in eager languages? I think it's quite the opposite: in lazy languages functions compose, in strict ones they don't necessarily. For example, you cannot compose a "take ten values" and "square all elements" function in a strict language if the argument you apply their composition to has infinite length (e.g. is cyclic).
With a lazy language its not always obvious if a certain expression needs to be evaluated now or not. In particular I was writing some list comprehensions in Haskell, trying to solve some of the project Euler problems, and when I introduced a bug I got an infinite loop. When I fixed the bug I got the correct answer thanks to lazy evaluation, but the buggy code and the correct code looked awfully similar. Maybe it is…
Maybe it is because you didn't show an example, but that doesn't seem like something caused by lazy evaluation. It is pretty easy to get into infinite loops due to logic errors in Project Euler type problems even when using imperative loops.
Re: Why We Use OCaml
#135Earlier quoted context omitted.
People say functional programming is hard, but it feels just like a knee-jerk reaction. In practice, it doesn't seem to be much of an issue. For example, IMVU gave an experience report at BayHac about switching from PHP to Haskell; they found that onboarding a new employee (without significant Haskell experience) took about as much time as it did for their particular flavor of PHP (conventions, frameworks... etc)[1].…
I've always been curious about Jane Street. It seems like a too-good-to-be-true story. Picking an obscure but powerful alternative to C++ and Java for a highly-competent core team makes sense, and has been done by several banks. But hacking OCaml does not fit the personality profile of (m)any traders I've met — most will happily whip up a spreadsheet to help their work, but writing extensive software and learning Hin…
> learning Hindley-Milner type systems
Well, HM is about type inference and they can just assume it works correctly. And I don't think they are expected to write extensive, complex programs in the language but more put together pieces from their "vast trove of proprietary libraries", which are most likely designed just for the fact of faciliating the use of the language for users who are not (primarily) software developers.
Re: Why We Use OCaml
#136Earlier quoted context omitted.
> But there is a strong community behind OCaml. A lot of undergraduate programs use a dialect of ML for their core classes I don't understand your response. Are you saying the OCaml community primarily consists of undergraduates? > While most OCaml implementations have poor standard libraries That right there should tell you something.
>I don't understand your response. Are you saying the OCaml community primarily consists of undergraduates? What I am saying is that a sizable portion of academia uses a variant of ML. Maybe it hasn't caught on in industry, but that doesn't mean that there isn't a community that uses it. > That right there should tell you something. A lot of development of core tools for mainstream languages comes from the companies…
Not really disaggreeing with you but,
> What I am saying is that a sizable portion of academia uses a variant of ML. Maybe it hasn't caught on in industry, but that doesn't mean that there isn't a community that uses it.
Academic communities tend to be scattered when it comes to software and the primary focus is on publishing papers rather than producing software that is useful to others. Also, I know a number of skilled academics that use functional languages, but they tend not to have an interest in changing into the industry, rather stay at university. So I wouldn't depend on them as source for recruiting.
Of course there are exceptions, e.g. OCaml Labs seems to be keen on producing well-written, usable software that can be used in industrial settings. The development of Mirage is a pretty exciting area.
Re: Why We Use OCaml
#137Earlier quoted context omitted.
Why do you think Rust is applicable, here? It isn't obvious to me that these people would benefit from a language that can be used anywhere that C++ can be .
Given that C++ is in fact used pretty much everywhere, I'm not sure what you mean by that. And I think Rust is applicable because it hits all of the big features the author is touting as good in OCaml, such as first-class functions, immutable values, strong static type checking and type inference, ADTs and pattern matching. It also has benefits that OCaml doesn't, such as full memory safety, no required garbage colle…
> I'm no OCaml programmer but glancing at the beginning of the Real World OCaml's chapter on FFI, it appears OCaml uses dlsym() to look up functions at runtime, whereas Rust can outright link to them like any C program would
This is not a limitation of OCaml but a deliberate choice of the authors of Real World OCaml to use the ctypes library. The OCaml implementation also supports directly linking with C code. What you need:
* Your ordinary C code
* Some C stubs that do the conversion between regular C types and the C types the OCaml runtime uses. Usually they are quite trivial, just use the few macros that OCaml ships with.
* Some type signatures to tell the type system what types your C stubs expect as that can't be inferred.
Re: Why We Use OCaml
#138Earlier quoted context omitted.
I've always been curious about Jane Street. It seems like a too-good-to-be-true story. Picking an obscure but powerful alternative to C++ and Java for a highly-competent core team makes sense, and has been done by several banks. But hacking OCaml does not fit the personality profile of (m)any traders I've met — most will happily whip up a spreadsheet to help their work, but writing extensive software and learning Hin…
> learning Hindley-Milner type systems Well, HM is about type inference and they can just assume it works correctly. And I don't think they are expected to write extensive, complex programs in the language but more put together pieces from their "vast trove of proprietary libraries", which are most likely designed just for the fact of faciliating the use of the language for users who are not (primarily) software deve…
I'm not sure you can realistically wire together pieces of functionality written in a statically typed language without understanding its underlying type system. Sure, by the time it compiles without errors the code probably needs less debugging than in a dynamically-typed language, but getting to that point can be difficult and frustrating. (Speaking from experience as a TA.)
Re: Why We Use OCaml
#139Earlier quoted context omitted.
>I don't understand your response. Are you saying the OCaml community primarily consists of undergraduates? What I am saying is that a sizable portion of academia uses a variant of ML. Maybe it hasn't caught on in industry, but that doesn't mean that there isn't a community that uses it. > That right there should tell you something. A lot of development of core tools for mainstream languages comes from the companies…
Not really disaggreeing with you but, > What I am saying is that a sizable portion of academia uses a variant of ML. Maybe it hasn't caught on in industry, but that doesn't mean that there isn't a community that uses it. Academic communities tend to be scattered when it comes to software and the primary focus is on publishing papers rather than producing software that is useful to others. Also, I know a number of ski…
Yeah. The movers and shakers in software are always the big companies. But there are quite a few institutions that feature functional programming in their undergraduate curriculum.
One of the main gripes that people mention with functional languages is that it can be difficult to find developers. Several good universities are pouring out competent programmers.
Re: Why We Use OCaml
#140Earlier quoted context omitted.
Given that C++ is in fact used pretty much everywhere, I'm not sure what you mean by that. And I think Rust is applicable because it hits all of the big features the author is touting as good in OCaml, such as first-class functions, immutable values, strong static type checking and type inference, ADTs and pattern matching. It also has benefits that OCaml doesn't, such as full memory safety, no required garbage colle…
> I'm no OCaml programmer but glancing at the beginning of the Real World OCaml's chapter on FFI, it appears OCaml uses dlsym() to look up functions at runtime, whereas Rust can outright link to them like any C program would This is not a limitation of OCaml but a deliberate choice of the authors of Real World OCaml to use the ctypes library. The OCaml implementation also supports directly linking with C code. What y…
You have to write C stubs? I'm glad it's possible, but that's still quite unfortunate. On Rust's side, you usually have to write wrappers around your C FFI functions in order to do any type translation and to add any necessary safety, but those are at least written in Rust (and are not actually necessary to call C, just necessary to provide a safe idiomatically-correct Rust API; you could just vend the C FFI functions directly if you wanted to).