I was looking at code.golf the other day and I wondered which languages were the least verbose, so I did a little data gathering.

I looked at 48 different languages that had completed 79 different code challenges on code.golf. I then gathered the results for each language and challenge. If a "golfer" had more than 1 submission to a challenge, I grabbed the most recent one. I then dropped the top 5% and bottom 5% to hopefully mitigate most outliers. Then came up with an average for each language, for each challenge. I then averaged the results across each language and that is what you see here.

For another perspective, I ranked each challenge then got the average ranking across all challenges. Below is the results of that. *removed externally hosted image*

Disclaimer: This is in no way scientific. It's just for fun. If you know of a better way to sort these results please let me know.

    • kaba0@programming.dev
      ·
      1 year ago

      It is always dismissed as too verbose, while in go’s case it is never mentioned, when in fact the latter is way more verbose.. People’s bias show.

      • coloredgrayscale@programming.dev
        ·
        1 year ago

        Maybe also bias by the number / experience of people using it.

        1st semester students getting shocked by public static void main(String args) and meming it on the internet.

        Go on the other hand likely isn't a common choice / option for a first language.

    • atheken@programming.dev
      ·
      1 year ago

      I don’t know the specifics of the golf problems, but I’m mostly in c#, also notorious for “having too much boilerplate,” and it looks like it’s 3rd by char count.

      My guess is that languages with comprehensive standard libraries can do more with less custom code. As you should expect.

    • xigoi@lemmy.sdf.org
      ·
      1 year ago

      Code Golf rules allow people to submit an anonymous function instead of a full program, which eliminates a lot of the boilerplate.

    • muddi [he/him]
      ·
      1 year ago

      I wonder if it's all those variables named with single letter and abbreviations, so annoying to code review

      • GarytheSnail@programming.dev
        ·
        1 year ago

        String IDontKnowWhatsWorseEspeciallyWhenTheTypeIsAlsoIncludedString = "I don't know what's worse, especially when the type is also included";

        • BlueBockser@programming.dev
          ·
          1 year ago

          Honestly, I prefer an overly long name over some cryptic naming scheme that looks like minified JS. At least you can be sure of the variable's purpose and don't have to guess, which is far better for readability.

  • philm@programming.dev
    ·
    1 year ago

    On another look, though, we have to keep in mind, though that this is code-golf, so in no way representative for actual code-bases.

  • expr@programming.dev
    ·
    1 year ago

    Haskell being so high really doesn't make any sense. Experience level maybe?

    It's one of the tersest languages out there.

    • arthur@lemmy.zip
      ·
      1 year ago

      It's hard make such comparisons on "real world" code, and challenges use to be more attractive to people trying to learn, so your hypothesis make sense.

    • silent_water [she/her]
      ·
      edit-2
      1 year ago

      it's probably not code golfed and the type signatures probably weren't elided. because otherwise I'd expect it to be above javascript.

  • spencerwi@lemm.ee
    ·
    edit-2
    1 year ago

    I'm really surprised to see Java ranked as less-verbose than OCaml.

    Here's an equivalent code sample in Java 17 vs OCaml:

    Java:

    abstract sealed class Expr permits Value, Add, Subtract, Multiply, Divide {
      abstract long eval();
    }
    record Value(long value) extends Expr {
      @Override
      long eval() { return value; }
    }
    record Add(Expr left, Expr right) {   
      @Override
      long eval() { return left.eval() + right.eval(); }
    }
    record Subtract(Expr left, Expr right) {
      @Override
      long eval() { return left.eval() - right.eval(); }
    }
    record Multiply(Expr left, Expr right) {
      @Override
      long eval() { return left.eval() * right.eval(); }
    }
    record Divide(Expr left, Expr right) {
      @Override
      long eval() { return left.eval() / right.eval(); }
    }
    

    OCaml:

    type expr = 
      | Value of int
      | Add of expr * expr
      | Subtract of expr * expr
      | Multiply of expr * expr
      | Divide of expr * expr
    
    let rec eval = function 
      | Value value -> value
      | Add (left, right) -> (eval left) + (eval right)
      | Subtract (left, right) -> (eval left) - (eval right)
      | Multiply (left, right) -> (eval left) * (eval right)
      | Divide (left, right) -> (eval left) / (eval right)
    

    ....Java has so much more syntactical overhead than OCaml, and that's even with recent Java and being pretty aggressive about using boiler-plate reducing sugars like Records. And F# has even less, since it doesn't require you to use different operators for numerics or do as much manual casting between strings/numerics

    • GiantRobotTRex@lemmy.sdf.org
      ·
      1 year ago

      It makes more sense when you realize it's based on code.golf submissions. No one is going to create a class like that for a code golf problem. They're probably not going to create any classes (other than one just to hold the main function).

      I'm pretty sure I can do the Fibonnaci one with less code than your simple class. Because these problems are simple enough they don't benefit from any OOP stuff so you avoid most of the syntactic overhead.

      I am surprised it's not higher in the list since the overhead of setting up a main method is still quite significant compared to most languages. But other than that, these problems can be solved without running into any egregious examples of overhead.

  • ydieb@lemm.ee
    ·
    1 year ago

    Interesting that zig is so much lower than c in expressiveness. Isn't that a bit weird?

  • aaaaaaadjsf [he/him, comrade/them]
    ·
    1 year ago

    Surprised by C# and Java. People always moan that they have too much boilerplate code and something else about how OOP sucks and that makes these languages too verbose, yet they're close to the top of the chart here for least characters used on average.

    • jvisick@programming.dev
      ·
      1 year ago

      C# is what I primarily write at work, and it’s honestly great to work with. The actual business logic tends to be easy to express, and while I do write a some boilerplate/ceremony, most of it is for the framework and not the language itself. Even that boilerplate generally tends to have shorthand in the language.

    • BatmanAoD@programming.dev
      ·
      1 year ago

      I suspect this is more a symptom of "enterprise" design patterns than the language itself. Though I do think the standard library in Java is a bit more verbose than necessary.

  • ivg@lemmy.zip
    ·
    1 year ago

    im confused, c and c have header files that are super verbose, not sure how its so high up that list

  • Gamma@programming.dev
    ·
    edit-2
    1 year ago

    It's interesting, the results here are way different than the Code Golf & Coding Challenges Stack Exchange. I would never expect Haskell to be that low. But after looking at code.golf, I realize it's because I/O on CG&CC is more relaxed. Most Haskell submissions are functions which return the solution.

    Sidenote: I like the CG&CC method, it's semi-competitive, semi-cooperative.

    • all languages welcome
    • almost all users post "Try it Online"/"Attempt This Online" links
    • most users post explanations under their submissions
    • often people will post solutions beginning with "port of user1234's excellent Foolang answer" when there's a clever shortcut someone finds
    • or people will post their own solution with "here's a solution which doesn't use user1234's algorithm"
    • or people will add comments to answers with minor improvements

    IMO It's geared towards what is the best part about code golf: teaching people about algorithm design and language design.