121–130 of 144 posts
Could someone comment on what instances you would typically apply lambdas and closures in real-world code? I figure that they are at least more convenient than callbacks with a *userData parameter like in C.
Earlier quoted context omitted.
Hey Jon, being an F# user who is not very familiar with OCAML, I'd love to know a little more about what specifically F# lacks that makes OCAML superior. I want to know what I'm missing out on.
Where Ocaml is better : - Single Core Speed (Ocaml is fast) - native compilation without requiring some installed runtime - Polymorphic Variants (Last I read, to be used only when regular variants are not sufficient) - Modules and Functors (there's a proof of principle for F# supporting these) - GADTs (allow for richer more expressive types, much more flexibility than regular algebraic data types) - camlp4 - more per…
We use camlp4 a bit at Red Lizard Software and we are eagerly looking to move to extension points as soon as they are released.
[1]: https://blogs.janestreet.com/ocaml-4-02-everything-else/ [2]: https://blogs.janestreet.com/extension-points-or-how-ocaml-i...
Earlier quoted context omitted.
What you need is that functions are values in your language. Lambdas are just a notation for function values. Typed lambda calculus is the internal language of cartesian closed categories and function values are then called internal morphisms. The composition above is then the internal composition of internal morphisms. It would be possible for external composition to be already defined by the language, take the unix…
> What you need is that functions are values in your language. Well yeah, that's what I meant by higher order functions . > Lambdas are just a notation for function values. But regular (named) functions can still be used as function values. So this doesn't explain why you need things like lambdas in order to implement function composition. > Typed lambda calculus is the internal language of cartesian closed categorie…
Earlier quoted context omitted.
One advantage that gives you, is that you can easily define a monad on top of that and not worry about monad transformers. Jane Streets async library does that in its Deferred module https://ocaml.janestreet.com/ocaml-core/111.17.00/doc/async/...
But I like transformers... a lot!
Earlier quoted context omitted.
Haskell tries to be exceedingly (some might argue excessivly) clever. OCaml strives to be pragmatic and predictable.
Do you have any specific examples? I ask as someone that has landed on the Haskell boat but still keeps an eye/ear on the Ocaml one ;)
That isn't a factor at all in OCaml - in fact the compiler is fairly "dumb".
Earlier quoted context omitted.
Why do you think Rust is applicable, here? It isn't obvious to me that these people would benefit from a language that can be used anywhere that C++ can be .
Given that C++ is in fact used pretty much everywhere, I'm not sure what you mean by that. And I think Rust is applicable because it hits all of the big features the author is touting as good in OCaml, such as first-class functions, immutable values, strong static type checking and type inference, ADTs and pattern matching. It also has benefits that OCaml doesn't, such as full memory safety, no required garbage colle…
1. It isn't a given, from what I've read, that their product would need a language that could be realistically used everywhere. A lot of applications can get away with technology that is more "limited" in that sense. And being "limited" can be a plus.
2. Even if a language is used everywhere doesn't mean that it is/was an appropriate choice in all those cases. Look at people implementing stuff in Python, then reimplementing it in some static language later, giving a performance boost and less bugs, and almost/just as productive (though having the experience of doing it for the second time probably helps). Turns out that they didn't really need the dynamicity of Python after all. In C++'s case, maybe someone started developing an app and found out that they didn't really need the performance that a no-cost abstraction language is able to give, and so wouldn't need to pay the cost of dealing with the complexity of C++.
> And I think Rust is applicable because it hits all of the big features the author is touting as good in OCaml, such as first-class functions, immutable values, strong static type checking and type inference, ADTs and pattern matching.
And you also have the added features of smart pointers, managing pointers, heap/stack allocation, explicit use of views vs allocated memory (string allocated on heap vs string slice, for example), etc. These are all features, or burdens, depending on your application area. But why would they be features, in this context?
> It also has benefits that OCaml doesn't, such as full memory safety,
Doesn't OCaml have full memory safety?
> no required garbage collector,
Why is a garbage collector problematic, in this context?
> , and good C FFI (I'm no OCaml programmer but glancing at the beginning of the Real World OCaml's chapter on FFI, it appears OCaml uses dlsym() to look up functions at runtime, whereas Rust can outright link to them like any C program would). I'm sure there are others too, but I'm not familiar enough with OCaml to list them. I'm also not sure what the performance of OCaml is like (a glance at the Computer Language Benchmarks Game suggests it's often slower than C++), but Rust aims to have C++-equivalent performance.
It boils down to fine-grained control over performance, I guess. But, again, I don't see how that is a plus in this context. It can also be a burden, hence all the languages that deliberately do not let you have explicit control over memory - it makes for less stuff in the language, hence less complex language overall, or perhaps more room for other stuff that might be relevant to the application of the language.
I don't get the apparent attitude of "it has all the features of OCaml, plus all this other stuff". More stuff is not necessarily good, and can be a burden if you don't really need it.
> OCaml includes many features that are not available in the more mainstream programming languages ... and we believe this gives us a competitive advantage. ... The purpose of this post is to explain the benefits of OCaml and compare it to other languages. We hope to convince readers, especially other developers, to consider adopting OCaml for their projects as well. The authors did a great job explaining the benefit…
I was trying to write an eloquent reply but I remembered that PG did a better job than I could. http://www.paulgraham.com/avg.html
"when you're writing software that only has to run on your own servers, you can use any language you want"
Earlier quoted context omitted.
I often hear how using how using less mainstream and more difficult to learn (as in requires some mind warping if coming from more mainstream language) languages acts as a filter that will leave more capable programmers to choose from, even if there are less of them. Does anyone know if there have been studies to back this up? Or studies that back up the above comment. My experience is that programmers who enjoy warp…
I would agree that in my personal experience, those people do tend to be quite intelligent. However, I have not found them to be more productive (and in some cases, they seem to be less productive, because they spend so much time fiddling and tweaking instead of just finishing things).
Earlier quoted context omitted.
Given that C++ is in fact used pretty much everywhere, I'm not sure what you mean by that. And I think Rust is applicable because it hits all of the big features the author is touting as good in OCaml, such as first-class functions, immutable values, strong static type checking and type inference, ADTs and pattern matching. It also has benefits that OCaml doesn't, such as full memory safety, no required garbage colle…
> Given that C++ is in fact used pretty much everywhere, I'm not sure what you mean by that. 1. It isn't a given, from what I've read, that their product would need a language that could be realistically used everywhere . A lot of applications can get away with technology that is more "limited" in that sense. And being "limited" can be a plus. 2. Even if a language is used everywhere doesn't mean that it is/was an ap…
I have no idea. Note here that "full memory safety" in Rust includes data shared between multiple threads, and includes protection against data races. Garbage collectors help avoid referencing free'd data, but if OCaml lets you share mutable data between two threads, then I doubt it's fully memory-safe (at the very least that suggests you can get data races).
> Why is a garbage collector problematic, in this context?
What, in the context of server-side software? I don't know if it necessarily is, but it's definitely problematic in other contexts. And I do know that there have been issues with other languages causing unpredictable performance on servers because of garbage collection, e.g. ending up with a big GC pause after some N requests. I hope OCaml doesn't have that problem, but I don't know.
> It boils down to fine-grained control over performance, I guess. But, again, I don't see how that is a plus in this context.
I'm not sure what specifically you're referring to in that second sentence. Just the general ability to have better control over performance? Having that ability typically is a plus even in the context of server-side software because it means you don't need to change languages just to write the performance-critical aspects of your software. Of course, using the same language is only a good idea if the language is also a good choice for the parts of the software that aren't performance-criticial. My claim is that Rust is indeed suitable for the rest of the program too.
Earlier quoted context omitted.
> I find it amusing that so-called "risk-averse" startup managers discount a 20-year old language with legendary stability in favour of relatively new languages. While I mostly agree with your post, the four languages mentioned as opposed to OCaml in the grandparent post (Ruby, Python, Javascript, and Java) are all older than OCaml (which is 18 years old) -- Java, JavaScript, and Ruby are all 19 years old, and Python…
20 years for language X do not bring the same amount of benefits as 20 years for language Y, as can be clearly seen if we compare Javascript and OCaml.