3 ms·
I mostly agree with you in that OCaml has a lot of problems no one is willing to admit exist. The language isn't very elegant and the type system is primitive c
by smabie 6y ago
I mostly agree with you in that OCaml has a lot of problems no one is willing to admit exist. The language isn't very elegant and the type system is primitive compared to Haskell or Scala.
I would use Haskell, but I don't believe in tracking effects with a type system and also lazy by default causes a lot of problems. Of course I guess I could use unsafePerformIO everywhere, but that seems wrong.
I've said this before and I'll say it again, modular implicits would be a game changer for OCaml.
- brmgb 6y ago> I've said this before and I'll say it again, modular implicits would be a game changer for OCaml. That would be the second time we disagree about that on HN but I still fail to see how modular implicits are supposed to be game changing for OCaml. The situation was different before 2011. Now, first-class modules and local open have made modules really easy to use. Modular implicits would mostly be sugar most of the time.
- smabie 6y agoYou're right that both of those things help OCaml out a lot. But just look at all the powerful stuff people do with Scala and implicits. All of that could be done with OCaml: typeclasses, parameterized behavior, configurable functionality, testing. All of that stuff can be done explicitly right now, but I really do think there's something powerful about changing an include/import and having all your code change behavior. For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. You gotta admit there's something just really awesome about that.
- brmgb 6y ago> For example, you could have two logging modules: one that logs to stdout the other that logs json to elasticsearch. Simply change an import, and the logging behavior of your entire app changes. But you can already do that with parametrized modules. Just change the module you pass as a parameter and the behaviour cjanges. It is not more cumbersome than changing an include and it is much more clear (dare I say explicit) in its intent.
- smabie 6y agoBut what if you're doing a bunch of category theory stuff? Passing in the right monoid or whatever to every function is such a drag. Alternatively using local open is also a drag. Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. Not sure how it came to be that everyone totally ignores it.
- brmgb 6y agoBut why would you be doing a bunch of category theory stuff while writing softwares ? Local open with let+ and let* make writing monadic and applicative code very easy when needed. Anything more abstract than that is over complex abstraction. OCaml is not Haskell. Trying to write Haskell code in OCaml is always going to result in something highly unidiomatic. > Maybe people should just use OCaml's object system. It solves a lot of these problems and is very powerful. I have written a fair bit of OCaml and never actually encountered these problems. In practice, module prefixing and local open are just fine. You rarely use more than one module per function anyway. I agree that the object system is nice but structural typing is rarely what you want and it leads to convoluted error messages.
- centimeter 6y ago> Of course I guess I could use unsafePerformIO everywhere I don't understand comments like this. This is obviously not something that Haskellers actually do, so the simplest conclusion (or, it seemed simplest to me starting Haskell) is that thinking this is necessary is simply indicative of not understanding how to program functionally/monadically. Indeed, once you figure out Haskell idioms this isn't ever an issue. You might also say that OCaml suffers from using unsafePerformIO everywhere, all the time. > modular implicits would be a game changer for OCaml. They would be very nice!
- smabie 6y agoOf course it's not necessary. I have a lot of experience with Haskell, but I still believe the Haskell way of tracking effects puts an undue burden on the developer. I'm simply not interested in keeping track of effects and mutation. In my experience, there's little value in the monadization of all effects and also a non-trivial cost. I much prefer the traditional FP style of avoiding mutation and side-effects but not lifting them into the type system when they are necessary. This does mean you can screw up and accidentally mutate things, but I've personally never had the problem.