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

101–110 of 230 posts

Re: My thoughts on OCaml

#101

Post by mattgreenrocks »

yodsanklai wrote: post #71
the_af wrote: post #47

Earlier quoted context omitted.

> 2. Syntax? yes, it's not C-like... you'll get used to it in a few days Since the author mentions Haskell as a positive example multiple times, I don't think a lack of C-like syntax is the problem for them here. Also, the author claims: > Since 2013 I’ve had the chance to use OCaml a few times in different jobs, and I got frustrated and disappointed every time I had to use it. So it's safe to assume "in a few days"…

Incidentally, I find Haskell syntax more confusing, specifically the semantic indentation. But maybe I'm like the author, I don't use Haskell regularly enough so that the syntax sinks in.

Been using Haskell full-time for a year or so now, and using it part-time a few years ago for a side project. The reliance on indentation is nice and light but definitely bites you every now and then.

Re: My thoughts on OCaml

#102

Post by jimsimmons »

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.

Re: My thoughts on OCaml

#103

Post by pdhborges »

ywei3410 wrote: post #76
hardwaregeek wrote: post #67

Earlier quoted context omitted.

Politely, I feel like this is the issue with OCaml as a community. You gave a beautiful answer about programming language design and composition. But how does it feel to write the language? How can you print a user defined data type? From reading around, it seems like your options are: explicitly pass a print function for that specific type, use a third party library for printing, or (my "favorite") don't. Or how doe…

> You gave a beautiful answer about programming language You do the same thing as in Rust, Scala or Haskell and derive the printer [1]. Then at the callsite, if you know the type then you do `T.show` to print it or `T.eq`. If you don't know the type, then you pass it in at the top level as a module and then do `T.show` or `T.eq`. > Or to convert one type into another type? If you want to convert a type, then you have…

Scala is probably not a good example because if you need some quick and dirty printing you can override toString and keep the rest of the generic code intact. In OCaml, Rust and Haskell you would have to add type constraints in a bunch of places to make println! T.to_string and show work.

Re: My thoughts on OCaml

#104

Post by reikonomusha »

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

- Coalton dispensed with ML's module system of structures, signatures, and functors. No doubt a beautiful concept, and sometimes satisfying to write, but almost always unsatisfying to use due to how explicit one tends to need to be. Like the author suggests, the "interface-style" of type classes or traits has always felt more intuitive, despite losing the ability to have multiple implementations of an interface for a single type. (However, I've come to appreciate that different interfaces should require different types—as opposed to one type having many interfaces.) Coalton uses type classes.

- Coalton has S-expression syntax. No indent rules. No precedence rules. No expression delimiters. All of the "tradition" of ML syntax is dispensed with into something that is a lot easier to read and write for complex programs... yes, provided you use ParEdit or similar

- It should be no surprise that with S-expressions, you get Lisp-style macros. Macros in Coalton are just Common Lisp macros. No separate pre-processors. No additional language semantics to deal with. Arbitrary compile-time computation and/or codegen, completely integrated.

- Because it's built on Common Lisp, Coalton gets something few (if any?) other ML-derivatives get: Truly incremental and interactive development. You can re-compile types, functions, etc. and try them out immediately. There's no separate "interpreter mode"; just a Lisp REPL.

Coalton's language features are still settling (e.g., records are being implemented) and the standard library [2] is still evolving. However, it's been used for "serious" applications, like implementing a compiler module for quantum programs [3].

[1] https://github.com/coalton-lang/coalton

[2] https://coalton-lang.github.io/reference/

[3] https://coalton-lang.github.io/20220906-quantum-compiler/

Re: My thoughts on OCaml

#105

Post by WastingMyTime89 »

boxed wrote: post #31
spqr233 wrote: post #26

I don't the author really gave Ocaml a chance. He argues that every language needs to have interfaces. I agree somewhat with that statement, but I think the truer statement is to say that every language needs to have some way of defining composition at a structural level. An interface allows you to pass different "structures" to the same function so long as they adhere to the same spec. In Ocaml this is accomplished…

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

Re: My thoughts on OCaml

#106

Post by amyjess »

OCaml is one of those languages (like Raku and Nim) that I really want to learn and do something in at some point but usually end up not bothering because it's easy for me to just start up new personal projects in Python like I'm used to.

Re: My thoughts on OCaml

#107

Post by [deleted] »

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.

[deleted]

Re: My thoughts on OCaml

#108

Post by JaggerJo »

pjmlp wrote: post #82
AlotOfReading wrote: post #66

Earlier quoted context omitted.

F# was originally just kind of a passion project that MS insisted get productized to continue development. It's still very much an internal favorite within Microsoft Research and the Bing team, from my understanding.

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.

Re: My thoughts on OCaml

#109

Post by HdS84 »

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.

Re: My thoughts on OCaml

#110

Post by yodsanklai »

hardwaregeek wrote: post #81
ywei3410 wrote: post #76

Earlier quoted context omitted.

> You gave a beautiful answer about programming language You do the same thing as in Rust, Scala or Haskell and derive the printer [1]. Then at the callsite, if you know the type then you do `T.show` to print it or `T.eq`. If you don't know the type, then you pass it in at the top level as a module and then do `T.show` or `T.eq`. > Or to convert one type into another type? If you want to convert a type, then you have…

Okay...so you have to add a third party library to print? Yes, recursive data structures are a pain in Rust (well, recursive multi-owner data structures). But that's like comparing changing your oil to opening your car door. We do one of these a lot more. And bear in mind, I had to find this answer by googling and reading a random forum post. That's some pretty poor documentation. And that's not talking about aesthet…

> `T.show foo` or `Foo.to_bar value` is a lot of syntactic overhead for a rather common task.

A lot of syntactic overhead sounds like a stretch. I suppose you could drop the `T` like you do in Haskell but I personally like my language to be a bit more explicit. It improves readability.

Post reply on HN