(which is allowing nice postfix ones with currying)
Scala does it pretty well. and nowadays finally the function names don't require a PhD in ancient Egyptian hieroglyph decoding.
so requiring alphanum names for functions is pretty important imho. (sure it's okay if it's just a stern lint warning and the developer has to opt-in. but searching for iteratee is easier than searching for \∆>> or whatever.)
I think it's okay for a language to help guide its users toward "better code" (of course Rust is the big one for this).
But I'm also a firm believer of providing escape hatches. So it should be just a toggle in the project/file/directory to enable whatever behavior. And a very good language would require a human readable explanation for these, so when the developer says
allowEmojisInCode = true "we decided to allow emojis to make our happy DSL, see emoji reference at https://..../...."
downstream users/readers of the code are in a much better position than with just 30000 lines of emojis :)
Scala has this escape hatch. But it's annoying. Why can I use arbitrary symbols (even with spaces, and such) by adding back-ticks, but not regularly. It wouldn't make any difference, besides not looking bad and needing extra key strokes for absolutely no gain (as it does not prevent bad code anyway!). I hate that kind of hand holding! Like I said: It's not the business of a language to judge what kind of code is "good".
Scala does not even let most people on the world express code in their native language, and that in the age of Unicode! Sorry, but that's a little to much of "we know better than you what's good for you" kind of thing.
Of course I know where this comes form: Scala is used broadly in education. There it's good to not allow the students to do all kind of "madness".
But Scala is also mostly used by seasoned professionals in real world settings. (Just have a look at the latest survey, found on the Scala website). For a professional it's just extremely annoying when a language tries hard to know better then they how "good code" should look like. The main thing about a expert programmer is that he knows when it's OK to break "rules". Needing to jump through arbitrary but completely useless loops just to do that — when you know exactly what you're doing(!) — makes me mad sometimes.
I considered to fork the compiler not only once because of this. I hate such kind of "but we know better" behavior.
The backticks are more of an anti-feature than anything, and it's absolutely not a file or module/package level setting. (I think a lint-exclude at declaration site would also be okay.)
> It's not the business of a language to judge what kind of code is "good".
Well, yes, but no. Language design is just inseparably infused with judgement calls. Making things easy leads to them being used (as the backtick illustrates, making things hard reduces their usage, even if it sounds nice that it allows for special cases).
But as you imply the language has to be flexible and thus powerful enough to provide the option of a seriously different design trade off. (Because backticks are just a bad compromise. It's not really switching to a different design choice after all.)
> I hate such kind of "but we know better" behavior.
I think that implies too much intent on the Scala core team, unfortunately the reality is - probably - that historically someone wanted something, it got done somehow, and that's it. (In the particular case of backticks maybe Martin really had a strong opinion. Dunno. Probably you have looked into this at least a few times if you considered a fork :) )
... related to this the recent discussion about Rust's GAT (generic associated trait) feature is a very interesting case study in the intersection of language design, "project governance/management" (the reality of pragmatic compromises). There a small team spent at least a year developing GAT support for the compiler, and then a bunch of people were asked to decide whether to merge it. And it's a very unenviable position, because of course the work was not perfect. So what to do? In the end, I think at least, the narrative that was comfortable for everyone involved was that "this is the best version we can have realistically, and yes it provides net positive value in this current state".
(which is allowing nice postfix ones with currying)
Scala does it pretty well. and nowadays finally the function names don't require a PhD in ancient Egyptian hieroglyph decoding.
so requiring alphanum names for functions is pretty important imho. (sure it's okay if it's just a stern lint warning and the developer has to opt-in. but searching for iteratee is easier than searching for \∆>> or whatever.)