Why Kotlin is my next programming language (2015) • Hacker News Board

Re: Why Kotlin is my next programming language (2015)

#181

Post by lmm » Thu, Jun 30, 2016, 3:19 PM UTC

winstonewert wrote: post #180

lmm wrote: post #179

Earlier quoted context omitted.

Even in Java it's possible (but it's not a great environment to learn these techniques in - they usually end up being very verbose when expressed in Java) .

I don't know. The pure fact I can't be sure I won't have NullPtrExceptions in java code would make it pretty hard to accept not writing those tests.

If you always declare object fields as final then you're forced to initialize them in the constructor, so there's no risk of null there. Reading a field in the constructor should be a red flag, as should literal null in your code. Local variables should of course be final too. At that point you only need to check for null around library calls. I'm not sure how much a test actually helps with that - if you don't think of the possibility that a library call might return null then you wouldn't write a test for it either, if you do think of it then you wrap the call in a null test in the same line (don't try to get clever and store possibly-null values in variables).

Re: Why Kotlin is my next programming language (2015)

#182

Post by winstonewert » Thu, Jun 30, 2016, 6:57 PM UTC

lmm wrote: post #181

winstonewert wrote: post #180

Earlier quoted context omitted.

I don't know. The pure fact I can't be sure I won't have NullPtrExceptions in java code would make it pretty hard to accept not writing those tests.

If you always declare object fields as final then you're forced to initialize them in the constructor, so there's no risk of null there. Reading a field in the constructor should be a red flag, as should literal null in your code. Local variables should of course be final too. At that point you only need to check for null around library calls. I'm not sure how much a test actually helps with that - if you don't think…

> if you don't think of the possibility that a library call might return null then you wouldn't write a test for it either

No, I don't think so. I'll write a test that uses the library. If the library returns null when I don't expect it, it'll go into my code an cause an exception to tbe thrown. I'm not deliberately testing for nulls, I'm testing generally that my code does what I think it does.

Re: Why Kotlin is my next programming language (2015)

#183

Post by lmm » Fri, Jul 01, 2016, 11:08 AM UTC

winstonewert wrote: post #182

lmm wrote: post #181

Earlier quoted context omitted.

If you always declare object fields as final then you're forced to initialize them in the constructor, so there's no risk of null there. Reading a field in the constructor should be a red flag, as should literal null in your code. Local variables should of course be final too. At that point you only need to check for null around library calls. I'm not sure how much a test actually helps with that - if you don't think…

> if you don't think of the possibility that a library call might return null then you wouldn't write a test for it either No, I don't think so. I'll write a test that uses the library. If the library returns null when I don't expect it, it'll go into my code an cause an exception to tbe thrown. I'm not deliberately testing for nulls, I'm testing generally that my code does what I think it does.

> No, I don't think so. I'll write a test that uses the library. If the library returns null when I don't expect it, it'll go into my code an cause an exception to tbe thrown. I'm not deliberately testing for nulls, I'm testing generally that my code does what I think it does.

The kind of library function that returns null doesn't usually return it on the "happy path", it usually returns null for some weird condition you haven't thought of. I mean, if it's a function that returns null often or that you'd expect to sometimes return null, you'll wrap up the return value in an option straight away even without having written a test. The kind of library function that causes you to get exceptions in production is the kind that returns null in some weird corner case - but unless you think of the weird corner case, you wouldn't hit it in a test either.

If I was using a library with some complex stateful interface I might write tests for the interaction with that (I'd probably put a facade on it, keeping it separate from the business logic, and the facade would have unit tests) - but I'd try to avoid using such a library. And I'll always have a few high-level end-to-end tests (not really "unit" tests) as a basic "does it work at all", because that kind of mistake is easy to make. But the bread-and-butter unit tests that I wrote when I worked in Python just don't seem valuable or necessary.

Re: Why Kotlin is my next programming language (2015)

#184

Post by winstonewert » Fri, Jul 01, 2016, 3:36 PM UTC

lmm wrote: post #183

winstonewert wrote: post #182

Earlier quoted context omitted.

> if you don't think of the possibility that a library call might return null then you wouldn't write a test for it either No, I don't think so. I'll write a test that uses the library. If the library returns null when I don't expect it, it'll go into my code an cause an exception to tbe thrown. I'm not deliberately testing for nulls, I'm testing generally that my code does what I think it does.

> No, I don't think so. I'll write a test that uses the library. If the library returns null when I don't expect it, it'll go into my code an cause an exception to tbe thrown. I'm not deliberately testing for nulls, I'm testing generally that my code does what I think it does. The kind of library function that returns null doesn't usually return it on the "happy path", it usually returns null for some weird condition…

I think you are assuming saner code then I'm used to.

Honestly, I can't say how it would work if I was using a java code base that consistently applied these kinds of ideas. You may be right, but at this point I have hard time believing.

Re: Why Kotlin is my next programming language (2015)

#185

Post by lmm » Sun, Jul 10, 2016, 8:44 PM UTC

winstonewert wrote: post #184

lmm wrote: post #183

Earlier quoted context omitted.

> No, I don't think so. I'll write a test that uses the library. If the library returns null when I don't expect it, it'll go into my code an cause an exception to tbe thrown. I'm not deliberately testing for nulls, I'm testing generally that my code does what I think it does. The kind of library function that returns null doesn't usually return it on the "happy path", it usually returns null for some weird condition…

I think you are assuming saner code then I'm used to. Honestly, I can't say how it would work if I was using a java code base that consistently applied these kinds of ideas. You may be right, but at this point I have hard time believing.

I've worked on some bad codebases. You can convert a little bit at a time, treating the remainder of the codebase as a large library with a poorly factored interface. You absolutely will need unit test coverage at the boundary, which will probably exist for several years.