> Non-programmers make this mistake all the time: thinking that the syntax is the hard part of programming.
Programmers make it all the time too, or at least something very similar. See all those people who are on the endless quest for the "perfect" language, which usually means one which allows for writing the shortest code, sometimes at a very high cognitive cost for very little payoff. No, I really don't want to do a massive amount of mental backflips just to save a few characters, thanks.
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 :)
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.
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
Programmers make it all the time too, or at least something very similar. See all those people who are on the endless quest for the "perfect" language, which usually means one which allows for writing the shortest code, sometimes at a very high cognitive cost for very little payoff. No, I really don't want to do a massive amount of mental backflips just to save a few characters, thanks.