Hacker News Reader

Comment by Scene_Cast2 | Hacker News Reader

I tried Kotlin during the Surprise Language round of Codeforces, a programming competition.

I found it to be more verbose than a typical modern scripting language. Maybe it's the result of choosing the least of the evils for what it's trying to accomplish.

The other drawback: the documentation. Kotlin's reference documentation (looking up how to properly use a call) does not have any examples. I'm not even talking about full compilable examples - although that would be nice, it doesn't even have one-liner examples. FWIW, I was trying to look up how to use a comparator to sort a MutableArray<Int,Int>.

View on HN

Personally I don't much mind the added verbosity, coming from Ruby/Python/JS, so long as I don't have to write so many damn tests. Speaking from minimal experience, Kotlin still seems like a big net win here. Same is true of other languages with lightweight, static type systems like TypeScript/Flow, Swift, and Go.

I agree about the documentation – I think it's one of the biggest reasons the language has seen such little adoption given its benefits.

I couldn't even find how to integrate Kotlin files into a Java project without using IntelliJ. Kotlin is developed by Jetbrains, so of course they're used to IDE-driven-development, and have a financial stake in people using their products for development. But coming from scripting languages, this sort of documentation gap was a real turn-off for me.

What is it that makes you not having to write so many tests?

A decent type system

Static typing.

Is the reasoning that you then don't have to test what happens if you pass a parameter of the wrong type to a function?

The compiler guarantees it won't happen. Such a test would be a test of the compiler and in my opinion unnecessary. And in Haskell at least... impossible. You can't write the the test because IT won't compile!

I understand that. My question is if that is the kind of tests that people have in mind when they say that static typing requires fewer tests.

I can't speak for anyone else but I believe so yes.

Yes. When writing JS you have to explicitly do a lot more validation.

Without looking, I'm guessing static typing.

> I couldn't even find how to integrate Kotlin files into a Java project without using IntelliJ.

I would suggest (and I'm not trying to bag on you with this) that this concern is more your unfamiliarity with the JVM than a failure of Kotlin, which is generally targeting Java and Scala developers. Kotlin operates pretty idiomatically in the Java universe and, as an experienced JVM developer who's comfortable with all of Maven, Gradle, and SBT, I dropped Kotlin into a Maven project, side-by-side with Java, with a cursory glance at the documentation--"oh, it's another pre-compile-step thing". (Which I then consume via IntelliJ, because IntelliJ imports Maven projects nicely, but Maven allows others to use their IDE of choice.)

The pre-compile-step thing sucks, I'll be the first to say that, and it's a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably. I prefer to use multi-module Maven projects and separate out Java and Kotlin--or Scala, for that matter--code into separate ones. But that's a different beast entirely from the initial bootstrap when learning.

> your unfamiliarity with the JVM

Correct!

> a problem with multi-language, multi-compiler projects that none of the major build systems on the JVM really handle admirably

A bummer to hear – though I'm glad it's not just me. I tried using Kotlin with the Play Framework and did not have a great time. The hot-reloading features of Play didn't work with Kotlin at all, even with my attempts to `touch` a Java file whenever my Kotlin file changed (presumably they're recompiling more intelligently than I was).

Perhaps having SomeController.java and SomeController.kt in parallel, where the former imports the latter, and receives a `touch` or similar whenever the Kotlin file changes, might work? Or would you recon such a project to be a fool's errand?

Play isn't built for Kotlin and SBT is kind of a tire fire in general. I would suggest something more like Dropwizard for use with non-Scala JVM languages.

Or Spring Boot, which is fantastic.

I've never used Spring Boot - feel like plugging it a little? Dropwizard is the de facto in my neck of the woods, but I'm always looking for an improvement.

Thanks for the tip! Looks like there's even a starter example: https://github.com/doomspork/kotlin-dropwizard/

I agree the documentation needs work and I am using Kotlin in prod. JetBrains please take note!

