101–110 of 251 posts
Earlier quoted context omitted.
> It has no performance or coding benefit for teams larger than a few. That must be why Jane Street uses it then.
And pretty much only them. Perhaps some day we'll learn how little the programming language matters for anything beyond coding.
Earlier quoted context omitted.
let's see: - OCaml vs Haskell: eager vs lazy (=> memory consumption is more predictable) - OCaml vs Rust: OCaml has a GC (=> comfort) OCaml has tco (could not resist this ;) ) - OCaml vs Clojure: vastly superior typing system. (=> less bugs) - OCaml vs Kotlin: no JVM needed. - OCaml vs C++: more safety. once it compiles it will not segv. - OCaml vs Go: vastly superior typing system. (=> less bugs) - OCaml vs Python:…
Not sure what you mean by "- OCaml vs Kotlin: no JVM needed." as Kotlin has support for native and JavaScript compilation, and WASM via native.
As a former OCaml hobbyist programmer my take on these kind of books or articles is that, yes OCaml is extremely elegant and beautiful as a programming language and it shines for simple applications. Some parts of it are actually not so elegant, for example the object oriented aspect completely spoil the elegance of the core language. On the other side OCaml, as a pure functional programming language with immutable v…
> Functional programming with immutable values is a wrong pattern for programming languages. Many algorithms, almost all actually, are naturally expressed in imperative style with mutable arrays or variables. The optimal implementation might be imperative but that doesn't mean we need to define our code that way. SQL is a good example here.
There are times when it isn't.
I'm thinking of Richard Bird's functional pearl, The Smallest Free Number, where the divide-and-conquer algorithm is faster than the imperative one.
From the conclusion:
One of the differences between a pure functional algorithm designer and a procedural one is that the former does not assume the existence of arrays with a constant-time update operation, at least not without a certain amount of plumbing. For a pure functional programmer, an update operation takes logarithmic time in the size of the array.1 That explains why there sometimes seems to be a logarithmic gap between the best functional and procedural solutions to a problem. But sometimes, as here, the gap vanishes on a closer inspection.
The ability to arrive at the divide-and-conquer algorithm is quite fascinating as it uses plain, boring old mathematics and is, for some, quite straight-forward to derive on one's own.
Yet people are more convinced by imperative implementations. I'm curious why this is. Is it because we "teach" people to believe programs are executed sequentially and are therefore somehow "inherently" imperative? Or is it easier to reason about algorithms in terms of their operational semantics?
As a former OCaml hobbyist programmer my take on these kind of books or articles is that, yes OCaml is extremely elegant and beautiful as a programming language and it shines for simple applications. Some parts of it are actually not so elegant, for example the object oriented aspect completely spoil the elegance of the core language. On the other side OCaml, as a pure functional programming language with immutable v…
Concerning the issue with function arguments, this is one of the reason why OCaml has labelled arguments. And for instance, Janestreet's idiom udes labelled arguments as often as possible. Similarly, I am not sure what is the issue with using imperative OCaml for imperative algorithms when they are a better fit for the problem at hand?
So you have to give up to one of pillars of the functional programming paradigm and you get a less elegant but more practical programming language. Otherwise I agree that using labeled arguments is mostly fine and doesn't completely spoil the language.
The more serious compromise to the functional programming paradigm is the fact that you need to use mutable variables and imperative style programming. Once you do this you lose most of the elegance and attractiveness of functional programming.
> Similarly, I am not sure what is the issue with using imperative OCaml for imperative algorithms when they are a better fit for the problem at hand?
What I mean is that for any moderately complex application you need to switch to imperative style so the appeal of OCaml is mostly lost. You better choose a programming language that is designed for imperative programming since the beginning.
The arguments I am giving explains why there are practically no real world applications done in OCaml. Some people insist using OCaml because they love the elegance of the language and I understand them but reality is it doesn't scale to complex applications.
For people in Janestreet I think this is a sort of niche where they get an added value from OCaml thanks to its superior typing system and compile-time detection of many errors. I guess they care really a lot about the business logic of their applications and OCaml shines to ensure it is correct so for them the advantages out-weights the inconveniences.
Earlier quoted context omitted.
Have you tried F#?
Nope, I must say I have only used a small subset of languages from the FP-language-zoo, so my opinion on OCaml might be biased But as an example when writing Typescript, I feel so frustrated of not having a clean way of doing pattern-matching
The whole point of Typescript and why it is so successful, is because they only add type system on top of JavaScript.
Pattern matching would introduce new language constructs beyond what is required for defining types.
Earlier quoted context omitted.
yes, that would be a straightforward error message! But I got the error message Error: This expression has type ((locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t) list but an expression was expected of type Result_set.t list Type (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t is not compatible with type Result_set.t Which is not half as readable.
It doesn't look so bad to me. It's telling you that a list type was expected but you passed it a function that returns a list instead. You're right though that OCaml isn't the kind of language you can pick up in an afternoon.
I don't know OCaml really, but I would read that intuitively as a list of (functions that return Result_set.t), which is not compatible with a list of Result_set.t.
Earlier quoted context omitted.
FWIW, F# is very similar to OCaml, but its error message in this case is usually quite clear. E.g. This expression was expected to have type 'int' but here has type 'string -> int'
yes, that would be a straightforward error message! But I got the error message Error: This expression has type ((locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t) list but an expression was expected of type Result_set.t list Type (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t is not compatible with type Result_set.t Which is not half as readable.
Earlier quoted context omitted.
Concerning the issue with function arguments, this is one of the reason why OCaml has labelled arguments. And for instance, Janestreet's idiom udes labelled arguments as often as possible. Similarly, I am not sure what is the issue with using imperative OCaml for imperative algorithms when they are a better fit for the problem at hand?
> And for instance, Janestreet's idiom udes labelled arguments as often as possible. So you have to give up to one of pillars of the functional programming paradigm and you get a less elegant but more practical programming language. Otherwise I agree that using labeled arguments is mostly fine and doesn't completely spoil the language. The more serious compromise to the functional programming paradigm is the fact tha…
In the same way, it is perfectly possible to switch to the imperative style only in the specific code path where performance really matters and use abstraction to isolate this performance-sensitive part from the rest of your application. Ideally, you can then keep both the elegance of functional programming and the performance of imperative programming.
Earlier quoted context omitted.
> when signatures changed in an unstable dependency The problem is not OCaml here.
I have a good point of contrast: I'm doing a similar task with an unstable Rust dependency, and when APIs change the error messages from the typechecker are crystal clear about why things are incompatible.
Earlier quoted context omitted.
FWIW, F# is very similar to OCaml, but its error message in this case is usually quite clear. E.g. This expression was expected to have type 'int' but here has type 'string -> int'
yes, that would be a straightforward error message! But I got the error message Error: This expression has type ((locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t) list but an expression was expected of type Result_set.t list Type (locl_ty * Tast.pos * ('ex, 'fb, 'en) Aast.expr_) list -> Result_set.t is not compatible with type Result_set.t Which is not half as readable.