[flagged]
My thoughts on OCaml
51–60 of 230 posts
Re: My thoughts on OCaml
#52Why 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.…
It won’t really answer your question, but I found the Signals & Threads podcast fantastic, and it made me appreciate OCaml much more (it is produced by someone working at Jane Street).
I personally found the MirageOS, build systems and language design episodes terrific.
Re: My thoughts on OCaml
#53[flagged]
Can you elaborate for us newer OCaml users? My first reaction to this critique/point is the author must want mli, right?
Re: My thoughts on OCaml
#54Building, LSP server, and immutability are definitely better in 2023 than author describe in their article.
In what sense is immutability better? What changed?
Re: My thoughts on OCaml
#55I don't the author really gave Ocaml a chance. He argues that every language needs to have interfaces. I agree somewhat with that statement, but I think the truer statement is to say that every language needs to have some way of defining composition at a structural level. An interface allows you to pass different "structures" to the same function so long as they adhere to the same spec. In Ocaml this is accomplished…
> 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?
Re: My thoughts on OCaml
#56I don't the author really gave Ocaml a chance. He argues that every language needs to have interfaces. I agree somewhat with that statement, but I think the truer statement is to say that every language needs to have some way of defining composition at a structural level. An interface allows you to pass different "structures" to the same function so long as they adhere to the same spec. In Ocaml this is accomplished…
Came here to make this exact point. But I totally agree with all of his other complaints. It’s a good list of the cons, but ignored the many pros
Re: My thoughts on OCaml
#57I 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…
F# is such a great language. The fact Microsoft seems to pretend it doesn't exist is bewildering. Surely the .Net ecosystem can have two languages being promoted.
Before F# came into VS 2010, we already had C#, VB, C++/CLI (nee Managed C++), IronPython, IronRuby, and all the third parties targeting the CLR.
It is really not having a clue what purpose they want for F#, I bet they have repented to ship it on VS2010.
First it was for libraries only, then during the VS Express days it was for Web development, now they are trying to pivot it into data analysis and ML, while DevDiv manages to bring Guido out of retirement and finally manages to pursuade CPython core team about improving its performance.
Re: My thoughts on OCaml
#58I don't the author really gave Ocaml a chance. He argues that every language needs to have interfaces. I agree somewhat with that statement, but I think the truer statement is to say that every language needs to have some way of defining composition at a structural level. An interface allows you to pass different "structures" to the same function so long as they adhere to the same spec. In Ocaml this is accomplished…
> 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.
Re: My thoughts on OCaml
#59I 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…
F# is such a great language. The fact Microsoft seems to pretend it doesn't exist is bewildering. Surely the .Net ecosystem can have two languages being promoted.
> F# is such a great language.
I very much feel this, I found it productive, but it feels like a complete ghost town. I'm considering swapping to Go over using .NET for tooling/scripting.
Re: My thoughts on OCaml
#60Why 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.…
Back when I tried it, there seemed to be a few verticals where Ocaml abstractions made Ocaml very productive to work with.
Once a colleague and I did a programming race between two languages, to see how long it would take to implement a small cryptanalysis program using Ocaml vs C++. I wrote it in a day, and it took my desk neighbor who was doing the same in C++ a couple of weeks.
What made the difference: - There were a lot of things I didn't have to worry about. For example, I was working with nontrivial structures but didn't have to write any boilerplate functions for deep equality or lex ordering. - Immutable structures with GC made it much more direct to translate the math into a working program. Ditto with guaranteed tail recursion optimization. - The match syntax caught many issues at compile time by forcing me to reason about every case. As a result I had many less runtime bugs to deal with, while my colleague needed to troubleshoot memory and correctness issues half the time.
Ymmv. This was for research and didn't end up in production use. The C++ implementation was also much "closer to the metal" so was able to wring out more performance. Still the difference in initial velocity was striking and there could've been a case that this would've been a better choice based on dev velocity in that vertical.