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

My thoughts on OCaml

osa1.net

Post reply on HN
Print view View original

171–180 of 230 posts

Re: My thoughts on OCaml

#171

Post by networked »

jorkadeen wrote: post #167
networked wrote: post #160

Earlier quoted context omitted.

I have been keeping an eye on Flix. Thanks to you and rest of the Flix team for working on a bold but practical language. I wish you success. I think Flix is one of the most promising languages in the ML family. (Do you consider it an ML?) I love that it has embedded Datalog. I know it is pre-1.0, but I would still like to ask about adoption. Are there notable third-party open source projects in Flix yet? By "third-p…

Thanks for the kind words. Yes, I would definitely consider it a language in the ML-family. Its core is based on Hindley-Milner (like StandardML, OCaml, and Haskell) which I think is the hallmark of ML-family languages. Flix sits neatly between Ocaml and Haskell in that it allows side-effects (like Ocaml, unlike Haskell) but they are tracked by the effect system. Hence one can program in the spectrum between those tw…

Nice to hear about the package management.

Sorry, I wasn't clear. I meant to ask whether you considered Flix "an ML" as opposed to just being in the ML family. It's an ontological question, and not important, so don't sweat the answer. I am just curious how Flix developers see their project.

Re: My thoughts on OCaml

#172

Post by networked »

reikonomusha wrote: post #104

Coalton [1] is an OCaml-like dialect of ML: it's strictly evaluated, has imperative features, and doesn't force a purity-based development philosophy. However, Coalton has S-expression syntax and integrates into Common Lisp. It works, and is used "in production" by its developers, but it's still being developed into a 1.0 product. Coalton made a lot of design decisions to work away from issues that this post describe…

> Coalton has S-expression syntax. No indent rules. No precedence rules. No expression delimiters.

This is a great selling point for a language in the ML family. Programmers can't abuse infix operators when there are none. :-)

Besides this, Coalton looks appealing. A highly interactive statically typed language is something I have thought of. I am sure I am not the only one. It is also a good sign that you are using it as it is being developed.

Re: My thoughts on OCaml

#173

Post by debugnik »

KingOfCoders wrote: post #88

I found that one hilarious "The regex module uses global state: string_match runs a regex and sets some global state. "

The builtin `str` regex library is obsolete anyway, most people use `re`[1], or sometimes bindings for pcre or Google's re2.

[1]: https://ocaml.org/p/re/latest

Re: My thoughts on OCaml

#174

Post by reikonomusha »

justinpombrio wrote: post #156
reikonomusha wrote: post #104

Coalton [1] is an OCaml-like dialect of ML: it's strictly evaluated, has imperative features, and doesn't force a purity-based development philosophy. However, Coalton has S-expression syntax and integrates into Common Lisp. It works, and is used "in production" by its developers, but it's still being developed into a 1.0 product. Coalton made a lot of design decisions to work away from issues that this post describe…

> Coalton [1] is an OCaml-like dialect of ML: it's strictly evaluated, has imperative features, and doesn't force a purity-based development philosophy. OCaml is also strictly evaluated, has imperative features (e.g. ref), and doesn't force a purity-based development philosophy. What makes you call Coalton a "dialect of ML"? ML's module system is its defining feature, beyond that there's really not much unique about…

That's why I said it's "OCaml-like" followed by a colon: to highlight the similarities.

As for why it's an ML dialect, maybe (maybe not) it's more fair to call it "ML-inspired". Nonetheless, it's similar enough to the ML family to be understood by ML programmers. But yes, one of the major pillars of ML—the module system—is conspicuously absent in favor of Haskell-like type classes.

Re: My thoughts on OCaml

#175

Post by oblio »

nequo wrote: post #129
jimsimmons wrote: post #102

Earlier quoted context omitted.

Functional programming community likes this stuff. They go into the classical mathematicians’ trap of writing more and more general versions of something even though it’s not necessary.

I think this is partly because of the syntax. When we write human languages (that use a Latin script), we use punctuation to delineate the beginning and end of terms. In a language like C or Rust, terms are surrounded by commas, parentheses, angle brackets, and so on. In OCaml and Haskell, many things that there is syntax for in C-style languages are done as ordinary function calls, which separate terms by only white…

Ah, now I realized, you're right. The lack of visual distinction between different syntactic elements is what's killing me.

Re: My thoughts on OCaml

#176

Post by yawaramin »

Miltnoid wrote: post #63

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…

I think looking at it as a 'failure' or 'deficiency' is the wrong mindset. OCaml makes a different tradeoff than Haskell. In exchange for not having ad-hoc polymorphism, OCaml's functor system allows much quicker compilation and easier-to-understand type errors. Like everything in tech, it's a tradeoff.

Re: My thoughts on OCaml

#177

Post by yawaramin »

atbpaca wrote: post #74

I learned OCaml two decades ago. It was great to learning algorithmics but I already had the feeling the language was old and awkward. Today there is Scala, Haskell, Rust, F# etc.

All of which are, incidentally, either directly or indirectly inspired by OCaml or its ancestor ML :-)

Re: My thoughts on OCaml

#178

Post by lmm »

WastingMyTime89 wrote: post #168
illiarian wrote: post #162

Earlier quoted context omitted.

> unidiomatic OCaml > You don’t write tuples without parentheses > Same for the precedence rules of expression. You just use begin and end for blocks This is exactly what I wrote, but in a Stockholm-syndrome-y way. > The author is just complaining that you have to mark blocks like in every language. He points out a real ambiguity in the syntax where the parser literally parses the same-looking and same-behaving state…

> 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.

Re: My thoughts on OCaml

#179

Post by ackfoobar »

nequo wrote: post #161
golergka wrote: post #158

Earlier quoted context omitted.

That's because of currying. If you want to partially apply parameters, in your example, with Haskell we would just have to do this: someLongAssFunctionName someQuirkyParameter And we get a function that accepts one parameter. But in Rust you would have to do this: move |another_one: i32| { some_long_ass_function_name(some_quirky_parameter, another_one) } Which is not easier to read.

It is true that currying looks comparatively awful in Rust. But that is not because Rust uses parentheses and commas. A hypothetical C-style language could use dedicated syntax for currying, like some_long_ass_function_name(some_quirky_parameter, ..) which would be more readable without giving up on punctuation.

Scala does that, with `_` being a "hole in the expression". I wouldn't call it currying though.

  func(param1, _)
Every once in a while you have to make some change to that expression.

  // you may want to write
  func(param1, func2(_))
  // but you need to write the full lambda
  param2 => func(param1, func2(param2))

Re: My thoughts on OCaml

#180

Post by daxfohl »

JaggerJo wrote: post #12

I think you should give F# a shot instead. 1. No standard and easy way of implementing interfaces No problem in F#, you have interfaces, abstract classed, ... 2. Bad standard library In F# you have access to the full .NET standard library and ecosystem. There are also quite a lot of libraries that are especially designed to take advantage of F# (SQL libs for example). 3. Syntax problems 3.1 OCaml doesn’t have a singl…

> NuGet is a decent/good package manager

I remember F# designed its own package manager (paket) because of NuGet's deficiencies. I haven't been on that ecosystem for a while now. Have things changed? (My memory is that paket added friction and I eventually dropped it for nuget on my personal projects).

Post reply on HN