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

41–50 of 230 posts

Re: My thoughts on OCaml

#41

Post by WastingMyTime89 »

boxed wrote: post #34
WastingMyTime89 wrote: post #13

The last paragraph show this article for what is is. That's an Haskell fan trying to discredit Ocaml and doing it very poorly. It takes a special kind of writer to write an incorrect sentence about the expression syntax while quoting the actual definition from the specification which contradicts what's written just after. I generally disagree about the complaint regarding the syntax. If you indent the code properly a…

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

Re: My thoughts on OCaml

#42

Post by lallysingh »

ronnier wrote: 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.…

.. that's a complaint for all new languages. You don't know which ones will stick until you try.

Code in a strongly-typed functional language is easier to maintain because of the features of the language. The functional part gives great abstraction, and the strongly-typed part gives enough structure to make the whole thing tractable.

Re: My thoughts on OCaml

#43

Post by WastingMyTime89 »

arc-in-space wrote: post #32
WastingMyTime89 wrote: post #29

Earlier quoted context omitted.

> I'm pretty sure is what the author meant. Clearly not considering he mentions typeclass in the article. Module signatures are similar to interface and parametrized modules allow you to do what you would do with abstract class: you define a signature and then write a module using these functions. Parametrized modules are more or less a generalization of functions which goes from module to module.

Sorry, I initially wrote 'interfaces as in OOP' to distinguish them from module interfaces, but had 'ad-hoc polymorphism' in mind. 'interfaces' is much too overloaded of a term.

Ocaml has no ad-hoc polymorphism but you can use parametrised modules to write generic code which you will have to specialise at some point. That brings you ninety percents of the way in term of what ad-hoc polymorphism is used for. It's more cumbersome but I prefer it to the complexity involved by what Scala does for exemple.

Re: My thoughts on OCaml

#44

Post by Verdex »

boxed wrote: post #34
WastingMyTime89 wrote: post #13

The last paragraph show this article for what is is. That's an Haskell fan trying to discredit Ocaml and doing it very poorly. It takes a special kind of writer to write an incorrect sentence about the expression syntax while quoting the actual definition from the specification which contradicts what's written just after. I generally disagree about the complaint regarding the syntax. If you indent the code properly a…

"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?

I agree, but the languages that actually do this are in a hyper-minority, I feel. Nearly every language allows you to do the wrong thing and then only lets you discover this at runtime via exception OR sometimes even just by careful examination of subtly incorrect output.

As such, this doesn't really feel like the best argument against ocaml (and I believe arguments against ocaml do exist and on a much more accessible level).

Re: My thoughts on OCaml

#46

Post by ywei3410 »

WastingMyTime89 wrote: post #43
arc-in-space wrote: post #32

Earlier quoted context omitted.

Sorry, I initially wrote 'interfaces as in OOP' to distinguish them from module interfaces, but had 'ad-hoc polymorphism' in mind. 'interfaces' is much too overloaded of a term.

Ocaml has no ad-hoc polymorphism but you can use parametrised modules to write generic code which you will have to specialise at some point. That brings you ninety percents of the way in term of what ad-hoc polymorphism is used for. It's more cumbersome but I prefer it to the complexity involved by what Scala does for exemple.

Would you not consider the object system to be ad-hoc polymorphism?

Re: My thoughts on OCaml

#47

Post by the_af »

yodsanklai wrote: post #19

1. To print values, nowadays you just derive pretty printers automatically. 2. Syntax? yes, it's not C-like... you'll get used to it in a few days. 3. Lack of interface? would be helpful to see a concrete example of what the author finds limiting. You have modules, functors, includes, objects, first-order modules... Personally, I find that plain modules are simple and go a long way. It's not perfect, but I find that…

> 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" their dislike for OCaml syntax won't go away.

For the record, I don't think syntax is a big issue.

Re: My thoughts on OCaml

#48

Post by the_af »

ronnier wrote: 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.…

> Why would a company use ocaml?

PG claims using Lisp was the "secret sauce" to his early success. Whether this is true or not, and whether this is still true for companies today, remains to be seen. But it's an argument for things like OCaml.

Re: My thoughts on OCaml

#49

Post by cies »

Taikonerd wrote: post #38
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/

Is ReasonML dead? Their last blog post is from August 2018... https://reasonml.github.io/blog/

Quieted down, but I depend on projects with worst graphs:

https://github.com/reasonml/reason/graphs/contributors

Re: My thoughts on OCaml

#50

Post by rashkov »

lallysingh wrote: post #42
ronnier wrote: 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.…

.. that's a complaint for all new languages. You don't know which ones will stick until you try. Code in a strongly-typed functional language is easier to maintain because of the features of the language. The functional part gives great abstraction, and the strongly-typed part gives enough structure to make the whole thing tractable.

Absolutely agreed. I'm lucky to work on a ReasonML front-end codebase and the type system and immutability are a real pleasure to work with. The strong typing lets you code against the compiler, and there are many instances of "if it compiles it works" that crop up throughout development. There's no fear of refactoring code that you didn't write, because the compiler will warn you about consequences on the far end of the codebase that you didn't even know existed.

As a result of all of that, the app feels very solid to use and has comparatively few runtime errors.

Post reply on HN