Many people looking for the "perfect language" want one that minimizes cognitive costs. An initial increase (comprehensive type systems like in MLs; rust's notion of ownership and lifetimes; Spark Ada's comingling of specification, code, and types) in cognitive cost which, once internalized, results in reduced cognitive costs for certain tasks. Less time spent developing tests. Less time debugging. Less time spent in maintenance (not because it's not needed, but because it goes faster when it's done).

> See all those people who are on the endless quest for the "perfect" language

To be fair, many programming language enthusiasts understand this and seek languages that properly frame the problems that need to be solved.

Sometimes languages seem to have a high cognitive cost because they expose that the underlying problem has a high cognitive cost. Some things that seem really simple are actually rather complex, like string manipulation and data sharing.

There isn't anything wrong with this kind of obsession tbh. We do need SOMEONE inventing, experimenting with new languages and if someone else is excited about doing so I'm quite ok with that :)

Quite true.

Apparently many programmers keep forgetting that the syntax is just a small part of:

- language itself

- toolchains (compilers, interpreters, AOT, JIT, hybrid)

- differences between implementations and specific behaviour

- libraries, both standard and the most well known third party ones

- IDEs

- build systems and deployment options

- extra tooling for correctness like static analysers

- culture of the people that usually cater for the language

Hence why it is easy to dabble and grasp concepts from multiple languages, but very hard to very quite proficient in a few of them.

Do you write in assembly?

If not, you clearly see some gain in more terse syntax.

Seems like a good thing to explore, although perhaps it should not be one's sole focus in life.

The difference comes down to syntax vs. semantics. The problem with assembly isn't its syntax (mov eax, ebx is fairly readable), it's that the underlying semantics are too low level. Exploring new abstractions/semantics to use is very useful (local variables, first-class functions, algebraic data types, etc.), but optimizing solely for source program size leads to a language that's great for code golf and not much else.

Not sure. I mean yes you can abuse some languages and fit an entire program on 1 line (see any golf project). But I can generally grok a 100 line scala program in the same time as a 100 line Java program, and the scala program is usually about twice as dense. (So I am groking scala twice as fast).

I generally find this to be true for myself, too. Although I would add the qualifier that I find Java to be an exceptionally wordy language, for lack of a better term. It seems to take a lot of talk to do a little in Java even compared to other object oriented languages.

Outside of J/K/APL few languages truly attempt to optimize for source size. Few people truly, deliberately optimize around source size outside those language programmers, demoscene types, and mathematicians/engineers-turned-programmers.

Add Ruby to the list. Many gems (and frameworks) advertise with how much you can pack into a single line of code, at the expense of seemingly impenetrable magic happening behind the scenes.

I am obsessed with programming paradigms, not languages.

Best way to learn a new programming paradigm is by learning a new programming language conducive towards a certain manner of problem-solving.

So yes, I am obsessed with programming languages. But not for the reasons you listed.

The language is the medium. I like writing code that I can look at and be happy, for no real reason. For traditional art, some prefer oils some prefer water-colors. It's the same for programmers. http://programmers.stackexchange.com/a/16164

Or learning one javscript framework after the other where you do the same thing with different syntax.