Could you please elaborate on what needs improving in the docs?

Btw, the whole kotlinlang.org is OSS, and you can correct things you don't

What sort of tests don't you end up writing? I ask because I work in both dynamic and static languages, and find myself writing very similiar tests in each case.

Tests that verify the behavior of functions when they are passed data of a type that does not support the behavior that the function expects to be supported. I find this to be a very common case.

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.

I don't see how this reduces the need for a test that the wrong type is handled correctly.

The underlying idea is that it shouldn't handle the wrong type at all, it should fail.

If some function A calls function B with a wrong type, the problem is with function A. So basically, there should be only type tests after IO functions (probably after parsing), the rest can be assertions.

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

Interesting point :)

At some point you have to assume something is there and correct (e.g., you don't write tests to check whether the tests are there, also you assume the testing tools work, ...).

In static languages you also assume the programmer set the right type for the function argument, so you might as well assume to have an assertion in the critical code of the functional languages.

> At some point you have to assume something is there and correct

If you excel at compositional design then this may work OK but a lot of code bases I have worked on just need a good ol' refactor to sort the mess out. And then the "there and correct" part could fail due to human error, or the new person not knowing the old assumptions etc. The asserts are a step in the right direction in documenting the assumptions though. Types go one level better by both documenting the interface, and enforcing that contract at compile time.

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)

My compilers have test suites.

And the compiler that generates the assert also has a test suite for that.

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?

Yes, you are missing a statically typed language. Tests or assertions? Neither. Security or efficiency? Both.

The grand-grandparent of your comment talked specifically about tests in static vs. dynamic languages.

Your comment just solved the problem by ignoring the latter, not much of a contribution to say the least.

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 (anecdotally) common cause of bugs, and instead wait to see them in their production logs, is an anti-pattern, rather than a positive thing.

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

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.

You might find https://spin.atomicobject.com/2014/12/09/typed-language-tdd-... enlightening (note that in modern typed languages there's a lot less overhead to using type technique than there is in Java - but even in Java you can do some of this stuff)

I'm afraid I found it confused.

For the tests the check types of values, that's just a dumb test that you shouldn't write regardless of the language.

Then for rest of the post, he talks about having nicely-defined tests which is orthogonal to whether or not your types are static.

> For the tests the check types of values, that's just a dumb test that you shouldn't write regardless of the language.

The thing is, almost all the tests you'd write in a dynamic language end up being something you can encode into the types of values.

Almost all? That just sounds plain ridiculous.

Can you actually give an example of a test that would be realistically written in a dynamic language that would be something encoded into the types of values?

You give me an example of a test that would realistically be written in a dynamic language then. I've been out of dynamic languages for so long that I've forgotten how to produce working code in them (seriously, I tried to write some Django because I used to be quite good at it and it seemed like a good fit for a specific problem, and I just wrote code that had stupid bugs everywhere).

Here's a test I wrote recently. The code in question is part of a nodejs service that talks to a database and produces json objects to be used by a web client application.

There is a definition for the schema to a fruit table.

    Fruit: {
        list_id: 32
    }

The list_id indicates that this isn't a real table, but is actually stored in the list_options table. So my code has to generate a different query then for a normal table.

The actual options are populated from a list:

    const LIST_OPTIONS = [
        [32, "Blueberry", 1],
        [32, "Apple", 2],
        [32, "Orange", 45],
        [45, "Nope", 1]
    ]

These get inserted into the database. Note that the first column is the list_id from the schema.

And for the actual test:

This actual sends the request to be processed.

       let response = await processRequest({
           type: 'QUERY',
           table: 'Fruit',
       })

