Imagine adding types to a legacy JavaScript codebase. You can turn everything to valid TypeScript by annotating `any` everywhere, then you can gradually add types here and there.
Or imagine writing Rust with `Rc` everywhere and then using the borrowing style on the hot path.
I can see where the author is coming from, but sadly a difficulty is that dependently typed languages often require the programmer to prove type equality during type checking. It's hard to do if the information is not complete.
AGI aside, sometimes HN critics/cynicism indeed points out the exact reason why something wouldn't work and is vindicated after the fact, e.g. Apple Vision Pro. I guess it's just hard to predict the future and for me, it's interesting to listen to even pure contrarians.
That private enforcing company has zero motivation to make the rule clear and easy to understand. Their letter soliciting license fees or a declaration of not needing a license is very obnoxious and threatening. Part of the strategy is that "you won't know whether you need a license, but if we caught you violating this arbitrary opaque rule, you're screwed. So you better pay that money."
The project itself is cool, but I'm doubtful on the philosophical side.
Mermaid aspires to be the Markdown of diagrams, so being editable and consumable via plaintext is paramount. If I have to use a visual editor, why not fetch for more powerful tools and be liberated from the limiting format?
This is akin to a WYSIWYG Markdown editor (which to be fair has a niche market). I would ask why not just use Google Doc or MS Word at that point?
Realistically, it's probably the group inside the Chinese Academy of Sciences wanting for a larger impact factor for their review, similar to all other state sponsored researching institutes.
From a Lisp-like introduction, to OOP (in Java), then to ACL2, and finally back to OOD. It's quite interesting in its own right, but now that functional programming is more and more adopted by the mainstream, perhaps there's no need for the "practical appeal" of OOP/OOD in the mix, or does the author genuinely believe that's the way to go?
I made a similar transition (1 year Haskell, 2 year OCaml) and this pretty matches up my experience. Some more points:
1. Compiler speed: a clear win for OCaml
2. OCaml 's module system is more explicit (always qualified Map.find). Haskell's type class system is more ergonomic (the instance is found through its type, so no explicit annotation needed, e.g. fmap fmap fmap, where the second must be the Reader's fmap).
3. > If I come to an existing OCaml project, the worst thing previous developers could do to it is have poor variable names, minimal documentation, and 200+ LOC functions. That’s fine, nothing extraordinary, I can handle that.
Though it's not common, but functor-heavy codebase does give you a headache. On the other hand, unifying type class instances across packages is no fun either.
4. OCaml's mixture of side effects and pure code tends to encourage using that in libraries and codebase. So expect more speed and more crashes.
My problem with OCaml is that it's in an awkward spot where the runtime offers very little, so it can't really be compared with most Haskell use cases where you want green threads (with preemptive scheduling), transactional memory, and so on. The runtimes of the languages aren't really equipped to do the same things, basically.
So that leaves OCaml in a spot where it instead competes with more bare runtimes, i.e. compiled languages like Odin, Zig and Rust.
In terms of straight forward control of behavior OCaml loses handily to both Odin and Zig. Likewise with how much effort you have to put in to get good performance out of what you're doing, despite what OCaml enthusiasts say it's not magic fairy dust, you still have indirection in terms of expressing your desired allocation patterns, etc., in OCaml that you wouldn't have in Odin/Zig, making it less appropriate for those situations.
So, OCaml's final upside: Language simplicity... It's not remotely small or simple enough to be compared to Odin. Zig (despite their best efforts) is still a simpler and leaner language than OCaml as well. Zig also has the interesting quirk that it can express functors just with its `comptime` keyword (returning structs with parameterized functions, all done at compile-time) in a much more straight forward way than OCaml can, making it almost a better OCaml than OCaml in that particular respect.
Given the above it seems to me that there's always a [obviously] better language than OCaml for a task; it can't really win because whatever you're doing there's probably something that's better at your most important axis, unless the axis is "Being like OCaml".
I liked writing OCaml with BuckleScript, though, compiling it to JS and using OCaml as a JS alternative.
OCaml's ecosystem is significantly smaller and less well developed than Haskell, and since you've given up on tight and clear control of allocation strategies by choosing OCaml, Rust looks like a very good alternative, which has an absolutely massive ecosystem in comparison to OCaml.
Again, the main issue with OCaml is that it really doesn't have an axis it's even in the top 5 of, except maybe compile times.
I understand people who like OCaml. There's a lot that's good about it, but it just doesn't have any edge. There's almost no way to pick OCaml and objectively have made a good choice.
I'm pointing out exactly the same thing I was in my original post: There is no axis on which OCaml is top 5. If you want control, there are better languages, if you want ecosystem, almost every language beats it. It's practically speaking never the best choice for anything. Basically the only reason anyone would ever choose it (for pretty much anything) is because they like it.
Or imagine writing Rust with `Rc` everywhere and then using the borrowing style on the hot path.
I can see where the author is coming from, but sadly a difficulty is that dependently typed languages often require the programmer to prove type equality during type checking. It's hard to do if the information is not complete.
reply