“Screw it, I'll make my own” – The story of a new programming language

I think camelCase easily beats underscores, but I also think it can reduce clarity a bit as soon as one uses abbreviations or mnemonics that commonly are written in all caps in identifiers.

Do you name your class IoChannel or IOChannel? For some, the former is a channel on a moon of Jupiter.

Do you name your variable classId or classID? For some, the former is related to Freud, so one could expect to see classEgo and classSuperego, too.

Made up examples? Yes, but I don't think you can fully ignore aesthetics; I find that camelCasing such terms as ID, IO, XML and HTML in identifiers sacrifices clarity. 'Id' in particular makes me cringe whenever I see it (yes, that makes me a bit of a snob, but I simply cannot get used to it). That certainly applies to cases where a common abbreviation also is a word or easily read as such.

On the other hand, I also think keeping such abbreviations all uppercase in CamelCase identifiers sometimes "doesn't look right", and "doesn't look right" aka "aesthetically ugly" distracts me from understanding code.

Also, the argument that "showing more" implies "more practical" isn't that strong. If it did, we could take an idea from colorForth and remove spaces, replacing them by color or font changes. We also could use multiple statements on a line.

I think I would prefer a language that allowed hyphens and punctuation in identifiers (the latter are really useful for such conventions as using a trailing '?' to indicate a method that tests a Boolean condition, a trailing '!' to indicate methods that mutate their arguments. I also like the Dylan convention of using asterisks to indicate class names.

That is 'think', though, because I don't use one for practical reasons such as the availability of libraries.

Certainly that's a useful starting point. The problem is in figuring that out when there are multiple, roughly similar representation.

But it also depends on the goal. Sometimes it's better to learn a new format (Einstein notation, bra-ket notation, copy editing and proofreading symbols, modern staff notation for music, shorthand, etc.) than to use a system that a larger subset of people will understand immediately.

Forth is an example of a programming language which is developed for programmer productivity, on the assumption that the programmer will put in the effort to be proficient in the language.

For my money, I'll take Python conventions of CamelCase for a few things and underscores for the rest. I find underscores a lot more readable (the omnipresence of CamelCase is one of these things that irk me about C#, though it's not as bad as the mutant mix that is Capitalized_underscore which you see in some OCaml codebases).

This rings very true. I look at Ceylon and the features I'm most jealous of are things that Scala would and should just do, except for the need to retain compatibility with 10 years of existing applications and libraries, so instead they're enhancement proposals for the version after the version after the next version, and in the meantime we get by with macros that more-or-less cover the most important use cases. And Scala is relatively young as languages go - its warts are nothing to those of, say, C++. Sometimes I wonder if language design can only advance by new languages killing existing languages - past a certain point it seems impossible to change a language in the ways that it needs to be changed to become good.