Live data from Hacker News

OCaml as my primary language

xvw.lol

251–260 of 296 posts

Re: OCaml as my primary language

#251

I tried to like OCaml for a few years. The things that hold me back the most are niggling things that are largely solved in more "modern" langs, the biggest being the inability to "print" arbitrary objects. There are ppx things that can automatically derive "to string" functions, but it's a bit of effort to set up, it's not as nice to use as what's available in Rust, and it can't handle things like Set and Map types…

Go's %v leaves a lot to be desired, even when using %+#v to print even more info. I wish there was a format string to deeply traverse into pointers. Currently I have to import go-spew for that, which is a huge annoyance. Python does it best from what I've seen so far, with its __repr__ method.

The default %v does leave some to be desired, but don't underestimate the utility of being able to shove anything at it and get something back. This is especially important because this applies recursively; you can have a structure that may have something "unprintable" buried deeply in it, but at least it won't prevent you from printing everything else.

Strongly-typed languages that do not force any sort of stringification on values, and thus refuse to compile if you try to dump a simple log message of one of these values out, are really annoying to work with. I understand the conceptual purity of saying "Hey, maybe not everything even has a string representation" but it makes debugging a real pain. If I were writing a new language today I think I'd mandate that everything gets a default debugging string output by default because the alternative is just so rough.

Even a not-great printer that may have a sort of "*unprintable*" bailout, or print something not terribly useful, but doesn't actually stop you from printing anything, is better than a language that completely rejects it at compile time.

Re: OCaml as my primary language

#252
post #123

Is OCaml somewhat suitable for desktop GUI app programming? I saw this in the OP: >For example, creating a binding with the Tk library and had also been thinking about this separately a few days ago, hence the question.

> Is OCaml somewhat suitable for desktop GUI app programming?

No. Unless you also want to be the maintainer of a UI bindings library.

Re: OCaml as my primary language

#253
post #241

Earlier quoted context omitted.

What is pathetic is the quality of your answers, who do you think has written the code between Java 6 and Java 24? I wonder what magic pixie dust has been writing Java code since 2013, those Sun employees have been working really hard on their ghost offices, surrounded by Oracle daemons, down in the dungeons. I am playing the FACTS game.

There is no facts game. I am in full agreement with you that Oracle maintains Java nowadays and writes most of the modern code in it. It remains originally a Sun product, a Sun initiative and most of the JVM historical code has been written by Sun. I have little interest in going to actually look in how many lines are from then and how many are new. It wouldn’t substantially change the nature of my argument anyway. Y…

Oracle has been a fantastic steward of Java. I don’t think Java would exist or still be popular without them. Java is in its best state it’s been in decades.

Re: OCaml as my primary language

#254
post #93

Earlier quoted context omitted.

I mean, I guess it depends on your background, but that code looks pretty nice compared to how it would look in a language without pattern matching and ADTs. This is why the MLs excel for things like parsers, interpreters, and compilers. Beauty is in the eye of the beholder, I guess. I suspect that if you gave it a bit of time it would start to really grow on you - that's how it was in my case. At first: "WTF is this…

I don't find the ADT and matching part weird, but rather everything else (as mentioned).

That's just lack of familiarity.

For this family of languages, it's very uncomplicated and easy to parse (and they all "sort of look the same" if you squint). Consider this: if you knew nothing of Java or C, their syntax would be weird mumbo-jumbo to you too. Even a language which is considered relatively simple, like Python, can trip you up in unexpected ways if you're unfamiliar with it.

Fortunately, getting familiar with the syntax is easy. Doubly so if you actually tackle a project with it.

Coming from a Java/C/Python/JS background, it's hard to casually read OCaml snippets before first getting acquainted with its syntax, because it belongs to a different family of programming languages.

Re: OCaml as my primary language

#255
post #71

I'm sure there's merit to the language, but the syntax seems absolutely alien to me. Some attempt to look like verbose imperative code, a bunch of semicolons, and for some strange reason, hate of parenthesis. Real life sample: let print_expr exp = (* Local function definitions *) let open_paren prec op_prec = if prec > op_prec then print_string "(" in let close_paren prec op_prec = if prec > op_prec then print_string…

I think that wouldn't be too foreign to anybody who has worked for a while in Rust? It's definitely more compact and expressive than the Rust equivalent, though.

