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

161–170 of 230 posts

Re: My thoughts on OCaml

#161

Post by nequo »

golergka wrote: post #158
nequo wrote: post #129

Earlier quoted context omitted.

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…

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.

Re: My thoughts on OCaml

#162

Post by illiarian »

WastingMyTime89 wrote: post #159
illiarian wrote: post #154

Earlier quoted context omitted.

> Because they are not issues on a day to day basis when you use the language. They still are. You just internalize them. Progammers are the world's greatest masochists with the world's biggest Stockholm syndromes, and we don't like to admit it. For example, his pain points about syntax ambiguity are absolutely valid, and true. However, when you "use the language every day" you learn to avoid those constructs and ext…

No, the syntax parts he criticises are not this kind (they are not ambiguous by the way). What’s in the article is very unidiomatic OCaml incorrectly intended purposefully to make it look like it’s doing something else than what it does. You don’t write tuples without parentheses because it’s weird, harder to read and no one does it. Same for the precedence rules of expression. You just use begin and end for blocks l…

> 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 statements completely differently.

Sure it's solved by "you just write begin-end" workaround that you internalise. Or it could be solved at the syntax level (like erlang and elixir)

Re: My thoughts on OCaml

#163

Post by WastingMyTime89 »

mcguire wrote: post #144
mjdowney wrote: post #99

Related: https://twitter.com/zetalyrae/status/1639474931086901248 My OCaml: let foo (x: bar): baz = (\* Is this quuxable? *) match is_quuxable x with | Yes -> (* Then, we have to ... \*) All the OCaml I see in the wild: qlet%bind f = 's 't 'a 'b (fun ꙮ -> ꙮ ((

Hmm. I haven't seen the latter in OCaml as much. More the opposite; when I first used it, things like list length in the standard library weren't tail recursive. 8-| Now, Haskell and shudder Scala shudder, on the other hand.

Compared to Haskell, OCaml developers are generally not to fond of custom operators which shield you from some of the worst cases unless you are reading code an Haskeller wrote in OCaml which happens.

For a long time, most of the users were either writing compilers or static analysers for low level languages and a fair share was very knowledgeable in C and system programming. It had a huge impact on what was seen as idiomatic. You can still find trace of it in for exemple the system library which looks more like the C stdlib than a modern standard library or how the compiler finds libraries.

Generally the community used to have a very different "flavour" than the Haskell one (it was also very French to be fair). I think I t’s less true nowadays. Still I would fall from my chair if I ever encounter someone working on the OCaml compiler writing a disparaging disingenuous post on Haskell. Meanwhile, we are here which reflects exactly my general experience with the Haskell community.

Ppx are used more and more often however and it did make code harder to read.

Re: My thoughts on OCaml

#164

Post by yawaramin »

jimsimmons wrote: post #102
mjdowney wrote: post #99

Related: https://twitter.com/zetalyrae/status/1639474931086901248 My OCaml: let foo (x: bar): baz = (\* Is this quuxable? *) match is_quuxable x with | Yes -> (* Then, we have to ... \*) All the OCaml I see in the wild: qlet%bind f = 's 't 'a 'b (fun ꙮ -> ꙮ ((

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 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 thing with JavaScript where that ecosystem is infamous for using tons and tons of npm packages to recreate simple functionality, e.g. 'left-pad a string'. Arcane mathematics-heavy FP code is just how that expresses in FP languages. And in fact, OCaml is actually an antidote to that (for the most part), because it deliberately offers a lower level of abstraction than Haskell. I frequently say that OCaml is like a cross between Haskell and Go.

Re: My thoughts on OCaml

#165

Post by gjm11 »

actionfromafar wrote: post #128
mjdowney wrote: post #99

Related: https://twitter.com/zetalyrae/status/1639474931086901248 My OCaml: let foo (x: bar): baz = (\* Is this quuxable? *) match is_quuxable x with | Yes -> (* Then, we have to ... \*) All the OCaml I see in the wild: qlet%bind f = 's 't 'a 'b (fun ꙮ -> ꙮ ((

