3 ms·

>build: Nowadays it's just build: ["jbuilder" "build" "-p" name "-j" jobs ] It's just one line of config and it is worth it since it gives an opportunity to u

>build: Nowadays it's just build: ["jbuilder" "build" "-p" name "-j" jobs ] It's just one line of config and it is worth it since it gives an opportunity to use any build system you want to (or for some reasons have to) use. Still much better then pulling "deps" from github repos directly. >I'm saying that you need to provide evidence that OCaml is faster >"OCaml is hard to very hard to make fast, but the OCaml compiler does a fantastic job despite". In which case you'll need to justify why that matters to me if it's not actually faster than Go (especially if the performance is worse and/or less intuitive). Sure, you can write manually a ton of boilerplate for each numeric type in go, just like it's done in gonum. I'm not sure if it is good since more code means more issues and bugs, and I definitely prefer to write or hack something like this: https://github.com/inhabitedtype/httpaf/blob/master/lib/parse.ml https://github.com/inhabitedtype/httpaf/blob/master/lib/pars... instead of this: https://github.com/valyala/fasthttp/blob/master/header.go https://github.com/valyala/fasthttp/blob/master/header.go (and this is only a header) and let the compiler do all the dirty work. > with a dozen `|>` operators how the hell is `|>` an obscure combinator? It's just a "unix pipe's" typesafe kin. I've never seen any usage of obscure combinators in ocaml beyond parser-combinator libs ofc but these usually are well documented and you wouldn't use them if you don't like combinators anyway. >Something as common as JSON should be dead simple It is dead simple, just add [@@deriving yojson] to your data structure, and you'll get to\of_yojson functions, what could be more simple?

weberc2 9y ago
> Nowadays it's just build: ["jbuilder" "build" "-p" name "-j" jobs ] It's just one line of config and it is worth it since it gives an opportunity to use any build system you want to (or for some reasons have to) use. Still much better then pulling "deps" from github repos directly. I strongly disagree here. Deps is rather ugly, but it works and it's easy to use. A language should have 1 build tool that works for 99% of use cases, and the rest of the tooling should support that by default. This is especially painful for beginners, amplified by the fact that the docs point you to Makefiles by default. > Sure, you can write manually a ton of boilerplate for each numeric type in go, just like it's done in gonum. I'm not sure if it is good since more code means more issues and bugs, and I definitely prefer to write or hack something like this: I'm confused; you're responding in the context of compilers producing fast code, but you seem to be advocating for a more generic type system than Go has, which I've already agreed about. > how the hell is `|>` an obscure combinator? It's just a "unix pipe's" typesafe kin. I've never seen any usage of obscure combinators in ocaml beyond parser-combinator libs ofc but these usually are well documented and you wouldn't use them if you don't like combinators anyway. I didn't claim it was obscure; I claimed that it's not useful--it's optimizing for fewer keystrokes and not readability. I can appreciate code-golf for its own sake, but I need my team to be able to jump into code quickly, and that often means that naive is better than clever and a little boilerplate is better than terseness. BTW, the HTTP parser that you shared is a good example of this. The Go version might be imperative, but at least it's clear. > It is dead simple, just add [@@deriving yojson] to your data structure, and you'll get to\of_yojson functions, what could be more simple? Like I said before; this might not be a good example, it's just the first one that came to my mind. Maybe the problem here is that the good documentation is so hard to find. Still, I've come across lots of unnecessarily abstract libraries before, I just don't recall the details.
- ernst_klim 9y ago
  >I claimed that it's not useful--it's optimizing for fewer keystrokes and not readability. it makes code much more readable produce_collection () |> Col.filter pred |> Col.map to_json Only pure logic of the program remained, no garbage like intermediate vars, loops, etc. >The Go version might be imperative, but at least it's clear. Depends on how do you define clear. If huge manually optimized pile of imperative spagetty is clear, than yes. My definition of clear presumes sophisticated abstractions making hard things easier to reason about and comprehand, not a pile of hand-written state machines. >Still, I've come across lots of unnecessarily abstract libraries before, So many that you couldn't find an example?
  - weberc2 9y ago
    Look, my remarks about OCaml were meant as constructive criticism, and you're plainly taking them personally. Frankly, such defensiveness doesn't make for very interesting conversation, so I'll duck out and leave you to the last word.

weberc2 9y ago

> Nowadays it's just build: ["jbuilder" "build" "-p" name "-j" jobs ] It's just one line of config and it is worth it since it gives an opportunity to use any build system you want to (or for some reasons have to) use. Still much better then pulling "deps" from github repos directly. I strongly disagree here. Deps is rather ugly, but it works and it's easy to use. A language should have 1 build tool that works for 99% of use cases, and the rest of the tooling should support that by default. This is especially painful for beginners, amplified by the fact that the docs point you to Makefiles by default. > Sure, you can write manually a ton of boilerplate for each numeric type in go, just like it's done in gonum. I'm not sure if it is good since more code means more issues and bugs, and I definitely prefer to write or hack something like this: I'm confused; you're responding in the context of compilers producing fast code, but you seem to be advocating for a more generic type system than Go has, which I've already agreed about. > how the hell is `|>` an obscure combinator? It's just a "unix pipe's" typesafe kin. I've never seen any usage of obscure combinators in ocaml beyond parser-combinator libs ofc but these usually are well documented and you wouldn't use them if you don't like combinators anyway. I didn't claim it was obscure; I claimed that it's not useful--it's optimizing for fewer keystrokes and not readability. I can appreciate code-golf for its own sake, but I need my team to be able to jump into code quickly, and that often means that naive is better than clever and a little boilerplate is better than terseness. BTW, the HTTP parser that you shared is a good example of this. The Go version might be imperative, but at least it's clear. > It is dead simple, just add [@@deriving yojson] to your data structure, and you'll get to\of_yojson functions, what could be more simple? Like I said before; this might not be a good example, it's just the first one that came to my mind. Maybe the problem here is that the good documentation is so hard to find. Still, I've come across lots of unnecessarily abstract libraries before, I just don't recall the details.

ernst_klim 9y ago
>I claimed that it's not useful--it's optimizing for fewer keystrokes and not readability. it makes code much more readable produce_collection () |> Col.filter pred |> Col.map to_json Only pure logic of the program remained, no garbage like intermediate vars, loops, etc. >The Go version might be imperative, but at least it's clear. Depends on how do you define clear. If huge manually optimized pile of imperative spagetty is clear, than yes. My definition of clear presumes sophisticated abstractions making hard things easier to reason about and comprehand, not a pile of hand-written state machines. >Still, I've come across lots of unnecessarily abstract libraries before, So many that you couldn't find an example?
- weberc2 9y ago
  Look, my remarks about OCaml were meant as constructive criticism, and you're plainly taking them personally. Frankly, such defensiveness doesn't make for very interesting conversation, so I'll duck out and leave you to the last word.