We know that the extremes of verbosity (e.g. C) and conciseness (e.g. perl) are 'bad'. But why? Because using C generally means writing more code, which takes more time. Whereas Perl is 'bad' because being the human interpreter to read and understand its very symbol dense syntax is slow, so reading Perl is harder than necessary. However, we have that `C` calls this same function `gets` (4 characters), but `perl` calls it `readline` (8 characters)! Therefore, I conclude that conciseness (and thus usability) is not a function of the length of function names (although let's not be extremist), but of language design.
additional thoughts: I can type readline slightly faster than readln, since the former is a word, and the second is not. But the difference doesn't matter compared to the time it takes me to figure out what to type. default arguments are good, like Stefan said, and should be added to `readline`. however, to me, this qualifies as an improvement in language design, in contrast to shortening the the length of a function name please don't a function `Base.readln() = chomp(readline())`, it's really unnecessary and confusing. However, I would encourage you to make a function `MyModule.readline() = chomp(Base.readline())`, as convenient. I feel this incurs the usual problem with creating benchmarks: they don't reflect the real world. in a real julia program, how many times do you type `readline`? in a well-structured program, it's should probably be true that you have a single entry point into your program from the user, so that you can unit test your helper functions without user intervention. in the julia repl, there are 3 uses of the readline function in 2 files, or 0.15% of the lines in those files. in a real jQuery program, how many times do you expect to type `$`? every line? several times per line? perhaps just every tenth line, if you really like spacing out your code? `$` is the roughly jQuery equivalent of `using` in julia (or more precisely, `import ... as ...`). since javascript does not natively have strong code separation, e.g. "modules", it is necessary to fake it with some shorthand. codegolf can be fun anyways. my roommate last year and I spent several months trying to cram a wireless encoding algorithm into a tweet. I think we could only get down to ~186 characters, by which time gcc didn't even want to parse the code (it warned of using a deprecated feature of K&R C, and aborted). clang still computed the correct answer (although I think it also emitted a warning that could not be silenced with any command line flag). the original C was somewhere around three times as long, iirc. On Sun, Apr 13, 2014 at 6:36 PM, <[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). > > 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 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.
