|
|
|
|
|
|
by dionian
3199 days ago
|
|
|
Yes, the problem with lack of clarity is more often than not the fault of the API designer, not the language. Non-traditional method names like ~%>$ or whatever should be done in a very clear and easy to understand way; if not, that's a feature of the language that was used poorly by the software engineer. Scala actually has a very consistent and simple syntax which after some initial learning phase is very easy to follow. The standard library on the other hand, like many APIs which are written in idiomatic Scala, can be difficult to understand, especially at first. I don't admit to understanding it anywhere near as well as I do the Java standard library. But the issues with Scala in this area is more akin to finding issues with the Java standard library (there are tons!), rather than Java as a language or a VM (two other things which are also correctly referred to as 'Java') One of the biggest humps I had when getting into Scala full time was getting my head around the fact that many of the features of Scala actually occur at compile time, which as a Java veteran was something that took getting used to. |
|
|
Well, a language that enables unreadable cleverness can be said to be at fault. This is why languages, like Kotlin, that follow the Java philosophy, intentionally try to avoid introducing primitive constructs (regardless of whether you believe they are "intrinsically" "simple") that give rise to such cleverness, even at the cost of what others may call expressiveness. Valuing expressiveness over readability (which I here define to be no-cleverness) or vice versa is ultimately a matter of personal preference, but it is a value judgment that's made by the language, and languages that differ in the priorities of their values are very different from one another. Just as the difference between a pure language that guarantees (for the most part) immutability vs. a language that doesn't (even though no one is stopping library designers from writing only pure functions) is big, so is the difference between a language that guarantees (for the most part) readability vs. one that doesn't.