Then I assert that the respone is exactly what I thought it would be:

      deepStrictEqual(response, {
           status: 'OK',
           records: [{
                id: "Blueberry",
                name: "Blueberry",
                position: 1
           }, {
               id: "Apple",
               name: "Apple",
               position: 2
           }, {
               id: "Orange",
               name: "Orange",
               position: 45
           }]

I would have written pretty much the exact same test if it were a statically typed language.

Ok, good example on some levels, though it's doing a lot of interfacing with untyped parts. In a real-world scenario I would be looking to extend the type safety by using thrift or similar rather than json, and ideally a strongly typed datastore (for a static list like this, probably plain old code rather than a database).

That aside, what pieces could actually go wrong in a statically typed language? You can't typo field names or the like. You could typo the names, but I don't believe typing them into the computer twice adds value - better to check them once in code review. People aren't going to be editing this code in a way that could lead to getting the names wrong.

You couldn't go down the wrong code path and end up with the "normal table" query, because having list_id instead of something else is part of the type. You couldn't pass some other number as the list id, because list ID is a typed thing that is different from all other IDs, and in any case where would an outside number come from? And you're definitely going to return a response that's formatted with a record list, because that's part of the type of the method. (You might need to test the JSON <-> String piece, but that's generic, so you only need an O(1) test for that, you don't have to test every JSON endpoint. In practice you're likely using an existing well-tested library. Similar reasoning applies to the database querying part). Assuming you have warn-for-unused-parameters enabled, you couldn't forget to apply the criterion and just return everything in the list.

So yeah, assuming this was for part of an existing system where I'd already tested generic facilities like database access and JSON serialization, I wouldn't feel the need to write this test at all.

> So yeah, assuming this was for part of an existing system where I'd already tested generic facilities like database access and JSON serialization, I wouldn't feel the need to write this test at all.

But this is the generic facility for database access. This is just an additional special case it has to handle. Does that change your perspective on whether you would write a test for it?

> That aside, what pieces could actually go wrong in a statically typed language?

Well, I could type the SQL wrong, but let's assume we are working in a sufficiently awesome statically typed language that would catch that kind of error.

I could filter on the wrong column, with the wrong operator, with the wrong value, on the wrong table. I could decode the name column using the wrong encoding. I could return multiple rows per option. I could do a huge number of other things that I couldn't think of. These may not be really likely to be mistakes I'd make (this is a pretty simple task), but several refactorings down the line, I can easily see an issue being introduced.

At the end of the day, even in a statically typed language where much of the functionality would be verified by the compiler, I'd still like to have a test on this.

> Ok, good example on some levels, though it's doing a lot of interfacing with untyped parts

Hmm... the fact that it deals with the boundary of the system and the fact that it deals only with converting data from one format to another might render it a poor sample (i.e. there's not really much interesting logic). I can come up with another if you are interested.

> 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 of my biggest reasons for using wrapper types around IDs - you shouldn't treat IDs as integers, because the idea of adding or multiplying or <=ing an ID makes no sense.

> with the wrong value,

How? You have to use the passed ID for something, and it can't do anything else.

> on the wrong table.

So make the table part of the type. A list ID is a different thing from a user ID, they shouldn't be compatible.

> I could decode the name column using the wrong encoding.

Encoding should absolutely be handled with types.

> I could return multiple rows per option.

Hmm, maybe. But I can't see how you'd do that by accident.

> At the end of the day, even in a statically typed language where much of the functionality would be verified by the compiler, I'd still like to have a test on this.

I started out thinking the same thing (I moved from Java/Python to Scala). I've gradually reduced the amount of tests I write over four years as I've found them to not add value. I was as surprised as anyone, and even privately entertained the thought that maybe I was some kind of super-programmer who was smarter than all those people who needed tests, but that month or two of trying to do stuff in Django made it very clear that it wasn't me, it was the language.

> Hmm... the fact that it deals with the boundary of the system and the fact that it deals only with converting data from one format to another might render it a poor sample (i.e. there's not really much interesting logic). I can come up with another if you are interested.

Yeah, happy to if you're interested. It's a useful exercise in thinking it through for myself as much as anything.

> 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 another test:

These are action objects, they represent a sequence of user actions on a JobExtra.

        const actions = [
            JobExtra.actions.load(undefined),
            JobExtra.actions.field('changeAmount', Money.actions.set(new Decimal("12.45"))),
            JobExtra.actions.field('certifiedForemanRelated', Checkbox.actions.set(true)),
            JobExtra.actions.field('appliedPercentage', Percentage.actions.set(new Decimal("4.5")))
        ]

I construct the final state by reducing across all those actions

        const state = _.reduce(actions, (state, action) => JobExtra.reducer(state, action), undefined)

I verify that the job extra is considered valid afterwards.

        strictEqual(true, isJobExtraValid(state))

To be considered valid:

1. The changeAmount must be set to non-zero 2. The certifiedFormanRelated must be false or the appliedPercentage must be true

But, if the user modifies the appliedPercentage, the certifiedFormanRelated should be automatically set to true.

So this, and a number of related tests verify that under different sequences of actions I end up the result I expected.

Is there a way to push this into the type system?

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

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.

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.

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

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

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.

Absolutely. Dynamic languages only seem terse because you don't see all the associated test code inline. I've been programming in a mix of dynamic and statically typed languages for more than 15 years now and I'll take a modern statically typed language over a dynamic language any time if I have my choice.

It's a lot harder to design a static type system that's both expressive enough to be pleasant to use and strict enough to be useful. But we're getting there in modern languages like Rust, Kotlin, Swift etc.

"integrate Kotlin files into a Java project without using IntelliJ" - compilation of a mixed project is not a trivial tasks, many things must be set up. A detailed description of this takes a chapter in a book.

That's the reason one should use build tools, be it Ant, Maven, or Gradle. The process of setting them up without an IDE is narrowly described in the docs https://kotlinlang.org/docs/tutorials/build-tools.html

From what I understand Kotlin is the language that was designed to be used in house by JetBrains to simplify their Java code. It wasn't born to be the revolutionary, just practical for Java developers.

The Kotlin reference is not supposed to be used for finding methods.

The way to go is to use auto completion in an IDE. If you type `myArray.sort<ctrl+space>`, you get all one needs, including `sort`, `sorted`, `sortBy` (which you needed).

Alternatively you could search the reference page for Array or MutableList or MutableMap, not sure what you wanted: https://kotlinlang.org/api/latest/jvm/stdlib/kotlin/-array/ https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collecti... https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collecti...

I had something like this:

    var heights: Array< Pair<Int, Int> > = ... //populating the array
    heights.sortBy { it.second };

It was not obvious at all that I had to use curly braces. The documentation says:

    inline fun <T, R : Comparable<R>> MutableList<T>.sortBy(
    crossinline selector: (T) -> R?) (source)

This is after I figured out that I'm not supposed to use sortWith (I never figured out how to use this one)

The curly braces are the syntax for lambdas, one of the basic types `(T) -> R?`. There are plenty of examples for using that, but in the respective chapters: https://kotlinlang.org/docs/reference/lambdas.html#higher-or... or in this bunch of examples: https://kotlinlang.org/docs/reference/idioms.html#filtering-...

The docs are arranged in a way that one reads them in the order they are written (at least the first half). I supposed that would take more than half an hour given at the competition.

I don't think Kotlin is the best choice for programming challenges like codeforces - they really don't let him shine (although I use it whenever I can). But if this is a valid case, we can collaborate and write a short tutorial for C/C++ to Kotlin programmers.

Oops, copied the wrong snippet out of the two:

    inline fun <T, R : Comparable<R>> Array<out T>.sortBy(
    crossinline selector: (T) -> R?) (source)

For those who want docs in the examples, perhaps "liking" my post regarding this on the kotlin discussion forum would help:

https://discuss.kotlinlang.org/t/examples-in-the-api-docs/16...

Reply on news.ycombinator.com