This doesn't look or feel all that different to me:

  enum Expr {
      Const(f64),
      Var(String),
      Sum(Box, Box),
      Diff(Box, Box),
      Prod(Box, Box),
      Quot(Box, Box),
  }

  fn print_expr(exp: &Expr) {
      fn open_paren(prec: i32, op_prec: i32) {
          if prec > op_prec {
              print!("(");
          }
      }

      fn close_paren(prec: i32, op_prec: i32) {
          if prec > op_prec {
              print!(")");
          }
      }

      fn print_rec(prec: i32, exp: &Expr) {
          match exp {
              Expr::Const(c) => print!("{}", c),
              Expr::Var(v) => print!("{}", v),
              Expr::Sum(f, g) => {
                  open_paren(prec, 0);
                  print_rec(0, f);
                  print!(" + ");
                  print_rec(0, g);
                  close_paren(prec, 0);
              }
              Expr::Diff(f, g) => {
                  open_paren(prec, 0);
                  print_rec(0, f);
                  print!(" - ");
                  print_rec(1, g);
                  close_paren(prec, 0);
              }
              Expr::Prod(f, g) => {
                  open_paren(prec, 2);
                  print_rec(2, f);
                  print!(" * ");
                  print_rec(2, g);
                  close_paren(prec, 2);
              }
              Expr::Quot(f, g) => {
                  open_paren(prec, 2);
                  print_rec(2, f);
                  print!(" / ");
                  print_rec(3, g);
                  close_paren(prec, 2);
              }
          }
      }

      print_rec(0, exp);
  }

Re: OCaml as my primary language

#256
post #184

Earlier quoted context omitted.

Before 2010-something, the very popular meme in software engineering was that functional programming is really hard to understand, and really not suited for anything outside of academia. [1] Now that I've been programming in an immutable functional language for almost a decade (Elixir), I'm certain the meme was mostly born out of unfamiliarity [2] than actual complexity; it's really not that much different than imper…

> the very popular meme in software engineering was that functional programming is really hard > I'm certain the meme was mostly born out of unfamiliarity > I would go so far as to blame Haskell for the misplaced belief that FP means overcomplicated type theory

Am I supposed to hallucinate a reply from my own words? Say what you mean.

Re: OCaml as my primary language

#257
post #71

I'm sure there's merit to the language, but the syntax seems absolutely alien to me. Some attempt to look like verbose imperative code, a bunch of semicolons, and for some strange reason, hate of parenthesis. Real life sample: let print_expr exp = (* Local function definitions *) let open_paren prec op_prec = if prec > op_prec then print_string "(" in let close_paren prec op_prec = if prec > op_prec then print_string…

As with all languages, the syntax seems strange at first until you get used to it, at which point you hardly think about it.

Re: OCaml as my primary language

#258
post #141

I saw a talk by someone from Google about their experiences using Rust in the Android team. Two points stuck out: they migrated many projects from Python, so performance can't have been that much of a concern, and in their surveys the features people liked most were basics like pattern matching and ADTs. My conclusion is that for a lot of tasks the benefit from Rust came from ML cicra 1990, not lifetimes etc. I feel…

> I feel if OCaml had got its act together around about 2010 with multicore and a few other annoyances[1] it could have been Rust That's about the time-frame where I got into OCaml so I followed this up close. The biggest hindrance in my opinion is/was boxed types. Too much overhead for low level stuff, although there was a guy from oxbridge doing GL stuff with it.

That's still the biggest hindrance in my opinion, at least for my use cases. OxCaml, Jane Street's fork, has some features for unboxed types and stack-based allocation of boxed types; hopefully it goes upstream.

Re: OCaml as my primary language

#259
post #181

Earlier quoted context omitted.

As someone who loves SML/OCaml and has written primarily Rust over the past ~10 years, I totally agree - I use it as a modern and ergonomic ML with best-in-class tooling, libraries, and performance. Lifetimes are cool, and I use them when needed, but they aren't the reason I use Rust at all. I would use Rust with a GC instead of lifetimes too.

How do you use Rust without lifetimes?

When I mean "use" them, I mean make heavy use of them, e.g. structs or functions annotated with multiple lifetimes, data flows designed to borrow data, e.g. You can often get by just with `clone` and lifetime elision, and if you don't need to eke out that last bit of performance, it's fine.

Re: OCaml as my primary language

#260

I saw a talk by someone from Google about their experiences using Rust in the Android team. Two points stuck out: they migrated many projects from Python, so performance can't have been that much of a concern, and in their surveys the features people liked most were basics like pattern matching and ADTs. My conclusion is that for a lot of tasks the benefit from Rust came from ML cicra 1990, not lifetimes etc. I feel…

"I feel if OCaml had got its act together ..." The great thing is we have choice. We have a huge number of ways to express ideas and ... do them! I might draw a parallel with the number of spoken languages extent in the UK (only ~65M people). You are probably familiar with English. There are rather a lot more languages here. Irish, Scottish, Welsh - these are the thriving Brythonic languages (and they probably have s…

From the gedcom wiki page it doesnt seem that bad. At least the data format itself. But it seems like its very easy to screw up working with it.
Post reply on HN