Am I missing something? I don’t think the standard library has any horrible, illegible names? And for your own code you can use whatever you want (even those questionable Unicode characters). What are we talking about here?
2 Likes
Speaking only for myself, it was a proposal to use unicode characters to obviate the need for has_ and is_ in function names, in order to more closely align with Base’s decision to avoid underscores wherever possible.
Right. I understand your point, but then my concern about the Unicode being possibly misunderstood as an operator is I think valid.
How about using prefixes with underscore and then mashed words when sensible? i.e.: has_selfloops, is_foobar, etc.
While I do think that this topic has probably seen enough discussion, something that I haven’t seen mentioned yet is the fact that we have easily accessible documentation via the REPL. So, even if a function name looks somewhat confusing at a quick glance, we can easily search it in the REPL and open the documentation, which would hopefully clear up any confusion. I think this should not be overlooked.
6 Likes
It’s not overlooked, but it’s another drag on productivity (just like taking longer to read something if names are mashed together instead of having words separated via underscores).
Julia can be a very productive language, but some of that is lost if you have to be copy/pasting stuff into the terminal to find out what it means.
1 Like
For what it’s worth: I really like the principle of trying to find a good policy and then stick to that policy even in fringe cases where it might be sub-optimal. It significantly reduces the number of things that I have to memorize.
For example, knowing that Julia never puts underscores in function names is just one thing to remember.
On the other hand: putting underscores “where necessary” would require me to memorize a list of maybe a hundred functions where the developer deemed underscores “necessary”.
I’ll happily sacrifice some readability for less memorization.
2 Likes
I suspect that one of the things that is not made explicit in these discussions is how much people rely on their IDE when writing code. In a reasonably good IDE, you would never need to memorize anything, and function names are be completed from fragments.
I agree that the fewer special cases one needs to memorize, the easier programming is. But function names just scratch the surface: it is nice to have them consistent, but that’s just the first step. @Evizero above mentioned a particularly important point about API design using multiple dispatch, which allows a small, composable vocabulary. I think that this is the an ideal we should strive for when feasible.
At the same time, designing a good API is an organic process that takes multiple iterations, which are sometimes tedious, frustrating, and occasionally require backtracking. My impression is that #20402 is not meant to be the final word, just a single pass to fix some warts and inconsistencies. No doubt there will be further ones, with results that are impossible to predict (if developers could predict the final API, they would write it first).
Evizero is reasonably confident that he didn’t even read this thread, let alone comment on it
1 Like
Of course, it was @ExpandingMan. I hit the wrong completion (but then why was it offered? a mystery). Sorry for the noise.
3 Likes
That is definitely true for languages like Java, where you frequently write things like GodObject.SubObject.SubSubObject. However, it is not so common for languages like English, where words are much shorter, but the first few letters of a word are not easy to guess unless you know the entire word.
I agree with your point, but you have to admit that this is a bit funny given the quote below 
9 Likes
Touché 
Discourse would probably not be a good IDE 
1 Like
I would much prefer the is_ has_ versions. The issue is exactly as you say, because we chose a convention for separating words that uses an extra character (_) people conflate this with being “verbose”. Nobody in javascript or C# would ever have hasloops instead of hasLoops because the convention doesn’t get mixed up with some strange feeling about being “shorter”. What is happening in julia is that we hate underscores, so we are left with ad hoc rules for when to use them and when not. Because of Base you really should name things like hasfoo and isfoo but if you have all other versions in your code with pre_foo then you now have a subtle convention that is not consistent. People are bringing up math abbreviations, but I really don’t find this convincing. Even Mathematica which is the shinning light of consistency uses the abbreviations, I think very justifiable deviations from convention is easy to understand.
Optim.jl is a beautiful example of nice consistent _ use, but it does feel like it clashes with Base. And even when I want to use the pseudo conventions from base if I do hasself_loops I feel gross but has_self_loops is less idiomatic. I know jokes about Hasselhoff seem to make this seem cute, but it is just adding a lot of special cases to the conventions used which make the language harder to remember in a pinch.
My eyes are open that this is not going to change, julia is going to be more like English, which lots of strange special cases and alternate spellings. I guess all I take from it in the end is that _ conventions are inferior to camelCase, people are just irrationally against 1-3 extra characters and will build whole sets of individual decisions instead of adding this insignificant overhead.
5 Likes
Again, I am not understanding this conversation. Are you guys complaining about the stdlib names or about some (imaginary) restrictions on the names you yourselves can use in your code? I say imaginary, because as far as I know there are no restrictions! Do you wish to stick to Julia conventions? Go for it! Do you wish to hang loose? Nothing prevents you…
6 Likes
I think it is you who are conflating things. Removing underscores does not make identifiers shorter. But discouraging underscores encourages you to make shorter identifiers.
More characters, more verbose (particularly if they are as inconvenient to type and, more importantly, visually conspicuous as _). That’s my definition of verbose. (I rather like camelCase, that’s a separate issue.)
Ok, but there are certainly cases in which I’d prefer mathematica to be more concise. As I’ve pointed out a number of times, multiple dispatch makes this somewhat easier in Julia.
Why not? This is the golden standard for comparison. Mathematical notations are largely designed to be easy to understand when you look at them. Seeing \nabla_{\mu}F^{\mu\nu} = J^{\nu} as \sum_{\mu=1}^{4}\nabla_{\mu}F^{\mu\nu} = J^{\nu} ~~ \forall \nu makes me want to kill myself. is_bits isn’t nearly as bad bit it’s still annoying.
Good notations have given rise to many wonderful tools and are an important boon in helping to understand things. Some subjects are difficult to study largely because they are notationally difficult. If we held consistency and explicit specification as the highest standard a lot of math would be completely unreadable. I very much want my code to look as much like mathematical notation as possible. Sometimes that’s impossible or impractical, a lot of times it leads to mildly inconsistent names such as isthing or hasthing.
1 Like
What are the Julia conventions for underscores? I get that when I am by myself I can use whatever I want, but this feels like a shallow response. I work in teams, I share my code, code conventions exist to remove barriers to reading other peoples code. I am happy to submit to whatever the prevailing convention is in a language I use. Julia is tricky as one of the main conventions for naming is ad hoc, how to I separate words? It seems to be mash together when you can, use underscores if you must – but feel bad about it, and wonder if maybe there is some magical mashed version that is better. But recently with some of the audits in Base this is moving to, mash together always.
If when 1.0 comes out and Base has not a single user facing _ name. The true de facto convention will seem to be lowercase names are purely mashed together. And more likely each project will make a personal choice on what it uses, so when using Base + Optim + LightGraphs etc, you will have potentially 3 different _ patterns to remember, and worse, see in your code. Maybe I choose my own convention as well, because freedom! So I will use camelCase as I want word separation, but don’t want those dastardly underscores. This is the conversation I was trying to have. What I feel has come back is that it is not an issue. Which I guess is a question for the future as the ecosystem stabilizes, maybe some true convention will emerge, or we will just have a stochastic pattern of underscores in Julia code.
4 Likes
we are talking about 1 character in the vast majority and 3 at the almost absolute worst. I just don’t buy that this is the same as real progress in notation, which is a vastly more difficult issue. 3+3 vs 3 + 3 I would argue is no change is semantic / notational beauty, but it is a perfectly good convention for separating operators in programming languages even if it has 2 extra characters. I see underscores between words (again with no arguments on what the words are, or if they are minimal) as being a typographic convention for programming, it is not a semantic change in notation.
1 Like