Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Kotlin is my next programming language (2015)

medium.com

Post reply on HN
Print view View original

171–180 of 185 posts

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

#171

Post by winstonewert »

sanderjd wrote: post #169
winstonewert wrote: post #142

Earlier quoted context omitted.

I find this to be a rare case. Of course, YMMV. But I don't see or write tests in dynamic languages that verify behavior when I pass an inappropriate type. I trust that it'll produce an error when it tries to use operations that the type doesn't support.

Maybe I'm misunderstanding you, but it sounds like you mean that you trust it to produce that error when it's running (ie. in production). If that's the case, couldn't you do the same for all kinds of bugs and not bother writing tests at all? Put another way, what is different from this class of bug, which you don't think is worth testing, and other classes of bugs, which it sounds like you do?

Primarily specificity.

I want the function to fail when it is passed the wrong arguments, but I don't really care about how exactly it fails. If the wrong types get passed to a function, I'm already screwed and there's no way to do the right thing at that point. I only care that I get enough information to debug what happened.

In pretty much any other case, I want to function return some precise value or do some precise action. These are situations that the code will encounter during normal execution, and so I do care about what exactly it does.

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

#172

Post by bbcbasic »

winstonewert wrote: post #143
mac01021 wrote: post #101

Earlier quoted context omitted.

And you don't need tests to make sure the assertions are there?

Do you need a test to verify that your compiler correctly checks the type signature? (Actually, that could be occasionally useful in the face of implicit conversions)

You can't get true 100% coverage* on digital hardware. (on quantum maybe!) so what to test or not is always a judgement call. Most of the time I'd assume the software stack is trustworthy but if you are doing something extreme you may want to test the compiler or even formally prove the compiler works as expected.

* true as in all possible inputs and outputs rather than merely all code paths

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

#173

Post by winstonewert »

sanderjd wrote: post #170
dmichulke wrote: post #36

Earlier quoted context omitted.

I address this problem by checking the type at run-time via an assertion. Depending on where you are in the security vs efficiency spectrum, you may opt to ignore those assertions in production. Writing specific tests for that looks very inefficient to me but maybe I am missing something.

For sure, and if you're someone who loves runtime assertions for type mis-matches, then I think you'd really love static type assertions, which are basically the same thing, but checked earlier, making bugs they find cheaper. I agree that writing specific tests for that is very inefficient, and that few people (myself included) actually do it. I just also think the fact that people don't really write tests for a (ane…

So, wait, what exactly is the common source of bugs? How does writing tests passing the incorrect types to function help catch them?

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

#174

Post by winstonewert »

bbcbasic wrote: post #172
winstonewert wrote: post #143

Earlier quoted context omitted.

Do you need a test to verify that your compiler correctly checks the type signature? (Actually, that could be occasionally useful in the face of implicit conversions)

You can't get true 100% coverage* on digital hardware. (on quantum maybe!) so what to test or not is always a judgement call. Most of the time I'd assume the software stack is trustworthy but if you are doing something extreme you may want to test the compiler or even formally prove the compiler works as expected. * true as in all possible inputs and outputs rather than merely all code paths

Perhaps a better way to ask my question: do you write a test to make sure your type signature was correct?

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

#175

Post by lmm »

winstonewert wrote: post #168
lmm wrote: post #167

Earlier quoted context omitted.

> But this is the generic facility for database access. This is just an additional special case it has to handle. Presumably it would be using a lower layer - or more likely an existing library - for doing the actual query though? > I could filter on the wrong column, Not if you've got a typed representation of which column's which > with the wrong operator, Not if equality is the only operator available. This is one…

> I started out thinking the same thing (I moved from Java/Python to Scala). Ah, Scala. I could be prepared to believe that this is true for Scala (and similarly advanced typed systems). It is when people claim they write fewer tests in java than in python that I found it really dubious. > Yeah, happy to if you're interested. It's a useful exercise in thinking it through for myself as much as anything. Ok here's anot…

Yep. Ensuring something is valid is a great fit for use of types - you make sure that the type is inherently valid and it's impossible to construct in an invalid state.

For 1., you could have a non-zero number type, or you could settle for a check in the JobExtra constructor. For 2., it sounds like this is a coproduct situation - a JobExtra is either certifiedFormanRelated or has an appliedPercentage. Scala doesn't quite have native support for coproducts the way it does for tuples, but you could represent it with a sealed class hierarchy:

    sealed trait ForemanOrPercentage
    case class ForemanRelated() extends ForemanOrPercentage
    case class AppliedPercentage(value: Decimal) extends ForemanOrPercentage
