Live data from Hacker News

My thoughts on OCaml

osa1.net

191–200 of 230 posts

Re: My thoughts on OCaml

#191
post #178

Earlier quoted context omitted.

> This is exactly what I wrote, but in a Stockholm-syndrome-y way. Do you complain about having to put braces around C expressions to not get unexpected behaviour from the compiler? > He points out a real ambiguity in the syntax where the parser literally parses the same-looking and same-behaving statements completely differently. No, he doesn’t. If that what you got from the article, you were bamboozled. He points o…

If you shouldn't write code that way then it should be a compilation error (or at the very least a warning) to write code that way.

Is there ANY common language without TONS of ways to write bad code?

Is there ANY such language at all regardless of popularity?

Re: My thoughts on OCaml

#192
post #136

Earlier quoted context omitted.

To be honest, anyone who used Ocaml understands immediately that the author gave it no chance and went looking for problems. It’s obvious because the post lingers a lot about things which are not actually issues like type conversion but don’t talk about the very real issues Ocaml has (opam is not great, dune is weird).

It sounds like it's weird and annoying to convert a value to a string. That's pretty damning. Did I misunderstand?

Primitive conversions are as simple as `_of_(myValue)`. For example, `int_of_float(2.0)` will give you an integer. `string_of_int(123)` will return a string. Noting very surprising.

If you want to do more complex conversions, you have to write those functions and call them.

I don't much care for Ocaml syntax (StandardML is a better language in basically every way and ReasonML is Ocaml with better syntax), but this isn't a big deal.

Re: My thoughts on OCaml

#193
post #191
post #178

Earlier quoted context omitted.

If you shouldn't write code that way then it should be a compilation error (or at the very least a warning) to write code that way.

Is there ANY common language without TONS of ways to write bad code? Is there ANY such language at all regardless of popularity?

It's a spectrum. Most languages have some ways to write bad code, but there are definitely languages that have more or fewer ways compared to other languages. E.g. languages with simpler precedence rules, like Lisp or TCL, avoid this particular issue because you just can't write code with unintuitive precedence (although in the case of Lisp people often end up writing a macro that recapitulates the problem).

Re: My thoughts on OCaml

#194
post #31

Earlier quoted context omitted.

To me it seems he gave it a lot of chance in order to find this many problems. It does sound to me like you stopped reading after the first point. Maybe you didn't give the post a chance?

To be honest, anyone who used Ocaml understands immediately that the author gave it no chance and went looking for problems. It’s obvious because the post lingers a lot about things which are not actually issues like type conversion but don’t talk about the very real issues Ocaml has (opam is not great, dune is weird).

I've been using opam and dune for a few years now and they haven't annoyed me much since I got used to how to set up projects. What are the issues with them?

Re: My thoughts on OCaml

#195
Everyone I’ve met, including on the steering committee, has been funded by high-frequency trading.

Heck, I almost took a job on a handshake in manhattan on this premise.

But it just seems, even now, archaic for the task. As the author mentions, the community is small, the integrations are weak. You will be working on legacy systems if anyone pays you well.

Same with certain parts of national defense, but we’ll make fun of PDP-11’s and FORTRAN another day.

Proactive thought: why don’t we fund a B-team to say, try using Julia? Even ERLANG has some superior qualities for these real-time audited tasks. (And hey, if you want employees for some reason, just use python).

Re: My thoughts on OCaml

#196

I used OCaml as my daily driver in grad school and my postdoc, and recommend my students use it. I think the main benefits of OCaml are: Functional Has mutable references Not lazy Haskell's type system is just better. But for large, complex systems that require performant code, it can be quite difficult to track the laziness, and sometimes life is just easier if I can use a mutable references. The author is completel…

What about StandardML?

Re: My thoughts on OCaml

#197
The author says: "If you have a reason to think that OCaml is the best choice for a new project please let me know your use case, I’m genuinely curious." I think it's overwhelmingly the best language for writing an interpreter or a compiler. I'm sure Haskell is also a good language for writing compilers, but whenever I tried writing interpreters in Haskell, I found myself fighting the laziness. Most of the criticisms listed strike me as things that bother people starting out in the language (syntax etc.) but which quickly become non-issues with more experience. And my experience with opam/dune has been _much_ more pleasant than with Cabal in Haskell (though ghcup has certainly improved matters). I think the infrastructure in OCaml, which admittedly used to be quite poor, is now on par with any other language, if not better. However, if your application domain is one in which few OCaml libraries exist (e.g. web programming) you probably should look elsewhere.

