Hacker News Reader

Comment by jermaustin1 | Hacker News Reader

I don't know if I like the "Elvis Operator" - I feel its one too many conditions on a single line.

And the ternary operator is just odd when there is a more terse "standard" approach to it.

The Elvis Operator is particularly useful because it's such a common pattern in Kotlin, since the language enforces null safety. When you're using a legacy Java API without nullability annotations, the language forces you to explicitly handle a null result.

It masks the complexity of your statement. I know in ruby we had the same issues with the “try()” method. Our rule was, do or do not, there is no try. :)

More info: https://karolgalanciak.com/blog/2017/09/24/do-or-do-not-ther...

No, in that case it does not enforce it

The Java types become platform types

The beauty of the ternary operator is that it isn't one. It's just taking advantage of the fact that if/else is an expression in Kotlin and it turns out that when if/else yields a value, a dedicated ternary operator is redundant. It's one of a small number of things that I like better about Kotlin than Groovy.

That's actually a really clever (yet simple) design. Have other languages done this before?

Now I cannot "unsee" that concept. Why isn't if/else an expression in other languages that just yields a value?! That's a powerful idea.

> Have other languages done this before?

LISP. For a more recent example, Rust.

It's very common for languages to adopt an everything-is-an-expression concept, and then make if/else the conditional operator.

Nim does this as well. Almost any block statement (including creating a new scope with `block`) can be put on the right hand side of an assignment. Whatever value is returned from the block is the result of the expression. All lisp inspired, of course, but with a Pythonic syntax.

> Have other languages done this before?

Well, yeah, Scala obviously, the primary language from which Kotlin drew inspiration for its syntax and features.

I wonder why people don't frame Kotlin as the middleman that takes the good parts of both Java and Scala.

Ocaml does this too.

Rust has this, as well as some other nice ML-inspired[0] features, like structured bindings.

That’s one thing I like about Rust: it fuses functional and imperative styles very naturally.

[0] “ML” here meaning the family of languages including SML and OCaml, which inspired (to varying degrees) Haskell, Rust, some parts of modern C++, and surely others. Not “machine learning”.

On the contrary, I consider the "Elvis operator" to be one logical operation: give me this value, or the other one if this one is invalid. What's the more terse way to write the example with a ternary operator?

One obvious advantage of the "if-else" approach is using indefinite "else if" conditions rather than just one "else"

It feels like a common sentiment that concise code == good code

That's true, and Kotlin definitely leans into it, but extremely concise code basically ends up looking like Brainfuck -- lots of symbols jammed together and hard to read.

To be more precise, I would say that expressive code == good code

As long as expressive doesn't mean too terse and somewhat readable to most...lest you commit perl's sins.

Yeah. This was the point I was halfheartedly making -- concise code for the sake of concise code is a dogma that needs to go away.

Well, more to the point - bugs / LOC is remarkably constant in real code across coding languages, so one of the best things you can do is reduce LOC.

You're missing the fact that the constant factor differs between languages. The density (bugs per LOC) of memory handling bugs is much different in Rust than in C.

Nope.

https://softwareengineering.stackexchange.com/questions/1856...

The link you gave confirms what I've said here.

> The quote is either wrong or outdated. In the second edition, it's on page 521: "Industry average experience is about 1 - 25 errors per 1000 lines of code for delivered software. The software has usually been developed using a hodgepodge of techniques.

1-25 is not a single number - it is a range.

APL may be a counterexample, at least when trying to understand what you have written a few months later.

Well: less code means less bugs doesn't it?

Reply on news.ycombinator.com