Live data from Hacker News

My thoughts on OCaml

osa1.net

121–130 of 230 posts

Re: My thoughts on OCaml

#121
post #3

Why would a company use ocaml? I’ve worked in software now for most of my life, from small to the biggest companies. I’ve watched teams with senior developers use non mainstream languages to build services and just about every time those devs get board again, leave the team, leaving them stuck with this system that’s hard to develop and different from the rest of the orgs, eventually resulting in a complete rewrite.…

I'm sure some companies out there might find a competitive advantage for using exotic languages and tech stacks. But I get the impression the more common scenario is that the engineers were bored and given the chance, wanted to play with something new and shiny. It also depends on the company's prestige. A company like Jane Street using OCaml? Considering both their prestige and the amount they pay, I'm sure they wil…

I worked on a team using Haskell at Target for a few years and we had a massively easier time hiring compared to the other data science/ML teams. I figure it came down to two things:

1. People are actively interested in using Haskell and working with others interested in Haskell/PL/FP/etc. More people want to do Haskell than there are Haskell jobs and Haskell openings get massive word-of-mouth advertising.

2. It's a way to show that we're willing to do something different and interesting. Everybody says they are, but how do you actually demonstrate it? I remember one of the first great hires we had was an OR professor who didn't even know about Haskell—but joined in part because what we were doing was different and innovative.

If I ever end up starting my own company, I'm going to use Haskell because it's so much easier to hire for it—completely opposite to the superficial "common knowledge" that guides executive decisions at large companies.

Re: My thoughts on OCaml

#122
post #118

Almost all modern statically typed languages have closures, higher-order functions/methods, lazy streams, and combinators that run efficiently. Persistent/immutable data structures can be implemented even in C. Also, OCaml has no tracking of side-effects (like in Haskell), and the language and the standard library have lots of features and functions with mutation, such as the array update syntax, mutable record field…

You might want to make it clearer that this is a literal quote from the last paragraph of the article. Are you posting this because you agree/disagree?

Re: My thoughts on OCaml

#124

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…

This looks excellent! I have a soft-spot for the elegance of Lisp but can't live without a robust type system. A few questions I didn't see immediate answers to on the GH page (sorry if I missed something/could've found those answers if I digged a little deeper):

1. Beyond the typeclasses you mentioned, how powerful is the type system beyond standard HM stuff? Are there GADTs/existential types? Any other interesting features?

2. The lack of records sounds like it might be a deal-breaker for current use. Is that as bad as it sounds? Is it something that is expected to be addressed soon? Are there any other large omissions?

3. How does it integrate into the existing Common Lisp ecosystem, if at all? Is there any friction there?

4. On that note: in the REPL example it looks like you need to wrap your expressions with (coalton ...), which feels like it'd get frustrating. Is there any way around that? I guess even a reader macro would help...but still wouldn't be ideal.

5. Is Coalton backed by any kind of corporate funding? And (assuming you're involved in Coalton in a professional capacity) ...you guys hiring?

Re: My thoughts on OCaml

#125

> Another example is the sequencing syntax ; and productions with as the right-most symbol: let test1 b = if b then print_string "1" else print_string "2"; print_string "3" > Here print_string "3" is not a part of the if expression, so this function always prints “3”. Well, yeah. Here's the equivalent Java code: void test1(bool b) { if (b) print_string("1"); else print_string("2"); print_string("3"); } You've chosen…

Now keep reading on to literally the next sentence.

The article's point is that the `if-else` behavior is inconsistent with `match`. And based on the part about double quotes in comments, the parser seems to be fucked up something fierce in other ways too.

Re: My thoughts on OCaml

#126

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…

> The issue is that this is not what’s going to annoy you as an Ocaml beginner.

Sure, but tbf, the post is about what annoys the author, not what would annoy beginners. As you say, the author is not a beginner, and so their problems wouldn't be beginner problems.

Re: My thoughts on OCaml

#127

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 use F# at work. Really love the language but the connection to the dotnet ecosystem is a curse as much as a blessing. Having to operate in a world of nulls and exceptions can reduce/nullify the amazing benefits of discriminated unions. Often you are back to relying on the due dilligence of other developers as a result. I use a lot of rust in my spare time. The runtime guarantees it offers make other languages feel…

> Having to operate in a world of nulls and exceptions can reduce/nullify the amazing benefits of discriminated unions.

I've been saying this about Kotlin on the JVM for ages. Using a Java dependency is an absolute last resort for me for those same reasons you mention about .NET from F#.

Re: My thoughts on OCaml

#128

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.

Re: My thoughts on OCaml

#129

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

It is easier to read this (Rust):

  let value = some_long_ass_function_name(some_quirky_parameter, another_one);

  another_function(value)
than this (Haskell):

  let value = someLongAssFunctionName someQuirkyParameter anotherOne
  in anotherFunction value
or this (OCaml):

  let value = some_long_ass_function_name some_quirky_parameter another_one in
  another_function value
Individual terms in camel case are difficult to read if they consist of more than a couple words. Consecutive terms in snake case are difficult to read because underscores and whitespace look alike visually.

Haskell and OCaml's idiomatic solution is to use extremely terse names for arguments, type variables, and local variables, out of what seems to be syntactic necessity.

Re: My thoughts on OCaml

#130
post #82

Earlier quoted context omitted.

Nowadays most of those folks are no longer at MSR, Don Syme has moved into Github and I doubt they are into F#.

Don is still working on F#. The F# team at MS now is bigger than is was years ago. People from different companies and the community are collaborating on compiler and language features. F# is beyond microsoft, a lot of early adopters are still there.

Stand corrected on that one.

What are the fruits of that increased team on the VS, VS4Mac and VSCode tooling, and .NET SDKs?

Post reply on HN