Re: My thoughts on OCaml

#198

Earlier quoted context omitted.

I don't think this is correlated to functional programming. Programmers in general tend to over-architect because we're often learning as we're going and sometimes it's more fun to use some cool concepts. Since design patterns started becoming en vogue back in the day, OOP codebases got filled with those patterns. Now we are left picking up the pieces with things like `AbstractProxyFactoryBean` or whatever. Same thin…

I don’t know OCaml, or really any language that would help me fully understand the code, but my exposure to OCaml is this stuff, and it looks pretty clean to me. https://github.com/janestreet/base Of course, I haven’t read every file, so maybe I got lucky with my random sampling.

It's a pretty practical language, so much so that its creators think it's actually a great language to teach Unix programming, and even wrote a book about it: https://ocaml.github.io/ocamlunix/ocamlunix.html

Excerpt:

> Tradition dictates that Unix system programming must be done in C. For this course we found it more interesting to use a higher-level language, namely OCaml, to explain the fundamentals of Unix system programming.

> The OCaml interface to Unix system calls is more abstract. Instead of encoding everything in terms of integers and bit fields as in C, OCaml uses the whole power of the ML type system to clearly represent the arguments and return values of system calls. Hence, it becomes easier to explain the semantics of the calls instead of losing oneself explaining how the arguments and the results have to be en/decoded. (See, for example, the presentation of the system call wait, page ??.)

> Furthermore, due to the static type system and the clarity of its primitives, it is safer to program in OCaml than in C. The experienced C programmer may see these benefits as useless luxury, however they are crucial for the inexperienced audience of this course.

> A second goal of this exposition of system programming is to show OCaml performing in a domain out of its usual applications in theorem proving, compilation and symbolic computation. The outcome of the experiment is rather positive, thanks to OCaml’s solid imperative kernel and its other novel aspects like parametric polymorphism, higher-order functions and exceptions. It also shows that instead of applicative and imperative programming being mutually exclusive, their combination makes it possible to integrate in the same program complex symbolic computations and a good interface with the operating system.

Re: My thoughts on OCaml

#199
post #136

Earlier quoted context omitted.

To be honest, anyone who used Ocaml understands immediately that the author gave it no chance and went looking for problems. It’s obvious because the post lingers a lot about things which are not actually issues like type conversion but don’t talk about the very real issues Ocaml has (opam is not great, dune is weird).

It sounds like it's weird and annoying to convert a value to a string. That's pretty damning. Did I misunderstand?

If Ocaml fixes this and makes opam/dune play in the same field as cargo, life would be great as an ocaml programmer.

Sometimes I go back to F# and sigh because I can just print any complex data structure. Sure, there’re limits, but it’s just one less pain.

Regardless, really enjoy everything else. I cloned and built the Dune repo to try to help fix something. Compiled very quickly for its size.

Re: My thoughts on OCaml

#200
post #21

Earlier quoted context omitted.

A language like ocaml excels when the input and output are program-like, and the problem can't be number-crunched by hardware. The typical example would be a compiler. Other examples would be model checkers, code generators for number crunching libraries, proof assistants, and so on. Complex problems, where you need to explore different avenues of approach quickly, and where symbolic manipulation is at the heart of t…

The question is if modern versions of popular languages (java, c#) caught up on ocaml's syntax sugar, or maybe this syntax sugar is trivially replaceable by some utility functions. Maybe you could bring any example of such ocaml functionality?

Syntax and sugar is subjective, right? Instead, easier to discuss the layer beneath syntax, and that’s to compare the type systems. Java now has some version of sum types aka algebraic data types, but because of its beginnings, it may never feel as easy to use. And ease of use is important, as is evident from discussions here.

Had to look up to see where Java is at for sum types. First link I found. https://sfietkonstantin.github.io/2021/09/03/Java-sum-type.h...

Post reply on HN