I wouldn't say the code is really that small in its language context, which is why comparing code by lines is inherently fallacious. It's just that a large per

I wouldn't say the code is really that small in its language context, which is why comparing code by lines is inherently fallacious. It's just that a large percentage of languages are quite similar in how they're structured. Since Pascal and at least until Java/C#, most mainstream languages ended up roughly doing "one thing" per line. Quite often one function call or simple mathematical operation. Then each function or block of a larger one does one larger thing. And so forth. Code and/or languages that break that paradigm are often confusing to "switchers" and thus often abandoned or maligned way too early. But most often, they're just scanned differently. Assembly would be the opposite end. It basically takes "do one thing per line" to the extreme. But quite often, experienced asm programmers scan the program by blocks, as some patterns are quite common or you find some constant/string to attach your focus to, then continue from there into the details. Forth programmers obviously read slightly differently, due to the high level of decomposition and the stack based nature (fewer parameters). Lisp looks a bit weirder at the first glance, but I wouldn't even say that it's read all that differently from the Algol family, if written imperatively enough. Functional code, in almost any language, often has to be read differently, as a lot of things can happen in one line. APL and some DSLs (regular expressions for example) are the opposite end of the spectrum. But line length would be the wrong axis to judge things, the amount of operations isn't necessarily that much smaller. Data exchange (arrays vs. stacks vs. function parameters) is the bigger change, as is symbolic density (APL symbols vs J shorthand vs. function names vs. HiHowYouDoingIAmAnAbstractJavaBeansFactoryConsumerImplementationNiceToMeetYou)