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

151–160 of 230 posts

Re: My thoughts on OCaml

#151

Post by weatherlight »

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…

Complete Feature List

    algebraic data types
    pattern matching
    first-class functions
    extensible records
    parametric polymorphism
    type classes
    higher-kinded types
    light-weight polymorphic effects
    type aliases
    Hindley-Milner type inference
    CSP-style concurrency
    buffered & unbuffered channels
    first-class datalog constraints
    polymorphic datalog predicates
    constraints with lattice semantics
    stratified negation
    interoperability with Java
    unboxed primitives
    keyword-based syntax
    redundancy checks
    monadic let\* expressions
    expressions holes
    compilation to JVM bytecode
    full tail call elimination
    core standard library
    parallel compiler architecture
    human friendly errors
    interactive mode
    Visual Studio Code support
Nice!

Re: My thoughts on OCaml

#152

Post by JackMorgan »

HdS84 wrote: post #109
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…

I really wish to like F# but the line noise kills me every time. I would kill for a "visual basic" f# where the absurd terseness is replaced with a little less noise. E.g. instead of seq use sequence, instead of abstract one letter symbols use words.

Perhaps you mean mix a little more noise into the dense signal? There's very little noise in F#, it's almost entirely dense signal.

One good thing is the ability to bind new operators, so if you don't care to learn to read you could make it something else. Or you could have a local binding for Sequence so you don't have to use just Seq.

It's also possible to avoid almost all operators if you don't like them. There's nothing wrong with using a limited pool as long as you can get done the job!

I also prefer to name variables, functions, and parameters with nice clear names, and I've not found F# to get in the way of that.

Re: My thoughts on OCaml

#153

Post by veec_cas_tant »

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…

Wanted to add my experience here: after writing C# code most of my professional life, F# is a breath of fresh air. The type system makes so many issues and annoyances I've lived with in C# just disappear. Much like Rust, the compiler is capable of providing so much more value when the type system is so expressive. You can bang out a lot of code quite quickly and be pretty darn sure it will work just because it compiles.

Re: My thoughts on OCaml

#154

Post by illiarian »

WastingMyTime89 wrote: post #116
hardwaregeek wrote: post #113

Earlier quoted context omitted.

Why are these things not issues? I think it's totally valid for someone who doesn't understand OCaml to raise issues of usability or documentation. It's not just the issues of experts that are a concern. And it's very demoralizing to get a "you're holding it wrong" response to a complaint.

Because they are not issues on a day to day basis when you use the language. I used Ocaml for a paid internship some years ago. I was very much a beginner. Do you know how many time I felt at loss or annoyed by type conversion or the precedence rules for various part of the syntax? I never did. The truth is you never encounter the precedence rules when writing Ocaml normally using parentheses like a normal human bein…

> 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 extract them into separate functions for example because "that's how it's always done, and it's a nice little quirk of the language".

Re: My thoughts on OCaml

#155

Post by illiarian »

crop_rotation wrote: post #93

The biggest problem I have with Ocaml is not the language, but the tooling and the libraries. The library ecosystem is not even remotely comparable to go or even rust. Jane street core is mentioned as a good option, but that library is the most popular undocumented library I have ever seen. There is not even some normal default structure every library follows (e.g go io.Reader). Compare this to languages with suppose…

> like Java, which has a library for everything and high quality well documented libraries

Unless it's a library that has been around for a while and is probably hosted at Apache.

There was a marked shift in 2010s in expectations, and now we expect libraries and code to be somewhat well-documented. For older libraries... well, it's often "here's a dump of autogenerated reference files with maybe a blob of prefacing text at the top. Good luck."

Re: My thoughts on OCaml

#156

Post by justinpombrio »

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 it (by design). Would you call any language with algebraic data types a "dialect of ML"?

EDIT: I'm picking on this one sentence, but the rest of your comment is a good overview of the language, thanks.

Re: My thoughts on OCaml

#157

Post by illiarian »

cies wrote: post #18

ReasonML and ReScript are a (more or less the same) new syntax on top of OCaml. ReScript only targets JS, while ReasonML targets both JS and the native archs OCaml supports. Facebook and Bloomberg are using ReScript internally, afaik. Messenger.com is written in it. Facebook also maintains React bindings to ReScript. https://rescript-lang.org/ https://reasonml.github.io/

The rescript-reason split killed both IMO. ReasonML was a very tiny language to begin with. Splitting it into two split the already tiny language and community into two minuscule ones.

And for no good reason (pun not intended).

And they were doing quite well, and influencing OCaml in good and meaningful ways (like improving error reporting).

Re: My thoughts on OCaml

#158

Post by golergka »

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…

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.

Re: My thoughts on OCaml

#159

Post by WastingMyTime89 »

illiarian wrote: post #154
WastingMyTime89 wrote: post #116

Earlier quoted context omitted.

Because they are not issues on a day to day basis when you use the language. I used Ocaml for a paid internship some years ago. I was very much a beginner. Do you know how many time I felt at loss or annoyed by type conversion or the precedence rules for various part of the syntax? I never did. The truth is you never encounter the precedence rules when writing Ocaml normally using parentheses like a normal human bein…

> 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 like you would use braces in C because you actually want to write a block. No one is just randomly writing nested code without them because well it doesn’t work.

It’s not a quirk. The author is just complaining that you have to mark blocks like in every language. That’s a weird thing to complain about.

I agree that the lack of as-hoc polymorphism is a downside (I don’t agree with how the article presents it but the article is disingenuous from the start anyway). Everyone would like to have modular implicit.

Re: My thoughts on OCaml

#160

Post by networked »

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-party" I mean created outside of Aarhus University and the University of Waterloo.

Post reply on HN