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

131–140 of 230 posts

Re: My thoughts on OCaml

#131

Post by actionfromafar »

kajaktum wrote: post #58
actionfromafar wrote: post #55

Earlier quoted context omitted.

> Ocaml's module system means that you can describe the async runtime as a signature and make your entire library generic to the async runtime it runs on top of So ... can you ELI5 to me how that is different from how you can for instance compile a C program against different libc implementations?

I mean…you can technically have a function that take void* and return void* be the interface. But you wouldn’t be able to represent things like iterator and chain them together without care. In C you would be tripping all over the slight details like forgetting to check errno or something.

So, it's like C++20 then?

Re: My thoughts on OCaml

#132

Post by ubertaco »

electroly wrote: post #65
ubertaco wrote: post #15

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

Agreed except for the part at the end: Java, C, C++, and JavaScript definitely do have the "dangling else" problem! It's a manifestation of the same basic issue. Who is saying they don't? You just showed how they do! It is a real problem and they all have it. The takeaway here isn't that those languages don't have the issue. They do. It's just really common in language design, that's all; certainly not something to s…

>Java, C, C++, and JavaScript definitely do have the "dangling else" problem! It's a manifestation of the same basic issue. Who is saying they don't? You just showed how they do! It is a real problem and they all have it.

Yeah, that's actually exactly my point: it's not some new weird novel horrible broken parsing problem that only OCaml has; rather, it's a common parsing rule that many languages (including Java, C, C++, and JavaScript -- and yes, OCaml) have.

Re: My thoughts on OCaml

#133

Post by yawaramin »

hardwaregeek wrote: post #119
ywei3410 wrote: post #90

Earlier quoted context omitted.

Not really third-party; ocaml-ppx is something similar to `javax` in the Java space? But it is optional and doesn't come bundled with OCaml. Recursive structures are only rare in Rust _because_ they suck to write and have terrible performance characteristics in the language. In languages like Haskell, OCaml and Scala using tagless initial encodings for eDSL's [2] are really, really common. I don't write Rust like I w…

A lot of these things that you mentioned are valid flaws in Rust. I'm not going to dismiss them as not important or non-problems because they are genuine issues. Compile times suck. We could use hot reloading and a REPL. Debugging macros, instrumentation and perf stuff is good, but I assume it could be better. That's what I expect from a language community. Not constant denial about the state of usability. And it rea…

If you are referring to OCaml, many people in the community care a lot about writing good documentation so that it's not just the type signatures. In fact the OCaml website team have made amazing leaps and strides integrating package documentation directly in the website.

And the experience using OCaml LSP Server with VSCode nowadays is honestly pretty good--type annotations displayed, error messages, go to definition, generating interface files. The core functionality is all there.

Re: My thoughts on OCaml

#134

Post by boxed »

WastingMyTime89 wrote: post #41
boxed wrote: post #34

Earlier quoted context omitted.

"the language invits you to do"? What does that mean? If it's the right thing to do it shouldn't be in invitation surely, but a syntax requirement?

> What does that mean? That's a best practice. Like always using braces in C or Java or not using ternary operators in hard to read way. The syntax is unambiguous but non obvious to read if you don't know precedence rules as it is for most languages. You can make it explicit using parentheses which you should. I personally agree that parentheses around tuples should be mandatory but it's fairly easy to just put them.

Those are examples of C and Java being very bad. So yea, I think my point stands.

Re: My thoughts on OCaml

#135

Post by manymanydots »

> No standard and easy way of implementing interfaces.

> In Haskell, this is done with typeclasses ...

> In OCaml there’s no way to do this. I have to explicitly pass functions along with my values, maybe in a product type, or with a functor, or as an argument.

Haskell is a mixed community / paradigm language too.

I routinely program in "Braindead Haskell" (keep stuff simple and direct as much as possible). Funnily, in that programming style, using typeclasses for _all_ interface types is bad style.

Instead, the Handle pattern [0] can be used. Which really is just shoveling functions in a product type. And imagine - it works worderfully.

Everyone has to find their own style I guess.

[0]: https://jaspervdj.be/posts/2018-03-08-handle-pattern.html

Re: My thoughts on OCaml

#136

Post by boxed »

WastingMyTime89 wrote: post #105
boxed wrote: post #31

Earlier quoted context omitted.

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

It sounds like it's weird and annoying to convert a value to a string. That's pretty damning. Did I misunderstand?

Re: My thoughts on OCaml

#137

Post by reikonomusha »

wk_end wrote: post #124
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…

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…

1. There are functional dependencies and multi-parameter type classes. No GADTs (yet?) or existential types (yet?).

2. Records are being implemented but it's far from being a dealbreaker, in the sense that thousands of production lines of Coalton have been built without needing them. It's just not ergonomic to shuffle around and pattern match against record-like data. With pattern matching in function arguments, things are at least easier.

3. All Coalton functions compile to Lisp functions. There's a guide that describes what is promised about interop (https://github.com/coalton-lang/coalton/blob/main/docs/coalt...).

4. Since Coalton functions are Lisp functions, you can call (unconstrained) functions directly. However there's a lot of room for improvement. There's an open issue to make a dedicated Coalton REPL that can show types and not require COALTON to be typed.

5. Coalton is developed as an open source project to build tools at HRL Laboratories, so it does receive sponsorship. Yes, HRL is hiring. Feel free to send me an email to the address in my profile.

As seems to be the case with any "serious" programming language, there's always another thing to do—seemingly perpetually—to make said language useful enough for "serious" use. :)

Re: My thoughts on OCaml

#138

Post by hardwaregeek »

yawaramin wrote: post #133
hardwaregeek wrote: post #119

Earlier quoted context omitted.

A lot of these things that you mentioned are valid flaws in Rust. I'm not going to dismiss them as not important or non-problems because they are genuine issues. Compile times suck. We could use hot reloading and a REPL. Debugging macros, instrumentation and perf stuff is good, but I assume it could be better. That's what I expect from a language community. Not constant denial about the state of usability. And it rea…

If you are referring to OCaml, many people in the community care a lot about writing good documentation so that it's not just the type signatures. In fact the OCaml website team have made amazing leaps and strides integrating package documentation directly in the website. And the experience using OCaml LSP Server with VSCode nowadays is honestly pretty good--type annotations displayed, error messages, go to definitio…

That's good to hear! I don't mean to be too negative. I'm genuinely glad that OCaml is making these strides. I'm hopeful that OCaml can find its equivalent of Esteban Küber[1] and they can make the language a truly fun and friendly experience.

[1]: https://www.youtube.com/watch?v=Z6X7Ada0ugE

Re: My thoughts on OCaml

#139

Post by WorldMaker »

hpstewed wrote: post #73
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 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…

The C# compiler got a ton of new smarts around reference type nullability and almost all of the BCL (.NET standard library) got annotated for it. I don't know when F# will finally pick up all the new compile-time smarts for Nullable Reference Types, but it has been proposed and prototyped, at least [1].

[1] https://github.com/fsharp/fslang-design/blob/main/RFCs/FS-10...

Re: My thoughts on OCaml

#140

Post by HdS84 »

JaggerJo wrote: post #117
HdS84 wrote: post #109

Earlier quoted context omitted.

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.

what noise? I get your example of ‘seq { 1; 2; 3; }’ but list, array are not even shortened.

Sorry, I literally forgot them. A lookup here refreshed my memory: https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
Post reply on HN