On Sunday, April 13, 2014 6:36:49 PM UTC-4, [email protected] wrote: > > ##readline vs. readln >> Seems like a lot asking for just 2 characters or even talking about it. >> It does make a difference though; It does distinguish Julia from other >> languages. Does it need those 2 letters? It does feel clearer, but at >> what expense? I'm not sure actually. But consider *JQuery*'s ***$***. >> it's just an alias for ****jquery***; the sole reason for its existence is >> so people don't have to type 5 extra letters. But then, that's 5 letters, >> not 2, and it so many people use JQuery, it saves thousands of man-hours. >> > > I believe there is a fine line between language conciseness and tooling. > Personally I prefer reading a whole word than non standard abbreviations. > Please note I mentioned *reading*, not writing. If your tooling (IDE) is > good, you should never have to write long parameter names or keywords or > function names, it should do all that for you. (You should also be able to > create shortcuts for very common words. e.g. J + space, should > automatically write out JQuery). >
I like the discussion! I'm not sure how to interpret your fine line statement though. Are you saying that there is a very complex set of circumstances where tooling is preferred or do you mean there's a precise transition from new to use one versus the other? In the former case, I think you're arguing for refining the language rather than against it. If you can't precisely know when tooling is better then you have to assume that at times it's not a good idea and you'll have to fall back to vi. In the latter case, I think I disagree; we can't even easily come to consensus on whether printline or println is best let alone agree on if an eclipse editing plugin is mandatory or not. > > So having code that reads well and is self documenting is more valuable > than really clever abbreviations that only a few people can decipher. (Sure > readln is not that bad, but once you start abbreviating everything, where > do you stop? If 2 characters are really that important then why not save > another 3 and just shorten readln() to rln()). > I'll say this, I agree with you, you can go too far. I would qualify rln() as a loose lower bound in fact rln is going too far, but I think you can go too far the other way too. "The project" started with simply an observation that people do judge the expressiveness of a language and SE is a useful too as it's a forum with a built in cost function. > I have read code with long (meaningful) parameter names and function names > and have also read code where all the parameters are of the form a1, a2, > b1, b2, etc.. and function names such as dfg(), hfp() etc... and I know > which I prefer *reading* and collaborating with. > > In summary I feel tooling can bridge the gap and keep everyone happy. > I have to straight up disagree on that. A language needs to stand on its own.