The latter code looks totally quuxable.

Nah, I think it's already been quuxed up.

Re: My thoughts on OCaml

#166

Post by omoikane »

> Int.abs can return a negative number.

The documentation for abs[1] explains: "Warning. This may be negative if the argument is Int.min_int."

I think that's just the nature of two's complement and not necessarily a fault of OCaml. C++ is also like that[2].

[1] https://v2.ocaml.org/api/Int.html

[2] https://gcc.godbolt.org/z/34b3GbvvT

Re: My thoughts on OCaml

#167

Post by jorkadeen »

networked wrote: post #160
jorkadeen wrote: post #150

An alternative to OCaml is Flix ( https://flix.dev/ ) which attempts to address some of the critiques in the post. For example: > Bad standard library A particular goal of Flix is to have a consistent standard library based on type classes. > Standard types are sometimes persistent, sometimes mutable. List, Map, and Set are persistent. Stack and Hashtbl are mutable. In Flix immutable types are named List, Set, Map, e…

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 two languages, but get strong guarantees from the compiler.

In terms of adoption, we see a lot of people trying it out, and there are some packages out there already, but nothing too big yet. We recently added support for package management, so hopefully that will help the community grow.

Re: My thoughts on OCaml

#168

Post by WastingMyTime89 »

illiarian wrote: post #162
WastingMyTime89 wrote: post #159

Earlier quoted context omitted.

No, the syntax parts he criticises are not this kind (they are not ambiguous by the way). What’s in the article is very unidiomatic OCaml incorrectly intended purposefully to make it look like it’s doing something else than what it does. You don’t write tuples without parentheses because it’s weird, harder to read and no one does it. Same for the precedence rules of expression. You just use begin and end for blocks l…

> 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 out that match, try and (;) have different precedence which is not ambiguous. Writing begin and end is not a workaround. That’s how you mark blocks which is what he should have done because, well, he wants a block.

Erlang has exactly the same issue if you write unidiomatic code by the way.

That’s unsurprising because "don’t write code implicitly relying on precedence behaviour" is taught to virtually all beginners in most programming languages.

Re: My thoughts on OCaml

#169

Post by anderskaseorg »

omoikane wrote: post #166

> Int.abs can return a negative number. The documentation for abs[1] explains: "Warning. This may be negative if the argument is Int.min_int." I think that's just the nature of two's complement and not necessarily a fault of OCaml. C++ is also like that[2]. [1] https://v2.ocaml.org/api/Int.html [2] https://gcc.godbolt.org/z/34b3GbvvT

In C and C++, abs(INT_MIN) is undefined behavior. (C17 §7.22.6.1: “The abs, labs, and llabs functions compute the absolute value of an integer j. If the result cannot be represented, the behavior is undefined.” Footnote: “The absolute value of the most negative number cannot be represented in two’s complement.”)

Re: My thoughts on OCaml

#170

Post by giraffe_lady »

rashkov wrote: post #50
lallysingh wrote: post #42

Earlier quoted context omitted.

.. that's a complaint for all new languages. You don't know which ones will stick until you try. Code in a strongly-typed functional language is easier to maintain because of the features of the language. The functional part gives great abstraction, and the strongly-typed part gives enough structure to make the whole thing tractable.

Absolutely agreed. I'm lucky to work on a ReasonML front-end codebase and the type system and immutability are a real pleasure to work with. The strong typing lets you code against the compiler, and there are many instances of "if it compiles it works" that crop up throughout development. There's no fear of refactoring code that you didn't write, because the compiler will warn you about consequences on the far end of…

Very cool to hear. I've been using rescript some recently and was hoping for exactly that sort of benefit.

I have a mixed opinion of ocaml itself having used it professionally a moderate amount. But one thing I can't deny is that ocaml programs seem to "age" better than any other languages, even other strongly typed languages.

Post reply on HN