or being a bit lazier you could just use an Option[Decimal] and say that if it's Some it's the applied percentage and if it's None then it's certified foreman related.

In Java there isn't a "sealed" keyword, but you can emulate it with the visitor pattern - you'd define a ForemanOrPercentageVisitor and only ever operate on ForemanOrPercentages via the visitor. That way if someone creates their own subtype of ForemanOrPercentage it still has to behave like one or the other, because they still have to implement visit().

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

#176

Post by winstonewert »

lmm wrote: post #175
winstonewert wrote: post #168

Earlier quoted context omitted.

> I started out thinking the same thing (I moved from Java/Python to Scala). Ah, Scala. I could be prepared to believe that this is true for Scala (and similarly advanced typed systems). It is when people claim they write fewer tests in java than in python that I found it really dubious. > Yeah, happy to if you're interested. It's a useful exercise in thinking it through for myself as much as anything. Ok here's anot…

Yep. Ensuring something is valid is a great fit for use of types - you make sure that the type is inherently valid and it's impossible to construct in an invalid state. For 1., you could have a non-zero number type, or you could settle for a check in the JobExtra constructor. For 2., it sounds like this is a coproduct situation - a JobExtra is either certifiedFormanRelated or has an appliedPercentage. Scala doesn't q…

I don't think that works for me.

Since the user input modifies this object, the user can put the object into an invalid state. In fact, when the object is first created it is in an invalid state. So I can't simply define my types so that invalid state is impossible.

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

#177

Post by lmm »

winstonewert wrote: post #176
lmm wrote: post #175

Earlier quoted context omitted.

Yep. Ensuring something is valid is a great fit for use of types - you make sure that the type is inherently valid and it's impossible to construct in an invalid state. For 1., you could have a non-zero number type, or you could settle for a check in the JobExtra constructor. For 2., it sounds like this is a coproduct situation - a JobExtra is either certifiedFormanRelated or has an appliedPercentage. Scala doesn't q…

I don't think that works for me. Since the user input modifies this object, the user can put the object into an invalid state. In fact, when the object is first created it is in an invalid state. So I can't simply define my types so that invalid state is impossible.

If your object has distinct possible states, maybe it should be two different objects. I don't think of user input as modifying my object (after all, this kind of object should be an immutable value) - rather I think of mapping my object to a set of form fields and mapping a set of form fields into a new object. (This goes well with having a component hierarchy model - just as my object is a value made of simpler values, its corresponding editor form is made of simpler editor forms). So I'd only create the (domain-level) object when the user's provided the right input to create the object. If you need a model of the user input in code, that's fine, but make that its own distinct type - then you have a single point at which to do validation, and the types make it very clear whether a given value is a business object (in which case it is necessarily valid) or unvalidated user input.

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

#178

Post by winstonewert »

lmm wrote: post #177
winstonewert wrote: post #176

Earlier quoted context omitted.

I don't think that works for me. Since the user input modifies this object, the user can put the object into an invalid state. In fact, when the object is first created it is in an invalid state. So I can't simply define my types so that invalid state is impossible.

If your object has distinct possible states, maybe it should be two different objects. I don't think of user input as modifying my object (after all, this kind of object should be an immutable value) - rather I think of mapping my object to a set of form fields and mapping a set of form fields into a new object. (This goes well with having a component hierarchy model - just as my object is a value made of simpler val…

I see now.

That's very interesting, and shows how types can go much further then what we see in languages like Java. I'll have to try out one of these languages some day and see how well it works in practice.

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

#179

Post by lmm »

winstonewert wrote: post #178
lmm wrote: post #177

Earlier quoted context omitted.

If your object has distinct possible states, maybe it should be two different objects. I don't think of user input as modifying my object (after all, this kind of object should be an immutable value) - rather I think of mapping my object to a set of form fields and mapping a set of form fields into a new object. (This goes well with having a component hierarchy model - just as my object is a value made of simpler val…

I see now. That's very interesting, and shows how types can go much further then what we see in languages like Java. I'll have to try out one of these languages some day and see how well it works in practice.

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) .

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

#180

Post by winstonewert »

lmm wrote: post #179
winstonewert wrote: post #178

Earlier quoted context omitted.

I see now. That's very interesting, and shows how types can go much further then what we see in languages like Java. I'll have to try out one of these languages some day and see how well it works in practice.

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.
Post reply on HN