It seems like there are about 22 27 46 219 320 493 1840 active subscribers here. I have a few questions for you all.

  • Which programming languages do you regularly use?
  • Which are your favorite to work with and why?
  • Which do you have interest in trying and why?
  • AbelianGrape@beehaw.org
    6·
    1 year ago

    I teach a class taught in OCaml. Despite that, I don’t really like OCaml. It’s good for education but IMO not that great for actually using it. My brother works at Jane Street and even he agrees… Like, it’s fine, but not great.

    Beyond that I make regular use of Haskell and Python for my graduate research and personal projects. I recently took a course in Java, but unless I don’t have a choice, I’d rather use Kotlin. I’m also involved in the hardware simulator Turing Complete, so a lot of my side projects lately have been ETCa assembly programs.

    I want to learn Rust and Scala, probably in that order.

    edit: I also quite like Scheme and I used it for advent of code last year. Unfortunately I don’t get opportunities to use it much, but if I ever get to teach a compilers course, I want to try the “reverse nanopass” approach that is currently used, I believe, at Brown University.

    • ericjmorey@beehaw.orgOP
      2·
      1 year ago

      I don’t really like OCaml. It’s good for education but IMO not that great for actually using it. My brother works at Jane Street and even he agrees… Like, it’s fine, but not great.

      I don’t get to converse with a lot of OCaml users. What makes it “not great”? Is it the tooling?

      What is your graduate work on?

      • AbelianGrape@beehaw.org
        2·
        1 year ago

        The tooling is actually OK, provided you work on Linux. If you work on windows, the tooling is basically telling you to go get Linux.

        It doesn’t capture a lot of what many functional programmers consider the essence of FP: the language, and the people who use it, actively encourage mutable state in programs, and the type system is not powerful enough to capture useful abstractions like functors (generalized containers) or monads (generalized patterns of computation).

        There are also some specific language design decisions that I don’t like. For example, this code typechecks:

        let id : 'a -> 'b = fun x -> x;;

        The 'a -> 'b is a type annotation that says “you give me anything of type 'a (a type variable), and I’ll give you back something of type 'b.” That’s complete bogus - that’s not possible. It typechecks because OCaml goes “OK, this is fine as long as 'a and 'b are the same variable,” and then for the rest of the typechecking process, that’s what happens. id actually gets assigned the type 'a -> 'a. In the best case, this is confusing and occasionally useful to do what other languages do with “type holes.” In the worst case, it’s actively wrong. Using different type variables in a type can provide static guarantees that some things cannot mix, and with OCaml that is simply not possible for a declaration like this one. You can do it, but with a lot more boilerplate. Compare that to Haskell, where the right behavior is the default, and you can obtain a type hole just by using a variable name that starts with _.

        My graduate work is currently on type error provenance. You know some piece of code has a type error, but where is the actual problem? This is a hard problem that compilers are notoriously bad at answering.