You can write concise Java. Just like you can write readable Haskell. It’s just not idiomatic to do so.

System.out.print("I agree.");

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.

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

They weren't writing enterprise Java or they'd need a dozen factories and a few factory factories and probably a factory factory factory just to be safe.

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.

I think code golf is a great dataset for this kind of analysis specifically because they are artificial and people are paying attention to the number of characters used. Leetcode solutions might be a better option though.

In real world projects there are too many confounding factors. People aren’t implementing servers in brainfuck or websites in C. Even rewrites of a project into another language have more/fewer features. So it’s an apples to oranges comparison.

In newer versions of C# you can use top level statements, which remove a lot of characters

Bash being so high is what confuses me.

Damn near everything is an acronym

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.

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.

How is it's current state for building windows binaries? As a game dev who wants to fiddle with doing "everything from scratch" at least once, Crystal always seemed extremely enticing, the syntax more so than Nim

https://en.m.wikipedia.org/wiki/Brainfuck

For those wondering (like myself)

I've never understood the complaint about forced indentation. What kind of monster doesn't use indentation for their code anyway?

If anything, it's nice that the language forces it on you so that you don't stumble on code written by one of those monsters.

Rest in pieces golfcels it's pychad time

Assembly would be lower. You have more complex / direct instructions in assembly. Brain fuck is pretty much just a pure turing machine, and has 8 instructions.

X86 has ~ 1000 + variants. Even ARM with a smaller instruction set has 232 instructions.

In brain fuck to set a number you'd have to count up (or down - underflow) to that number. In assembly you just set it.

Somewhere I've read that current assembly code with Makros should be similar to writing C.

This is from codegolf competitions, so non-Flutter I'd assume.