Hacker News Reader

>Kotlin (1.0) works well with everything and is relatively succinct except for Mockito due to everything defaulting to 'final' - but it appears that Kotlin 1.1 fixes this with a compiler plugin.

It's worth pointing out that since Mockito 2.0, you've been able to opt into mocking final classes, making testing Kotlin pretty painless.

https://github.com/mockito/mockito/wiki/What's-new-in-Mockit...

Curious, if you were aiming at writing in a functional programming style, why didn't you try Clojure?

If I may jump in, here, for my 2 cents, I've never developed anything commercial with Closure, but I learned it, have played with it and have quite enjoyed it. Having never done any Lisp(-based language) programming before it didn't come... naturally. My guess is that the parent commentator didn't include it for that reason.

It doesn't have compile-time type checking. When many people say functional code they really mean code that can be and is strictly type checked at compile time. Clojure is functional, but it's not what most people want when they say "functional".

"It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." —Alan Perlis

Functional style in my opinion is about creating functions that operate on standardized data structures. Class based type systems actively discourage functional style, even when the language gives you a functional veneer over your OO code.

Haskell avoids this problem by using algebraic data types instead of class style types. Clojure avoids this problem by using dynamic typing.

I definitely do not associate 'functional' with static typing.

Type-checking doesn't really have any bearing on weather a language is functional. Functional languages can be statically or dynamically typed.

It's one of the big differences between the lisp and ml types of functional languages I would say. Other than the parentheses that is of course :)

I've never been comfortable doing big projects - multiple files, more than a few hundred lines of code - in a dynamically typed language. It's the same reason were seeing the big uptake of typescript. Statically typed languages give us so many superpowers when we need to do refactoring or any changes at all to an existing codebase. Just changing a function name in a dynamically typed language can be hell. Rearranging the parameter order is even worse, cause you have such trouble finding all of the function uses and where you need to update. With statically typed languages you get editor support for simple stuff like this and it becomes automatic and a push of a button almost.

Static typing is great. My point is that whether a language is statically or dynamically typed has no bearing on whether it is functional.

What functinal techniques did you use? Only higher order functions or did you go all the way to applicatives, monads (maybe even free) etc.?

btw: is the source code available somwhere? Would be interesting to see a comparison between the languages.

I'm interested in the comparison code as well if it's available.

> The Scala 2.12 compiler has at least one bug that appears to affect its interaction with Java 8 lambdas (in particular, in at least one case expr.method() and (expr).method() will not pass the compiler's typecheck

There are many many things that should be valid Scala but are not, due to type check limitation. All kinds of times you should be able to infer the type, but the compiler cannot and you have to start naming types. Not sure this is really a "bug" but more of a wart. Sure is annoying when they happen, but not a "unique" thing to Java8 lambdas by any measure.

> all within a single Gradle project. [...] Groovy [...] worked with everything, though.

Given that Gradle was originally designed with Apache Groovy as its only language for writing its build config files, I'd say you should try again with the build system relevant to each language, such as SBT for Scala, Leiningen for Clojure, etc.