Why `readLine` instead of `readln` like `println`?

Scala provides a builtin function println(), but the recommended function for capturing input is readLine() from

import scala.io.StdIn.readLine

Why was a camelCase style chosen instead of staying consistent with println with readln?

Side question: Why is an import necessary at all, if println is available without one? Are there historical reasons for these quirks?

I’m guessing that println is shorter than readLine because (aside from the fact that it was inherited from Java) it is used more often (e.g., for debugging).

By the way, speaking of println, I wrote my own little version for handling multiple arguments, as follows, and I suggest thise should be the default version.

def printx(a: Any*)(implicit s: Text=" ") = print(a.mkString(s))
def printlnx(a: Any*)(implicit s: Text=" ") = println(a.mkString(s))
1 Like

Consistency would be nice; I believe Kotlin provides both println, printLine and readln, readLine variants as aliases, Scala could do the same. Personally I think println is both easier to type and more pleasant on the eyes, and would like to also have readln for consistency.

I also like your idea that the default println should accept an arbitrary number of arguments.

In my browser, the title displays readln indistinguishable from readIn.

That may sufficiently motivate the name readLine.

2 Likes

I would personally prefer printLine. But I think println was simply chosen because of Java’s System.out.println() familiarity.

1 Like

I suspect that has to do with expected relative frequency of usage. In my years with Scala I’ve used println at least 10x, probably at least 100x, more often than I’ve used readLine.

2 Likes

Between 8 - 10k RPM, readLine is pronounced redline.

1 Like

Regardless of which we prefer, now that we have both inconsistently, it would be nice to add readln, possibly printLine as aliases as well.