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

211–220 of 230 posts

Re: My thoughts on OCaml

#211

Post by giraffe_lady »

frou_dh wrote: post #208
giraffe_lady wrote: post #30

Earlier quoted context omitted.

Rescript is completely excellent imo. I have used ocaml for years and while I like it more than most languages it's also weird and frustrating sometimes. Rescript uses the best parts of ocaml (type system & exhaustive pattern match, first class modules) to patch over the worst parts of js. It's almost alarming how effective it is to combine these two gnarly hostile languages like this. I also work in typescript a lot…

How does that work with Fresh? Just not using its built-in "Islands" machinery at all? Or smuggling stuff in that as far as Fresh is concerned are more orthodox React components?

Rescript has good react integration and compiles to normal js, so a little care to structure your rescript files so the compiled js ends up where fresh expects it is mostly all you need.

The more worrying thing is that fresh uses preact while rescript explicitly uses react and so far doesn't have a way to change it. I just overrode react in the import map to link preact instead. This is frightening and fragile, since the interfaces aren't guaranteed to be identical. But it's been working fine on a personal project for a few months now.

Re: My thoughts on OCaml

#212

Post by hajile »

boxed wrote: post #210
hajile wrote: post #192

Earlier quoted context omitted.

Primitive conversions are as simple as ` _of_ (myValue)`. For example, `int_of_float(2.0)` will give you an integer. `string_of_int(123)` will return a string. Noting very surprising. If you want to do more complex conversions, you have to write those functions and call them. I don't much care for Ocaml syntax (StandardML is a better language in basically every way and ReasonML is Ocaml with better syntax), but this…

That's terrible though. How can that possibly work if the type is not hardcoded? How can you write code that works on any type like that?

The type system will know if you don't handle a potential conversion.

This restriction is better for pretty much every real-world use case anyway.

If you don't know what you're converting, then you are almost guaranteed to be getting garbage out the other end. If you do know what you are converting, being explicit and covering all your options isn't a big deal.

And of course, you can pack this all away in a module if you really want too. Modules are more flexible than typeclasses in a language like Haskell anyway (as you can't have multiple typeclass definitions in Haskell).

In truth, I believe module typeclasses (typeclasses only definable in modules) would be a nice addition. It would allow flexibility while creating a pattern that actively discourages the abuse you see in Haskell where typeclasses quickly devolve into unreadable garbage.

Re: My thoughts on OCaml

#213

Post by yawaramin »

WastingMyTime89 wrote: post #163
mcguire wrote: post #144

Earlier quoted context omitted.

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…

> Still I would fall from my chair if I ever encounter someone working on the OCaml compiler writing a disparaging disingenuous post on Haskell.

This exactly. OCaml devs uniformly respect Haskell and give it its due props for pushing innovation and commercialization in FP. We just think OCaml is pragmatic especially if you ever need to scale up your codebase and team.

Re: My thoughts on OCaml

#214

Post by yawaramin »

riku_iki wrote: post #205
belmont_sup wrote: post #200

Earlier quoted context omitted.

Syntax and sugar is subjective, right? Instead, easier to discuss the layer beneath syntax, and that’s to compare the type systems. Java now has some version of sum types aka algebraic data types, but because of its beginnings, it may never feel as easy to use. And ease of use is important, as is evident from discussions here. Had to look up to see where Java is at for sum types. First link I found. https://sfietkons…

sum types is not something supercritical, it saves few lines of code. Also, somehow I rarely have need to use something like that personally. > And ease of use is important the question is if insignificant syntax sugar worths switching to unpopular platform with undeveloped toolings and uncertain support.

Sum types save more than a few lines of code, they can save you from nasty bugs thanks to exhaustiveness checking in pattern matches. Once you get used to this you will be hard pressed to go back to prehistoric times.

Re: My thoughts on OCaml

#215

Post by riku_iki »

yawaramin wrote: post #214
riku_iki wrote: post #205

Earlier quoted context omitted.

sum types is not something supercritical, it saves few lines of code. Also, somehow I rarely have need to use something like that personally. > And ease of use is important the question is if insignificant syntax sugar worths switching to unpopular platform with undeveloped toolings and uncertain support.

Sum types save more than a few lines of code, they can save you from nasty bugs thanks to exhaustiveness checking in pattern matches. Once you get used to this you will be hard pressed to go back to prehistoric times.

> Sum types save more than a few lines of code, they can save you from nasty bugs thanks to exhaustiveness checking in pattern matches.

do you have specific example?

Re: My thoughts on OCaml

#216

Post by mcguire »

yawaramin wrote: post #213
WastingMyTime89 wrote: post #163

Earlier quoted context omitted.

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…

> Still I would fall from my chair if I ever encounter someone working on the OCaml compiler writing a disparaging disingenuous post on Haskell. This exactly. OCaml devs uniformly respect Haskell and give it its due props for pushing innovation and commercialization in FP. We just think OCaml is pragmatic especially if you ever need to scale up your codebase and team.

Oh, I like Haskell a lot. I'm a bit leery of using it because performance and memory use are still a bit of a dark art, though much less than they used to be.

I just like mocking Haskellers (and Scala) for the symbols. :-)

Re: My thoughts on OCaml

#217

Post by yawaramin »

riku_iki wrote: post #215
yawaramin wrote: post #214

Earlier quoted context omitted.

Sum types save more than a few lines of code, they can save you from nasty bugs thanks to exhaustiveness checking in pattern matches. Once you get used to this you will be hard pressed to go back to prehistoric times.

> Sum types save more than a few lines of code, they can save you from nasty bugs thanks to exhaustiveness checking in pattern matches. do you have specific example?

Look at this code which prints out an HTML tag: https://github.com/yawaramin/dream-html/blob/main/lib/dream_...

Initially you might think generating HTML tags from data structures in code should be a simple matter. But there are complexities--some tags are defined as having no child tags, others do. Some tags are purely character data (unstructured text), not structured data. Some are just comments. We need a way to compose multiple tags together into a single 'virtual' tag for flexible HTML generation. All these conditions can be pretty hard to keep track of--unless your compiler does exhaustiveness checking. Then the compiler will tell you if you missed any cases.

In the example above I didn't make any manual effort to cover all the cases, I simple listed out the cases I wanted to handle in order. The compiler made sure that I didn't miss any.

Re: My thoughts on OCaml

#218

Post by yawaramin »

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

Honestly the way OP just throws out a scary-sounding 'well this is an obvious bug that abs can return a negative number', without giving the context that it's for the minimum value of a machine int type, really says it all. He doesn't have an interest in evaluating it fairly, he's just doing a hit piece.

Re: My thoughts on OCaml

#219

Post by reikonomusha »

xigoi wrote: post #204
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…

Why does Coalton require two different implementations of Lisp to be installed?

Why do you say that? You just need a single (supported) Lisp implementation, like SBCL.
Post reply on HN