4 ms·
I have to agree. Sometimes you do find developers with so much tunnel vision of the "one true way" that it becomes difficult to open their minds to doing things
by solidninja 8y ago
I have to agree. Sometimes you do find developers with so much tunnel vision of the "one true way" that it becomes difficult to open their minds to doing things slightly differently.
For example, the null safety example and the complaint that having `!`, `?`, `!!` is "too Scala like" and too complex. I wonder if the author ever had to reason about <? super T> or <? extends T> in Java (e.g. https://briangordon.github.io/2014/09/covariance-and-contravariance.html https://briangordon.github.io/2014/09/covariance-and-contrav...). Scala doesn't even have these sigils (there is a different syntax for variance, type bounds and context bounds - but that's about all there is).
Another example - "In the C-family of programming languages, we have the standard way of declaring types of things." At that point you may as well point out that maybe Kotlin isn't in the C family.
- lokedhs 8y agoFirst let me tell you that I agree with you, and I just have a small comment. The type bounds in Java are there for a reason. Kotlin's syntax is simpler but it it unable to express all the types that the Java model can. I have found myself in situations where I want unable to express the proper type information in Kotlin simply because the designers of the language decided that having full support was too complicated.
- paulddraper 8y agoScala does have wildcard types. List<? super T> is List[_ >: T] List<? extends T> is List[_ <: T] Scala leave a feature out? Psht...always room for one more.
- solidninja 8y agoRight, you can use _ as the placeholder for a type and it works with the bounds syntax. I probably did not make it clear enough - my point was that Java is also not as "simple" (for some definition of "simple" the author could use) as you'd expect. For good reasons too - these bounds are useful to have sometimes!